Re: metallized interface (offtopic rant)

FROM : David W. Halliday
DATE : Fri Nov 01 23:48:20 2002

Simon Stapleton wrote:

> From: Phillip Hutchings <<email_removed>>
>
> <snip highly offtopic XP / OSX performance discussion>
>
>> ...
>
> ...
>
>> The 'Real World' metaphor explains this quite well.
>
>
> <rant>
>
> ...
>
> Of course, and way offtopic, the new OSX look has thrown away much
> that was good about MacOS, and much that was good about *Step, in
> favour of -  well, just 'stuff'.  Some examples:
>
> - Window close button now next to minimise button.  At least they kept
> the 'closing the window doesn't kill the app' behaviour, so we're not
> quite windows yet.

    Yes!  The Close button should be separate!  Furthermore, for
right-to-left language systems, the "most /important/ first, most
/dangerous/ last" philosophy, that was used in /most/ of the original
Mac OS (before it was called Mac OS), would dictate that the close
button /should/ be on the right, while the minimize and "optimize"
buttons should be on the left.  (Yes, I know this is exactly the
opposite of the classic Mac OS, but I submit that that was more of an
historical accident:  Just look at how the system evolved.)

> - No windowshade (except by using 3rd-party additions)
> - Minimise button.  What purpose does that serve that wasn't served by
> window shading?

    I wouldn't mind at all having both "windowshading" and minimizing.
I would use them for different purposes.  (Though, admittedly, speaking
only for myself, I prefer minimization to windowshading, most of the
time.)  One can use the "minimize" button, while the other would be
activated by double-clicking on the title bar.  (Let the user decide
which is which.  It certainly makes no sense to have both modalities for
the same function.)

> - No tear-off menus

    I certainly miss these.

> - Useless toolbar hide button on window titlebar (how often do you
> need to hide/unhide toolbars?  The only possible justification for
> this one is that it shows there is a toolbar when the bar itself is
> hidden)
> - Toolbars too damn big.  Actually, I'd go as far as to say that all
> the UI elements are now too big.  I didn't buy a 19" monitor so my
> toolbars could take up more space, dammit.

    Hopefully, there will come a day when we have a more "true" device
independent system, where we, as users, can decide how many pixels
represent a unit of length.  Right now there are too many aspects of the
user interface that insist upon being drawn based upon numbers of pixels
(though this will help shrink things as we go to displays with more than
100 pixels/inch).  (I look forward to the day when our displays will
have upward of 300 pixels/inch.)

> - Can't remotely desktop any more

    That's a biggy!

> - HelpViewer
>
> ... etc.  I could go on.  Well, I _do_ go on, but this is in danger of
> getting so offtopic I'll get booted from the list.
>
> Sadly, I think we are going to see more and more divergence from good
> UI design, and more and more metal interfaced crap, more and more
> skinnable apps, until we are as bad as windows (or, god forbid,
> X-Windows windowmanagers like enlightenment/sawfish/etc - have you
> _seen_ some of those horrible skins?).

    The only way I see this not occurring (unless Apple gets truly
dictatorial, and maybe even then, with their own faux pas) is if Apple
gives developers tools that help make good user interfaces easy
(Interface Builder is a step in this direction) while not restricting
functionality (this is, typically, where Interface Builder tends to fall
down, right now [admittedly, such is not an easy proposition]), and
Apple stops violating good user interface themselves (that's probably
the biggest kicker).

> ...
>
> Just say NO!
>
> </rant>
>
> Sorry, but I had to vent.
>
> Simon
>
> ...


<email_removed>
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.