This article the 5th installment in of a series titled 'How I build an application'. You can find the other installments and subsection here.

Nothing is more critical then the User Interface (UI) of an application. All things come together in the UI. If your database design is top notch, but your UI sucks, your application sucks. Examples of this are all over the computer world.

That being said, I definitely wouldn't consider myself a great UI designer. I can achieve a passing grade, but there are giants in this field that I am constantly bowing to. I work much better with the bottom 90% of the application. I'm the guy who engineers the application with the care of a Ferrari mechanic, but has difficulty with designing the seat to perfectly fit with the driver in a way that makes the car feel like an extension of your body.

When I went through building Use Cases in my last article, I was laying the groundwork for the User Interface. Since I wrote that article, I've been playing out several scenarios in my read of how this could all come together. That was before I read an article about MagicInk. After reading that article, I was inspired to throw out my traditional method of UI design and really push the bar with this project.

Sidenote: It's important to note that when inspiration strikes, it's best just to go with it. Your subconscious is definitely smarter then your conscious brain and pushing yourself to explore new territory is important. It's all about the growth mind set.

Putting Ideas on Paper
I often have good ideas that are forgotten because my short term memory is small and constantly being filled with new things. This is where the suggestion for keeping a notebook handy comes from. I personally prefer whiteboards when making drawings. A white board and a camera phone are a great set of tools that don't get much credit.

I have several white boards, but my favorite are actually from the hardware store. Your local hardware store will sell whiteboards in 4' x 8' sheets. Depending on how much you need, you can usually get them cut down to size. This is MUCH easier then buying the expensive white boards at an office supply store. I personally prefer a board about 18" square. Much bigger and I will try to squeeze two ideas onto the same space. Smaller and I can't fit one idea onto a single board.

After drawing on a whiteboard, I typically take a picture of my drawing with my camera phone and email myself the picture. My email inbox is the perfect place for this information to go. The pictures below are from drawings I did while writing this article.

UI Brainstorming on a White board
After reading the MagicInk article, I started drawing. Here's what I came up with:

My main piece of inspiration was to design the entire site as one single page. The principle activity will be matching recipe's with meal times. Thus, the main interface elements I need will be a collection of recipe's and a time line of the menu. The menu is the most important, so that naturally goes near the top. There are two dimensions to the menu. The first is the meals during the day, ie. Breakfast, Lunch & Dinner. Second is the days of the week. I've already decided in my previous articles to make the assumption of a 7 day week with three meals a day. With these assumptions, I'm able to construct a two-dimentional table with days on the X-axis and meals on the Y-axis.

Another realization was that I need to use pictures instead of words to describe my meals. The hard part here will be building the picture upload functionality. I believe pictures will be an important enough component that I can't cheat and use just the words of the recipe.

Navigating through a selection of recipes is a difficult problem. For inspiration here, I looked back to the original cookbook model. Cookbooks are organized by types of food, Pasta, Baked Goods, Poultry, Desserts, etc. When I go looking for a recipe, I typically decide what kind of recipe and then look in that section. Thus, the thought flow would be "Pasta Recipe" -> "Spaghetti". I am thinking the application should work this way too. That's what the bottom piece is for.

The initial list will be my food categories, Pasta, Baked Goods, etc. Then somebody clicks on a category, a list of recipes under that category will be displayed with a picture and the name of the recipe. From this list, a user can drag a picture to the menu, associating a recipe with a meal.

What's the Result?
After I've assembled my recipe, I typically would like to print it out along with a grocery list. Because of the low-level design, assembling a grocery list shouldn't be difficult from the menu information. Since the result will be a printed list, I can avoid a page refresh by implementing a print stylesheet to hide my main interface elements and show the grocery list at print time. This will keep everything on the same page.

Here's my whiteboard brainstorm of what the list and menu should look like.



Conclusion
Of everything I've designed so far, the UI will need to be the most flexible. Right now, I need to move forward with just the brainstorms of what the end interface will look like. This is one of those difficult decisions when it comes to design, how do you maintain
flexibility? Well, I answer that by at least coming up with a starting point, then moving towards a given end point. If that end point moves while I'm walking, I simple change my direction, but at least I've got a beginning and end in mind.


»