Monthly Archives: June 2010

Seeing is Believing: Why Prototyping is Worth the Time

This week I was joined by a former colleague who previously helped work on a story-based course similar to the one we are trying to design.  The previous course had no game elements and was targeted at the general university student rather than at the middle school level, but the design of the art and story could be similar for these two projects.  While we had a few ideas for the story and individual game segments prior to his arrival, bringing him in really jump-started the project and helped flesh out many ideas for the story and gameplay.  More important than the help of another person, though, was seeing prototypes for ideas that we had previously only talked about.

The first example of this came when my colleague decided to mock-up a martian landscape.  We had been discussing using a martian landscape with a space station as the main setting for weeks.  Seeing the basic landscape allowed me to consider the finer details of the scene instead of just the big picture.  It also assured that the picture in everyone’s mind for this space station was nearly identical, rather than the unlimited possibilities we leave open by simply discussing it and not having any visual representation.

The second major breakthrough came when I was able to convince my boss that having controllable 3D characters was a perfectly reasonable possibility for this game.  At one point, we were debating having much of the story happen through comic strip-like interludes with text possibly supplemented by movies.  But with Unity, I found it was not much of a challenge to put together a control and camera scheme for any 3D model that we have.   I thought perhaps my boss was simply more fond of the movies/comic idea than having controllable characters until I showed her a demo with a controllable character having a discussion with an NPC (non-playable character).  She then informed me that she previously was concerned that controllable characters would have taken more time than we would be able to allocate.

Giving visual representation to ideas can serve two purposes in software design (games or otherwise):

1.  It gives your team a unified representation of the visual object you are discussing.

2.  It proves that the idea can be put into action.

In creating the dialogue between the playable character and the NPC, I presented a basic paragraph about Mars (borrowed from the wiki entry), then presented the user with a question and the ability to offer 3 answers, each with its own response from the NPC.  While the code for this would be quite inefficient for a larger dialogue, I have proven that dialogue between characters can be done in a short time. While I’ll need to tackle the dialogue problem in the near future, this prototype demonstrated to my boss that player controllable characters can be used to do nearly anything we require in order to convey the story.  With only a few hours of work, I was able to settle a debate we had been having for months.  Even if this wasn’t what we wanted, having this decided for only a few hours of work is certainly worth the small investment.

Software: Mint

I love the idea of Mint.com.  I love that their business model is based on anonymous user data. A one stop shop for all of my financial accounts is an amazing convenience for me;  I have five financial institutions whose online services I use.  Finally, having a product that allows me to plan a monthly budget and keeps track of how well I stick to that budget is amazing.  The idea of Mint is great.  Unfortunately, the execution couldn’t be more disappointing.

Mint has been around since 2006, and in November of 2009 it was acquired by Intuit, the makers of Quicken and Turbo Tax according to Wikipedia. I would expect most of Mint’s major functionality issues to be ironed out after four years of development time and now having Intuit’s design experience. In the 5 months that I have had my account, they have not.

One problem I can easily forgive is Mint’s inability to correctly categorize all of my transactions.  Fine, I get it, you don’t know every retailer and what they do.  Even if you did, what if I wanted to categorize things a different way?  This is not a problem.  What is a problem, though, is how I am supposed to categorize purchases.  While I could keep up with every transaction I make in the Transactions tab, I much prefer to check my spending at the end of each month and make changes there.

To do this, I must click the ‘Planning’ tab, go into a preset category (or the default ‘Everything Else’ category) and see individual purchases in each.  Up to this point I have no problems.  Now I re-categorize something.  Great.  Next, I want to go back and check what that purchase was under ‘Shopping’ that seemed like it might need changed to a more specific category.  Where do I go?  I have to go back to the ‘Planning’ tab, go back into the month I was correcting (the default is the current month, and I am usually correcting the previous month), reopen the category I want to see, and finally check the transactions for that subcategory.  After four or five corrections, it becomes apparent just how awful this interface is.

I want to be clear here that I am not an interface designer.  I’ve been doing some minor interface design for work recently, and it has made me realize just how tedious it can be (should I move this text box 5 pixels left? up?) and how much work goes into making it so the user never thinks about it.  It isn’t a flashy job.  Rarely does someone say ‘you know, the placement on that text box was so perfect.’  More likely it will be ‘Oh yes, that was easy to use, but I don’t know why.’  With that out of the way, this is not a minor interface gripe where I think a box should have been moved or something should have been presented in a different way.  When I go into the ‘Planning’ tab, open a category (or categories), then click through to a specific subcategory to change a transaction, there absolutely needs to be a button that brings me back exactly to where I was.

For a simple example of how this design can ruin a project, imagine if Facebook had a similarly designed interface.  I click on Jack’s profile and want to see what his favorite bands are, so I go to his info.  Now I want to see his wall.  The correct design allows me to simply click that tab and go there.  However, with a design analogous to Mint, I would have to go back to my list of friends and find Jack again before I was able to check a different section of his profile.  As much as I might love to waste time on Facebook, I prefer to do so efficiently.

There are other problems I have with Mint (both major and minor), including the lack of a running tally for my accounts, but these pale in comparison to the clunky interface.  Software is meant to be designed so that users can’t get it wrong.  Mint just doesn’t have the ease of use that would make its product great.  For now, I’ll continue going to my individual financial institution sites until Mint can clean up its act.