Responding to Andreas: == Edit all Navigation Titles I'll post that code when I have finished the Newsletter function. It should take moments to finish once that code is available.
== "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..." That code is not useful for combining the tabs. We need a new wrapper that compares the fields with their old values to decide what changed. Whether the new code handles the changes, or calls the old tasks, can be decided by the developer. == security-sensitive GUIs "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." I avoid menus. People do not understand them. (Mostly because they rarely have any logic to their layout, which I discussed earlier.) Pretend all my suggestions have been implemented: There is a button at the top "Go to Administration Screen". If you are not an Admin, that button does not appear. Non-Admins would never see the button. Admins would know something is wrong if it disappeared. Editors never see the Publish button. Reviewers see the Publish button, and will understand if it is not there. A greyed Publish is not helpful. == "A basic Lenya principle is to keep the GUI in the background. the GUI should not interfere with the actual page layout. When starting with Lenya, this was one of the top requirements made by clients. Keep the GUI in the background. Not to hide it, but to put it in a small, non-prominent space (at least in the authoring area)." I agree. But this does not apply to the current discussion. The Site tab has none of the "actual page layout". == Menu Mouseovers and other tricks "I'm open for improvement suggestions. Hiding the disabled items will frustrate people like me. Maybe we should add a configuration option?" Without menus, there is no need for these tricks. There is no disabling. There are just available functions. When everything is obvious, you will not notice anything missing. == "Everything should be easy for newbies, because everybody is a newbie for some time. Most people will use Lenya infrequently. 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." A good interface for newbies should be a good interface for experienced users. Our current discussion is removing the tabs. Those tabs require an additional click for every function. An advanced user wanting to make several changes will click many extra times. Removing the tabs improves productivity. It makes it easier for newbies because nothing is hidden, but that improves productivity for advanced users. It might even improve the server's productivity because each page is delivered and processed with no non-functional pages. === "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." Yes, I advocate the grouping approach. It is natural for me, so I do not consider it "sophisticated". The current tab approach is more sophisticated/complicated, although it is much easier for the programmer. (I do not consider the programmer's time significant compared to the lost productivity of the users.) == "This 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." How bad was the old interface if adding tabs was an improvement? === Responding to Jörn: == "changing menus are the most evil thing that has happened to user interfaces in the last years." Menus hide functions. If a function is available, it should be obvious. Web applications should not need menus; there are never enough options that hiding some of them is necessary. Menus were developed because screens were extremely limited in the early days. The original appications used a key to open a command line (such as '/' in Lotus123). A question mark on the command line showed all the options. Then it was the ALT key showed a menu. There was never more than 2 levels. The structure was obvious to the users, all of whom were advanced by today's standards because computers required understanding files and processes. Then windowing GUIs made an appearance. As the old applications were converted, the menus were kept. It was easier than redesigning the UI. The the web was created. Menus were not possible, so the new interfaces were extremely easy. The web became very popular, and older companies started moving their applicaitons to the web. They kept their menus because it was easier than redesigning the interfaces, and because they weere used to them. Menus still harm everyone. It does not matter if something disappears, turns grey, or is five levels deep. Even the old two-level menus hid functionality, and that always hurts productivity. == Removing the top-level tabs Ignore that for now. I may eventually build a prototype showing how effective a good GUI could be, but it can wait. The current issue is improving the Site tab. == Scrolling A very long page is good for both sequential and random access. When creating a page, you work top-to-bottom, and the developer should have organized the information so it feels natural. Later you skip to the section needing changes. (And links to sections at the top removes most of the scrolling.) == "Losing visitors" A good interface is enjoyable for both newbies and advanced users. A bad interface makes people look for alternatives. Whether that is replacing Lenya with a different program, avoiding using Lenya so the site becomes obsolete, or changing jobs to get away from it, it is bad for Lenya. I did a performance-tuning contract. I improved one screen from "5 minutes with a slight (3 lines) scroll" to "2 seconds without a scroll". I fixed unworking features, added a few features, and rearranged most of the GUIs. Before my revisions, the users were in one application for 8 hours every day, and worked 2 hours at other stuff. After the revisions, they worked 2 hours in the application. They could take their time (so quality increased) and do the 10 hours of work in less than 5 hours. Some of this was because my code is better; much of it was because the function they were looking for was always where they were looking. When I returned a few months later, one woman thanked me because she had seen her children more in 2 months than she had in the last 3 years. She had started looking for a new job, but had not taken an offer after the application was improved. Just because the user are "forced" to use Lenya does not mean they will like it. === The big question is will any of this be implemented. I can recommend (and justify) better interfaces. I built a prototype. I will make more suggestions if they have a chance. But does anybody care enough to work on it? solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
