[JDEV] UI opinions..

[Vivre Draco]

On 4 Aug 99,, Ben Apple sounded off on Re: [JDEV] UI opinions..:

> 	When given a choice, some users prefer buttons and some menu
> bars... I think it's a good idea to have the complete bunch in the
> menu bars, and the more basic (and frequently used) duplicated on
> the list window. 

   Guess it's time to expand on my last message (which, for those of 
you who are skimming, consisted entirely of the words  
"Configurability, configurability, configurability!").

   I agree entirely with Ben on this. Some people prefer buttons, 
others prefer menus. Personally, I like to have buttons for my most 
common functions, and everything else the program's capable of doing 
listed in the menus. Of course, not everyone will necessarily use the 
same functions as I do regularly. And so, configurability comes in.

   Provide a nice configurable toolbar to put the buttons on. Let ppl 
move it around, top, bottom, side, floating, put it wherever they 
like it. Next, DO NOT make the actual buttons included on the toolbar 
hard coded. Load them from a file.

   Personally, I'd suggest a simple, easy to edit text file. Include 
some "global" settings in the file, so it knows whether to show text 
labels, icons, or both on the buttons, whether to show button borders 
all the time, on hover, or never, and whatever other options you make 
available that'd apply to the entire toolbar (or at least all the 
buttons on the toolbar); this would probably be where you'd store the 
location of the toolbar (top, left, etc) too. You might also have a 
field saying which window-type this toolbar is associated with 
(roster, message-read, message-write, or whatever). (Note: In the 
first two cases [button borders and text/icons] you probably actually 
want them stored in a user preferences file, rather than individually 
for each toolbar, but you might want to allow individual customized 
toolbars to have settings for this that over-ride the user's usual 
settings.)

   Something similar to this would make a good, expandable, easy to 
edit specification format for the buttons:

<text label> {
   icon: <path>;
   type: <button type>;
   commands: <commands to execute>;
   etc.
}

   The intended purposes of most of these are pretty obvious, I 
think. Type is intended to specify any special option(s) that modify 
how the button works, for example you might have a "toggle" type. 
Alternately, you could do things like this as special, stand alone 
keywords, e.g. rather than "type: toggle" you might just have 
"toggle."

   This format would be pretty easily extensible without breaking 
backwards compatibility; you could add more fields if you decided you 
needed more in a later version, and old versions could ignore any 
fields that they didn't recognize.

   So far, the fields I've suggested are pretty simple and straight-
forward; the bare minimums, so to speak. But since this is a "wish 
list" as Thomas (I believe) described it, I'll add some others that 
would be extremely nice to have, if not absolutely necessary...

   First off, a tooltip field. The obvious thing would be for the 
tooltip to just repeat the text label, but usually the label will be 
one or two words intended to be shown on the button when "show text 
label" is turned on. You might want a separate field specifying what 
to show in a tooltip so that you could give a more detailed 
explanation of what the button does, like a line or two, rather than 
having to search thru the help (especially since if it's a customized 
button it wouldn't be listed in the help anywayz).

   The other thing I'd like to see is support for an optional drop-
down list of extra options... Sort of like how in Netscape you can 
click the "back" button to go to the last page you were at, or right 
click to get a list of sites you've been at recently. Alternately, 
you could do it more like in Winamp, where you hold the mouse button 
down on a button and several additional, related buttons slide out of 
the original.

   Which in a round about way brings me to my next suggestion: 
Buttons and menus can be specified almost exactly the same way. Let 
me step back a moment to clarify the basis of my idea first, though. 
There's no reason you have to just let the user customize what 
buttons are on "the toolbar"; instead, you should allow them to 
create as many customized toolbars as they want, which is one reason 
why I suggest that the toolbar text file needs to specify both what 
window type it's associated and where on the window it's supposed to 
be displayed.

   So, let me go into more detail on my thoughts on specifying a 
toolbar. Let's suggest something like this:

<toolbar name> {
   type: <toolbar type>;
   window: <window type it's associated with>;
   position: <left, right, whatever>;
   etc.
   <button name> {
      icon: <path>;
      type: <button type>;
      commands: <commands to execute>;
      etc.
   }
   <another button> { etc. }
}

   Doing it this way, or something similar, allows you to specify 
multiple toolbars per file, and seems like a fairly consistent, 
simple, extensible format. The point of the type under toolbar is 
mostly cosmetic; you could have a menu type and a buttons type, and 
then have separate settings for borders etc. for menus and buttons. 
The actual specifications under any given toolbar can be done almost 
exactly the same way regardless of whether you're dealing with 
buttons or menus, though...

   For menus, I suggest doing something basically like this:

<menu title>
.<menu item> {
   icon: <path>;
   commands: <commands to execute>;
   etc.
}
.<submenu title>
..<submenu item> {
   commands: <commands to execute>;
   etc.
}
etc.

   Or at least, something similar. Basically, if it has additional 
items under it (items following it start with a dot), then it's a 
menu and clicking on it drops down a list of the menu items. You 
could still specify an icon path and such, exactly as if it were a 
button, but most users would probably set menus to only show the text 
label.

   The specification formats above are loosely based on Cascading 
Style Sheets and mIRC scripting. The exact format could probably be 
improved upon, but this gets my basic idea across, and *could* be 
used as is, even though it may not be exactly the best way of doing 
it. I wasn't too concerned about the *precise* details as I layed 
this out because I'm sure if anyone does actually use my idea, it 
will be modified before implementation anyway.

   Ok, let's see, what's left that I'm forgetting... Well, some 
advantages of the basic format I've suggested, is that it's extremely 
configurable, easy to edit by hand with a text editor so you can make 
the design and implementation of a graphical toolbar creation tool 
low priority, and it's highly extensible. You can start out only 
supporting the most basic commands ("message.compose $selected.user" 
if you want a button to send a message to the user selected in your 
roster, or whatever), and gradually add support for more and more 
complex scripting ("if (selected.user.status = away && my.status = 
occupied)..." [or whatever]). Also, you might want to have support 
for the commands option to not actually have a command to execute, 
but access a separate script file that tells it what to do, though 
this could actually be done by having a command which runs a script 
and passes it parameters (such as "exec /usr/sbin/cooljabberfluff.pl 
$1 $2 $3," for example).

   Let's see, the icon path would always be optional. I'd suggest 
that for any menu/button/etc that doesn't have a icon specified, you 
always show the text label even if the toolbar is set to only show 
icons -- You have to show something, and having an "no icon" icon 
would just get confusing. As far as icon formats, I suggest at least 
supporting the most common formats: png, gif, tif, jpeg and such. But 
if at all possible, I'd go for vector-based graphics formats for the 
icons; since they can be resized to any size without blockiness, this 
allows the user to customize the size of the icons on the toolbars in 
their user preferences, and it means you won't have to deal with 
icons of widely varying size on one toolbar, which tends to get kinda 
ugly.

   Also, by having separate files each with a set of toolbars, you 
can include several different user interfaces in your standard 
distribution and let the user decide which they like best, without 
them having to either put up with one default config which they might 
not like, nor forcing them to figure out how to customize their own 
UI.

   Alright, I'm going to shut up now. I'm sure there are things I'm 
forgetting, but this gets my basic idea across and I can always add 
more later :)

--
"Love doesn't make the world go 'round. 
 Love makes the ride worthwhile." 
--Franklin P. Jones 

Copyright 1999 Vivre Draco (cfc at paganpaths.org)
excelsior ad infinitum -- http://www.paganpaths.org/~cfc/