Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Tools Do You Use for UI Prototyping?

Cliff posted more than 8 years ago | from the dialog-drafting dept.

GUI 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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Qt designer (3, Insightful)

dcapel (913969) | more than 8 years ago | (#14073278)

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.

X-Code (2, Informative)

MBCook (132727) | more than 8 years ago | (#14073505)

On the Mac side, X-Code is fantastic. Not only do you get to lay out the components but you can even connect many of the simple actions with drag and drop. This means that checking one box that should enable and disable other fields can work in just a few seconds. The button that is supposed to make the drawer slide out? That is trivial to do. You get a working demo that looks exactly like the final thing will. It is just like using Visual Basic but better because you get a "real language" (sorry, I don't like VB for most things).

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 [] .)

Re:X-Code (+pyobjc+python) (1)

tmontes (80312) | more than 8 years ago | (#14073765)

...and with PyObjC, you can easily plug some "brains" to the interface in good old Python. Really neat !

does X-Code run on OS-X? (-1, Offtopic)

green pizza (159161) | more than 8 years ago | (#14074081)

X-Code, does that run on MAC OS/X or is that OS-X?

Maybe I'm thinking of Xcode for Mac OS X.

NeXT never did have a good grasp on capitalization. Their own OS went through at least three names, "NeXTStep", "NeXTSTEP", and "NEXTSTEP". NeXTpple these days continues the mess with the lowercase "i" in iMac, iBook, iLife, and then the uppercase "X" in Xcode, Xsan, and Xserve.

Maybe it's lowercase for consumers, uppercase for pros?

Then there is Gorm (1)

Burz (138833) | more than 8 years ago | (#14076906)

Gorm is the IDE environment for NextStep. sorry..... I meant GNUStep ;-) []

Its still ugly as sin, but its the closest thing OS X has "native" that could also be considered multi-platform.

Re:X-Code (1)

Arandir (19206) | more than 8 years ago | (#14084718)

Except that Qt Designer already DOES all of that stuff. Xcode is good but it's Mac only. It depends on who what your market is.

wxPython (2, Interesting)

YetAnotherLogin (534226) | more than 8 years ago | (#14073294)

You should try using wxPython [] . Python is terrific for fast prototyping. Hell, I'm still using the prototypes I've developed.

Re:wxPython (0)

Anonymous Coward | more than 8 years ago | (#14081719)

wx also has good bindings for Ruby and COBOL. Ok, maybe not COBOL.

My suggestion (5, Insightful)

PunkOfLinux (870955) | more than 8 years ago | (#14073295)

I like to use pen and paper, personally. Pen and paper is good for anything, it seems.

Re:My suggestion (1)

Deltaspectre (796409) | more than 8 years ago | (#14073370)

My only problem with pen and paper is getting elements centered on the form

Re:My suggestion (2, Funny)

Smallpond (221300) | more than 8 years ago | (#14075648)

Cut and paste is more fun this way. Especially if you like to eat the paste.

Re:My suggestion (1)

x_terminat_or_3 (873666) | more than 8 years ago | (#14077148)

I second this.

My UI prototype tools of choice has always been:


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, ...) and select them later to move to another position or change the shape.

Re:My suggestion (1)

AndreiK (908718) | more than 8 years ago | (#14088569)

Glad others think like me. When I start a new project, I always get a cheap one-dollar spiral notebook to keep interface sketches, weird code highlights, etc.

Also, if my game ever becomes popular, how much will that notebook cost? ;-)

Re:My suggestion (1)

Macgrrl (762836) | more than 7 years ago | (#14096277)

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 (1)

(H)elix1 (231155) | more than 8 years ago | (#14073302)

Whiteboard planning out the dev side, Visio for anything we hand the customer. That way they don't get any illusions there might be some prototype they can slam into production - even if I've got the HTML looking right on my part.

Dia (1)

akh (240886) | more than 8 years ago | (#14073314)

I use Dia all the time for interface. It's great for trying out different variations. Since the graphic primitives are so, well, primitive, it's easy to focus on usability instead of eye candy. Visio might also be usable for this.

Re:Dia (1)

anomalous cohort (704239) | more than 8 years ago | (#14084376)

I use Dia all the time for interface.

For another low fidelity mockup tool, try inkscape [] . 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 earlier, prototypes can be throw away or not. If not throw away, then the tools you use for the prototype are the exact same tools that you are planning to use for the real thing.

Assertiveness and a strong will to back it up (4, Insightful)

GoofyBoy (44399) | more than 8 years ago | (#14073350)

"how do you manage your client's expectations?"

A good solid "NO!" with lots of eye contact.

VB prototype becoming final product (3, Funny)

dtfinch (661405) | more than 8 years ago | (#14073358)

They call that RAD.

It's been a while but... (1)

shumacher (199043) | more than 8 years ago | (#14073378)

A laptop running either RealBasic, O'Basic or Visual Basic, hooked to a large TV. One person on the laptop, but the whole team working on the idea. Notebook and markers, laser pointer, pizza, and (if your team is disciplined enough) beer. The UI builds itself.

Re:It's been a while but... (1)

aspx (808539) | more than 8 years ago | (#14073880)

Well if you involve beer as you suggest, the UI will need to build itself.

"incomplete" prototype (5, Interesting)

Anonymous Coward | more than 8 years ago | (#14073383)

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.

Mod parent up, NOT Funny (2, Insightful)

tm2b (42473) | more than 8 years ago | (#14073618)

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.

Re:Mod parent up, NOT Funny (1)

gstoddart (321705) | more than 8 years ago | (#14081137)

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.

For example, the Windows logo has been doing that for some of us for years. :-P

Re:"incomplete" prototype (4, Interesting)

mykdavies (1369) | more than 8 years ago | (#14075224)

If you're using Swing, have a look at Napkin [] -- it gives you a great 'sketch-style' look-and feel. As the author says 'the idea is to try to develop a look and feel that can be used in Java applications that looks informal and provisional, yet be fully functional for development. Often when people see a GUI mock-up, or a complete GUI without full functionality, they assume that the code behind it is working. While this can be used to sleazy advantage, it can also convince people who ought to know better (like your managers) that you are already done when you have just barely begun, or when only parts are complete.'

Re:"incomplete" prototype (2, Insightful)

FacePlant (19134) | more than 8 years ago | (#14081632)

Often when people see a GUI mock-up, or a complete GUI without full functionality, they assume that the code behind it is working.

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.

Re:"incomplete" prototype (1)

faster (21765) | more than 8 years ago | (#14082441)

For web prototyping, there's DENIM [] from Berkeley. It produces functional web pages from sketches. Another Java app.

Re:"incomplete" prototype (1)

Arandir (19206) | more than 8 years ago | (#14084688)

If you use Qt, simply use the fugly SGI style.

Flash (2, Funny)

TheMysteriousFuture (707972) | more than 8 years ago | (#14073384)

Flash. No seriously, give it a shot

Graphically Flashy Interfaces. (0)

Anonymous Coward | more than 8 years ago | (#14074030)

Maybe you got a funny for "giving it a shot" at Flash? Seriously Flash with Actionscript is one of the tools I use. I also write in LISP and Smalltalk (amoung others) so GUI development is easy.*

*I don't recommend the MVC pattern.

Microsoft Sparkle. (2, Interesting)

Dewb (4591) | more than 8 years ago | (#14073393)

No, seriously. teractive_designer/default.aspx []

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.. (2, Informative)

aldragon (782143) | more than 8 years ago | (#14073444)

Glade + Pygtk + Python

Best way to prototype UI is to just do it. (3, Interesting)

TheSkepticalOptimist (898384) | more than 8 years ago | (#14073448)

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.

Re:Best way to prototype UI is to just do it. (3, Interesting)

elemental23 (322479) | more than 8 years ago | (#14073488)

How do you do your usability testing then? Don't tell me you code up a UI for every testing iteration.

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. (2, Insightful)

Burz (138833) | more than 8 years ago | (#14077482)

the answer most open source developers seem to have is some variant of "Who needs usability testing?".

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. ...Rant OFF :-)

Best way to prototype UI is to storyboard it. (0)

Anonymous Coward | more than 8 years ago | (#14077874)

Actually the movie industry (*cough*cough*spit*spit*) came up with a solution. Storyboarding. Forget all the implimentation details, and storyboard your interface from start to finish.*

*Of course this is called a paper UI. Really the issue is "amount of detail"

Re:Best way to prototype UI is to just do it. (1)

Peter La Casse (3992) | more than 8 years ago | (#14086124)

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.

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. (1)

Imsdal (930595) | more than 8 years ago | (#14089511)

This is very, very true, and, incidentally, the one area where most Microsoft bashers underestimate the giant.

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 at that time, Apple was 5-10 years ahead of MS.

But Microsoft realised this, got their act together, and spent an incredible amount of time and effort om Windows and, in particular, on the Office suite. Excel (and to some extent Word) is the reason everyone uses Windows today, not the other way around. And Excel is an incredible piece of software.

Excel used to have competitors, like 1-2-3 and Quattro Pro. In the early nineties they were about as good as Excel (or possibly better?). But when Microsoft decided that usability was what counted, they crushed their competitors who considered that less important (or simply didn't have the resources to keep up in the arms race).

In the real world, productivity is what counts, and in an office settig ("office" as in "office, not as in "Microsoft Office"), usability is by far and away the most important productivity factor. It is far, far more important than security and reliability, for instance.

This is not true for databases, for instance, which is the reason Oracle is huge there. Neither is it true for back end servers, which is why Linux/Unix/AS400 is widely used there. But on the desktop? Usability, usability, usability.

I will believe Open Office will have a future when I see usability test that show them ahead of the MS Office suite. Not TCO, not feature set, not reliability but plain old "can your average50-year-old semi computer illiterate desk jockey create a simple budget in the spreadsheet application?".

Re:Best way to prototype UI is to just do it. (1)

Burz (138833) | more than 7 years ago | (#14091095)

Excel used to have competitors, like 1-2-3 and Quattro Pro. In the early nineties they were about as good as Excel (or possibly better?). But when Microsoft decided that usability was what counted, they crushed their competitors who considered that less important (or simply didn't have the resources to keep up in the arms race).

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 really a fine product for many years now in terms of usability and otherwise. Yet it's not overtaking MS Office. Lotus SmartSuite I used alot back ion 1996, and it was excellent. Most people still swore by DOS products up until W95 arrived, and what it amounted to was people switching their excuses for not changing their vendor.

What MS did right was maintain the focus on visual interaction, which saved their monopoly from competition on yet another front. The Mac became a bit more marginalized as a result.

OTOH Linux is a true threat. You can't play the usual dirty tricks against it, even if it lacks the user-focus needed to catch fire. So you have to compensate with real, hard work like adding stability and security. We just need a stable place that inspires programmers with the confidence to bang on (not IN) out platform; We need to attractively define the API set and hold to it until the next major revision. Then the use-case of "Download app from ACME website and install" becomes workable for average people. Leave the distro repositories for updating the core OS, and much of what is supplied with Linux distros should be marked as 'extras'.

MS really did get lucky with their initial association with IBM. With an IBM PC, you could make an end-run (literally, with SneakerNet) around the sleepy mainframe programmers in M.I.S., and take control of your department's data and even get creative with it. What fealty that inspires! I know from experience.

Later on, MS could let Lotus keep selling DOS/Windows systems while they plotted Lotus' demise. Its win-win for MS in the short term.

Ruby-On-Rails (0)

Anonymous Coward | more than 8 years ago | (#14085199)

Best way to prototype? Dive right in and code up working UI.

Total agreement here. Our marketing department started doing UI prototypes in Ruby-on-Rails which let them easily flush out deeper "prototypes" as the user-testing suggested more research was necessary.

Interestingly, now that UI prototype is quickly approaching full-functionality even faster than the "real" C#/.NET project that engineering's working on - and interesting things may happen to the whole engineering group with the company now considering turning the marketing department's prototype into a replacement for the "real" product.

Paper and Pencil (4, Insightful)

jrockway (229604) | more than 8 years ago | (#14073453)

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.

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. -1.01/lib/File/ []

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 (2, Interesting)

Bastian (66383) | more than 8 years ago | (#14074261)

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.

Re:Paper and Pencil (1)

shadow0_0 (59720) | more than 8 years ago | (#14085900)

Agreed! With the help of a scanner, the hand drawn diagram can become the first draft of the design document as well.

I... (2, Funny)

Jeff DeMaagd (2015) | more than 8 years ago | (#14073483)

use chalk on cave walls, you insensitive clod!

Re:I... (1)

MarkRose (820682) | more than 8 years ago | (#14073524)

Walls? You have walls? I have to use a stick in the dirt!

Re:I... (1)

Andux (260446) | more than 8 years ago | (#14073836)

Sticks and dirt? Luxury! In my day, we had to spend weeks clawing at solid rock with our bare hands... and we liked it!

Re:I... (1)

00110011 (917752) | more than 8 years ago | (#14074610)

Without going up hill both ways to get to the solid rock first?

Re:I... (1)

click2005 (921437) | more than 8 years ago | (#14073843)

You have a stick? I have to use my finger.

Re:I... (1)

JustOK (667959) | more than 8 years ago | (#14074686)

You had FINGERS??? We only had rudimentary flippers, and damn glad for that!

Re:I... (1)

jo42 (227475) | more than 8 years ago | (#14074776)

What, no Smoke and Mirrors(tm)?

Re:I... (1)

symbolic (11752) | more than 8 years ago | (#14077253)

I tried that once, but I had a hard time getting the cave into the client's office.

I just copy apple (0)

Anonymous Coward | more than 8 years ago | (#14073596)

and that's that.

Photoshop + Whiteboard + Paper + Pen (0, Redundant)

telstar (236404) | more than 8 years ago | (#14073660)

Photoshop + Whiteboard + Paper + Pen + Thinking

That's my usual combo. Sometimes I'll throw together some PHP if I want to test out some usability stuff.

Borland or Bust (1)

Bob Gortician (246811) | more than 8 years ago | (#14073695)

C++ Builder or JBuilder are as easy to work up a GUI in as Visual Basic, with the added advantage of actually being what I would use to complete the project.

PHP web-based then convert it to PHP:GTK (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14073751)

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.

Visio + CutePDF (1)

rocjoe71 (545053) | more than 8 years ago | (#14073790)

Since most of my prototyping is for web applications, I quickly found that HTML as a prototype is just as time consuming as actual coding. The temptation to include prototype pages that would actually appear to do something would only stetch out the time it would take to produce something that could satisfy a client.

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, which would help when quickly rebranding the prototype for other clients in under 30 minutes (pretty common practice when you work for an App service provider).

When a proto was ready for client review I'd send the Visio printout to CutePDF, using the filename for dating and versioning. Our clients loved PDF prototyping since it was easier to printout the whole "website" and make their own notes, something they wouldn't do as easily with a website, prototyped in HTML or as a working demo.

I chose Visio as it was easily available in our office, no doubt there's an equivalent that would do just as well.

Re:Visio + CutePDF (1)

Burz (138833) | more than 8 years ago | (#14077003)

I chose Visio as it was easily available in our office, no doubt there's an equivalent that would do just as well.

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 (4, Informative)

Blnky (35330) | more than 8 years ago | (#14073892)

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.

Re:MVC (1)

ceoyoyo (59147) | more than 8 years ago | (#14074177)

Python, PyObjC and Interface Builder are great for that. Interface Builder strongly encourages MVC architecture. The GUI stuff all gets done in IB and Python. The model and controller you can write mostly in Python, with maybe some auto-wrapped ObjC code where it counts. I personally like to write back end objects first, then make a GUI to drive them. That way you're absolutely sure that your GUI code doesn't pollute your back end stuff, and all of it is reusable.

MVC-Holub. (2, Interesting)

Anonymous Coward | more than 8 years ago | (#14075235)

"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"

Re:MVC (1)

Synonymous Yellowbel (720524) | more than 8 years ago | (#14077887)

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.

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 natural reaction is that the whole thing is done.

I think it's management of these expectations that the article poster is seeking to improve.


A piece of software I can't find... (1)

afd8856 (700296) | more than 8 years ago | (#14073990)

There is a freeware or shareware that is java based I believe, I found it about a year ago, I've tried it and now I can't find it anymore. It allows you to hand-draw boxes and ui elements and connect them to each other to make a working UI prototype. Anyone knows what I'm talking about?

A piece of cloth I can't find... (3, Interesting)

Anonymous Coward | more than 8 years ago | (#14074074)

Re:A piece of cloth I can't find... (1)

afd8856 (700296) | more than 8 years ago | (#14074781)

Thank you, mr/mrs AC. That's what I've been looking for!

DENIM!!! (1)

platypus (18156) | more than 8 years ago | (#14076005)

Sorry, just to give this post more visibility, because Denim is actually very great.

Glade (2, Insightful)

Heretik (93983) | more than 8 years ago | (#14074121)

Libglade is the greatest thing ever.

Re:Glade (1)

(startx) (37027) | more than 7 years ago | (#14092996)

Libglade is the greatest thing ever.

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 (4, Informative)

noblethrasher (546363) | more than 8 years ago | (#14074151)

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 []

vote parent up - ns (1)

quiddity (106640) | more than 8 years ago | (#14076599)

thats it

powerpoint (or impress) (2, Informative)

rnd() (118781) | more than 8 years ago | (#14074221)

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.

The best way... (2, Interesting)

Da VinMan (7669) | more than 8 years ago | (#14074296) 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
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 (1)

Ratbert42 (452340) | more than 8 years ago | (#14075151)

Pen and paper sketches, then some quick Photoshop mockups which eventually morph into a look which gets hacked up for a DHTML prototype.

I use C++ (Yes, it is "Cee plus plus") (0)

wysiwia (932559) | more than 8 years ago | (#14075938)

I've just done a prototype in C++ for the Tor GUI context [] . If you don't believe me just see mgr.html [] .

Re:I use C++ (Yes, it is "Cee plus plus") (0)

Anonymous Coward | more than 8 years ago | (#14077390)

No, it is "C plus plus"

The only way to spell "C" is "C", by attempting to give it a spelling you just look like an idiot.

Text editor, email (1)

try_anything (880404) | more than 8 years ago | (#14077398)

But maybe you meant to say GUI.


Paper UI (1)

Omniscient Ferret (4208) | more than 8 years ago | (#14077417)

Someone else made a deliberately lo-fi, rough draft theme based on paper & pencil. For the background, picture white paper with blue horizontal lines. Instead of straight lines, picture a freehand line drawn in pencil. A messy, obviously handwritten font would also help.

I can't remember where I saw this; I haven't used it, but I thought I'd bookmarked it.

Re:Paper UI (1)

Curl E (226133) | more than 8 years ago | (#14078671)

I don't know where you saw it but it looks like they were taking this advice [] .

In Solvat Russia... (0)

Anonymous Coward | more than 8 years ago | (#14078509)

UI Tools prototype you!

Make a Clay Model Prototyping Another Product (3, Funny)

rewinn (647614) | more than 8 years ago | (#14079059)

... 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 (1)

Khelder (34398) | more than 8 years ago | (#14081527)

The very first prototype of a UI should be on paper. You draw the interface, menus, dialog boxes, etc. You can even user test a paper interface, ideally with one person "playing computer" (i.e., bringing up dialog boxes when the user "clicks" on the buttons), one person providing directions to the participant, and one person making notes.

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 version. And it's *so* much faster to build with paper than even with the easiest software prototyping/RAD/whatever tool.

Microsoft Excel (3, Interesting)

justdev (721467) | more than 8 years ago | (#14084192)

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.

XUL (1)

mobileink (932913) | more than 8 years ago | (#14085183)

If you haven't looked into XUL it's well worth the effort. With XUL (i.e. the Mozilla App Platform) there's a real possibility you could respond "Ok" to a request to implement the prototype.

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 some resemblance to the finished product. Be sure to charge a lot of money and call your people "designers", so your client will think he's getting real value for the money. Call the PDF files by some term that sounds like a term of art - they called them "wireframes" on my project - to enhance the illusion that mere mortals could not possibly do the work. Then hire some grunts to look at the PDF files and try to make a GUI that looks like them, sort of. Be sure to make expensive, customized button images, even for stuff like "Yes", "No", etc. Also, make sure you call yourself a "User Experience Specialist" or something like that. No, "User Experience Architect" is better - always try to get "Architect" in your titles, and charge extra for it.

And it's not a "prototype", its a "User Experience architecture preview".

P.S (was Re:XUL) (1)

mobileink (932913) | more than 8 years ago | (#14085285)

If you need to make high level node-arc diagrams of the structure of a site, take a look at GraphViz ( [] ) It's very powerful, with a very simple text syntax, and saves you the trouble of manually routing the arcs. You might also want to take a look at Asymptote ( [] )

mmm snow (1)

Ojuice (638639) | more than 8 years ago | (#14087200)

I tend to use my piss on snowy days.

printf and GNU readline (1)

Kymermosst (33885) | more than 8 years ago | (#14088583)

Enough said!

Vector graphics? (1)

patonw (747304) | more than 7 years ago | (#14095386)

Anyone use vector graphics programs to do this?

Use Canvas (1)

DaRat (678130) | more than 8 years ago | (#14099925)

I use Canvas [] to do almost all of my design and low-mid level prototyping work once I'm past the pencil and paper stage. Canvas is sort of a jack of all trades graphics program that is a cross between Illustrator, Photoshop, and light version of InDesign. Not as capable than any of them individually, but tightly and smoothly integrated. Imports and exports a very wide variety of file formats.
For semi-interactive prototypes, I can output my work in a PDF which can have links so people can click on buttons and be taken to different pages in the PDF (which simulates changes in the UI).
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?