Re: Arlo, a little QA comment regarding your interview withlinux.com

[Kevin Cullis <kevincu orci com>]

John Sullivan wrote:
> 
> Kevin Cullis wrote:
> 
> <stuff deleted>
> 
> > Agreed, not everything belongs under the 80/20 rule, but looking at the
> > 80/20 rule does help in identifying features which belong closer to the
> > user and those that do not.
> >
> > For example, in GNOME in the File Manager, in order to show the hidden
> > files I have to go to the settings menu and select preferences and then
> > select the hidden files option.  While I normally don't have the show
> > hidden files selected, from a user's perspective of time, it would be
> > nice to have this in the menu itself rather than bringing up a dialog
> > box.
> 
> This is a good case to think about for the tradeoffs involved.
> 
> It is obviously faster for a user to toggle the display of "hidden" files via a
> menu item than to set the preference inside a dialog box, possibly behind a tab
> or section heading inside a dialog box.
> 
> On the other hand, in theory anyway, hidden files are hidden for a reason -- they
> aren't intended for users to futz with. So making it really easy to display them
> is likely to lead to some users getting into trouble by messing with them when
> they shouldn't.

True, but then they shouldn't be called hidden files, but
configuration/etc files to indicate that most people should leave them
alone.

> 
> Also, if you provide the menu in the menu bar, then you have to decide whether
> choosing that menu affects only the current window or all file manager windows.
> There are arguments each way, which means whichever way you choose will seem
> wrong to some people, and will probably cause usability issues for some people.

Ah, here's where it gets interesting because we're now back at the
"Defaults Preferences" issue.  Default is just that, my default, and
buttons or menu items should be exceptions to my "default preferences." 
As long as I can configure, within certain reason, my defaults, then I'm
happy, and so goes the other 80% ;-).

> Also, every menu item adds a little bit of complexity to the menus. If the
> program has 200 menu items, it is much harder to deal with than a program with 50
> menu items. It's harder to remember where things are, it's harder to find the

But menu items are easier to find than dialog boxes, who remembers them?
With a menu item, at least I can puruse the higher categories and
somewhat eliminate what I don't want.  With dialog boxes, I have to
really remember them.

> thing you're looking for, it's harder to come up to speed on which features are
> important. Sure, any given menu item seems like it isn't adding much complexity,
> but you have to think about this in terms of the big picture too -- you have to
> fit this decision into the context of all the other potential such decisions; you
> can't think of it only in isolation

Either I'm too new or I'm missing something. How can having 200 menus
with few dialog boxes be more complex than 50 menus with more dialog
boxes with tabs?  Didn't Apple's studies show that menus were faster? 
I'm a process type person, and I think in terms of getting things done,
the quicker the better because reducing cycle time makes me more
productive. Of course, we can debate "quicker" and "better," but I would
leave that up to the users and find out how THEY would consider it.  But
dog gone, it seems like we're reinventing the wheel instead of making it
a tire!

> So (like everything), it's a tradeoff. I'm not sure what the "right" answer is
> for this particular case for Nautilus. I just wanted to point out that even
> apparently simple decisions like this one are rarely simple.

Oh, and I agree, but there should be some common sense and ground to
move forward from here.

Kevin

begin:vcard 
n:Cullis;Kevin
tel;home:720-489-9283
x-mozilla-html:FALSE
adr:;;8285 S Poplar Way #202;Englewood;CO;80112;USA
version:2.1
email;internet:kevincu orci com
x-mozilla-cpt:;0
fn:Kevin Cullis
end:vcard