Step Two: Paper Sketches
So, my wife and two kids are all sick today, giving me ample excuse to not go to work. They’re all napping right now, miraculously, and it seemed like a great opportunity to tinker on BudgetWise some more.
If you’ll recall from the last article, BudgetWise is to be a web-based, budget-centric, financial management application. And I’m using it as a test-bed for some of the concepts preached by 37signals in their Building of Basecamp workshop.
In this article, I’ll be showing the paper sketches of the login/logout screens. (I’m certainly no artist, but I think the sketches will be understandable enough. I’ll narrate them anyway.)
Login, Ideal State
Jason Fried suggested in the workshop that each page may have three different states:
- The “ideal” state, in which the page works as advertised,
- The “blank slate”, where a page that is supposed to present data to the user can’t, because there is no data to present, and
- The “error” state, where something goes wrong and the user must be told.
So, the first sketch shows the ideal login state, where the user is asked for their username and password. (Note that I’m omitting everything else on the page—there may be more outside of this box, but I’m trying to learn how to do epicenter design.)
This is pretty self-explanatory, but just in case you can’t read my chicken-scratch, there is a link in the middle of the box in case the user has forgotten their user name or password, and a link in the bottom of the box to sign up to use BudgetWise.
Login, Error State
This next sketch shows the error state for the login. (Of course, any number of things can go wrong, but the most common error will be a mistyped user name or password—which is why this example only demonstrates that one error.)
A box at the top of the area displays the error message. It also demonstrates another technique that Jason taught: don’t just tell the user what went wrong, help them figure out how to fix the problem. In particular, it suggests that if the user has forgotten their user name or password, they can click a link and get help. (The wording can, of course, be much improved, but I’ll work on that when I get to the HTML mockup.)
Everything else about this state is identical to the ideal state.
Logout, Session Timeout
I lumped the logout and session timeout scenarios into the same sketch-session as the login. Basically both of these scenarios are just messages displayed to the user, along with a link to the login page.
I kind of puzzled over this with the logout message. A part of me would like to just have the user given the login page directly when they log out, but I thought it might be nice to give them a little more information. Logging out of a web application is always tricky to me—where do you take them after they log out? I figured a simple “you have been logged out” message would suffice, although I’m still not completely satisfied with it.
A user may be logged out through inactivity, as well. If they let their session sit open long enough, without sending any activity to the server, they will be logged out automatically. In that case, the next time they attempt to perform an action, they will be taken to the session timeout message.
It is almost identical to the logout message, but it gives an explanation of why they were logged out. More verbage could be helpful, maybe… Perhaps a bulletted list of what the timeout criteria are. I’ll tinker with that in HTML as well.
Layout
The last sketch I did was a “big picture”, to get an idea of where the above epicenters would actually fit on the page.
The problem I encountered here is that each of the bits described above are small. They don’t eat up very much screen real estate. So what do you do with the rest of the screen?
I like what Basecamp does, which is just to put the login in the middle of a neutral-colored screen. No distractions. It gets right to the point. I was tempted to just go that route, since I trust 37signals to know what they are doing. :)
However, since this is my baby, and it’s all about experimenting, I thought I’d try something different. The page itself will still be pretty minimalistic, but instead of centering the login box, I want to try moving it slightly up and left of center. Then, a watermark of the name of the app, “BUDGETWISE”, would sit behind the box, and a colored bar would divide the screen into two unequal halves.
Conclusion
I’m amazed at how much this simple exercise has forced me to think about the interface of my application. Even something as trivial as the login box (which I selected first because it was trivial) was found to have several sticky issues that required some thought.
I also found it really hard to focus on making the sketches. I kept wanting to jump into a text editor and start hacking away at HTML. The programmer in me kept thinking in terms of controllers and models.
I think this is something I could get used to doing, though. And with practice, it would come much more quickly and naturally.
Next up—the HTML mockups, and some more paper sketches of subsequent areas of the application!