Thursday, September 30, 2010

The Lacuna Expanse

The Lacuna Expanse




A guy I know has got a team of people together to develop a new web-based MMOG called The Lacuna Expanse. He describes it as a mix of Sim City and Masters of Orion. It's got a whole array of things to do like developing your colony, venturing off-planet to explore, and engaging in trade, espionage, and war.




The game has been in beta, but I just started playing last week and I'm really enjoying it so far. On top of it generally being a cool game, it's got an open API with which anyone can write their own clients (they currently have the browser client, and an iPhone client on the way) or other tools (you could automate the tasks of resource gathering and storage, etc). They're launching publicly next Monday, but you can get in now and start playing. This means you'll have a leg up on everyone else ;)




The game is free to play, but you can purchase something called "Essentia" (the in-game currency) which can give you a leg up on your development or can be used in trade with other players. If anyone's interested, let me know and I can send you an invite (using an invite code will place you in roughly the same area of the universe as me).




Check out some screen shots below:











Monday, December 15, 2008

Happy Holidays

We just finished up our company holiday card and people have been having a lot of fun with it. It's a Flash-based Snowman creator that lets you create snowmen in a variety of scenes where you can dress them up like paper dolls, add props and greetings, and then save the image to send to friends.

Anyone interested should check out the Hoffman York Snowman Maker.

Here's a few I've seen come through recently...










p.s. I hate Blogger.

Wednesday, November 5, 2008

Wikipedia Needs a Redesign?

Brooke shared a blog post in Google Reader and asked for my thoughts, this is what I shared back to her.



In response to Brooke.

It would be hard for me to disagree more with this post, and here's why...

"Languages more important than search on the front page." -- What an amazingly Anglo-centric way of thinking. Believe it or not, the wikipedia is not an "english language site". There is an English wikipedia and there are wikipedias in numerous other languages. Every article in the wikipedia provides links to the other language versions where that article exists. For the article on "English Wikipedia" there were companion articles in 41 other languages. FORTY ONE! If you are an english speaker/reader, "your" wikipedia lives at en.wikipedia.org. If you're a french speaker, "your" wikipedia lives at fr.wikipedia.org. The domain wikipedia.org is a landing page which provides links to the most popular/active languages of wikipedia. English is by far the "busiest", but to treat English as an assumed universal default sounds like a policy that our soon to be gone administration would enact. It would be arrogance, plain and simple. When the author says "I can't speak for everyone", it's about the only thing that I see them getting right. Before one can begin to search, one needs to know what language one is searching in.

moving along...

"Tiny navigation tabs at the top of the page — that don’t even act as tabs." -- I'm not sure which wikipedia the author was using, but when I go to wikipedia and click on the edit tab, the edit tab is active (joined to the main document) and behaves in a tab-like manner. Whatever extra functionality the author was expecting, I can't imagine, and they've certainly not articulated. This point is pure B.S. Go try it your self and see.

next...

"Tiny search box hidden in the sidebar." -- This person must be a speech writer or something. Hidden? Yes, hidden in plain site is the search bar that I use regularly. Could it be bigger? I suppose. Does it need to be? I can't imagine why. Would I be able to more effectively search with a larger search box? Doubtful. Will some users not like it just the way it is? Obviously. Is that a reason to make some arbitrary change to it? Hardly. I'm not a UX expert, but this seems like a pretty empty gripe.

next...

"Too many links in the sidebar, rendering it useless." -- This makes a quantitative valuation and that absolutely fails to quantify what an acceptable number of links would be. Not only that, but it's not just "too many links", it is, in the authors estimation "useless". The author apparently doesn't use random article (clearly this person has never been bored and needed a way to kill time) among other sidebar links. News flash: just because you don't find a link useful, doesn't mean it's not useful to someone else. This post has slowly been shifting from American/Anglo-centric, to simply Me-centric.

next...

"Confusing icons in the article editor." -- Here's how I read this: "This doesn't look like Microsoft Word". That's true, and I hardly see the point. I would guess that 90% of all wikipedia edits are purely related to copy or link updating/correcting/adding. They are not formatting operations. When you do need to do formatting, you can do it in the document using wikipedia's fairly straightforward (at least for the "simple" things) markup, or highlight things and click buttons. The button icons are not pretty, but they're hardly "confusing". Bold looks like a bold face "B", italics looks like an italicized "I", etc. For those that might seem "confusing", as the author even mentions, there are title tags on the links which will give you mouse over tool tip info; you know, like in Microsoft Office? I could _maybe_ see griping about wikipedia's markup syntax, but complaining about tools that clearly (at least to me) take the guesswork out of applying the basic formatting and markup seems like a real stretch.

and finally...

"No hierarchy of elements." -- I'm not really sure what the author is driving at here. This sounds to me like somebody who's been drinking too much of the Web 2.0 Kool-Aid. Wikipedia essentially mirrors an encyclopedia. It has several pages, it has sections, and sub-sections, and sub-sub-sections. As near as I can tell, wikipedia's documents/data are structured in a perfectly logical way. If this is such an issue, why does the author say, "[...]Wikipedia’s design is just how basic it is, without a clear hierarchy to guide your attention to the more important elements. There needs to be better grouping of items[...]", but not actually enumerate what elements are at issue and what items need to be grouped in what manner? My guess? Because the author doesn't really know.



Everything the author derides and take issue with seems to be fairly subjective and there's essentially no solution provide, just a list of empty bitches. Wikipedia, to my way of thinking, is like Craigslist. Neither site is very pretty (Craigslist even moreso), but they are both incredibly useful. The notion that a site can be fixed via design assumes that people visit sites because they're pretty, and that clearly is not the case. People go to websites for meaningful, interesting content, and both of those sites (CL and Wiki) have got that in spades. Designers go to websites because they're pretty. Web 2.0 interfaces are often about polishing turds to a high gloss finish so people don't notice that you don't actually do or provide anything of value. That said, I will continue reading, and enjoying wikipedia content in it's plain old wrapper, and the original author can resume their apparent career as a turd polisher.”

Tuesday, October 7, 2008

WTF Google?

I'm working on some Google Maps API stuff and was reading up on the MarkerManager in the OFFICIAL Google Maps API blog and clicked on a demo link for a particular mapping technique. It was supposed to be hosted on google.com, but it was missing. I looked at the URL, suspecting that they'd made a typo--but honestly, who types URLs--and it looked OK. I navigated back in my browser and noticed that below the link there was an update note that had been added relating to changes to the API, open sourcing, etc. and that the link was no longer valid.

So lemme get this straight. They took the time to add a note about the link being bad, but didn't.. you know, just remove the offending link, or at least style it as text-decoration: line-through. Put a note after the link that says it's now B.S. so people can read that when they get back to the originating page from the dead link you sent them too, that makes a ton of sense. It's like they're actively supporting link rot; WTF?

Moving right along, I clicked through to the new link to the updated API stuff and navigated the SVN repository to a new sample file which I clicked on and it showed a map with 4 markers on different continents and when a particular marker's location wasn't visible, it showed a small version of the marker along with a chevron shaped pointer showing the direction you would travel in to find the marker. It was clever, and precisely not the thing I was looking for. I looked at the address bar and noticed that now, instead of sending me to dead links, the Google Maps API blog team was simply sending me to the wrong links.

I really dislike when I can't get information, I especially dislike it when I'm given misinformation, be it through incompetence (as I suspect in this case) or genuine malice (as in the case of our Republican VP candidate).

Thursday, October 2, 2008

How I Choose Software

This afternoon I'm trying to take some changes I've been testing local for a really gross IE6 PNG transparency hack/fix and integrate them into a client website where I have to make it all fit with the site's CMS templates.

To make the change, I figured I ought to diff the current code against my new changes and I didn't have a diff installed. In the past, I've used whatever the in-house preferred diff software was, but seeing as how prior to my arrival development at the current job was done in a fairly loose manner we didn't have a standard... well, anything really. So, I decided to find something good, but wasn't really sure where to start.

I started by looking up "diff" in Wikipedia. The article talked about its being a "file comparison" tool, which is apparently the proper name, though they're all "diffs" to me. Anyway, Wikipedia tends to have companion articles for things like categories of software that are named "Comparison of X" where X is the software in question. Anyway, the Comparison of File Comparison Tools (what a great name) article is a big table of features, names, licenses, platforms, etc and allows sorting by any column so I sorted on license and started scanning through all of the GPL applications and checked out the articles on a few.

