[EMAIL PROTECTED] wrote:
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?
Sure, would you mind filing an enhancement bug?
- States there was a publication without the menubar, so maybe we can
borrow code from that.
Actually it was just another menu XSLT which matched the layout of
the site. Here's some info how this could be implemented:
http://lenya.apache.org/1_2_x/components/layout/lenya-menubar.html
- 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.
Yes
If you cannot, the reason is obvious.
I'm not sure here. If menu items disappear, I'd wonder why.
If the are greyed with a hint, I have a chance to find out.
But these questions can only be answered with user tests.
- "A basic Lenya principle is to keep the GUI in the background (I
know that this doesn't conform to your GUI principles)."
Maybe I chose the wrong expression, what I meant is that the GUI should
not interfere with the actual page layout. When starting with Lenya
(or rather Wyona CMS, as it was formerly known as), this was one of
the top requirements made by clients.
Are the design goals documented somewhere?
I don't think so ...
If necessary, we could discuss this (as we already do :) ) and
state some basic guidelines in the docs.
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"?
Not to hide it, but to put it in a small, non-prominent space
(at least in the authoring area).
- 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."
I'm open for improvement suggestions :)
Hiding the disabled items will frustrate people like me.
Maybe we should add a configuration option?
[...]
=== 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.
Actually there's an equally large number of people who do it as an
everyday job.
A customer of us (NZZ online, http://www.nzz.ch) employs a room full
of people who work with Lenya 8 hrs a day. They don't care about a
narrow learning curve, all they care about is productivity.
I don't say that a productivity-oriented GUI should be the default,
but it should be possible to configure it.
[...]
=== 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.
(Vertical) Scrolling is fine for homogenous information, like text.
But for a complex GUI, the amount of decision options on a single screen
should be limited, or at least a sophisticated grouping approach should
be used.
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.
I agree, but this rather applies to a single usecase.
The site area tabs allow to execute multiple usecases, I don't
think they should be combined on a single page.
I'm not a particular fan of tabs, but we got quite positive
feedback from users when they were introduced.
BTW, thanks for all your valuable comments!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
