Copyright (c) Hyperion Entertainment and contributors.
Difference between revisions of "User Interface Style Guide"
Jump to navigation
Jump to search
Steven Solie (talk | contribs) |
Steven Solie (talk | contribs) |
||
| Line 46: | Line 46: | ||
So our intention was to write a manual that introduced the Amiga from basics - in terms a non-technical reader could understand. The GUI sections were especially targeted for the layman. Other sections, such as the ARexx chapter, were structured more like reference guides since they will likely be used by readers with more of a technical background. |
So our intention was to write a manual that introduced the Amiga from basics - in terms a non-technical reader could understand. The GUI sections were especially targeted for the layman. Other sections, such as the ARexx chapter, were structured more like reference guides since they will likely be used by readers with more of a technical background. |
||
| − | |||
| − | = Introduction = |
||
| − | |||
| − | The purpose of this book is to describe how the user interface of a standard Amiga application should look and operate. It is intended to be read by current developers as well as developers who are considering writing and/or designing application software for the Amiga. |
||
| − | |||
| − | This book assumes some familiarity with computers and their interfaces in general, and with the Amiga's graphic user interface (GUI) in particular, but, for the most part, you do not have to be a programmer to understand the material. |
||
| − | |||
| − | Only the behavioural guidelines for an Amiga application are presented here. The details of how to implement them are covered in other volumes of the Amiga [Technical] Reference Series. |
||
| − | |||
| − | == What's In This Book == |
||
| − | |||
| − | This document provides the following information: |
||
| − | |||
| − | * the benefits of a standard user interface; |
||
| − | |||
| − | * an overview of the components of the Amiga user interface; |
||
| − | |||
| − | * specifications showing how to use the components of the Amiga user interface to create a standard Amiga application. |
||
| − | |||
| − | The Amiga hardware and system software provide the basic building blocks of the user interface: a mouse and pointer, windows and icons, menus and requesters and more. But it is your software that combines these elements and ultimately determines how the machine will be used. |
||
| − | |||
| − | === Non-Stifling Standards === |
||
| − | |||
| − | In one sense, this style guide can be considered a book of rules for you to follow when designing application software for the Amiga. It describes the best ways to combine and use elements of the Amiga system software to communicate with the user. |
||
| − | |||
| − | Unlike rule books such as a state's driving code or a company's employee handbook, the style guide's originators don't suggest penalties for violators. In fact, penalties of that sort would be counterproductive. The aim of this book is to establish standards for Amiga applications without stifling creativity. New versions of the Amiga and new types of applications will probably require refinement and expansion of these standards in the future. |
||
| − | |||
| − | That's not to say no penalties exist. In a free, competitive market the only real penalties are financial and self-inflicted. This book has been created under this premise: standardized software will be better for reasons described later in this chapter, and thus, in a competitive situation it should sell better. |
||
| − | |||
| − | In short, these standards were devised to improve your program and the Amiga platform in the eyes of the user. |
||
| − | |||
| − | {| class="wikitable" |
||
| − | | This manual describes the best ways to communicate with the user. |
||
| − | |} |
||
| − | |||
| − | === A Point on the Horizon === |
||
| − | |||
| − | No one expects every application to conform to every one of the rules and guidelines in this manual. |
||
| − | |||
| − | These rules have not been created in a vacuum. Many of the standards discussed in this manual have been culled from experience - experience gained through the multitudes of Amiga applications released since the Amiga's inception. The writers of this document first looked at what has worked best in specific applications and then tried to transform that raw experience into a standard, efficient and accepted way to do things on the Amiga. The trick was to come up with ideas that worked well ''and'' would work well in a variety of situations. |
||
| − | |||
| − | Clearly there will always be exceptions to these rules. Even applications created by Commodore may not comply with every idea in this book. |
||
| − | |||
| − | The hope is that the idealized application described in this manual will be like a point on the horizon you keep in sight throughout the development of your very real program. |
||
| − | |||
| − | {| class="wikitable" |
||
| − | | The rules in this manual describe an idealized application not yet created. |
||
| − | |} |
||
| − | |||
| − | == Some Perspective == |
||
| − | |||
| − | The user is the most important part of any application. In the past, improving the speed or increasing the capacity of application software has been a major focus of computer programmers. The idea of emphasizing the user interface of a computer system over its performance and capacity is a relatively recent innovation in computer history. |
||
| − | |||
| − | Historically, most users of computer systems were technical people who could tolerate the exacting requirements of expensive computer hardware and their "unfriendly" application designs. Complex commands had to be remembered and typed into a terminal in the proper sequence and thus required these early computers to have a professional staff in order to run them. This made sense because the computing hardware of that era was much more expensive than human labour. The user was there to serve the needs of these expensive machines. |
||
| − | |||
| − | The advent of microprocessors and the long-term trend to lower-priced computers has changed all that. Today's computer user is trying to get work done. The user probably does not know much about computers and may not even know how to type. The human-machine interface has been reversed, and now computers must serve the needs of the user. |
||
| − | |||
| − | === The User's Needs === |
||
| − | |||
| − | The user's needs are simple: |
||
| − | |||
| − | * the operation of the software should be predictable; |
||
| − | |||
| − | * learning the software should be easy; the software's functions should be easily scannable; |
||
| − | |||
| − | * the software's operations should be consistent throughout tools, applications and similar objects; |
||
| − | |||
| − | * feedback should be provided to the user, so he knows what has happened and what he can do; |
||
| − | |||
| − | * the software should adapt to the users's level of experience. |
||
| − | |||
| − | {| class="wikitable" |
||
| − | | The user needs: predictability, intuitiveness, accessibility, consistency, feedback, adaptability and simplicity. |
||
| − | |} |
||
| − | |||
| − | === Consistency === |
||
| − | |||
| − | The user's needs listed above really all combine into one: consistency. If your interface is consistent with the model, it becomes predictable; if it can be scanned easily, it provides feedback; if it provides feedback in a reasonable manner, the user always feels |
||
| − | comfortable and can master increasing levels of complexity. |
||
| − | |||
| − | Consistency in a user interface allows the user to apply previously learned knowledge to each new application. The user will spend less time figuring out how to get work done, and can therefore be more productive. Learning a new application is much easier if it works just like one the user already understands. |
||
| − | |||
| − | The Amiga is a multitasking computer that allows the user to run more than one application at a time. This makes consistency even more important because the user can easily switch from one application to another. Consistency between applications allows the user to make this switch without having to make a "mental jump" between one way of working and another. |
||
| − | |||
| − | Following standards also makes new applications more familiar; thus the user will probably be less afraid of inadvertently wiping out data or making other non-recoverable mistakes. |
||
| − | |||
| − | {| class="wikitable" |
||
| − | | Once again: predictability, intuitiveness, accessibility, consistency, feedback, adaptability and simplicity. |
||
| − | |} |
||
| − | |||
| − | === Filling the Needs === |
||
| − | |||
| − | A graphic user interface (GUI) is current the best method available for simplifying the user interface and meeting the needs of the user. |
||
| − | |||
| − | Amongst the first computers to use GUIs were the Xerox Star and Apple Lisa. Based on pioneering research performed at the Xerox Palo Alto Research Centre in the 1970s, these computers allow the user to issue commands with a mouse and pointer. Resources represented by graphic icons can be activated by pointing to them with the mouse, and actions can be performed through mouse-activated menus. |
||
| − | |||
| − | GUIs provide immediate feedback and scanning ability, so users can tell what their options are and don't have to memorize commands. They allow for enormous growth and adaptability of an application, because levels of functions and commands can be buried yet still be graphically accessible. In short, they provide a user interface that lets the user operate, without learning, the computer - in much the same way that the average driver doesn't need to be versed in internal combustion. |
||
| − | |||
| − | By utilitizing standardized tools and objects provided in the GUI, programmers are less likely to invent needlessly different ways of doing things. The interface becomes predictable and consistent. |
||
| − | |||
| − | === The Amiga === |
||
| − | |||
| − | The Commodore Amiga is a further refinement of this philosophy that puts the needs of the user foremost. Like many other systems, the Amiga has a GUI with a mouse, pointer, windows and menus which makes it easier for users - especially beginners. |
||
| − | |||
| − | But the Amiga also offers two other built-in interfaces: a text-oriented interface, the Shell, an an inter-process scripting language, ARexx. |
||
| − | |||
| − | Together, these three interfaces provide a powerful and flexible environment for both the novice and the expert. In fact a philosophy for the design of the Amiga user interface might be "Power to the User". |
||
| − | |||
| − | == Developer-Oriented Benefits to Standards == |
||
| − | |||
| − | The obvious beneficiary of a good user interface design is the user. He can pick up a new application and learn how to use it, scan its functions to see what it does, apply old knowledge to cut the learning curve, and so on. |
||
| − | |||
| − | But a disciplined approach to designing and building an application also has enormous benefits for the software developer. |
||
| − | |||
| − | === Market Acceptance === |
||
| − | |||
| − | Marketing is simplified when a product "belongs" in a comfortable environment, sharing features and tools with other popular applications. A user trying out a demo version of your software and your competitor's software in a store rarely has the time to learn a new way of doing things. A familiar environment and controls that work in a predictable manner will allow him to experience what you are really selling - how well your application does its job. |
||
| − | |||
| − | {| class="wikitable" |
||
| − | | Some real market-oriented reasons exist for standards too. |
||
| − | |} |
||
| − | |||
| − | === Coexistence === |
||
| − | |||
| − | By following the recommended guidelines, applications acquire the ability to inter-operate, thereby increasing each application's value. When applications can inter-operate and share data as well as they can on the Amiga, users can combine in off-the-shelf software packages to create custom solutions for the work they want to do with the Amiga. |
||
| − | |||
| − | Secondly, it is important that applications behave well in a multitasking environment. Sticking to the standards assures peaceful coexistence. |
||
| − | |||
| − | === Easier Creation and Maintenance === |
||
| − | |||
| − | Design is also simplified when you follow standards. |
||
| − | |||
| − | For one thing, Release 2 of the operating system features toolkits such as GadTools which provide you with pre-coded elements of the GUI. Even when elements aren't provided "prefab", standards allow you to spend less time devising and designing environments and more time working on the actual operations of your program. It also allows you more time for testing. For instance, if you are designing a CAD program, chances are that it is computer-aided design which really interests you. Instead of spending a lot of time working on gadgets to control your application, you could be spending more time working on the actual CAD operations. |
||
| − | |||
| − | Also in the absence of any stanards, progress is more difficult because each application will require an individual upgrade plan. |
||
| − | |||
| − | == Power to the User == |
||
| − | |||
| − | Clearly, this book was created to sell the idea of standards as much as to simply present those standards. But the reasons for those standards goes beyond an innate need for order originating from some corporate boardroom. The reasons set forth here have been set forth honestly in an attempt to provide more power to the user. This book intends to make clear what features of the user interface will help to make the interface simple - and predicatable - and consistent - and adaptable - and intuitive. This in turn should improve the Amiga market for all of us. |
||
Revision as of 18:44, 28 June 2012
|
This page is currently being updated to AmigaOS 4.x. Some of the information contained here may not yet be applicable in part or totally. |
User Interface Style Guide
The Amiga User Interface Style Guide provides an introduction to, and in-depth explanation of, the issues programmers must understand to create the best user interface for Amiga applications. The guide includes:
- the design principles and metaphors underlying Intuition, the Amiga's graphical user interface;
- guidelines for programs that use the Amiga's high-performance ARexx and Shell interfaces;
- detailed specifications on how to arrange the elements of the Amiga's user interface to make applications consistent, powerful, and easy to use.
For the serious programmer who wants to take full advantage of the Amiga's impressive capabilities, the Amiga User Interface Style Guide is the definitive source of information on designing the front end to Amiga applications.
UI Style Guide Windows and Requesters
Preface
Like any written work with a distribution wider than a personal letter, this style guide attempts to be many things to many readers.
After much deliberation we developed the following profiles of the average reader: a current Amiga developer working alone or with one partner; a developer from another platform who would like to develop for the Amiga; a first-time developer; a graphic artist designing a user interace for a developer; a team of developers working for a medium-sized company...the list goes on.
So our intention was to write a manual that introduced the Amiga from basics - in terms a non-technical reader could understand. The GUI sections were especially targeted for the layman. Other sections, such as the ARexx chapter, were structured more like reference guides since they will likely be used by readers with more of a technical background.