Ultimately I settled on WinMerge due to features like shell integration and integration with TortoiseSVN--which I'm slowly getting people here to start using. It's a Windows only app, and that's a bit of a turn off, but it was certainly nice to be able to turn to the Wikipedia for a side by side comparison of the tools from a 30,000 foot view.

Friday, August 8, 2008

The Dream

It's 5 minutes until midnight on 8-8-08 as I begin writing this. I just woke up. The weather is surprisingly cool (60F) for August; it's nice. I haven't blogged in a while, I sort of decided it wasn't really my thing, and Blogger being such a P.O.S. hasn't made me very eager to use it frequently.

Anyway, The Dream.

I had The Dream this evening. For those who are not xkcd readers who commit every strip to memory, The Dream--as I'm calling it--is a profoundly revelatory dream relating to functional programming. xkcd #224 deals with the author's eye-opening experience with Lisp, mine happened to be with Scheme.



I used to just like this particular strip because of how it presented Perl as the glue that actually holds it all together, now I've got a whole new appreciation. This particular comic is both funny and deep.

Around 2006/2007, I started to get a bit more serious about programming and wanted to break out of much of the lameness that writing the same sort of .NET code for financial transactions at work was bringing on. I decided, based on a lot of the reading I'd been doing, that I needed to give functional programming a go. I never went past my sophomore year at UW-Madison, and subsequently wasn't exposed to functional programming, assuming it's even part of the curiculum, and had been largely locked into the imperative procedural and object oriented programming paradigms, with a bit of the "a ha" that comes from getting your head properly wrapped around SQL.

Anyway, moving into 2008 I acquired a copy of Guy Steele's Common Lisp the Language, which introduced some interesting stuff, but wasn't really framed correctly for a novice trying to learn the language. I've subsequently found out that it's generally accepted that CLtL is more a book targeted at implementors of Common Lisp. I read that book here and there, for a while, but given the nature of it, my interest faded a bit.

Enter: Peter Siebel's Practical Common Lisp. This book is available for free online, and I read the first 3 chapters there. I so enjoyed how practical (surprise, surprise) the book made Lisp seem, and how it dove right in to writing code (which made it fun), as opposed to swamping you with mathematical theory (which is interesting, but not so much "fun"), that I ordered a copy. I got setup with a SLIME environment and spent a while working through some of the chapters in the book. It was fun, but slowly, I started having some questions, and found I was not getting some fundamentals really "in" my head, and as a result, that project went a bit by the wayside.

I tinkered a bit with Haskell a while back, and it looks neat, and I may explore it more later, but again, I didn't really stick with it. Then, a few weeks ago I was reading about The Little Schemer, which I'd heard of but never really explored. I have a friend who related some of his painful go with Scheme when he was in college and as a result of that, I never had the motivation to check the language out. I recently came across The Little Schemer on Google Books, where it had a few chapters available, and I started reading. I was immediately grabbed by the book's writing style, which was formatted mainly as two columns of question/answer Socratic dialog. The book approached the language, and the ideas of programming, from a somewhat abstract direction I hadn't previously seen. There wasn't a focus on the heavy duty use of the language, or of the history which lead to the language's creation, or even an acknowledgment that what you were reading was a programming "How To". The book just presents the theory of some of the basic building blocks of Scheme (car, cdr, cons, etc) in a simple, whimsical way, and begins giving examples of using those blocks to manipulate lists. You're learning to program without realizing it; it feels like game or a puzzle. Before you know what's happening, you've got a vague notion of S-expressions, and subsequently, atoms, lists, and how you can use them. You're still not doing anything meaningful, but at least for me, there's a sense of something powerful.

Suffice it to say, it's a good book, and I'm currently only 25 pages in.

Anyway, back to The Dream.

I was reading some of The Little Schemer on the porch today after work while drinking a lightly hopped adult beverage and was getting tired. I went upstairs and ended up laying down on the bed. Sometime before 9pm, I fell asleep.

The next thing I knew, I woke up, and had had this bizarre, epiphanous dream. Much like the xkcd comic, the whole tree like, nested lists of Scheme had suddenly clicked and it was as though they made perfect sense and as a result, made the whole world make a bit more sense. It was an experience on par with the sort of eye-opening effects one might get from a strong psychoactive drug. I actually laid in bed in the dark for a bit, trying to process everything from the dream. Slowly waking up and making sense of of it was an ongoing surreal experience. This was as close as I feel I've ever come to anything approaching a religious or spiritual experience. It was really that intense. I'd try to relate the substance of the dream, but it lacked any real narrative, and my putting it into words would likely water it down and fail to convey what it actually said.

