topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 1:47 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Latest Jeff Atwood (Coding Horror) Column: UI-First Software Development  (Read 8661 times)

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
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.

« Last Edit: April 04, 2008, 05:33 AM by mouser »

tinjaw

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,927
    • View Profile
    • Donate to Member
I've been telling my employer this for 2 years. Maybe now they will believe me.   :-\

tinjaw

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,927
    • View Profile
    • Donate to Member
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."
-Mockup Screens - Frequently Asked Questions

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
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

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,898
    • View Profile
    • Donate to Member
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 (https://www.donation....msg108506;topicseen)
« Last Edit: April 04, 2008, 06:16 AM by justice »

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
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.
-mouser
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.
- carpe noctem

tinjaw

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,927
    • View Profile
    • Donate to Member
Hm, hadn't considered that - interesting point.

I will gladly accept my consulting fee in donation credits.  :P

Renegade

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 13,288
  • Tell me something you don't know...
    • View Profile
    • Renegade Minds
    • Donate to Member
This is one of those things that Microsoft really "gets". The Expression series are ideal for this kind of thing.
Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 6,646
    • View Profile
    • Donate to Member
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."
-Mockup Screens - Frequently Asked Questions
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.