Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: RE: cvs: apps playlist.c,1.37,1.38

RE: cvs: apps playlist.c,1.37,1.38

From: M. OReilly <moreilly_at_moreilly.com>
Date: Tue, 20 Aug 2002 17:28:15 -0400

Robert - yours is a very well written letter. I have some comments embedded
below.

>>
-----Original Message-----
From: owner-rockbox_at_cool.haxx.se [mailto:owner-rockbox_at_cool.haxx.se]On
Behalf Of Robert Tweed
Sent: Tuesday, August 20, 2002 12:09 AM
To: rockbox_at_cool.haxx.se
Subject: Re: cvs: apps playlist.c,1.37,1.38


The problem is when you have a large number of features that are only used
by a tiny minory of people. In the case of the office analogy, it's actually
the same 10% subset that most people tend to use, not an entirely different
subset. Most of the features of office are completely unknown to most users:
it's not simply a case that people choose to use different features because
they work differently, in fact most users do exactly the same jobs in
exactly the same way.
<<


That's true. There are a few major functions that a particular piece of
hardware or software is intended to do, which is really the reason for its
existence in the first place. Par example, the Archos is designed to store
and play (and in the case of the AJBR, record) mp3s. This is the reason
people use it to begin with, and is what constitutes the 10% (+/-) that
makes up the majority of use. Most people buy Word to do word processing,
not math equations, though the Word equation editor is nice in some ways.


>>
In fact, in writing this I just thought of a new term: optionware. Most
open-source software is optionware. It is stuff that tries to be everything
to everyone, or as it is known to designers "jack of all trades, master of
none" design.
<<


As long as the *ware functions for what it was designed to do, most people
won't even care about the options; generally it's only power users and above
that care. There are three types of functions (that I can think of right
now) - explicit (this is an mp3 player) functions, implied (the right arrow
handles fast forward/next track) functions, and optional ("you can set the
clock with your keychain laser") functions.

The real trick is to make the options which are included for power users
transparent (or at least unobtrusive) to the ordinary user, without
eliminating the functions for power users. (This, btw, has been my biggest
complaint against Microsoft for years - they keep taking the power users'
functionality away to make it "safer" for the ordinary user.)

Options are obviously the most easily culled due to space/time/other
limitations. Open source software is interesting in that anyone can add
their own options, which is a really neat idea. But when we're relying on
the coding expertise of a limited number of (very talented) programmers, I
think the explicit and implicit functionality should come first by far.


>>
I could pull many more examples from the world of open source, but it's a
simple point: more options = less intuitive interface, and often a less
efficient program.

- Robert
<<

This is due in large part to open source being "open-ended" to some degree.
There are very few hard limits on the coding of open-source projects like
this one, so there is no "end" in sight. IMO, it helps tremendously to have
releases - 1.0, 1.1, etc., because we have deadlines for particular pieces.
Most commercial software enterprises, however, need to know *what* they will
have ready *when*, months in advance, so their feature sets and
functionality are known quantities well in advance.

Hmmm, I think I got off-topic a little. I guess what I'm trying to say is,
for those options that 1) cause controversy, 2) are not easily implementable
or 3) require a lot of design, maybe we can actually see what sort of design
work can be done ahead of time so we can have the functionality, including
the heuristics, laid out before any of the programmers start in on it. That
might make us non-coders a little more handy to have around, too. :-)

Sorry to waste so much bandwidth.

Matt
Received on 2002-08-20

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy