Re: metallized interface (offtopic rant)
Re: metallized interface (offtopic rant)
- Subject: Re: metallized interface (offtopic rant)
- From: "David W. Halliday" <email@hidden>
- Date: Fri, 01 Nov 2002 16:48:20 -0600
- Organization: TNRCC
Simon Stapleton wrote:
From: Phillip Hutchings <email@hidden>
<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@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.