[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
