[openbeos] Re: scheduler/reminder

  • From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 22 Sep 2003 10:03:48 +0100 BST

> >products, but especially OSS ones, is "feature creep". Have 
> >you seen the default context menu in the latest tracker - it just 
> > keeps 
> >growing and growing. I for one would love to see the view options 
> > taken 
> >out of that (how often are they really used? They already have an 
> > entry 
> >on the "Window" menu, and keyboard shortcuts!!)
> I too agree that the Tracker context menu is big, Axel too is 
> conscious of that problem, and a discussion about that started long 
time ago.
> But it's not that you can say: "ok, let's remove this, that and that 
> other thing over there".

Somebody has to say that, and somebody has to do it, otherwise it will 
remain a problem for ever. In OSS it seems very easy to get code added, 
but infinitely harder to get it removed - that does not necessarily 
ensure good apps.

> That said, have you ever read some of "Joel on Software" pieces ? 
> Some users like to reach a command via the context menu, others via
> the "window" menu, others via a keyboard shortcut, etc. etc.
> If you don't provide to users an option where they think they can 
> find it, they won't use it. They won't use your product. They will use
> something else.

Then let them.

This project has a big scope for inovation - but if you put everything 
where users expect it, in a few years you'll end up with a clone of 
Windows :-)

Users are humans after all, they have a capability to learn and re-
learn. OBOS should not be Windows - therefore users should feel like 
the experience is different - and therefore we shouldn't be afraid to 
make them learn to do stuff differently (ie better). Some people in 
Windows copy-and-paste files using the toolbar buttons - does that mean 
Tracker should have toolbar buttons for that too?

As for context menus, they are probably the most over-used concept in 
interfaces IMHO. Word 95 was great - spell a word wrong, it gets 
underlined, bring up a context menu on it with a few spell options. 
That is really what a context menu is about - it is "contextual" to the 
point where you click.

Now context menus often just seem to mirror the menu bar. The time 
saved by not having to move the mouse is wasted by the brain having to 
scan and read a much longer list of options, and having to move the 
mouse further to find the option you want. Context menus should be as 
short as possible, otherwise a lot of their value is lost.

Users do use different methods to do the same thing, but not because 
they have a specific reason for prefering one over the other, but 
because we, the development community, couldn't decide what was the 
best way of representing the option. That meant we implemented every 
possible way to do the same thing we could think of, and assumed 
everyone would be happy. I bet if we only implemented one way for each 
type of task, current users may take some time to adjust, but complete 
computer newbies would find it much easier to get to grips with.


Other related posts: