The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Specifiying features with (primarily) just a UI

I usually start an app design with a UI sketch.  I always thought that was a bit unprofessional or unscientific, but it's always felt very natural, so that's how I've always done it.

I was just thinking today that if you have a really well designed UI, it should be obvious how the program works.  The usability folks migt say that the UI is an affordance (it looks like what it does). Sort of how a round knob looks like you rotate it, a flat button looks like you push it, etc.

Any thoughts on this?

Obviously, the UI can't tell the programmer what the ARCHITECTURE would be. But a UI mock up seems like a good way to express FEATURES.  And of course, you'd probably need to have some way to "check off" the status of a feauture (finished? Tested? Buggy?)
Mr. Analogy {ISV owner} Send private email
Friday, January 21, 2005
 
 
That works really well for some types of applications, but if you prototype a compiler that way your "beautiful UI from which all code can obviously and trivially be derived by one-armed unloved monkeys from Elbonia" would be a textbox.

Joking aside, I think that the key issue is whether it's really possible (or likely) to have multiple types of user interfaces.  One mistake that I've seen very often is when people build the UI first and then write the code around it in a rigid way.  They let the naturally messy UI code infect other, more subtle and important, parts of their code.

My typical approach is actually the exact reverse order of what you're suggesting.  I first try to figure out the structure of the problem, the domains and types that are relevant, and the logically distinct units that will make up the whole system.  Once I get to the most basic levels in this process, it's usually pretty easy to derive a UI (or attach multiple UIs for different usage scenarios).
Kalani Send private email
Friday, January 21, 2005
 
 
That's basically the approach I use. Since I don't create a GUI in my current job, I start off thinking about the inputs, outputs, and configuration files. That's how I define the problem in explicit terms.

Once I envision the correct behavior, I can crank out the code that does the right thing. I build the simplest solution I can think of. However, various abstractions do emerge, some of which are visible to someone running the program and some of which are hidden.

Here's the weakness in starting with an engine and then building a UI. The resulting UI often contains artifacts related to the engine design, and isn't as easy-to-use or intuitive as it could be. Going the other direction, given a well-defined UI and behavior, I'm capable of translating those specs into code.
Julian
Saturday, January 22, 2005
 
 
The UI and the application have little to do with each other. The same functionality could be delivered over a cli, soap api, thick client, etc.
son of parnas
Saturday, January 22, 2005
 
 
son of parnas,

Counterexamples: Word, Excel, Powerpoint, Outlook, Internet Explorer, Outlook Express, Photoshop, Acrobat...

To think that the UI is some replacable cog in an application is a mistake.  Most applications do not have as trivial of an interface as you describe.

To the OP, at my previous employment we used that model to design our web applications.  The entire design was created in HTML and then it was my job to "make it work".  We'd go over the design a few times discussing functionality, changing thing, etc.  Once that was done it was pretty obvious, from the design, what the application needed to do.
Almost Anonymous Send private email
Saturday, January 22, 2005
 
 
I think you are confusing the functional side of the app with the technical side of the app. Please re-read the following:

http://www.joelonsoftware.com/articles/fog0000000035.html

These 2 things are seperate. The user obviously sees the GUI (if it is an app with a gui as opposed to a console app) and the user doesn't necessarily care how you implemented the app inside. Well sometimes they do, but not the average user... not for shrinkwrap apps anyway.

I don't think it is a good idea to merge these two parts for development. It is better to keep them seperate and keep two seperate check-off sheets for progress.
dilbert
Saturday, January 22, 2005
 
 
> Counterexamples: Word, Excel, Powerpoint, Outlook,
> Internet Explorer, Outlook Express, Photoshop, Acrobat

Point taken. Most of these have a large underling core engine available through an API, but there are a lot of GUI only behaviours as well.
son of parnas
Saturday, January 22, 2005
 
 
"""That works really well for some types of applications, but if you prototype a compiler that way your "beautiful UI from which all code can obviously and trivially be derived by one-armed unloved monkeys from Elbonia" would be a textbox."""

"""The UI and the application have little to do with each other. The same functionality could be delivered over a cli, soap api, thick client, etc."""

"""Counterexamples: Word, Excel, Powerpoint, Outlook, Internet Explorer, Outlook Express, Photoshop, Acrobat..."""

Thought: folk seem to be using an overly-narrow definition of 'user interface' here. CLI, SOAP API, programming language syntax, etc. are all types of UI too. An application can also have more than one type of UI, which may provide equivalent and/or different functionality; e.g. Word, Excel, Photoshop all have extensive RPC scripting interfaces in addition to graphical ones.

Working out a rough UI design seems a reasonable first step towards nailing down a design, no different to roughing out the public methods of a class before working out and filling in the actual implementation. Doesn't matter if it's sketching a GUI, or working out RPC calls, or mocking up programs in a yet-to-be-implemented programming language - after all, won't matter how good your internal architecture is if nobody can figure out how to interact with the damn thing. :)

/2c
has Send private email
Saturday, January 22, 2005
 
 
Currently finishing up a project based on exactly what you are trying - building off a UI.

Definitely worked better than building off any other part of the spec.  But I've run into problems with my db design (laid out immediately after UI) that I think a better spec writer would have found (through some kind of checklist of functionality?).  Also, what worked very well for me as a spec was not too helpful for other people as they came on.

It's hard for me to judge because I don't know how to make a "real" spec, but my suspicion is I should have immediately brought my ui to a real spec writer to flesh out a complete spec.  Even though I was very careful, there was lots of avoidable rework that would have easily paid for someone great.

