What Tools Do You Use for UI Prototyping? 88
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?"
Qt designer (Score:3, Insightful)
X-Code (Score:3, Informative)
Re:X-Code (+pyobjc+python) (Score:1)
Then there is Gorm (Score:2)
http://www.gnustep.org/experience/Gorm.html [gnustep.org]
Its still ugly as sin, but its the closest thing OS X has "native" that could also be considered multi-platform.
Re:X-Code (Score:1)
wxPython (Score:2, Interesting)
My suggestion (Score:5, Insightful)
Re:My suggestion (Score:3, Funny)
Re:My suggestion (Score:1)
My UI prototype tools of choice has always been:
Pen
Paper
Scissors
Paste
You may want to use recycled paper, or if you want to go for an environment clean solution, use Inkscape (Free Vector Based Drawing Program, available for Linux, Apple, and even the arch enemy windows).
Using a vector program rather then a raster program enables you to make shapes quickly (rectangles, circles,
Re:My suggestion (Score:1)
Also, if my game ever becomes popular, how much will that notebook cost?
Re:My suggestion (Score:2)
I'm a big fan of light trace paper for layering - very useful if you want to test templates with dynamic elements.
Usually I'm trying to test a workflow rather than code. In those circumstances code gets in the way for establishing how the job SHOULD be done. It also helps develop a functional specification up front before you have such a huge investment in code that making changes when something obviously doesn't work like it should is a make or break decision.
Low tech (Score:2)
Dia (Score:1)
Re:Dia (Score:2)
For another low fidelity mockup tool, try inkscape [inkscape.org]. Mockups and prototypes are two different animals. There is no interactivity with mockups unless they are talked though by a facilitator with the relevant stakeholders. This is called a paper prototype. A real prototype is an actual application that can be executed. It is usually somewhat limited in capability and tends to have nothing designed in it for scalability, security, portability, performance, etc. As stated
Assertiveness and a strong will to back it up (Score:5, Insightful)
"how do you manage your client's expectations?"
A good solid "NO!" with lots of eye contact.
VB prototype becoming final product (Score:4, Funny)
It's been a while but... (Score:2)
Re:It's been a while but... (Score:1)
"incomplete" prototype (Score:5, Interesting)
Mod parent up, NOT Funny (Score:3, Insightful)
Re:Mod parent up, NOT Funny (Score:2)
For example, the Windows logo has been doing that for some of us for years.
Re:"incomplete" prototype (Score:5, Interesting)
Re:"incomplete" prototype (Score:3, Insightful)
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 contr
Re:"incomplete" prototype (Score:2)
Re:"incomplete" prototype (Score:1)
Flash (Score:2, Funny)
Microsoft Sparkle. (Score:2, Interesting)
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.
What I use.. (Score:2, Informative)
Best way to prototype UI is to just do it. (Score:3, Interesting)
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.
Re:Best way to prototype UI is to just do it. (Score:4, Interesting)
I'm not making any assumptions about you but, sadly, the answer most open source developers seem to have is some variant of "Who needs usability testing?".
I'm in the early stages of a small project and spent a good part of the day today making a functional prototype for the web application/service I'm working on. As I code, I've got two iterations of paper prototypes sitting next to me as well as the notes taken during the user testing I did last week. I've found this process to be extremely valuable, as the feedback I got in the initial rounds of testing will save me a lot of time in the long run, not to mention ensure that the UI is intuitive and easy to use.
Re:Best way to prototype UI is to just do it. (Score:3, Insightful)
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 t
Re:Best way to prototype UI is to just do it. (Score:2)
In the stereotypical open source project, the developer is the audience. For those few projects that cater to the needs of others, I agree that more rigorous methodologies are appropriate.
Re:Best way to prototype UI is to just do it. (Score:1)
Microsoft caught an incredibly lucky break some 25 years ago that allowed them to grow and become huge. However, they are not that big today because of that one incident. The reason they are as big as they are today is that they, around '92 or '93, realized that usability is tremendously important. Sure, that wasn't an original thought. In fact, that was what Apple had been doing all the time, and a
Re:Best way to prototype UI is to just do it. (Score:2)
Yes but they did this by having a head-start in the Windows 95 environment, the replacement for their monopoly product. OTOH Wordperfect Suite (incl. Quattro) has been advancing and
Paper and Pencil (Score:5, Insightful)
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
Re:Paper and Pencil (Score:3, Interesting)
It's the same story for software development.
Re:Paper and Pencil (Score:1)
I... (Score:3, Funny)
Re:I... (Score:2)
Re:I... (Score:1)
Re:I... (Score:1)
Re:I... (Score:1)
Re:I... (Score:1)
Re:I... (Score:2)
Photoshop + Whiteboard + Paper + Pen (Score:1, Redundant)
That's my usual combo. Sometimes I'll throw together some PHP if I want to test out some usability stuff.
PHP web-based then convert it to PHP:GTK (Score:1, Interesting)
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 bet
Visio + CutePDF (Score:2)
Then I switched to Visio and was able to crank out diagrams of a robust website quickly, and still include all the subtitles and annotations that you want. I could template pages easily enough,
Re:Visio + CutePDF (Score:2)
I believe the leading FOSS application would be Kivio (although Dia and OOo Draw work well for many people). I think there are one or two others.
MVC (Score:4, Informative)
Re:MVC (Score:2)
MVC-Holub. (Score:2, Interesting)
*"Holub on Patterns: page 15"
Re:MVC (Score:1)
Unfortunately non-developer clients often don't understand (and sometimes won't accept) that the view is not the whole product. They see the only thing they really grasp, the interface, is complete, and the nat
A piece of software I can't find... (Score:2)
A piece of cloth I can't find... (Score:3, Interesting)
Re:A piece of cloth I can't find... (Score:2)
DENIM!!! (Score:2)
Glade (Score:3, Insightful)
Re:Glade (Score:2)
Spoken like a man(?) who has never used Interface Builder in OS X. I've worked with VB, VC++, GTK+(Glade), QT(forget the app name), but Xcode and Interface Builder on OS X is by far the easiest and fastest tools available (that I've used) for prototyping GUIs and software development in general.
Check out DENIM (Score:4, Informative)
vote parent up - ns (Score:2)
powerpoint (or impress) (Score:3, Informative)
I'm still optimistic that a better tool may exist, but I've had good results with this approach when discussing UI design issues.
The best way... (Score:3, Interesting)
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.
Photoshop (Score:2)
Text editor, email (Score:1)
Paper UI (Score:2)
I can't remember where I saw this; I haven't used it, but I thought I'd bookmarked it.
Re:Paper UI (Score:1)
Make a Clay Model Prototyping Another Product (Score:4, Funny)
... 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.
Paper (Score:2)
Some types of interfaces require more finesse than others when using paper, but even if the interface includes animated elements, you can still learn a lot from the paper v
Microsoft Excel (Score:3, Interesting)
- 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.
XUL (Score:1)
Or you could do what a consulting firm did to, er, for my employer. Buy some Macs, and spend a lot of time using Photoshop etc. to create bitmap images that look like a GUI. Then spend a lot of time making PDF files from the images, showing a UI that looks nothing like a computer GUI, but that in the end will bear som
P.S (was Re:XUL) (Score:1)
mmm snow (Score:1)
printf and GNU readline (Score:2)
Vector graphics? (Score:1)
Use Canvas (Score:2)
For semi-interactive prototypes, I can output my work in a PDF which can have links so people can click on button