You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by so...@gmail.com on 2005/09/01 06:26:53 UTC
Re: Too many tabs in site area
On 8/31/05, Michael Wechner <mi...@wyona.com> wrote:
> solprovider@gmail.com wrote:
> >Browser-based applications should put as much information on a single
> >page in a single column (two table columns for label and information)
> >with a single "Save Everything" button at the bottom. Vertical
> >scrolling is good. Tabs (each with their own Save buttons) are bad.
> >Combining all of the tabs into a single page would be a major
> >improvement.
> >Check out:
> > http://test.solprovider.com/lenyasite/
> cool
>
> >The changes are:
> >1. Tabs combined and removed.
> >2. Information reorganized for usability.
> it seems to me that Lenya specific data (which is generic for
> all documents) and Meta data (which can be document or publication specific)
> should be cleary separated.
I rearranged everything from a pure Usability perspective. From a
Developer perspective, it would be best to separate the Lenya and
ResourceType information. Add a new DIV after the general information
(just before Assets) with easily configurable additional fields. The
configuration would be similar to the Flow Forms (for fieldnames,
datatype, choices) plus the XPath for where to store it on the
document.
> >[...]
> >Pull-down menus are understood by almost everyone and are not as
> >unproductive as tabs,
> I don't fully understand what you mean. Can you explain a bit more?
Users can misunderstand almost every interface.
Cars have a wheel for turning, a couple of pedals, a few switches for
lights and windshield wipers. Most people require lessons to learn to
drive. There are also a few laws to learn, but most of them are "Read
and obey signs." People still have trouble with them after driving
for years.
DuPont called me because an application I designed and built 2 years
earlier did not have a manual. After a short conversation, they
decided if over 2000 people could use it for years without one support
call, it did not need a manual.
I built an application for a supermarket chain. The one support call
asked how to "Do This"; the answer was the big button labelled "Do
This" at the top of the screen. One person had trouble finding it
because I had not put the button in the proper context.
There are two rules for good usability:
1. Make every function as obvious as possible.
2. Require the least action for every function.
Tabs and pull-down menus violate both rules.
Tabs hide information. They require clicking to display something
related to the current something. You often need information from
another tab to decide what to do on the current tab. How do you
decide the Navigation Title and Document Title when you cannot see the
page?
Pull-down menus hide functions. Worse, the common naming convention
of "File" "Edit" "Help" rarely means anything to a novice.
- Files are an obsolete storage system. Most people do not understand
files. In Lenya, the basic unit is the "document", which stores its
information in several files for different languages, plus some
information stored in sitetree.xml, plus the field definitions in the
DocType. So call the menu "Document" or move the functions onto the
page where they are visible.
- The Edit menu rarely has much to do with editing (maybe Cut, Copy,
Paste). Changing a document's properties belongs on the "Document"
menu, or on the page where they are obvious.
- "Help" might be obvious, but context-sensitive and always-obvious
comments on the page are much better. The Assets section "(No
whitespace, no special characters)" is a good example. Why is "View
Logs" on the "Help" menu?
I have designed many, many applications with workflow; I have never
used a "Workflow" menu as the primary control. Security-sensitive and
status-sensitive buttons on the page are much better.
If I am a Reviewer, I can Publish if the document has been changed.
If the latest version was published, the Publish button is replaced by
"The latest version has been published" so I know why the button is
missing. I never have to Submit, because there is no approval process
for me. I also have a "Reject" button if the current version was
submitted but not published.
If I am an Editor, I can "Submit for Review". If the latest version
was submitted, the button is replaced by "The current version has been
submitted for approval." I never see the Publish button because I
cannot use it.
Oh, and pull-down menus encourage short names for functions. "Submit"
should be "Submit for Review". "Copy" should be "Copy selected text".
Never underestimate the power of a few additional words.
Any function on a pull-down can be handled with a button on the page.
The pull-down requires 2 or more clicks; a button on the page requires
one click. A pull-down may be context-sensitive, but the user never
sees it, and rarely understands why something is greyed. A button can
be extremely context-sensitive by placing it near the relevant
information. Imagine how poor the interface would be if the "Browse
for File" and "Add Asset" buttons were hidden on a pull-down menu.
> >but button/links on the page are more visible
> >and easier to understand, especially when placed in context. See the
> >"New Language" button for an example. Repeatedly explaining to every
> >content manager to use the Edit menu for changing the Menu Title or
> >the Visibility is frustrating.
> >
> >More possible improvements:
> >1. The Workflow menu could be moved onto the page.
> >2. "New document" and "Move Up/Down" (or better, "Move to Here" and
> >"Move After" icons in context) could be moved to icons on the left
> >menu. This could make the left menu rather messy.
> >
> >The difficult part will be making the dynamic tables work. Best would
> >probably be to refresh the page, remembering all the values that have
> >been changed but not saved. It might need a "Revert to last saved
> >values" button.
> it seems to me that this is one of the major problems. Let's say
> I have a changed some Meta data and at the same time I will revert
> to an older document version ... Where do I click? I think this
> leads to very confusing situations and it seems to me that this
> the major reasons for keeping separate screens for the different tasks.
That confused even you, and you know Lenya well, so it must be
incredibly poor design. Saving the current information should create
a new version. Store the Meta data with this version of the document.
Reverting the version must also revert the Meta information. (I
discourage reverting moves, since the older version's parent may not
exist. Moves should be permanent, or possibly allow an immediate Undo
if my suggestion to add "Move here" icons to the sitetree is
implemented.)
The prototype at:
http://test.solprovider.com/lenyasite/
removes this confusion. If you Rollback to an earlier version, all
information (Meta and whatever) also rollbacks. That is why the
versions are after the "Save everything" button, because the versions
and history are not related to the current information. Maybe we
should add a bigger break or use another color for the later sections?
A "Compare Versions" function would help if information from multiple
versions needs to be merged.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Too many tabs in site area
Posted by Felix Röthenbacher <fe...@wyona.com>.
solprovider@gmail.com wrote:
> On 8/31/05, Michael Wechner <mi...@wyona.com> wrote:
>
>>solprovider@gmail.com wrote:
>>
>>>Browser-based applications should put as much information on a single
>>>page in a single column (two table columns for label and information)
>>>with a single "Save Everything" button at the bottom. Vertical
>>>scrolling is good. Tabs (each with their own Save buttons) are bad.
>>>Combining all of the tabs into a single page would be a major
>>>improvement.
>>>Check out:
>>>http://test.solprovider.com/lenyasite/
>>
>>cool
>>
>>
>>>The changes are:
>>>1. Tabs combined and removed.
>>>2. Information reorganized for usability.
>>
>>it seems to me that Lenya specific data (which is generic for
>>all documents) and Meta data (which can be document or publication specific)
>>should be cleary separated.
>
I also would suggest to put more information on a page. The overview
tab, as it is now, is rather useless, as I have to click *at least*
once more to change some settings. Combining overview information
with the possibility to change settings on one page would be a
major improvement from the user perspective. Maybe the tabs can
be kept for in-page linking to the right place. This way, scrolling
may be omitted.
- Felix
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Too many tabs in site area
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@gmail.com wrote:
[...]
> Tabs hide information. They require clicking to display something
> related to the current something. You often need information from
> another tab to decide what to do on the current tab. How do you
> decide the Navigation Title and Document Title when you cannot see the
> page?
It would be cool to edit the navigation directly ...
Actually it should be possible to setup a BXE environment for
the site structure.
> Pull-down menus hide functions. Worse, the common naming convention
> of "File" "Edit" "Help" rarely means anything to a novice.
> - Files are an obsolete storage system. Most people do not understand
> files. In Lenya, the basic unit is the "document", which stores its
> information in several files for different languages, plus some
> information stored in sitetree.xml, plus the field definitions in the
> DocType.
> So call the menu "Document"
+1
> or move the functions onto the page where they are visible.
> - The Edit menu rarely has much to do with editing (maybe Cut, Copy,
> Paste). Changing a document's properties belongs on the "Document"
> menu, or on the page where they are obvious.
IMO menu titles with orthogonal meanings (Document / Edit) should be
avoided.
How about
Document Sub-Site
------------------------------
Edit with BXE Cut
Edit with Forms Copy
Change Nav Title Paste
New Move Up
Move Down
Delete
> - "Help" might be obvious, but context-sensitive and always-obvious
> comments on the page are much better. The Assets section "(No
> whitespace, no special characters)" is a good example. Why is "View
> Logs" on the "Help" menu?
>
> I have designed many, many applications with workflow; I have never
> used a "Workflow" menu as the primary control. Security-sensitive and
> status-sensitive buttons on the page are much better.
The Lenya menubar is just a default, generic approach.
The framework character of Lenya doesn't allow to insert GUI elements
into a page by default - we just don't know how a page would look like.
If you want to change the GUI for your publication - just go ahead.
We once created a publication without a menubar, where the GUI elements
were integrated in the HTML page. It worked fine.
> If I am a Reviewer, I can Publish if the document has been changed.
> If the latest version was published, the Publish button is replaced by
> "The latest version has been published" so I know why the button is
> missing. I never have to Submit, because there is no approval process
> for me. I also have a "Reject" button if the current version was
> submitted but not published.
>
> If I am an Editor, I can "Submit for Review". If the latest version
> was submitted, the button is replaced by "The current version has been
> submitted for approval." I never see the Publish button because I
> cannot use it.
This would mean that the GUI might change from page to page
(if you're an editor on doc A and a reviewer on doc B) ...
From what I learned up to now that generally isn't recommended.
> Oh, and pull-down menus encourage short names for functions. "Submit"
> should be "Submit for Review". "Copy" should be "Copy selected text".
> Never underestimate the power of a few additional words.
>
> Any function on a pull-down can be handled with a button on the page.
> The pull-down requires 2 or more clicks; a button on the page requires
> one click.
But where to place the button?
A basic Lenya principle is to keep the GUI in the background (I know
that this doesn't conform to your GUI principles).
> A pull-down may be context-sensitive, but the user never
> sees it, and rarely understands why something is greyed.
This has been taken care of in 1.4, greyed menu items have a mouseover
hint. Not perfect, but better than 1.2.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org