UI-First Software Development


#21

another nice tool for mockup website designs is

http://dub.washington.edu/denim/

it’s designed to be used with a graphic tablet or similar.
looks like you did the design on paper, and i guess with such a tablet it would be equaly fast to do so.


#22

I talked about this theme in the past. You can read it here: http://blog.codiceplastico.com/?p=87


#23

Totally agree with what Natch said at 10:18 about paper giving the team carte blanche to rip it all up and start over.

Paper prototyping lets you act without thinking about how you’re going to act. Instead of drawing lines with a mouse, you just draw some lines. I like to use a fat sharpie on index cards. It forces you to under-design the problem. Digital tools tend to get you mired in the details too early.

You know what else really helps with design, writing, or any creative endeavor? Going outside for a nice walk by yourself and thinking about the problem at hand. You’ve gotta get away from your tools sometimes, especially tools as distracting as computers.


#24

So this unreadable colour scheme wasn’t an April Fools after all!!! TTFN.


#25

Another good tip when scribbling out UI on a whiteboard or paper is to use the fattest tipped markers you have. Most developers go for the fine points because you can be much neater and fit more information into a space but an actual page or form usually has no where near the resolution that a fine tipped marker does.


#26

Personally, unless i start a project with the fun stuff (the coding) then there’s no chance it will ever materialize, i’ll just sit with pen and paper frustrated at the lack of progress - i might sit for hours trying to decide on a good interface design without getting anywhere. If i start to code then i’m guaranteed to get somewhere. And if it means i have to redo the code in the future because i rushed in then no problem, more coding = more fun. I’d rather code multiple times than endure the frustration and disappointment of UI design (or anything artistic). I’d rather go around in circles for a while than having to sit still - at least i get some exercise - if that’s a valid analogy.


#27

I couldn’t agree more with Tom

In simple terms for any end user application as the term indicates end user requirements / use cases are a first. For me that’s the ground to start with. To validate/discuss/freeze the requirements naturally the next step is having a fully detailed and fine tuned UI specification. So mixing it with code designing / architecture makes no sense at all.

Inface application architecture/ code design must be geared up to support all kind of UI requirements and must be flexible enough to acoomodate all changes/modifications in my view.

So requirements UI first - and everything else follows isn’t it the golden age old rule ??

Though one particular aspect that many designers do not capitalize on that this article has emphasized on is the use of power point. For a recruitment process application using PowerPoint I was able to freeze almost 300 UI specs within 2 / 3 weeks. Its one of the MS products I use extensively for application development. I used dreamweaver/MS word/ Excel / EA and many others for UI protos.

But nothing beats PPT in this segment. Unless a team brain storming is on I don’t use even whiteboard or paper. Though it can be a lot of fun its unnecessary to waste all of that.


#28

LOL, I have been designing with Keynot for ages :slight_smile: It’s the best way to “show” what you want, but let the “specifics” for later. I gotta admit that I sometimes DRAW and scan what I want. My fellow programmers love me for that. :slight_smile:


#29

Allow me to introduce the “excellent” principle of “The Easier First”. :slight_smile:

Start a project, code the easy and exciting stuff until you hit a wall. Ask yourself, “is there a wall better than this one that i could be hitting my head against”? If answer is yes work your way through that wall until you hit a wall tougher than the previous one. If answer is no then change your state of mind to “this has to be done” and “the sooner the better” remind yourself of what’s on the other side (easier walls). Repeat.


#30

My only complaint is with the implicit assumption that command-line tools don’t have a UI that must be carefully considered as part of the development process – if it’s a tool someone else will use, anyway. Anyone with significant Unix experience should know this.


#31

Know thyself.


#32

I disagree, our company has always done GUI first or GUI driven application development (was originally a VB and access shop, now a c# and sql server shop and looking to move into cross platform, distributed, internet aware, db portable, dynamic language based stuff) and we are suffering now. We don’t have any good object model, our business rules and db access stuff are tightly coupled with the GUI.

It would have been better to do the object model first, then think about the db layer, then the business logic etc, before even thinking about whether this is going to be presented to the user via a web page, a windows form, a cli, a java applet or a facebook application, or even whether it wont be used by a human at all but rather a web service sitting on a remote server somewhere.

Ideally the actual program functionality would be designed well enough (gui independent) that a lightweight UI module of any type can easily be slapped on as needed.

GUI first might work for small, fully upfront designed, completely specified, user oriented tools, but in these modern times of rapidly changing requirements its just not agile enough.


#33

Forget it. A programmer should never ever design an UI. If you know what you want split the jobs to designers and programmers. we have programmers which never ever doing other things like communication or db. Highly specialiced, but far more efficient than anyone who likes to do everything by himself.


#34

What I’m doing quite often is to use Flash as tool for early interactive prototypes. It has many advantages and you can easily integrate all the pictures of your paper prototype.


#35

I’ve had tremendous luck with a mix of static HTML, paper prototyping, and digital cameras. HTML lets you design a few screens really hastily without worrying about properly aligning or nesting elements (because the browser does it for you). Print the screens out and use scissors and pens to rework the UI and develop workflows. This draws lots of players into the UI design process who might otherwise find themselves excluded, including salespeople, account reps, the customer, and users themselves. When you reach a point of agreement on a particular interface, take a photo of it — this might be all the documentation you need to move forward.


#36

Ryan:
“My two cents are to build project requirements and specification in many different media#8217;s or styles. Include the case diagrams, include the #8220;faux screenie#8217;s#8221;, and include the obligatory written word document so that it is easy for anyone to wrap their head around.”

Yes, I think that’s the best way to do it. I, for example, am not a visual person, and that probably influences my opinion. A holistic (is that the right word?) approach to specification/design has the best chances to make everyone involved understand the project.


#37

I have had a lot of success with Axure RP (http://www.axure.com/). It’s cheap, and it is really easy to build quite functional prototype screens. Best of all though, is the amount of element annotation you can do. Its straightforward to put together some very quick and dirty prototypes that can be generated to interactive HTML screens (or Windows Help files). But it is also simple to add useful information to screen elements and generate pretty thorough specification documents from the prototype.

The key things for me, for any prototyping tool, are that it needs to be extremely quick and easy to use, and the end result can never be mistaken for a real application. It has to look rough - otherwise, you find the customer gets unreasonable expectations for how much work is left. After all - to them, the UI is the application, and if the UI looks finished, then the dirty stuff behind it can’t take all that much longer surely?


#38

“UI-First Software Development” aka “Front Ahead Design (FAD)” - don’t miss this recent 1. April joke on the topic (controversy included :wink:
http://thedailywtf.com/Articles/FrontAhead-Design.aspx


#39

We use Visio and Omnigraffle extensively in work, before a line of code has been written. We go as far as creating real life clickable prototypes, user testing them, optimising for user behaviour etc.

Personally I don’t ask for a single line of code until every aspect of the UI has been created, tested and improved. I find programmers like this approach once they understand it. They know that there is a great piece of software sitting there and seem to enjoy the fact that their job is to bring it into reality.

The only downside of paper prototyping, and wireframing is that in an AJAX world it’s hard to communicate the difference between in-page interactions (JS stuff) and actual page changes.


#40

This isn’t a new idea - the RAD fad of the eighties/nineties was about this too: build forms quickly, have them accepted, add the logic later on.

The trouble is, this way you often don’t get a consistent architecture but code copy-pasted into Button triggers on forms, because the client assumes that it’s 80% done and you have not time for planning…