Fog Creek Software
Discussion Board




great UI design is done by taking away, not adding

Uh, doesn't that mean the greatest, most useful app in the entire world is "Hello World"?

I think the subject line is a cutesy phrase without any real meaning - great UI design is about designing good UI's. Yes, it's often about knowing when to stop, but that doesn't mean the *only* way to improve on a good product is to remove features.

Philo

Philo
Sunday, July 27, 2003

I'm reminded of a similar phrase:

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint Exupery

I believe she was referring to writing there, but one can critique that phrase on the same merits. It's just another cute reminder phrase, like the KISS principle. It doesn't mean that you should take it literally, it means that complexity when not needed is bad.

To make something more complex than it needs to be is bad. To make it complex enough to do what it needs to is good.

Don't read so much into this, there's not that much there.

Mike Swieton
Sunday, July 27, 2003

Mike, Antoine is male.
http://www.westegg.com/exupery/

dat
Sunday, July 27, 2003

Hmm... should have looked at that name a bit closer when I copied that quote ;) Ahh well, he/she/it, what's the difference? It's all subjective anyway...

Mike Swieton
Sunday, July 27, 2003

What about Einstein's "Everything should be expressed as simply as possible, but no simpler" (roughly).  I think this is saying the same thing.  Good UI should be as simple as possible, but no simpler.  If you think the original statement is vacuous, then you might think this is too.  But I think it makes a good point which most people overlook.

Most bad UIs are cluttered with crap, rather than lacking in the ability to do something.

Andy
Sunday, July 27, 2003

I think (I hope) that phrase and those like it aren't meant to be taken literally.  I like the Einstein quote for expressing this sort of thing because it also addresses oversimplification. 

The reason that things like this are so prevalent in technical fields is that the types of people who get into those fields tend to be more prone to overcomplication than oversimplification.  The stereotypical computer programmer likes to use fancy data structures, spends days on unnecessary optimizations, etc.  These sort of sayings serve as a reminder to keep the whole picture in mind. 

Unfortunately, it's not uncommon these days to encounter people in technical fields that got into it for the money rather than because they are the technical type.  I cringe when I see things like what you quoted because there are people who will exploit it as an excuse for their laziness or lack of knowledge.  Either extreme can be a bad thing.

SomeBody
Sunday, July 27, 2003

I like the Larry Niven quote (can't be bothered to look it up) about writing, and think same applies to software, but paraphrased:

When you have something important to say, say it as clearly and simply as possible. When you have nothing in particular to say, say it anyway you like.

S. Tanna
Sunday, July 27, 2003

"Most bad UIs are cluttered with crap, rather than lacking in the ability to do something."

I beg to differ:
http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/mewtab.gif

[g]

Philo

Philo
Sunday, July 27, 2003

A good UI, in my book, comes down to how you show your information. If you plan on showing lots of things on screen, a grid might be preferable; of course, this assumes you have such a grid at hand. And more importantly, that it supports the featureset you need. If you *need* all the f ancy bells and whistles to show your data and cannot provide it, then your UI would - relatively speaking - be inferior. This, I think, contributes to why so many UI's appear lacking/broken.

Mickey Petersen
Sunday, July 27, 2003

A popular session bass player said this about playing country bass:

"Think of the simplest line you can play. And then play half."

Occam's Razor

"Of two competing theories or explanations, all other things being equal, the simpler one is to be preferred."

Entia non sunt multiplicanda praeter necessitatem

"Entities should not be multiplied beyond necessity"

Pluralitas non est ponenda sine neccesitate

Plurality should not be posited without necessity


Great UI does what it should, and no more or less. Read Donald Norman.

www.marktaw.com
Sunday, July 27, 2003

Try this link too:

http://www.aristeia.com/TKP/

James Ladd
Monday, July 28, 2003

Showing information is one thing, getting information from the user is entirely something else.

Its not that hard to do the former (though some software seems to break its neck to prove otherwise), the latter is an insoluble problem and why 80% of the time should be spent in solving it to nobody's satisfaction.

Simon Lucy
Monday, July 28, 2003

Google v Yahoo, Altavista, et al...

Need to say more?

Raddy Echt
Monday, July 28, 2003

Did Altavista lose their search engine crown because of their UI design? I thought it was because Google's search results are better because of their PageRank algorithm?

Although the Google UI is nice and uncluttered.

John Topley (www.johntopley.com)
Monday, July 28, 2003

There's a trade off between functionality and the ability to use it.

High end users with high ability levels want more and more functionality, however, if you're developing an application for 'the masses' most people won't be able to use complex functionality.

IT people generalise in the most facile of ways, especially people like Joel who have limited experience with developing software for enlightened users.

I wrote a system for a bunch of actuaries once, it had so many features even I didn't know what half of them were, and still they wanted more.

Realist
Monday, July 28, 2003

I have to agree with Simon and Realist...  What I have seen is that good design is very subjective to the task at hand.  -- Good to look at?
-- Good at extracting data?
-- Good at data entry?

In many cases, it is bad design on a subtle scale.  Slightly misaligned fields, tags all over the place, etc.  Just bad layout.  In many others however, it is "I looked at your FooBar entry system and it is a horrible UI."  Well, it was designed for the power users.  The learning curve is steep but once you learn it, you can enter data at ten times the rate of other designs.  So is it a bad UI?  No, but people will still make a "cover of the book" evaluation.

BigRoy
Monday, July 28, 2003

I need to look no further than my company's network access request form.  Its a catch-all access request form for everything from UNIX to the mainframe to PC software.  I can never find the appropriate boxes and form fields, so I simply fill out the "Other information:" memo at the bottom, as does everyone else.

We'd be much better off with either separate forms or at least some sort of wizard or smart highlighting and grouping.  That's one scary form - and what's the point if its that unusable.

Lou
Monday, July 28, 2003

I would have written you a shorter letter, but I didn't have time.
-- Blaise Pascal

Tapiwa
Monday, July 28, 2003

... this board is also pretty darned minimal.

www.marktaw.com
Monday, July 28, 2003

Monkey do as monkey do. Think with your own head pathetic people.

Pablo
Saturday, August 09, 2003

When to stop applies both ways. Don't add or remove too much. But I think removing is the way to go, at least for me. It is too easy to add all related features in one screen.

I currently work on a wizard for writing an article and then link it to a menu item. The story goes like this:

- I want to write an article, but the menu I want the link on is missing, ok create the menu. The menu has to know which page it is implemented on to show it in the proper place, ok add fields for all this. Now I have selected the new menu, now I will select the menu item (link), but it's not there. Ok, create it. Now that I have selected the menuitem I can write its article.

The menu creation part requires information the typical author has no clue about. So it is a very sysadmin like task. I removed it. Then the wizard is reduced to this:

1. Select the menu (if not there, bitch on someone until he creates it).
2a. Select the menuitem, or...
2b. Create it
3. Edit the article

The typical wizard has back and next buttons, but the next button doesn't make sense until a selection is made. The selection itself advances the wizard, so only a back button was required.

I hopefully have an easy to use wizard. It sure is simple to code...

Thomas Eyde
Tuesday, August 12, 2003

*  Recent Topics

*  Fog Creek Home