bunny– no, iceberg

I should tell you to rush over and read Joel on Software – The Iceberg Secret, Revealed because […]

I should tell you to rush over and read Joel on Software – The Iceberg Secret, Revealed because it reveals important things nonprogrammers need know about programming so they don’t lose their minds during projects, and point out it’s written in the lovely non-techie Joel style and even has some great insights into client-consultant relations but really all I want to say is…

bunny!

bunny.

bunny!

5 Comments

Add Yours
  1. 2
    Peter

    “If you can, build your UI in such a way that unfinished parts look unfinished. For example, use scrawls for the icons on the toolbar until the functionality is there.”

    That is brilliant advice. I’m gonna use that this week.

  2. 3
    vanderwal

    Yes, this another reason to develop with wireframes. Offer functionality in a wireframe with images pooping in displaying a GIF with the words image1, image2, etc. This tends to get the point across that we are not done and what is important is not the GUI, but the functionality and possibly the layout of the page/screen. If we are building an information application where the user (and also the client) needs to understand the functional elements and see what works and does not work so to get buy-in a simple wireframe works well. Understanding the information we work with is important so to grasp what metadata might be needed so to capture it or create it to help functionality in the application, or more importantly across applications.

  3. 4
    James Buckley

    “If you can, build your UI in such a way that unfinished parts look unfinished. For example, use scrawls for the icons on the toolbar until the functionality is there.”

    Common sense for any graphic designer, we often use greeking to simulate text while working on formating and design. It keeps the client from concentrating on words when its the design that is usually the focus.

  4. 5
    Andrew

    re: “greeking” text

    One of the points that Joel makes is that often using “dummy” data causes needless distractions: clients who aren’t expert in evaluating interfaces sieze on that wrong-looking data, since that _is_ what they’re experts in. Using realistic, or even real data in UI prototypes will give them additional “finish.”

    Of course, that distraction can be useful if you want the clients to have something easy to worry about.

Comments are closed.