Latest Jeff Atwood (Coding Horror) Column: UI-First Software Development

[mouser]

Jeff recently quit his day job, but thankfully his Coding Horror columns are going strong.

His most recent one is about the importance of prototyping a user-interface design before you start coding.

Before I write a single line of code, I want to have a pretty clear idea of what the user interface will look like first... Of course, UI is hard, far harder than coding for developers. It's tempting to skip the tough part and do what comes naturally -- start banging away in a code window with no real thought given to how the user will interact with the features you're building.

Remember, to the end user, the interface is the application.

I agree completely with the idea of prototyping before coding.  Personally I've found that the best way to design a program, especially if you are collaborating or working for a non-programmer, is to actually imagine the program is done, and walk through its use.

However, I do think something needs to be added.  Speaking as someone who has fallen into this trap before - it's important to realize that although "to the end user, the interface is the application", as a coder you should as much as possible separate the user interface from the guts of the application.  The user interface should be a light wrapper around the main code -- don't let it get its hooks in too deep or you'll find that maintaining the code becomes that much more difficult.  If you approach your program thinking that the user interface really IS the application, you're setting yourself up for trouble.

The "model-view-controller (MVC)" approach is a sound one, it advocates separating a program into a front-end view (the user interface), the main program logic (the controller), and the components dealing with any stored data (the model).

So yes, by all means prototype programs before coding -- walk through them with a focus on how the user interface would actually work from a users standpoint.  Then once you have that done, step back from the user interface and figure out how to code your program in a way that makes the user interface a thin (easily replaceable) layer.

http://www.codinghorror.com/blog/archives/001091.html

[tinjaw]

I've been telling my employer this for 2 years. Maybe now they will believe me. 

[tinjaw]

I'm going to add that I suggest using Mockup Screens for the same reason as the developer.

"2. Why does MockupScreens create sketches instead of "real" screens?

Showing the life-looking prototype to the customer or managers can spell disaster. They will percieve "almost finished" application and you can't say or do anything to explain otherwise. The easiest way to avoid this is to have mockups that clearly don't look even close to the real thing."

[mouser]

Showing the life-looking prototype to the customer or managers can spell disaster. They will percieve "almost finished" application and you can't say or do anything to explain otherwise."

As funny as this sounds, it's true, and it's definitely something to be concerned about.  It also may lead to the client getting fixated on a particular layout or look that may not be the ideal finished product.

[justice]

I've used Adobe Fireworks to create digital mockups in the past (very time consuming), and also Visio (but it's too general a tool so don't get the results quick enough).
Mockup screens look really promising but it crashed on me already within 15 minutes of use. (vista) Also I could imagine a more polished program although I could live with that.

Are there any other programs like it? I know Denim which is java used but the interface of that was even quirkier. We'd definately have budget for the best tool, so I'd like to hear your recommendations.
Ah there's already a thread, i'll look in there (http://www.donationcoder.com/forum/index.php?topic=12902.msg108506;topicseen)

[f0dder]

However, I do think something needs to be added.  Speaking as someone who has fallen into this trap before - it's important to realize that although "to the end user, the interface is the application", as a coder you should as much as possible separate the user interface from the guts of the application.

Amen! And this is an extremely important point. With the "RAD" (which really should be called RUID) tools like Delphi, BCB, VB etc. it's way too easy to intermingle your GUI and core logic, and this becomes really messy. Keep your "OnClick" (etc.) routines simple, calling into separate modules.

"Showing the life-looking prototype to the customer or managers can spell disaster. They will percieve "almost finished" application and you can't say or do anything to explain otherwise. The easiest way to avoid this is to have mockups that clearly don't look even close to the real thing."

Hm, hadn't considered that - interesting point.

[tinjaw]

Hm, hadn't considered that - interesting point.

I will gladly accept my consulting fee in donation credits. 

[Renegade]

This is one of those things that Microsoft really "gets". The Expression series are ideal for this kind of thing.

[Stoic Joker]

I'm going to add that I suggest using Mockup Screens for the same reason as the developer.

"2. Why does MockupScreens create sketches instead of "real" screens?

Showing the life-looking prototype to the customer or managers can spell disaster. They will percieve "almost finished" application and you can't say or do anything to explain otherwise. The easiest way to avoid this is to have mockups that clearly don't look even close to the real thing."

I've gotten burned on this one myself.  Just because it looks like a duck, walks like a duck, & quacks like a duck ... Doesn't mean it's a complete duck.