Re: To answer your question about the upcoming Style-Guide..

["Dan Kaminsky" <effugas best com>]

>I'd like to get a couple more topics rolling, among them:
>
>- the panel
>  basic configuration should be more sane and less windoze/kde like. for
>  instance, DO remove the "start button" analogy, every ui knowledgable
>  person I know agrees that it's one of the worst things ever.


Microsoft bashing.  Damn it, you can't *out*class something you can't
recognize the class *of*!  And before you pull some "newbie" argument on me,
let me tell you from personal experience that the number one thing newbies
appear to have problems with is THE MOUSE.  Are we to eliminate clicking,
dragging, double-clicking(which button?!?), and so on because newbies don't
figure it out quickly enough?  They figure out the start menu quicker.

I think the present "Unix Way" of listing *categories* of apps on the bar
instead of a single app button is tremendously wasteful.  Screen desk space
needs to deliver as much relevant information is as little space as
possible, mindful of the organizational factors of whitespace but not
excessive like 90% of the non-windows menu bars out there.  If there's one
thing we learned from Windows 95 its that windows should have VERY LITTLE
VERTICAL WHITESPACE.  Take two apps, one 95, one 3.1.  Ask a newbie which
looks more "modern."  Hell, ask any category of user.  Their response is
quite predictable.

But that's not the point.  Point is, wasted space is useless.  Most UI
suggestions don't entail every single system application recieving a screen
button; too much clutter, and *way* too little dynamic information value.
Lots of space being wasted for what is essentially advertising for what's
around to do besides what you're doing right now.  The only gain, and it is
a value, is that of reduced reachability, or the time necessary to tell your
computer you want to load a given app.  On-screen buttons have a direct
linear mouth path with but a single click to load.  But the clutter has a
way of contraverting this by forcing the user to hunt without the benefit of
alphabeticals through far too many boxes.  So this gets shot down pretty
easily.

What the standard Unix way appears to be, then, is to place *categories* of
applications on a standard bar instead of the apps themselves.  This too, is
flawed, because though there is less clutter, you no longer have the
click-line advantage, you're still wasting alot of space, and most
importantly, there's STILL no dynamic information value!  Now, email gets a
window or a box or a checkmark or a whatever because you *get new email*.
There's nothing dynamic in your app windows; you're not going to have the
soccer ball signifying games start bouncing because Starcraft just got
installed without you knowing :-)  That being said, it must then be noted
that the only value you get having apps listed on the taskbar is static--it
never changes without user intervention.

That's why the Start menu concept(maybe not the name, but who cares about
the name, really?) is actually a great one.  It's the minimum necessary
space needed to convey the fact that this is where one goes for their
applications.  That's the thing about statics.  You want to suck up as
little real estate as possible for them, so that the stuff you're really
looking for, the dynamic stuff, actually has room to operate.

Now, all this being said, there *are* definite flaws with the Start menu,
though Microsoft has begun to address a few of them.  Probably the largest
flaw is the Programs menu--WHY?  All apps should default above the
separator.  Second largest flaw--who the hell organizes software by
*company*?  But this flaw is mitigated with the standard installer script
allowing one to choose folder, as well as the long-overdue ability to
operate on objects directly inside of the start menu.  (The best part of
98/IE4 is being able to delete an entry from the start menu by a simple
rightclick-delete.)  Third flaw--major doozy itself--is that you have to
follow a specific path to get from one tree level to another.  Miss one twig
and your you fall out of the tree!

(Again, not to say 98 is wonderful--making the app menu scroll instead of
page onto another column was stupidity undeniable!  Actually, to be fair, it
was a decent idea until they forgot about pgup/pgdown/home/end and scrolling
if I hit the next letter after what's visible.  Then it stunk.)

So, what should GNOME make sure to do in response?
1)  Don't add extra branches if one doesn't have to--once someone clicks on
the Gnomeprint menu, their personal attention is usually on figuring out
where their app happens to be.

2)  The style guide should probably suggest standard apps categories for
GNOME, and we need an autoinstaller.

3)  Allow operations straight in the middle of the app tree, yes, just like
98.  After years of people screaming at Microsoft to do it, lets get it
right a bit quicker :-)

4)  About jumping through the tree:
    a)  The tree should only disappear if an outside window is *CLICKED*.
