Summarizing...
=== Andreas Hartman ===
- Does not like scrolling.
(There is more explanation about that at the end.)
- "It would be cool to edit the navigation directly"
I built a screen for editing all the Navigation Titles. I dropped
development when our site went live because I made the changes
manually. Do you want the code?
- Likes changing menu from "File" to "Document".
I did not really suggest that, but it is one of my standard rants.
- States there was a publication without the menubar, so maybe we can
borrow code from that.
- Does not like security-sensitive GUIs.
They are one of the top reasons my applications do not need
instructions. If you can do it, the method is obvious. If you
cannot, the reason is obvious.
- "A basic Lenya principle is to keep the GUI in the background (I
know that this doesn't conform to your GUI principles)."
Are the design goals documented somewhere? I would like to read them
so I can stop making suggestions that violate them. I do not
understand "keep the GUI in the background". Is that equivalent to
"hide everything"?
- States 1.4 has mouseovers for greyed menu items.
I read an article about Usability that suggested this. I think it
"solves" the issue by adding to the problem. The user finds the
function desired, it is inactive, but somehow the user will realize
they can place the mouse over the obviously inactive area of the
screen, and text will appear explaining why clicking here does
nothing. That is not close to "Make everything obvious."
As a techie, I really wish Photoshop did that. I hate finding a
greyed option and not knowing if the graphic is in the wrong format or
I need to select a filter first. Better UI is silently changing the
format to allow this feature, or a popup "Please select a filter
first".
Non-techies just get confused by greyed options. They are less
confused by changing menus. The best answer is to let them do what
they want, make it happen behind the scenes, and only tell them when
something is really not possible. As developers, it is our job to
make everything possible.
An email program has an Attachment icon at the top, but you must be in
the Body for it to work. Many people think {I need to send this file
to Joe, so "Create Memo", "Attach File", add "Joe" to "To:", anybody
else need this?, and add a comment.} They learn to do this after
sending a few memos without the attachment. The email program should
silently add the attachment to the end of the Body, and return to the
To: field. The bad UI was to popup a message saying "That operation
cannot be completed", which just frustrates the user because the
computer is not letting them do what they want, and does not even
explain what it expects of them.
=== Felix Röthenbacher ===
- Likes removing the non-functional "Overview" tab.
- Suggests adding an in-page menu to my interface for quick access to
the sections to help avoid scrolling. (I am not against that.)
=== Jörn Nettingsmeier ===
- Does not like scrolling.
- Thinks my interface makes it easier for newbies.
- Thinks my interface makes it less productive for experienced users.
Everything should be easy for newbies, because everybody is a newbie
for some time. Most people will use Lenya infrequently. When they
come back next month, they have forgotten where the controls are
hidden. Keeping everything obvious keeps it productive for everybody.
It is possible to have "beginner" and "advanced" interfaces, but the
development effort of an "advanced" UI is not worth it for the
extremely few people who switch after learning the "beginner" UI.
- Suggests removing the top-level tabs.
The top-level tabs are confusing.
"Admin" switches to the Administration screen, which has its own
version of tabs displayed vertically. (Another place where the
default screen is non-functional.)
"Site" is about the documents.
"Authoring" is about the documents.
"Live" opens a new window. Live needs to be explained better: "Open
last published version in new window." It is not really Live; the
document displayed is from the Live area of the Authoring server.
Most advanced users will have the published version open in another
window, so this function is almost unneeded.
Site and Authoring should be combined into "Documents". There
should be a single button toggling between "Administration" and
"Documents" screens.
The "Documents" screen could have tabs: "Properties" (my interface),
"Current version" (Authoring), "Edit (Kupu)", "Edit (BXE)". Each
deserves it own screen. That moves the Edit functions from the menus
to somewhere obvious, and removes a click for the most-used function.
The choice of editors should be decided from configuration based on
DocType.
=== Scrolling
Go look at any popular web interface (such as Amazon) with information
that cannot fit on a single screen. There are 2 methods for dealing
with it:
1. If the information is sequential, use multiple pages: the Wizard interface.
2. Use scrolling.
Companies complain they lose visitors when using the Wizard interface,
because people do not want to complete several pages, although
progress indicators reduce the incompletes. The single page approach
(scrolling) uses the familiar window scrollbar as a progress
indicator.
There are no popular web interfaces that depend on tabs. The closest
is Email Folders, but most people just keep everything in Inbox.
Advanced users tend to use the keyboard more than the mouse. They
understand they can hit PageDown twice to get to all the information
in the GUI. They use the Tab key to quickly advance through the
fields. They should never be a concern when designing a GUI.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
