Slashdot Mirror
What Tools Do You Use for UI Prototyping?
AccUser asks: "There are many articles discussing methods of UI prototyping. Having been involved in the design and implementation of a number of commercial applications (both desktop and embedded), I know the value of producing early prototypes of the UI. In the past I have used visual programming tools, such as Visual Basic, but there is always that request: 'Can't you just complete the prototype and release it?' One project I was involved with, the UI prototype employed hand drawn graphics (including hand written text labels, etc) in order to be explicit about the fact that it was a prototype. What I would like to know is what tools and techniques do you use for UI prototyping, and how do you manage your client's expectations?"
If you are OSS, or want to buy a Qt license, Qt designer is very good for prototyping -- you can even make it functionally quickly with some pyqt, then write it in whatever language you want later.
DYWYPI?
I like to use pen and paper, personally. Pen and paper is good for anything, it seems.
Show this to your friends and family that don't know what a real hacker is
"how do you manage your client's expectations?"
A good solid "NO!" with lots of eye contact.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
I draw out a UI before writing a line of code. Depending on the problem at hand, I then draw (again by hand), implementation details like class hierarchies, interfaces, callbacks, etc.
e -1.01/lib/File/CreationTime.pm
;)
When you're sitting in front of a computer, it's too easy to just start writing code. When you lose your train of thought, though, you'll end up throwing it all away because you won't know how it works. If you go to your local coffee shop with a notebook and a pencil, and start prototyping, you'll have a good plan on paper. It will be much easier to implement from a fixed plan that's written down than from some idea that you have. It will also be easier to come in the next day and start where you left off, rather than going off on some other tangent because you forgot your idea that seemed good yesterday.
My usual successful development strategy is this:
1) plan UI, interactions, structure, etc. on paper.
2) design reusable modules to do the grunt work.
3) write the documentation and unit tests for said modules. This is where you get the chance to play test your modules before you've committed to an interface. The SYNOPSIS section of your documentation (where you show example use of your module), is a great place to experiment with how your code is going to work and interact with other pieces of code. Once you know what the interface is going to look like, document the methods. Then write unit tests for them. If your interface is no good, you'll know by now, and you won't have wasted any time writing code that you're just going to trash.
4) go home and relax. you don't have to think about your code anymore because "perldoc My::Module" is going to tell you everything you need to know when you come in tomorrow morning.
5) write the actual code
6) move on to the next piece, knowing you have a well-designed, documented, tested module to build on!
I'll throw in a link to a module I developed like this. It's not particularly good in the sense of using amazing algorithms or being incredibly useful, but the documentation and tests are decent.
http://search.cpan.org/~jrockway/File-CreationTim
Note that every interaction the module has with the outside world has at least a little blurb to refresh my memory about what happens. That's the important part. (It's an added bonus if some random person on the Internet can understand how your code works too
My other car is first.
I think this is actually an excellent idea. It makes a lot of sense for elements that aren't finished to be immediately recognizable as such by the end user.
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
Libglade is the greatest thing ever.
Probably true. What strikes me is that most OSS projects don't even collect use-cases, so their concept of who their audience is and what their habits are likely to be becomes unhinged. And of course there is no plain-language, functional basis for actually testing the UI or cerating the docs, etc. Check out the Help section, and you see what... entries arranged by the contents of the pulldown menu or by the buttons on the form. And there are so many GUI apps that won't even provide an icon for a Linux desktop, cutting the user off at the knees near their very first step; that's not to mention the apps that half-heartedly try to provide an accessible icon and fail. A document listing common use-cases would have made these shortcomings stand out like a sore thumb after a few revisions; Its something you look at to ponder, "How is the user going to get from A all the way to Z?"
User installs application
User starts application
User drops file onto app icon
Admin updates application
User opens document in home directory
Take the last use-case: You create a real scenario for it, and have a person sit down and execute it. They're puzzled or annoyed that the file dialog defaults to "/", or that it remembers the last location but there is no easy way to get back to home. After the issue is addressed, major revisions of the app in future will not alienate existing users because their most basic expectations are no longer being met. But in real life, the coding hotshots out there are consistently hampering the acceptance of their apps with such simple yet humungous blind spots.
My advice to the FOSS dev community *cough*Gimp*cough*Xorg*cough*Kino*cough*... Get a red-hot poker and force OOo and Mozilla to teach you professional, user-centric methods.
Xorg, for instance, does not accommodate the essential use-case of a user permanently changing their screen resolution. The product just screams: "Let the vi-jockey or desktop-layer grok our conf file on their own." Hello??? This is a major component that cannot serialize its own configuration data back to disk??? Xorg still handles a crucial GUI-configuration task as though a sysadmin were present (not unlike the early Windows-NT method for which Microsoft fired the author back in the 90s!). So we get KDE and Gnome applets that are custom-supplied by each distro, and all understand xorg.conf in many different but deeply flawed ways. Supplying an API function to write the config to disk to enable these KDE/Gnome/Other applets to work consistently and well is not even on their radar, because runtime use-cases are beaneath them... those are for KDE/Gnome people and their style guides.
Other OSes ace'd this stuff a very long time ago.
Simple things facilitate an end-user focus, most of which don't even need beta-test volunteers or fancy automation.
Not often. Every time!
Never use the real GUI to demo a prototype or even to demo a GUI mock-up. Your customer will assume that those screens are complete. When you come back to demo the screen in its comleted state, they will not be impressed because they've seen it already, and they'll wonder what you've been doing for the last couple of weeks. Nothing you say to the contrary will make a difference.
Use screen shots, displayed via presentation softwares, or print them out and mount them on big cards. Or use the Napkin GUI mentioned in a previous post.
Never show the actual GUI, executing in real-time, unless you are giving the product demo.
Follow this rule, for health and happiness.
My Heart Is A Flower