Mouse-focus users should be free to call someone an idiot in IRC and then
return to working on their app.
    b)  A doubleclick on the gnomeprint should retrace the steps of the last
walkthrough.  If my last category was apps/Office, then a double should
return me there.

5)  This is critical--Windows key must be supported by GNOME, but remappable
to other keys for boards that don't have it.  This is *critical*--I swear by
this key.  My mouse is a pinky flip away but I *love* keyboard control.

While we're in the category of beating the crap out of windows...

I think it's clear that if you click on the print, it shouldn't shrink down
if you're not dragging(<cough> Mac).  What we need is autocomplete and
tabsearch.  Click the gnomeprint once, and the first object in there is the
runbox.  In fact, if you do *any* typing after clicking the gnomeprint, you
automatically type into the runbox.  In the runbox, you could, for example:

Begin typing the first few letters of the folder or app you are looking for.
Say you were a windows drone and have your folders set up like windows.
Looking for Programs/Office/LyX?  You could type in "Pr<TAB>" and in inverse
type with the entire batch underlined, "ograms" would complete.  Press
enter, and that "branch" would reveal itself but your cursor context would
still be operational.  (Now, where to put the run box?  If we leave the
runbox in the gnomeprint first level, we're forcing the user's eyes to bat
back and forth but we're keeping consistency of where you're typing.  If we
move it, we force the user to "hunt for the box" each time it moves, we're
making it difficult to go back levels, and we're left with the question of
what to do with the *original* runbox.  This is one of the things we'll need
a mockup to figure out).  In addition, a line above or below the runbox
would list the currently active branch.  To continue:  if, after looking at
the programs branch you realize you want to go down the Office tree, type in
"Of<TAB>", which would cause autocomplete to find, say, Official Documents.
Suppose you didn't want this--not surprising.  You *could* type in
"Office<TAB>" and it'd underline the entire package(underlines thus
signifying that this is an entry the system can accept), *or* you could
press "tab" tcsh-style before this to skip onto the next "of" entry, thus
being office.  Shift-tab would go backwards.  Press enter to pop open the
office branch, or type in /l<TAB> to get LyX to open up.  Enter once more,
and your app is open, all driver by keyboard, something the original PARC
designers realized was much more efficient.  (This isn't to say that the run
menu isn't case sensitive, just that it'll go for the closest item first.)
Of course, at any time if the up or down arrow was pressed, that would
select one by one through the last opened Gnomeprint branch, similar to what
we see in Windows.

However, it gets a bit more complicated.  Suppose I want to run LyX.  Should
I have to guess if it's Programs/Office?  Should I even have to think about
it?  No way!  If I type ly, and LyX is the only app in the entire index that
begins with ly, we should see an autocomplete to Programs/Office/LyX.

Gets better, of course.  This type of system should work for file access,
meaning of course a / branch and a $HOME branch.  So, while "Pro" would
default to Programs, a simple tab would send us off to /proc.  Perhaps we
could even integrate a control-tab as a "go direct to file system without
scanning through the gnomeprint tree", though simply beginning with ~ or /
is a more efficient way to pull that puppy off.  Now, we discover why I'm
suggesting tabs *before* autocomplete.  If this system is to be applicable
to file system stuff, we have to consider the CPU and network load of ls'ing
everything.  Requiring tab *before* autocomplete prevents extra load, and
also has a way of preventing embarrassing autocompletes when people use your
computer.

