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?
You should try using wxPython. Python is terrific for fast prototyping. Hell, I'm still using the prototypes I've developed.
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.
They call that RAD.
Make unfinished items on your prototype have a funny font or a strange color. When the client asks you to fix it, say that it looks bad because it isn't finished. Generally, people who aren't programmers have no idea that writing an application is any harder than changing the font on a button, or that changing the font on a button is trivial. If your mockup uses Comic Sans with random alignment, they can evaluate it while realizing that it is not actually near completion.
Flash. No seriously, give it a shot
.sig
No, seriously.
n teractive_designer/default.aspx
http://www.microsoft.com/products/expression/en/i
Prototype in XAML and then hook the prototype UI directly into your back-end code.
Of course, judgment is suspended until it actually ships, but the demos at PDC were very promising.
Glade + Pygtk + Python
I mean, lots of people need multi step procedures and seek approval inbetween each step, so developing UI goes from paper to prototype to working model finally to release.
This is mostly why many software/web products take months or years to develop.
Best way to prototype? Dive right in and code up working UI.
After developing UI for software for the last 10 years, I can safetly say that I can work up a working "prototype" just as quickly as I can do the release version. I have written my own Windows based GUI controls which make it easier and quicker to implement then your basic Win32 or MFC ones. This way, I can actually start working on the release software while getting feedback from people directly using the UI.
Whether its software or web design, UI really needs to be experienced and interacted with in order to determine is efficiency or practicality. Drawing up static images of a website or application is all nice, but its a waste of time. What do you do while waiting for management to approve your pretty pictures. Sure things might look all nice, but when they finally get the release product, they may not understand why some control doesn't do what the picture suggested it would do.
It takes me anywhere from a few hours to a few days to get a functional UI up and running and while management is playing around with it and deciding what they like and don't like, I am continuing to develop the UI further, all in an effort to get to the release product quickly. In this way, by the time management decides what it is they finally want, its already done.
In any regard, I find it best to work up prototypes in the development environment you would use to create the final product, that is, just start working on the final product right from the start. Using any kind of thrid party tools or procedures is just a good way to waste time and money.
I haven't thought of anything clever to put here, but then again most of you haven't either.
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.
use chalk on cave walls, you insensitive clod!
When it gets approved, you just add the code on the back and you're all set.
Plus you could let your manager or client play with it. Put all the buttons and fields on there and set things up, then let him drag 'em around, change font sizes, etc. Sure it will probably be hideous, but he'll be happy :). They even did something like this for Steve Jobs when making the original Mac (story here at Folklore.org.)
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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
This is an an excellent reason to develop with the Model-View-Controller paradigm. You can develop the UI to be as complete as you want. It becomes reasonable to turn the prototype into the final product. However, that doesn't mean you can release it right away since the interface is only the view. You still have to develop the other two parts of the architecture. It is good for the customer because you can say yes to their request. It is also good for you since this separation has kept you from accidentally polluting the the rest of the code with the UI prototype/non-prototype. Also you can use separate languages for each part of the MVC architecture. Use a language that suits itself to the UI and then change to something else that better fits the controller and likewise the model.
http://dub.washington.edu/projects/denim/
Libglade is the greatest thing ever.
Surprised no one has mentioned DENIM, it's a free (as in juice) UI design tool that basically combines the advantages of a traditional whiteboard (it uses a drawing tablet for the primary interface) and something like the VB6 IDE. Check it out at http://dub.washington.edu/denim/
I've used PowerPoint (and Impress) to do UI mock-ups,.. The nice thing is that it's clearly not actual web/software widgets that are being used, so nobody really expects the final version to look exactly like the powerpoint version. Also, it is easy for anyone to change or update the document. I turn off the snap to grid feature which greatly improves the usability of PowerPoint, and build any standard widgets by grouping boxes and text as needed.
I'm still optimistic that a better tool may exist, but I've had good results with this approach when discussing UI design issues.
Amazing magic tricks
..is to use paper. Use a piece of paper and pencil or pieces of construction paper that are then labeled by hand, arranged on a surface, and then affixed with tape when it's done. It's a very hands-on way to do it and users are immediately comfortable with it and not intimidated. Or just use a dry erase whiteboard. That works pretty well too.
When your users can comfortably pretend to use the application by talking through the drawings/cutouts, THEN you put it into your functional specification document in a couple different ways:
1. take a picture and paste the pic
OR
2. "transcribe" the prototype into MS Access or the VB form designer or whatever (with NO functionality) and paste a screen shot of that into the document
And that's it. Try it. Your users will thank you.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
"MVC is OK for implimenting little things such as buttons, but it fails miserably as an application-level architecture because MVC requires the controller to know way too much about how the model-level objects are implimented. Too much data is flowing around in the system for the system to be maintainable."*
*"Holub on Patterns: page 15"
... such as a Car, a Shoe, a Candy Bar or an iPod.
Then respectfully ask "Can't you just complete this prototype and release it?"
Some will get it. Some won't.
--- Attorneys Assisting Citizen-Soldiers & Families -
In the past, I have used Microsoft Excel to do UI prototyping. It has some features which can be used to convey the design:-
- Cell Comments: To mention any special logic etc on a particular field on the screen.
- Can show drop downs, buttons.
- Use multiple sheets and make the hyperlink work to navigate between sheets.
- Can use colors to mark changes to some sections to existing UIs.