Da musste ich feststellen, das auch yT mit Zeta auf demselben (korrekten) Pfad waltet...
Btw. Babelfish Übersetzung
Be Engineering Insights: Be User Interface Basics
The Be development environment is designed to make it easy and fun for you to create powerful, innovative applications. Similarly, the soon-to-appear Be user interface guidelines will be designed to help you create applications that your customers will find easy and fun to explore, learn, and use.
The BeOS doesn't try to reinvent the graphical user interface. Instead, it builds on the successful interfaces developed on a variety of platforms over the past dozen years. What's new in the BeOS is a lightweight, multitasking environment that's not beholden to bad UI design entrenched in legacy UI schemes.
You should aim to create applications that users find obvious, so they can discover and quickly come to appreciate the power (and value) of your application's features. Users shouldn't need to read all (or even any) of an application's documentation to guess how to perform most of the things it can do for them -- even if they don't understand what the application is doing at first! Even if many of your application's features are sophisticated and require detailed explanation, you can design them in a way that will help users catch on quickly if you organize them in menus and panels, so users have some categories and topics to look up in the documentation as a head start.
This article introduces you to the basic principles of the Be UI guidelines. Look for details and examples in a forthcoming edition of The Be Book.
All of an application's features should be visible as menu items or as buttons or other controls in windows or panels. Avoid implementing features that require users to hold down keys on the keyboard, use the secondary or tertiary mouse buttons, or type commands they have to remember: These techniques are great for shortcuts and they may become the preferred techniques for users experienced with an application, but you should allow users to perform each action in a more obvious way first.
Don't hide your application's features or users won't find them. Most users refer to documentation when they have a question. If users don't stumble on a feature, they won't think to look up the details in the documentation, no matter how clearly written it is.
Make every context clear: For example, it should be obvious what application every panel belongs to and what users can or should do in it. If a panel asks for information, make it clear what application is asking and what part of that application is affected.
Users find and remember features best if they perform them by directly manipulating objects on the screen -- selecting tools, dragging objects to move or alter their attributes, and so on, rather then by selecting an object and then finding a command to perform a function. For example, it's easier and more natural-feeling for a user to rotate an object by dragging a handle, than by selecting the object and choosing a Rotate command or* entering settings in a panel.
Use similar UI for similar features, from application to application, and within an application. Users will often guess how to do something new if the UI looks and works like other UI they already know.
When inventing new UI, try to build on existing UI rather than invent from whole cloth: This gives users a leg up. And never create UI that behaves opposite to other well- known UI -- that's an easy way to create a feature that users will trip on every time.
Make it obvious to users that what they're trying to do is working -- or not working. Users are often unsure whether they're doing something right, or whether they've done it at all. Help them by providing feedback for each user action.
If a task will take more than a moment, open a status panel that shows the progress of the action. Put the user in control by providing the panel with a Cancel (and maybe a Pause) button. Users don't know how long a new activity will take, and often think actions that take longer than expected simply haven't started at all.
When users manipulate graphical controls, tools, and so on, show them that their actions are having an effect. If different parts of your application's UI react differently when clicked, dragged, or pressed, change the shape of the cursor or provide some other visual clue to inform users that something different will happen. For example, when a user selects an on-screen object, highlight it. It's also helpful to change the shape of the cursor when it's over editable text or when a modal tool is selected.
Provide feedback throughout the steps of dragging and dropping: Show that the object is selected for dragging, consider changing the cursor to provide a clue as to what action the drag-and-drop will perform, and highlight or in some other way indicate that the target of the drag-and-drop will receive the object when the mouse button is released.
When a user changes a setting, apply the new value immediately if possible. A second-best approach is to apply a setting when the user clicks a Set or Apply button. Avoid forcing users to restart an application to make a new setting take effect.
Users become confident in an application (and thus learn it more quickly) if they know they're in control -- that is, if it performs only actions that a user initiates. Resist the temptation to help out users by changing information or the state of controls behind their backs. It's good to try to learn from a user's habits and remember preferred settings in panels, arrangements of windows, and other state they've set in the past, but don't "improve on" what the user has done if the reason isn't obvious and the improvement wouldn't be expected.
Maintain the state users set in windows even when they switch to other windows or applications. For example, if text is selected in a panel, don't unselect it when a user makes another window active; be sure the highlighting is restored when the panel is made active again.
The BeOS makes it easy for many applications to work simultaneously, and for each application to perform many tasks at once. Structure your application so that when activities in one area will take a while or must pause to request information from the user, activities in other areas of the application and in other applications continue uninterrupted.
Users make mistakes, but they shouldn't be punished for them. Try to alert users if their action risks losing data, and try to make it easy for them to undo actions they might regret.
The BeOS is a new world, with plenty of room to invent new ways of working and playing. Feel free to violate these UI guidelines if you have new ideas, but violate them for a deliberate and clear purpose. Users may come to love your new way to copy text, but if your new technique is only subtly or arbitrarily different than what they're used to in other applications, they'll simply be annoyed. Innovate boldly!