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?"
You should try using wxPython. Python is terrific for fast prototyping. Hell, I'm still using the prototypes I've developed.
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.
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.
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.
The company I work for has done very well doing very basic prototypes in web pages with PHP with a MySQL backend. That really gives the customer a chance to review the basic system quickly. Then we convert the interface to a GUI one using the GTK libraries from PHP. For a few of the more important projects we've then converted the PHP to C.
This gives our company the opportunity to have MBA's with a little HTML and PHP programming training talk to the customers initially. Then guys that are a little better at PHP and know GTK convert the initial prototype to a much more fleshed-out prototype. Then I personally either polish-up the PHP or convert it to C depending on the requirements.
By having MBA's work with the customer on the requirements and giving the customer the ability to quickly (within a week on a small project) see where the project is starting, we've been able to give customers much better estimates of how long something will take and how much it will cost. Also, it's really cut-down on the amount of code we've had to rewrite. Before we started doing it this way 18 months ago, it was just me programming for the previous 22 years. I'd hired about two dozen programmers, and all were completely useless for anything nontrivial. It's much easier to find a programmer that can write PHP well enough to prototype. Now I can get more than five to ten times as many projects done because the requirements are so much better and almost set in stone before I have to start working.
It's neat to see non-programmers (MBA's) work with people that claim to program but are pitiful at it (the average Comp Sci graduate) then a good programmer (me) all work together to take a project smoothly and quickly from a discussion in a meeting with a customer to a working system that does exactly what the customer wants.
http://dub.washington.edu/projects/denim/
So true. A carpenter doesn't design furniture with a hammer and saw in hand, because without a plan for what he's doing the pieces won't fit together quite right and the finished product will end up looking shoddy.
It's the same story for software development.
..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"
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.