There've been a few times in my life--the bulk of which I've now been programming and/or learning to program--that I've had a new understanding that really shifted my perspective. Offhand, I'd say those previously were:
1. First learning programming with GW/QuickBasic and seeing the power of code emerge (sometime around 1990, OMG a loop!?).
2. Taking a data structures class in 1997 (my freshman year in college).
3. Starting to learn Perl in 1997.
4. Beginning to really grok regular expressions (sometime in the early-mid 2000s).
Now, there's a 5th item on that list:
5. Reading The Little Schemer, and beginning to see the elegant simplicity of functional programming.
I've only now been acquainted with Scheme and The Little Schemer for about a week--and I've not yet written a single line of code!--but they've already got a familiarity and affinity for me that's taken years to build with other languages/books, like Perl and Programming Perl.

Thursday, May 22, 2008

Progress status: keeping the user in the loop

I was in-office in Milwaukee yesterday and that means my work laptop gets its weekly reboot. This morning when I sat down to work there was a pending update to Adobe CS3 so I figured I'd kick it off while I drank a cup of coffee. I came back and the updater was still running and indicated it was about 25% complete. I fired up IE to check my e-mail and the Adobe updater complained about IE running, so I killed IE and decided to start the day working from my personal Ubuntu laptop.

After about 20 minutes I VNCed to the work laptop and the progress bar looked the same. I walked over to the machine and sat down. I watched for a minute as the progress bar would make incremental steps forward, and then, as it made incremental steps backward!

I've seen this before, these confused progress bars that seemingly move forward and back as though rewinding time. I've seen the reverse progress bar used by uninstallers which makes some sort of metaphorical sense, but is still, in my opinion, an abuse of a reasonably well understood widget. As I watched, I saw that there were patches being applied to several different parts of CS3 (Flash, Dreamweaver, etc) but there was one lone progress bar.

This made me think of a number of applications I've written that had long running processes that made it easy to let the user keep tabs on their progress and I gotta say, maybe I'm the odd one, but I generally include a ton of information expressed in different ways so I (or whoever is using the software) has a concrete sense of "where we're at".

In a document archiving application I wrote when I worked at Greystone one part of the application could take a large (100+ pages) PDF and strip the individual pages out as TIFFs for processing and later storage. The source PDFs resided on a network drive, and the TIFFs were ultimately stored there as well. Between network overhead and processing, a PDF could take a minute to process on a user's desktop. Not an eternity, but long enough that you want to know that the application hasn't hung. So, when the user was processing a PDF, an always-on-top floating progress bar appeared. The progress bar was small and innocuous but still included some useful information like: percentage complete, pages processed, total pages, pages per second, time elapsed, and estimated time remaining.

Now, I'm sure there are those who would say that's overkill, and in part redundant since most of the values are easily derived from one another, but you know what: it gave a lot of useful information in different formats and it was dead simple to implement. Never did I wonder how far along the process was. Never did I wonder if it had frozen. At a glance I knew exactly what was happening and when I might expect it to be done.

The bottom line is: generally speaking, you can easily determine the progress of your application and meaningfully report that to the user. The Adobe updater is now going on 40 minutes of run time and I still have no clue as to when it might complete.

I would propose a few guidelines as to how we as developers should report status to users:
  • Show a numerical percentage (possibly including one or more decimal places of precision for really long running stuff) along with the graphical bar.
  • Express things in terms of items (items being: pages, kilobytes, whatever-is-relevant-to-you-application, etc) complete and a moving average of items/second.
  • Show the elapsed time and an estimate of time remaining.
  • For processes that are actually composed of separate tasks, have either new, clearly labeled progress bars for each step, or two separate task, and overall process, progress bars.
  • Don't make the progress bar move in reverse; ever.
To me, these things just seem obvious, and it's the kind of stuff I've added to programs going back to my early days of hacking QBasic. It's fairly easy to do for most processes, and the payoff to the user can be huge. If I see my updater says it's going to take an hour, I'll go grab lunch, if it says 45 seconds to complete, I'll probably stick around. The computer ought to be working for me, not the other way around.