Mike
Bankstrong Send private email
Sunday, January 23, 2005
 
 
"I should have immediately brought my ui to a real spec writer to flesh out a complete spec.  Even though I was very careful, there was lots of avoidable rework that would have easily paid for someone great."


NEW CONSULTING GIG:
SPEC EDITOR /REVIEWER
I wonder if a good spec writer could work like a good book editor: you show them a draft and they could read it and say "hmmm... this isn't clear. That's ambiguous. This is too specific".


If so, that could be easy to outsource. They might not need to know about how your software works. They're essentially checking your spec for useability: is your spec clear enough for the average programmer.

Ideally, a good programmer could do this for you. But that assumes they have good english skills and project management skills. E.g., a good PM might have enough experience to know where specs can go wrong.


And the beauty is that you could probably show them only a fraction of your spec and, in 10 minutes they might be able to demonstrate to you things that you missed.
Mr. Analogy {Shrinkwrap ISV owner) Send private email
Sunday, January 23, 2005
 
 
CLARIFICATIONS

1. I read the Joel article. (Thanks for linking. I'd read it before, but it deserved rereading).

I'm talking about FUNCTIONAL SPECS for a shrink wrap desktop app for a non-technical user.

2. When I say UI I mean the screen UI for a non-technical user. I'm not talking about APIs, etc.

3.  But even with designing programmer interfaces (class methods, etc.) I've found the best method is to IMAGINE USING THE CLASS. That will show you what you need from the class, how the interface should be structured, what names to give things.
E.g., instead of a method called GetGasMileage you might instead, from USING the class in real code, realize that:
car.MilesPerGallon  is a better method name.
Mr. Analogy {Shrinkwrap ISV owner) Send private email
Sunday, January 23, 2005
 
 
>>I always thought that was a bit unprofessional or unscientific

I don't know why you think this. I've always done it this way because I want to think of the software from the user's perspective.

Having "grown up" in a MS programming environment, I could never get my mind wrapped around the MVC pattern. The way I look at event-driven programming, the user is the implicit controller acting through the view (UI) upon the model.

I realize to most Windows programmers, this is stating the obvious, but I don't think of it from a coding perspective.  I think of it from a how-to-approach-the-problem perspective.

When I've tried to implement an MVC pattern, it's for me hard not to think of it in terms of the program controlling the user instead of the user controlling the program.
Cowboy coder
Monday, January 24, 2005
 
 
Well, I think you can certainly get a long way with UI-driven specification, but then you need some scenarios to flesh out the "invisible" details.

For example, a simple meial client would show a nice picture of an inbox and a detail view of the message.

However, this doesn't say anything about automatic checks for new mail, filtering policies, what sorts of mail protocols you support, and so on.

So how would you capture functional requirements that aren't visible?

I used to be a proponent of UI-driven design, until I realised its more like "use case" driven design.  How will a user use this software, and what does the software need to do to support it?

Still, UI mockups with a bit of scenario text (what kind of users are using the software, and what goals are they trying to reach)  should be fine for many applications.
Dave C Send private email
Monday, January 24, 2005
 
 
meial = mail above ;)
Dave C Send private email
Monday, January 24, 2005
 
 
Clients Can't tell you what they want, until they see it.

Check out this guy's wireframe idea:
http://www.halhelms.com/index.cfm?fuseaction=newsletters.halsteve&issue=4

He makes some excellent points.
Stacy Murray Send private email
Monday, January 24, 2005
 
 
my 2 cents worth: I've just finished writing a spec and without a doubt a picture speaks volumes - and it's one of the only ways to sell the concept to the people in Marketing ( you know it's true ).  Even among fellow developers, it's much easier pointing at a mockup sketch to discuss functionality than for people to quickly get their head around a bunch of abstractions. So hand in hand with good writeup, it's an unbeatable combination because it leaves no ambiguity - very professional.

In addition it lets your other brain hemisphere contribute by automatically testing the design for consistencies from your intuitive side - the hint is that if you can't actually express it on the screen then the concept is probably flawed.  I would venture that all the good designers do address an application's appearance because their primary concern should be the user experience - of which the UI is a large part.
Warren Bullock Send private email
Tuesday, January 25, 2005
 
 
has, I can appreciate a more abstract definition of user interface but I was responding to what I thought was Mr. Analogy's particular definition of it (as a window with buttons and so on).  Maybe my response was less to Mr. Analogy and more to a previous employer who'd describe too much about the UI of the applications he wanted (e.g.: "OK, so I want a window with a button right here ::draws window:: and a green listbox with a ...").

Mr. Analogy, yes I think that your last description is actually the typical way that people design things (if they're designing them very well at all).  If a bad designer ran Google, you'd type in the name of the internal cluster where you want your query to run, and a million other bits of extraneous implementation-specific information (maybe manually construct the parse tree for your expression for good measure).  The idea is to minimize the work required to use your widget.  But actual graphical user interfaces are in the vast minority of such interfaces.
Kalani Send private email
Tuesday, January 25, 2005
 
 
I think it makes a lot of sense to design the user interface before anything else. But I also think it's important to delay the writing of GUI code until the very last stage of development. That way, you enforce a clear delineation between UI code and business-logic code.

I personally prefer to think of desktop development as client-server development in which the client happens to be on the same machine (or even in the same compiled application) as the server.
Benji Smith Send private email
Tuesday, January 25, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz