views:

201

answers:

7
+2  Q: 

Interface bloat

Can someone explain to me what interface bloat is (preferably with an example).

Sorry I meant interface bloat in OOP

+2  A: 

Most Microsoft products?

Interface bloat is having too much on the screen at once, particularly elements that are little used, or are confusing in their function. Probably an easier way to describe interface bloat is to look at something that does not have it, try Basecamp from 37signals. There are only a few tabs, and a few links in the header.

Interface bloat can be remedied by collapsable panes (using Javascript, for example), or drill-down menus that hide less-often used choices until they are needed.

jnunn
Notepad not included ;)
Cecil Has a Name
Best example from my point of view: the Ribbon interface.
Felix Kling
@Felix I would disagree about Ribbon. Because Office has so many options, there needs to be a way to find them quickly without providing so much information that the user is overwhelmed. The Ribbon does this pretty well. For example, to do superscript now, I don't need to click 7 times - I just click once.
JasCav
@Felix: the Ribbon was explicitely designed to remove the interface bloat of having too many toolbars and menus in Office. And I think it has succeeded.
Tommy Carlier
I agree that you can reach actions 'faster'. But nevertheless sometimes it can be very hard to find a button among those many. Maybe it is easier for new users than for those who are accustomed to the old interface. If I compare it with iWork, I feel much more comfortable with it because only those buttons are shown that are reasonable in a certain context. Ok I have to confess, my comment is subjective but I know I am not the only one how has troubles with it ;)
Felix Kling
+2  A: 

Interface bloat is the gradual addition of elements that turn what may been a simple, elegant interface into one littered with buttons, menus, options, etc. all over the place that ruin the original cohesive feel of the application. One example that comes to mind for me is iTunes. In it's early renditions, it was quite simple, but has, over time, added quite a lot of features that might qualify as bloat (iTunes DJ, Coverflow, Genius).

Nate B
+4  A: 

G'day,

Assuming you mean API and not GUI, for me I/F bloat can happen in several ways.

  1. An API just keeps getting extended and extended with new functions without any form of segregation so you finish up with a monolithic header file that becomes hard to use.
  2. The functions declared in an existing API keep getting new parameters added to their signatures so you have to keep upgrading and your existing applications are not backwards compatible.
  3. Functions in an existing API keep getting overloaded with very similar variants which can lead to difficulty selecting the relevant function to be used.

To help with this you can:

  1. Separate out the API into a series of headers and libraries so you can more easily control what parts you actually need. Any internal dependencies should be resolved automatically by the vendor so the user doesn't have to find out the dependencies by trial and error, e.g. that I need to include header file wibble.h when I only wanted to use the functions in the API declared in the shozbot.h header file.
  2. Make upgrades to the API backwards compatible by introducing overloading where applicable. But you should group the overloaded functions into categpories, e.g. if new set of overloaded functions are added to an existing API, say our_api.h, to adapt it to a new technology, say SOA, then they are provided separately in their own header file our_api_soa.h in addition to the existing header our_api.h.

HTH

Rob Wells
A: 

Interface bloat is sometimes caused by trying to have every feature one click away, as in this humorous example:

Too many toolbar buttons

(Although funny, this example isn't fair to Firefox because in this example the user added all those toolbars)

A UI design technique called "progressive disclosure" is one way to reduce interface bloat. Only expose the most frequently-used features as a top-level click. If you have less-frequently-used features that are still valuable enough to include in your app, group them in a logical way, e.g. behind a dropdown menu or other navigation element.

+1  A: 

Think of an OO language where all methods are defined in Object, even though they are only meaningful for some subclasses. That would be the most extreme example.

Adrian
+2  A: 
Juliet
A: 

An extreme example of interface bloat that most C++ programmers will be familiar with is std::basic_string. Page up and page down of member functions with only small variations, most of these functions wouldn't have had to be member functions but could have been free functions in a string utility library.

Andreas Brinck