On 8/31/05, Michael Wechner <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