Using the Gnomeprint for a file browser isn't perfect.  For one thing, the
standard method of traversing a tree is to show each branch along the way.
This can have a nasty way of forcing far too many full ls's, potentially
bringing down more than a fair share of NFS servers.  Not Good.  Perhaps
then, the default solution should be just a single branch/bar line for
midpath destinations, for example [/][usr]/[home]/[effugas]/* instead of
each directory in [home] being listed :-)

However, there's no reason to *shrink* data once it's been (painfully?)
deduced.  So, if [usr]/[home]/[effugas] has been listed fully, no real
reason to shrink this back down once we open [mail].  Besides, the user
might want to move or copy something out of [mail] into [effugas].  But what
if they want to move or copy something into, say, /tmp/effugas because it's
sucking up so much space?  If [tmp]/[effugas] is opened, it'll close the
link to the original window.  I offer two solutions to this:

1)  Gnomeprint windows should be pinnable.  In fact, there's a very strong
argument that I don't really want to make right now that says that
gnomeprint windows should really just be specially formatted GNOME file
manager windows.

2)  Bufferline.  One can drag files to the buffer, and keep on adding em up,
and then drag the buffer to whatever directory the files should go in.  It's
up for debate whether the copy/move/hardlink/symlink nature of the move
should travel in the method it was dragged to the box(which should reside as
an entry in the root gnomeprint but NOT on the GNOME bar).  Standard copy
commands should function as always inside of the gnomeprint, though.  I'm
gonna differ with some people and agree with microsoft--cutting a file
shouldn't delete it until it's pasted somewhere else, and a "move to the
buffer" shouldn't occur until that buffer is given a place to go.

Ugh there's more on my mind but I gotta move on :-)  One final thought
though--if I enter into the runbox "\usr\home\effugas\ma*", the box that
pops up should contain "ls \usr\home\effugas\ma*".   If I want full
contents, welp, . works great.

Mockups will explaint this all better, btw.

>- general layout instructions
>  there will be a lot of different gnome apps (hopefully), but a couple of
>  general guidelines should help create a consistant appearance of them.
>  for example, one already mentioned point is that there should be a rough
>  rule of thumb to not clutter the interface. this IS a gnome thing and
>  if we want gnome apps to have more in common than the main menubar, we
>  have to go into the apps as well and issue guidelines for them.


The eternal problem.  I think the underlying design idea behind GNOME, or
any UI, needs to realize this fact:

Everything that is consistent between applications should be accessable
consistently between applications.

As tempting as it is to leave as much as possible to app developers, look at
the system tray in Windows.  Do I rightclick?  Leftclick?  Depends on that
app.

That's *BAD*.

>- templates and examples
>  a "general gnome app" template program should be provided, that creates
>  a main menu, a default menubar and such, so that this work doesn't have
>  to be duplicated by every gnome programmer and is done in a consistant
>  way.
>  also example programs should be distributed to end-users (i.e. non-geek,
>  non-gnome-participants - people who only care that it WORKS) to test the
>  various approaches that have, and will again, surface in our discussions.


Agreed.

>I absolutely agree on that. my point went to say that we have to think
about
>what's good for GNOME - no matter whether it's done differently on other
>systems. if there's a good reason to throw overboard a convention, no
matter
>how common or "well-used-to", we should do it. people have the ability to
>relearn, and if how we do it really is better, they will have the
>willingness, too.


Well, it's an issue of cost-benefit analysis.  St. Thomas Aquinas said that
it's OK to rebel, but not just any time.  There's an inherent pain in
revolution, or in fighting for the just cause.  Therefore, it's only moral
and right to rebel against the law if the gains caused by removing the law
outweigh the pain caused by a mass of people violating the rules of
society(or in this case, computing).

>
>> > and this is the reason I put time into gnome, but have deleted kde
after
>> > checking it out. :)
>>
>> Indeed, a wise decision. :)
>
>however, I don't like the flame-war very much. I do like the talks between
>the projects.
>I don't dig the license discussion over kde. qt license is of some
>importance, but not much. what I didn't like on kde was the kwm and several
>of the core kde features. and I will fight tooth and nail to avoid the same
>mistakes being made in gnome. I haven't taken the time to talk to screen
>designers, and others to get hit with the "everyone does it this way"
>argument.


Bleagh.  Problem with K is simple...they're embracing and extending X.  What
Linus doesn't realize about K is that it's different than a standard app...I
have *no* problem with anybody writing a program that's licensed in any way.
I *do* have a problem when people who didn't write the initial program being
encouraged to write for a closed platform while believing it's open.

But whose whining?  In a world without pocketbook voting, I'll use my meager
mental resources to make GNOME a better app.  Even better, I hope :-)

>so in the end I'd like to join the guy who asked that you publish
EVERYTHING
>style-guid'ish to this list before the general public sees it. there are a
>few people here, and many more indirectly involved (as in "someone here
>knows someone who...") that know quite a lot about specific and/or more
>general aspects of ui design. you should listen to them. listen, not obey,
>we all agree that in the end the one who has to code the stuff has the
final
>decision on the matter.


Welp, if you've got arguments, justify them.  I didn't justify much of this
stuff because I'm looking to see what people don't understand and don't
like.  I'll clarify once I hear that.

>The universe does not have laws -- it has habits, and habits can be broken.


The universe is a bad habit, but I can't seem to break it.