Subject: RE: [hackers-il] Comments on "In the beginning there was the comm and line"

From: Chen Shapira <[email-masked]>
Date: Wed, 14 Feb 2001 11:32:06 +0200

> Use TeX or troff: they have excellent scripting capabilities.

I agree, and I use TeX (and its macros) for math related work, but I much
prefer a wysiwyg enviroment, as I find it hard to look at TeX source and
imagine what the document will look like, I'm not too interested in
extending this capability, IMO it is one of the things a computer should do
for me.

---

From: Chen Shapira <[email-masked]>
Date: Sun, 18 Feb 2001 11:58:01 +0200

> The huge number of buttons in MS-Word is a GUI disaster, and 
> I don't believe
> I'm the only one seeing that. Most MS-Word users have on 
> their screen about
> 50-100 buttons, each one smaller than a single character, with cryptic
> pictures on them. Does that remind you of anything? To me it 
> reminds of the
> pictographic writing system of the Chinese and Japanese. I 
> consider the
> alphabetic system more logical and natural (at least to me) - and the
> "alphabet" equivalent in a GUI is a menu system - each 
> operation [word] is
> composed of a small number of menu movements [characters].
> An alphabetic system can have a small number of shortcut 
> symbols, like "&" for
> "and", or "$" for "Dollar", but this number has to be small 
> when compared to
> the number of alphabet characters. Similarly a GUI can (and 
> should) have a
> toolbar, but the number of buttons on it should be small, say 
> in the order
> of 10 (or maybe maximum 20).

I'm repeating what I already said 100 times in this thread:

Every single usability professional in this planet agree's with you 100%.
Having 300 cryptic icons is a disaster.
Horrible, unuable, non-natural and un-intuitive.
And it is a direct result of having actually 4 words (point, click,
double-click, and drag) to work with, and the low imagination of some
designers.

What I'm saying in this:
1) If you program has 3 options its better to have them as buttons than as
menus because pictures are easier to remember and you have visual clues for
their existance (you don't need to read the help to find out about them)
2) If you have 30 symbols, you need menus, and some icons for the 3 most
used.
3) If you have 300 of them, you will need menus, tabs, icons, bars, and it
will be a disaster, because if you have 300, you will have 3000, so what you
really need is a language, where you can combine symbols to say new things.
I say that the natural language for GUI is gestures, and I'll refer you to
the palm-pilot example.
I'm highly interested in discussing the possibilities of gui based language,
discussing the short-commings of the current system is redundunt and
pointless.
 
> I think that when you have 50 small icons on the screen, it 
> becomes very
> hard for your brain to search for a specific icon. So you 
> either memorize
> their relative position on the screen, or move the useful buttons to a
> specific position - in any case you don't actually use all 
> those 50 buttons,
> or use some of them so rarely that finding these operations 
> in the menu
> system will be quicker than searching for them in the toolbar.

I agree.

> When I wrote a GUI a couple of years ago, I used that 
> philosophy: buttons were
> relatively large and easy to see (I'd say about 5 times the 
> area of MS-Word
> buttons on-screen), and there were a small number of them 
> (usually about 10)
> displayed at a time. The users had all operations (say, 50 of 
> them) in the
> menu system, and were expected to choose the operations they 
> most commonly
> use and put them in the toolbar.

Good thinking. Although if you have large buttons on a window application
now users will have a nagging feeling of something being wrong. This is
becaused they arent used to that.

Another usefull idea is to put most used options in an easy to reach place
(menu popping on right click, edge of the screen, etc. see where the *file*
menu is, and where the send button is on outlook)

> It took me about 1 hour to learn Grafiti (perhaps a little 
> more to learn some
> special, rarely used, symbols - I'm not sure I remember all 
> of them even now).
> So this "high learning curve" is very overrated.

higher than a virtual keyboard. I ment this as a relative term.
But it took me quite a bit more to be able to use Grafiti, so maybe one of
us is an extreme.

> One of the things I love about the Palm Pilot is how its user 
> interface is
> so refreshingly different from other systems I used in the 
> past. I'm not
> talking only about grafiti, and the fact that you have a 
> touchscreen rather
> then a mouse - another very interesting feature of the 
> standard Palm interface
> is it's non-modality: you're never "in a program" or need to 
> "stop the program
> and run something else" - you can switch in a second between 
> programs (e.g.,
> the calendar and phone book) and all the context that you had 
> last time
> remains. You can leave a game in the middle, and come back to 
> see it exactly
> as it were.

I agree! long live new UI ideas! they are far to rare.

> To me, what you just said is true only for programs you use 
> very rarely.
> When you use one program very often and for a long time, e.g.,:
>   1. You're a programmer and use the same editor (or compiler 
> or debugger)
>      all the time.
>   2. You're a writer and use the same word processor all the time
>   3. You're an artist and use the same graphic program all the time
> 
> Then you couldn't care less about this "consistency". If this 
> program wasn't
> consistent, then true, it would have been strange and take 
> you a (say) week
> to learn the different interface, but when compared to the 
> years you'll be
> using it, this week is negligable. On the other hand, 
> configurability is
> of great importance to you. If you find yourself, 10 times a 
> day, wishing
> that you had a button that, say, "changes a complete word to 
> uppercase",
> then you better have the capability to add such a shortcut.

I will seperate the desicsions into 2 categories:
1) things the user doesn't care about
2) things the user will give his life to control

When you are in a programming enviroment you'd give your life to control
syntax color, tab space, letter case, search and replace features, etc.
You don't care much about look and feel features, such as placement of tool
bars and menu items, images on icons, etc.

On the other hand it seems like in MP3 playing enviroments, people care
about look and feel and play lists, and about nothing else.

So what the users cares about should be as configurable as you can, and what
he doesn't should be consistent.

Thanks,
Chen.