Re: Stop the bling, fergawdssake!

On 12/11/2011 12:07 PM, Andr=E9 Neves wrote:
> It seems to me like you're blaming Firefox for Microsoft's inability
> to, or lack of will to, keep the Skype extension up to date.
> Am I wrong?
> I hope so, because this would be a "dick move".

Well, there's no incentive for MS to keep the plugin compatible with FF....

> I also very strongly disagree with your opinion that the upgrades
> above 3.x have zero or negative effects on usability:
> - The area of the browser window for display of webpages was augmented
> immensely;

Two lines is "immensely"????? Anyhow, not an issue, now that all new =

monitors are hi-res.

> - The condensed menu speeds access to the most used features;

Menu design, button placement, etc is a perennial issue, and theoretical =

talk is pointless. Consider that Apple placed the application's menu bar =

on the desktop, because theoretically that would result in shorter mouse =

moves. It's one of the dumbest design decision ever made IMO.

There are few logical aspects to menu design - I know, I designed lots =

of menus, back when I was writing small apps for myself because no one =

made what I wanted. Many of the choices are arbitrary, and for many =

their placement is a matter of history. Eg, Options" vs "Preferences" =

and "Tools" vs "Edit" for the location of those choices on  DOS- vs =

*nix-derived OSs.

Any time a design feature is largely or wholly arbitrary, it's =

_necessary_ to agree on  and adhere to some standard, else people will =

make silly (and in some contexts lethal) mistakes. Aircraft designers of =

aircraft have figured this out, so why do program developers resist =

standards? And even pride themselves on change for the sake of change?

Watch actual users and how they use the menus: Once a person is used to =

a particular menu design, they mouse to what they want automatically. =

It's like driving a car: over 90% of what we do while driving we do =

automatically (and therefore very fast, BTW.)

IME, condensed menus in practice means submenus, and each submenu adds =

an extra move.

As for speed of access to most-used features: I've found that typing in =

a familiar URL is often  faster than finding it in Bookmarks.

> - There is a print preview option;<3

Yup, and NB that was added before 3.

> - There are tab groups;

Tab groups? If you just mean tabs, well, that began with 3.

> - The about window checks, and tells the user, whether Firefox is up
> to date - further offering an option to get those updates;

Providing a program's version number is SOP for many years now. As for =

the option to get the latest updates: redundant, since FF checks for =

updates by default. But lately, you have go to a sub-menu and uncheck =

"Automatically download..." Bah! Double bah! Triple bah! No app should =

update by default, not even for, nay  _especially_ not for the average =

(naive) user.

> - The downloads window no longer jumps on your face when you get stuff;

I don't understand. I want to see the d/l window, so I can decide where =

to put the stuff. Which I do 90% of the time. Dumping it all into one =

place by default is not a time saver in the long run.

> - etc?

- Changes in names, eg, from Organise Bookmarks to Show All Bookmarks: =

why? Users knew what the old name meant.
- Hiding the Menu bar by default. I think having the option to hide it =

is fine, but hiding it by default? You should've heard my wife's wails =

when it disappeared after an automatic update (now turned off). And my =

curses until I found that clicking on an "empty spot" brought up the =

menu to unhide it. The "logical"access to that would be right-click on =

title bar, right?

> These contradict, IMO, your opinion.
> Many others are too good for me to have noticed, or they feel so
> natural that I can't remember them as differences from 3.x .

IOW, you've habituated yourself to the later versions of FF. Good for =

you. But that merely demonstrates my point, which is, that a program =

update should require little new learning, and no unlearning.

We've gone back to 3.6.24 on both machines because every change above 3 =

required unlearning something. Updates shouldn't do that. Learning =

something new for a new feature is fine. Unlearning something because a =

feature was changed or hidden is bad design.

> And I am not even a usability person, I am just a power user who
>  infrequently reads dev-usability.
>
> I'm sorry, I think your contribution lacks solid fundaments.
> Maybe you can review and improve it?

Well, I'm a power user, too (and I bottom post). I'm also a design geek, =

who appreciates all aspects of design. That's why I can tell the =

difference between an elegant kettle and a usable one, for example. I =

also taught logic, so I know the difference between logical and =

reasonable. And, as said, I've designed and written programs to suit =

myself, during which exercises I found that designing the user-interface =

was a knottier problem than designing program structure. Why? Because =

any program worth writing/using has several different paths through its =

task-space. Setting up a menu system so that it's easy to navigate any =

needed path is not trivial. See the Travelling Salesman problem for a =

sense of how difficult it is.

The ergonomics of program design are not AFAIK well understood, though =

many attempts have been made. But since I was the go-to guy for =

computers in my school when we first started using them, I've had enough =

practical experience watching how people use computers to tell you that =

the first rule of program design is:

Study how people actually do a task; then design a program that enables =

them to do it without thinking about how they do it.

Easier said than done.

Have a good day,
Wolf K.