OK, posting it:
http://www.joelonsoftware.com/articles/Biculturalism.html
A question from which direction you come and in which direction you have to go. And itâs a question of personality if you use paper based prototypes or excel. I personally prefer mind prototype. I move elements around in my imagination and come to high quality result where elements are positioned in the best way. I do this because itâs more quickly than drawing anything. In team work prototypes are very important to share your point of view. I came to programming vie HTML so for me itâs so f*ing normal to think (better say imagine) of the UI intuitively that I have changed completely to an API (or data interface) view of things. Itâs more important to create a webservice (which is or could be accessible via terminal) than creating a well-formed user-interface. So you SHOULD NEVER let a UI designer design a webservice. The first step is the layers behind the thing and easy information flow on an abstract level. I for my self HATE terminals because I really hate hacking dumb words into a keyboard, itâs stupid work. WHEN I do this I want that this work gets a high value, so I want to write reusable code. E.g. I never insert simple SQL statements to a terminal. For simple statement I use PHP scripts or UI like PMA.
So creating interfaces (good interfaces 
is a natural intuitive process for me because the more often you access structured information the same way the more you âcryâ for an easy human interface. People who embrace their console the whole day are not human beings.
The last several years I have been very much a UI first type of developer it has seemed to work out very nicely for me.
Tom (and co), who think that GUIs are the be-all-and-end-all of user interfaces, please cosider those of us who really donât want to work with them.
We like to automate stuff, having a nice scriptable interface is a must. Donât assume that I particularly care to learn your programming/scripting languages of choice, just let my choice of glue language interface with it.
Never assume that the input of any program will be provided by a human, itâs just as likely for me to script the process.
Never assume that your reports are the end of your application, they might as well be input for something else.
@Tom:
Quote: âWhat will our users do?â = GUI
Nope. Perl script, getting data off another host and sending it to your application.
Quote: âWhat do our users want back?â = GUI
Nope, plain text output for sending to another system as a regular task which MUST not involve humans for normal use.
Quote: The architecture and data format have absolutely no bearing on this question. Theyâre part of the next questions: âHow do I solve this problem?â, âWhat problems might I encounter in 5 years?â, âWill this interface with my competitors?â
You also forgot the bit about being able to use them with multiple other programs, on multiple different hosts.
Quote: How you get there is entirely immaterial to the user, except that it must be fast enough not to annoy them. Note the word âenoughâ. Also, it doesnât matter if itâs come up with a result, unless it DISPLAYS it within this time = GUI.
I donât want/need a display. I need the data, not the formatting. Formatting is an option, but lack of formatting is mandatory.
Forgive the commercial plug, but anyone who is interested in participating in a prototyping software beta, visit here: http://www.protoshare.com/
All the issues discussed here were the impetus for our product dev. Youâve got to do the UI first, do it quickly, change it a lot, and get all the stakeholders involved. ( I hate it when the client doesnât actually look at what youâre doing until 3 days before the site goes live.) Itâs really about developing a workable, implementable spec with the client before you start coding.
Whiteboard + digital camera + Whiteboard Photo a href="http://www.polyvision.com/products/wbp.asp"http://www.polyvision.com/products/wbp.asp/a . I really love this tool (not affiliated with it in any way). Itâs not obvious it actually adds anything other then aesthetics, but itâs just magicalâŚ
I donât know why anyone would use paper over a whiteboard in the digital age :-p
also +1 for Denim a href="http://dub.washington.edu/denim/"http://dub.washington.edu/denim//a
Typically, my big GUI designs so far has been moving paper-and-pen processes to web-based applications for internal clients. So Iâve developed the following process:
1 - GUI design starts with looking at the paper forms that currently exist; find out what information is not on the forms that is also collected.
2 - Mock up with whiteboard, dry erase markers, Post-It Notes, and the end-users. One large package of yellow sticky notes used up now is worth many, many hours of my time spent in redesign later.
3 - Mock up the whiteboard ideas in HTML (static screens only, no live data) Review with end-users. This second review will often prompt recall of things that were not thought up in the previous step.
4 - Build application
5 - Review working application with end-users. Let them play with it, without live data, for a week or so.
6 - Make the GUI screens a bit prettier, neaten up placement, move a few elements around as requested. Couple of days for further review.
7 - Go production and maintain. If serious changes are required, back to step 1 or 2.
Devdas, youâre confusing UI with GUI.
also, if a program is automated then of course it doesnât need much of an UIâŚ
âI donât want/need a display. I need the data, not the formatting. Formatting is an option, but lack of formatting is mandatory.â
are you THE ONLY user of the system? and will always be THE ONLY user? can you speak for others who are using or may be using the application??
Jin, the comment I was responding to was trying to do the GUI enforcement.
Lack of mandated formatting allows me to easily convert the data into other forms.
Having formatted data as an option allows for humans to deal with the data.
Having lack of formatting allows machines to deal with the data. Machine readable data can be converted into human readable format more easily than vice versa (cue the comment from people who have written screen scraping programs for mainframes).
My point was more in terms of making automation easy, rather than trying to enforce a GUI and making it difficult.
Devads, iâm for using a method where the method applies, appropriately. if youâre focusing on automation, then a UI may not be a focus. I didnât read through all the comments in this particular blog, i just hope people donât mistake UI in this topic with GUI.
Designing the UI first is critical to delivering a good experience for normal users. When prototyping a web interface (intranet or internet) for a client, itâs pen and paper, to Photoshop/Illustrator, to HTML+CSS ready for implementation. The Photoshop step can sometimes be jumped if you have a decent Web Designer.
Even if you have awful graphic design skills you can still iterate using this methodology. Even go as far as using some JavaScript or similar to emulate how data may be loaded from a backend. Best of all is that you can work this way and not overly compromise on design or architecture (an invalid point raised in some comments).
Something else that is important but is more of a âsofterâ issue is branding. You can follow the approach above and deliver a UI that is usable, but the icing on the cake is involving a good graphic designer and someone in a marketing type role who ensures you have a consistent design across your collection of applications, and common functionality/patterns exist.
If you are developing in C or C++, consider using XVT for your GUI layout. It has a convenient drop and drag layout for user interface objects/views/widgets, etc. Then, when youâre done, youâll get ansi compliant C or C++ code for the GUI, and you can compile this code on any (and all) of a dozen platforms. This productâs capabilities seems to be the best kept secret in the developer world sigh
âPaper Prototypingâ?!?! Are you INSANE? Anyone can prototype a user interface in dot net in lightning speed, and ya know what? When youâre done, the thing is WRITTEN IN DOT NET.
If you are building a RESTful web app then I think the best place to start is the URL.
Thatâs the URL schema for all the resources that go to make up your pages i.e. the individual elements that you want to point to, the elements you want to transclude onto your pages.
Starting from the URL helps map out how the information fits together - what information lives at each page etc.
Once youâve got this sorted then start making it available as semantic mark-up and design with the css.
Obviously to start this you need to understand your domain - and to do that you need to watch how people currently work etc.
Jeff,
Although my University course in CS only requires command line interfaces, Iâm into doing a UI for other projects.
Once Iâve got the data format sorted out ( usually XML), program artitecture (class inheritance, etc) and any other non-UI operations, I write the UI since I figure that the UI usually dictates what data manipulation needs to be done to present that data to the user. Not to mention the fact that the UI has tons of small stuff like tooltips that need to be thought about and done.
Great post!!
Itâs great to see a lively discussion on this topic.
I think software design is very much an iterative process of discovery - gathering requirements and use cases, getting a feel for the domain objects, designing the user interface and working on the architecture. All this must come before writing code. Iâm convinced of that.
How much effort goes into each area depends a lot on the project so thereâs no strict rules for everything. Some projects need hundreds of pages of detailed specification while others can be scribbled on the back of a napkin. You have to use a bit of common sense.
But creating the architecture and back-end systems without regard for the user interface and how users actually want to work with the data (domain objects) can be disasterous.
Several years ago, one project I was involved in struggled really badly after months of careful data and architectural design and implementation. Users asked if they could edit the data in a particular way and were told that the highly optimised data structures didnât allow for that! It took many more months of re-designs and rewrites to sort it out.
This could have been due to poor requirements gathering in the first place but, in the case of this highly interactive application, the full requirements were not really evident until we had the user interface in front of us and could explore the application a bit more from a userâs perspective. Up-front UI prototyping would have really helped.
My experience with paper prototypes is that theyâre good at the early concept stage of a project but design sessions need a fair bit of planning. Unless youâre talking about making quick sketches in a note book, you need a reasonable amount of desk space (or a dedicated area away from your desk) and have some sort of prototyping âkitâ ready.
Then youâve got the hassle of how to keep a copy of the designs. You canât keep them all up on the whiteboard or laid out on a table indefinitely and just committing them to memory is a really bad idea.
I just checked out Whiteboard Photo at http://www.polyvision.com (thanks for the link Eugene) and the example results look fantastic. But youâve still got to get the images on to your computer, process them and print them before you can refer to them in your design sessions (unless the lighting was good and your camera has a large, clear display).
PowerPoint, Photoshop and generic drawing tools are used for UI and interaction design because theyâre readily available and can just about cope with the job but theyâre not really suited or intended for the task. Itâs a bit like using a plastic spoon to dig a trench. You can do it but itâs a lot harder work than it ought to be.
Our GUI Design Studio tool at http://wwww.carettasoftware.com (thanks for the mention Jeremy) and the other related tools mentioned in these comments were created to address all of these issues. Many have been around for a few years but I think thereâs still a general lack of awareness that they exist. Check them out though because they can really make a difference to your productivity and your ability to prototype.
I totally agree with youâŚ
Hi there. I am working on a tool to solve just this problem. Itâs not yet âofficially releasedâ yet, but Iâm pretty close.
http://www.balsamiq.com/products/mockups
Iâd love to hear your feedback!
Peldi
There is good article in Boxes and Arrows from December 2006 that analyzed the market for simulation/prototyping tools that is still worth reading (Visio Replacement? You Be the Judge - An Introduction to the Newest Simulation Tools by Scott McDowell).
You can find it at: http://www.boxesandarrows.com/view/visio_replaceme
Personally, Iâm no expert on software development, but a self taught hobbyist Cocoa programmer. So on that basis take my opinion with a grain of salt.
With my limited coding experience, and primarily as a user, starting with the GUI design seems natural enough. Prototyping the UI helps me to refine what my app is and what it isnât. It allows me to see what I need to do, and suggests the best way to do it, from a usability perspective.
Interface builder and the Cocoa NIB paradigm seems to fulfill many of the sugestions here. NIBs are decoupled from code - there is no way to paste handlers into button attributes, for example. It is quick and easy to prototype a GUI, and even to hook it up to a data model using bindings. Target-Action makes it easy to snap together working buttons. All this obviates the need for distinct UI protyping processes. Paper prototyping is useful, but the freedom to quickly try out many iterations of your UI in IB is liberating. And, once you fill in the blanks with your specialised code, you have a working UI, no extra work.
In my opinion, it seems wasteful to design the UI somewhere other than in your development environment. Surely this is something your IDE should be providing for you? Why do you need a separate app to mock up the UI?