DesignGuide Style Guide

This chapter describes how usability concepts will help optimize the interaction between users and ADS DesignGuides. Wherever possible, examples from DesignGuides will be used.

This document is written for developers of DesignGuides. It contains information that will help you create DesignGuides that fit within the ADS product environment. It provides specific information that will help you plan and make user interface decisions about your design. The information in this document is not platform-specific and can be applied to DesignGuides running in either Microsoft Windows or UNIX Motif operating systems.

Information for this document was obtained from DesignGuide developers, Agilent EEsof EDA and Customer Usability Engineering personnel. A bibliography of additional usability sources is listed at the end of this chapter.

User-Centered Design Principles

The usability of DesignGuides is an essential ingredient to customers success. Time spent designing usability into DesignGuides will contribute to customers success in doing their jobs and the success of DesignGuides as a product.

Computer users have continually rising expectations about the usability of their software applications. They work in environments that demand better results in shorter periods of time. They complain about feature-laden software; they can't find features they care about, and they can't figure out how to use the features they find.

DesignGuides have been developed to allow users to focus on their work (Job 1 - making good design decisions) and not the tool (Job 2 -manipulating the ADS user interface) by eliminating many steps required to manually create schematics, set up and run simulations, and set up and view results.

Delivering simplicity does not mean just removing functionality. Simple, elegant user interfaces require work. Even a simple interface can require a significant investment in code. The benefits in taking the time to do it right include reduced training and support costs and happy, successful, productive and loyal customers.

Because great usability is one of the goals of DesignGuides, a review of the basic principles of user-centered design is appropriate. This section describes basic usability principles that should be considered when creating DesignGuides.

You will very likely find that you cannot design a product to meet every user-centered design principle. You will have to make decisions based on which principle or set of principles is most important in meeting your current design goal.

User in Control

Users should always feel in control of the DesignGuide. People learn best when they're actively engaged. User interface objects are always in view while the user is physically manipulating the objects. When the user performs operations on an object, the results of those operations are immediately visible.

Create a balance between providing people with the capabilities they need to get their work done and preventing them from destroying data. If there will be grave consequences to actions they are about to take, they will want to know how to avoid this situation.

As people become more proficient with applications, they will want shortcuts to commands that required greater numbers of steps. Provide users with standard keyboard shortcuts as well as the ability to customize the user interface to meet their specific needs.

Consistency

Consistency in the user interface allows users to transfer their knowledge and skills from one application to another. Use standard elements of Windows and Motif user interfaces to ensure consistency within your DesignGuide and to benefit from consistency across applications.

Effective software tools are consistent in several different ways. Consistency in the interface helps people learn and then easily recognize the graphic language of the interface. For example, once users know what a checkbox looks like, they don't have to learn another symbol when making choices. Consistency means users have to learn basic user interface behavior only once. They can spend their time on the task at hand, modifying a schematic, running simulations, and analyzing results.

Feedback and Dialog

Keep people informed about what's happening with DesignGuides. Provide feedback as they perform tasks and make the feedback as immediate as possible. When a user starts a process, provide a visual or audible indication that the command was received and the process has started. Provide as much information as possible about how long operations take. Tell the user how to get out of the current situation whenever possible. Provide direct, simple feedback they can understand. Messages should spell out what caused the error so that users can prevent the situation from happening again.

Forgiveness

Encourage people to explore DesignGuides by building in forgiveness. Forgiveness means that actions on the computer are generally reversible. People need to feel that they can try things without damaging the system. Always support Undo.

Always warn people before they start a task that will cause irretrievable data loss. When options are clearly presented and feedback is appropriate and timely, learning how to use software should be relatively error-free. Frequent error messages are a good indication that something is wrong with the program design.

Stability

If people are to cope with the complexity of computers, they need stable reference points in the user interface. To give users a visual sense of stability, DesignGuides (and ADS) define a number of consistent graphic elements (menu bar, tool bars, palettes, schematic symbols, etc.) to maintain a sense of stability.

To give users a conceptual sense of stability, the interface provides a clear, finite set of objects on a clear, finite set of actions to perform on those objects. Even when particular actions are unavailable, they are not eliminated from the user interface but are merely dimmed.

Modeless Features

Try to create modeless features that allow people to do whatever they want (and when they want) in DesignGuides. Avoid using modes because a mode typically restricts the operations that the user can perform while it is in effect. It locks the user into one operation and doesn't allow any other work to proceed until that operation is completed. In contrast, a modeless state allows the user to perform one operation at a time and thus gain more control over what he or she can do on the computer and in a DesignGuide. For example, consider the problems users would encounter if they could not use ADS while running a simulation. On the other hand, if the user initiates an operation that could cause ADS to crash, he or she should not be allowed to take any action until acknowledging the problem.

Aesthetic Integrity

Aesthetic integrity means that information is well organized and consistent with principles of visual design. This means that things look good on the screen and the display technology is of high quality.

Follow these guidelines:

• Keep user interface graphics simple. More is less. Too much information clutters an interface and confuses users. Don't clutter the screen with too many windows, overload the user with complex icons, or put dozens of buttons in dialog boxes.
• Don't change the meaning of standard items. For example, checkboxes should not be used for multiple choices one time and exclusive choices in another part of the interface.
• Don't use arbitrary graphic images to represent concepts. When you add nonstandard symbols to menus, dialog boxes, toolbars or palettes, the meaning may be clear to you, but to other people the symbols may appear as something different or distracting. Follow specific guidelines established for ADS graphic images, such as toolbar or palette icons.

Before You Start

Designing effective user interfaces is more than just following a set of rules. An understanding of your target customer is important to providing an effective solution that meets their needs. The creation of schematics and presentation of data is a highly individual and creative process. DesignGuides turn standard ADS schematic and data display windows into interactive user interfaces. A typical schematic or data display might be viewed by relatively few people throughout a typical project life cycle. DesignGuides will be viewed and used by many people.

This broader audience requires that DesignGuide developers have good understanding of what users want to accomplish. User profiles and understanding users work and task flows will provide focused information for creation of DesignGuides. Before reviewing user profiles and users task flow, there are a few general concepts that should be considered.

The 80/20 Rule

Eighty percent of users of a given application will use only twenty percent of the application features. While this statement may seem overly broad, especially when applied to CAD/CAE software tools, it is wise to review a design with this concept in mind. Does your DesignGuide contain the right amount of capability to meet a majority of your users needs? Is there an abundance of features that only very experienced users will want to use and may get in the way of the majority of the DesignGuides users?

First Hour Experience

User's overall success with an application can be heavily influenced by their initial experience. This is not just using the software, but the whole product experience beginning from when they first open the software package. A good first impression is critical to gaining a user's trust and confidence. Users will want to try an application immediately after it has been installed. Will your DesignGuide provide users with all the tools to become successful ADS users in less than an hour after installation is completed?

User Profiles

User profiles consolidate and focus a wealth of information about the people who use DesignGuides.

They help highlight specific areas of a users work that will be improved.

• Job description
  User's engineering expertise, technology and process knowledge and overall level of experience in these areas
• User objectives
  What gets in the way of the users ability to do his/her job and how will DesignGuides help eliminate those roadblocks?
• Demographics, Education, Skills and Characteristics
  User's job location (country and type of company), education - formal and on the job, specific job skills, age, career path
• Tools
  Hardware and software tools used by the user
• Work environment
  R&D, production, field etc.
• Concerns and opportunities
• What will help users do their jobs better (schedules, money, meeting specs., project or process breakthroughs)?

User Task Flow

As shown in the illustration that follows, understanding the steps people take while doing their job will give you insights into where they need help - where the breakdown points are that increase costs, ruin schedules and cause missed specification targets. Task analysis can be as general or as specific as required. In the case of DesignGuides, you may need to focus on how the current ADS user interface impacts a user. However, an overview of a user's entire task while building a part might also provide insight into areas where ADS can be applied, via DesignGuides in new and innovative ways.

DesignGuide Usability Guidelines

The following guidelines are intended to provide DesignGuide developers with a set of rules that will provide a solid base from which to build DesignGuide user interfaces. Their purpose is to help remove ambiguities that can confuse and frustrate users by providing a consistent look and feel across the DesignGuide user interface.

As DesignGuides mature, these guidelines will change. Periodic reviews of the DesignGuides, possibly based on specific releases, should be anticipated. This style guide will follow the typical task flow a user follows when using DesignGuides. For each task, specific guidelines will be reviewed. Additional topics have been added to cover areas not specific to a task.

Opening and Selecting DesignGuides

The DesignGuide menu structure allows users to perform all DesignGuide operations (viewing a Quick Start Guide, opening specific DesignGuide applications, opening DesignGuide palettes, viewing simulation results and opening the User Manual and QuickStart documents).

DesignGuide Menu Structure

When building a DesignGuide, the menu should be structured to guide users sequentially through the DesignGuide process.

The following illustration shows a standard DesignGuide menu layout.

Menu Usability Notes

Following are guidelines on creating usable menus.

Menu Labels

DesignGuide menu labels should avoid using non-standard abbreviations or descriptions that have no meaning to users. Users should not have to guess at what kind of window will open when a DesignGuide menu is selected. Shorter is better.

Menu Levels

General user software guidelines suggest that pulldown menus should be structured so that users do not have to go more than two levels deep, with three as the maximum.

Standard Menu Control Features

Use standard operating system fonts, navigation controls (sub-menu arrows and label ellipses to indicate dialog boxes) and keyboard shortcuts indicators for DesignGuide menus.

DesignGuide Schematics

The physical layout of schematic and data display windows is a highly iterative and creative process. The interactive nature of DesignGuides requires developers to take a closer look at the overall usability of schematics. By applying a few basic usability principles to DesignGuide schematics, users will experience better ease of learning and increased ease of use. This section covers guidelines for schematics. Data display guidelines will be reviewed in the next section.

The following illustration shows a hypothetical DesignGuide Schematic layout.

Schematic Window Usability Notes

Following are tips on usability of the Schematic window.

Overall Format for DesignGuide Layouts

Use a landscape format when creating schematic and data display layouts. This format corresponds to the computer screen aspect ratio. Try to group components within the window for quick visual recognition. Well grouped schematics also help users when performing cut and paste operations and when printing schematics.

Locating Primary User Information

If possible, schematic and data display windows should locate the most important user data in the upper left and top of the window. Users generally start to scan their view from this location. This provides users with preliminary information and instructions about how to use the DesignGuide. If necessary, provide links from instructions (numbers, color coding etc.) to relevant points in the windows. This helps users focus on information and processes important to their success.

On-schematic Help for New Users

If your users are predominantly new to ADS, include hints or descriptions of ADS commands that may be unfamiliar to them. For example, users may not know how to access sub-circuits. A note about the Push-in and Pop-out features of ADS might be placed on the schematic near a sub-circuit symbol.

Selecting Text for DesignGuides

Title, descriptive and instruction text should be large enough for users to read when a schematic or data display window is open in the full screen mode in a 15" to 16" CRT. The Arial font family is recommended for text in ADS DesignGuides.

• For titles and headings (24 point and above)
  Arial for CAE Bold (color black)
  (Do not use outlining around titles or headings.)
• For components, instructions and description text (12 point and above)
  Arial for CAE Bold (color black)
  Specify the text size in your DesignGuide to provide optimal viewing and reading capabilities within your DesignGuide windows. The following two figures show applications of title text based on schematic size.

Outlining Important Information in Schematics

When outlining critical instructions for users, take care when placing the box so that you do not hide other schematic information. This may require turning off the snap-to-grid feature. The figure shows current outlining (left) and revised outlining (right).

Red outlining has been the predominant method of highlighting important information in DesignGuides. To reduce the impact of this color in schematics and data displays with a lot of outlining, consider using a combination of lighter line weight. Review the following guidelines.

• Use a line weight of 3 and light blue color for important information.
• Use a line weight of 3 and the color red for critical information.

To create an outline (rectangle):

1. Insert a rectangle into a Schematic window.
2. Select the rectangle (it becomes highlighted).
3. Select Edit > Properties.
4. In the Properties dialog box, under Name, enter: line_thickness_prop.
5. Under Value, enter: 3.
6. Click Add.
7. Click OK.

Consistent Naming of DesignGuide Controls

Providing consistent labeling between user interface components and controls gives users a visual link between an action taken and the result of that action. For example, if a user selects a menu command, the label of the UI component opened should be consistent with the menu label.

Keep data display and schematic names the same if possible. For example, the Power Amplifier Design Guide has the schematic:
HarmZopt1tone.dsn
It also has three corresponding data displays

• HarmZopt1tone.dds
• HarmZopt1toneSC.dds
• HarmZopt1toneTime.dds
  It should be clear from the DesignGuide names that the files are related.

Labeling and Symbols for Subcircuits in Schematics

When showing sub-circuits in top level schematics, do not use generic boxes, but symbols appropriate to the sub-circuit. In the illustration that follows, the appropriate symbol (amplifier) is shown on the left, with a generic box symbol on the right.

DesignGuide Data Displays

Many Usability Notes reviewed in the section DesignGuide Schematics also apply to DesignGuide data displays. Additional usability guidelines for data displays follow.

Remember, keep it simple and provide the MVUI (minimum viable user interface).
The following shows a hypothetical DesignGuide data display layout.

Data Display Window Usability Notes

Following are tips on usability for the data display windows.

Highlighting Data in Data Display Windows

Do not use highlighting (using a background fill color - available only in data display windows), when creating DesignGuides. Printing the highlighted text can produce poor results. Use the outlining method of highlighting important areas of the data display.

Selecting Color for Data Display Traces

Data display traces should be programmed to provide default values when data displays are created for DesignGuides. Users should be free to easily change trace colors to meet their specific needs. Colors on computers are also viewed on a wide variety of hardware in a wide variety of environments. These factors have a big impact on color perception.

• Use red for traces that indicate the most important data.
• Use the following colors, shown in order of preference, to highlight specific trace data on a white background.

• The following color combinations are recommended for thin line images (traces) on a white background.

• Whenever possible, stay away from de-saturated bright colors (yellow, light green)
• Avoid colors that are hard to see on a white background or when printing in color.
• Use colors sparingly.

• Black text on a white background is preferred.

Using a Grid for a Data Display (and Schematic) Layout Design

Consider using a grid to help you place components when you are laying out either a Schematic or data display window. Grids will help you provide visual order to the window. Visual order helps users gain a quicker understanding of the information you are presenting. It will also help users when they want to cut, paste and print parts of the data display window.

Printing DesignGuide Windows

The hardcopy lab notebook is still a mainstay for R&D engineers. Printouts of computer data are routinely pasted into lab notebooks to record design history. With this in mind, the following guidelines should be followed.

• Because most documents are printed in portrait mode, consider the grouping of data display components so that they can be easily printed in portrait mode.
• When locating specific data display components, allow room between components so that individual components or groups of components can be easily selected for printing without overlapping other components.
  

Linking Listing Columns for Simultaneous Scrolling

Listing columns of related data should be linked so that scrolling of the data works simultaneously for all columns. In the figure that follows, separate listings items, as shown, are acceptable when scrolling is not needed (list columns not full).

When listing columns are filled and scrolling is needed to view all data, separate columns do not allow the user to view correlated data across all lists.

If all listed data must be viewed while one column is scrolled, listing columns must be linked.

Titles for Listing Columns

When using text as titles for listing columns, use separate text entries for each title. Though this is time consuming, when one long text entry is used for a group of the titles, scaling of text is a problem when a user zooms in and out of the data display window.

Reducing DesignGuide Datasets

DesignGuides are capable of generating a great amount of simulation data, to the point that it might have an adverse impact on a user's disk space. To minimize the impact of large amounts of dataset data, DesignGuide developers should consider the following guidelines when setting up simulations.

• Set up simulations with coarse sweeps. Let the user decide how to refine their sweep parameters in subsequent simulations.
• Don't sweep over larger ranges than necessary. Again, start with a minimal range of parameters. Let the user decide to expand the range is necessary.
• Delete unnecessary datasets.

Hiding Equations

A few assumptions can be made about the need to either show or hide equations.

• The average user is not interested in seeing every equation and might in fact be put off by a window full of equations.
• Power users want to have access to equations to understand the inner workings of a DesignGuide process.
• Showing equations may compromise Agilent intellectual property.
• Equations take up valuable space in schematic and data display windows.

Based on these assumptions, two approaches for equations are suggested.

1. If there are 10 or fewer equations, don't hide them. Make them small, using a text size of 6 point Arial for CAE. Include some basic documentation and place near the equation.
2. For DesignGuides with many equations, hide the equations using the zero font approach. This is done by placing equations on top of each other and reducing the font size to zero. Place them below the lower left-hand plot or listing column. Other suggestions are placing the hidden equations under the data display title or by placing the data display title over the equations.

Designing Dialog Boxes

This section provides guidelines on user-friendly dialog box design.

Dialog Box Usability Notes

DesignGuides will see an ever-increasing use of dialog boxes. When designing dialog boxes, a few usability rules will help make them use easier to learn and easier to use. The goal in dialog box design is to let the user make intelligent choices, quickly.

• Controls. Use the appropriate control. Controls are optimized for certain types of functions. The wrong control not only affects the user's efficiency, but also confuses the user about the purpose of your design.
• Layout conventions. Use recommended layout conventions. For example, buttons such as OK and Cancel or Yes and No should be aligned either at the top right or bottom right of the dialog box. OK is always the first button, followed by Cance l, and then any other buttons. If you don't have an OK button, then Cancel follows all the other buttons.
• Labeling. Use appropriate labeling. Always use the appropriate capitalization and access key assignments. Include colons when you use static text to label another control. This not only identifies the text as a label, but also provides a cue for screen reader utilities.
• Control alignment. Use appropriate alignment. Alignment affects readability and therefore usability and efficiency. It also affects the user's overall impression of the quality of your application.
• Control spacing. Use appropriate sizing, spacing and margins. Make good use of overall space. Avoid cramming too many controls together if you have additional space.
• Default dialog box location. When opening a dialog box for the first time, default the location to the center of the active window. If the user moves the dialog box, display the it at the new location the next time the user opens the window, adjusted as necessary to the current display configuration.
• Button size. Make buttons a consistent length for readability. However, if maintaining this consistency greatly expands the space required for a set of buttons, it might be reasonable to have one button larger than the rest.
• Tabs. Similarly, if you use tabs, try to maintain a consistent width for all tabs in the same window (and in the same dimension). However, if a particular tab's label makes this unworkable, size it larger and maintain a smaller, consistent size for the other tabs. If possible, avoid designing dialog boxes that require the user to scroll left or right (using arrow controls) to view tabs.
• Grouping controls. Group related components - you can use group box controls, separator lines, or spacing. Avoid using a group box when you have only one set of related items or where the group box may take too much space or add visual clutter rather than structure. Instead, consider using separators to group related items.
• Dialog box task flow. Design the dialog box so that the user works from right to left and top to bottom when making choices.
  

Designing Icons for Toolbars and Palettes

To design pictorial representations, such as icons or other graphics, begin by defining the graphic's purpose and use. How will the graphics help the users finish a task? Graphics are used to support or illustrate the user's task rather than compete with or distract from the task.

Consistency is important in the design of graphic images. Make the scale, orientation, and color consistent with other related objects, and fit the graphics into the overall environment in which they appear. In addition, make sure you provide sufficient contrast for your images so that users can identify different elements or details of the images.
Microsoft defines three icon sizes: 16 x 16 pixels, 32 x 32 pixels, and 48 x 48 pixels.

Palette Icons

ADS palette bitmaps are 32 x 32. Please review the following guideline for creating palette bitmaps.

Helping New Users

Not all DesignGuides users will be knowledgeable ADS users. It might be necessary to provide these users with additional help as they learn ADS. Help documentation is available for new users, but many users will start using ADS without referring to documentation. The user interface must guide them through the process.

Review the following guidelines for helping users through their "first hour" experience with ADS and DesignGuides.

Throwaway Dialog Boxes

Use throwaway dialog boxes to help users navigate through the interface. A throwaway dialog box contains a checkbox that allows the user to hide the dialog box from view.

Following are locations in the DesignGuide user interface where throwaway dialog boxes might be useful.

• Telling users how to edit component parameters (both onscreen and dialog box editing)
• Locating and inserting components from palettes
• Running a simulation
• Locating a dataset and applying it to an open data display window
• Moving markers in data display windows
• Undoing the sticky cursor after placing components
• Editing color and line weight parameters for polygons
  Throwaway dialog boxes are not the same as wizards. Wizards are self-contained tools that guide users through a process with little or no interaction with other parts of the user interface. Wizards are not educational tools.

Information Dialog Box

If users start processes that do not work within the DesignGuide environment, providing informational messages will help them learn to work within the DesignGuide framework. For example, a user with ADS experience, while within the Passive DesignGuide, may start a simulation using the standard ADS menu commands.
The following shows first a current message, then a possible replacement message:

Release Checklist

Before checking in a DesignGuide, review the following checklist.

• If you make schematic or data display windows that use an entire 1280x1024 display, the windows will come up off the screen on smaller displays
• Delete any schematic, data displays and datasets that are not important to your DesignGuide. Less is better than more.
• All schematic and data displays should have a title in black.
• On data displays, avoid using full path names. They make plot axes harder to read, and they make data display files difficult to re-use.
• Change the labels on axis labels. 10 ns is better than 0.000000010 sec. Also, take the time to make axis labels larger so they may be read more easily.
• Every data display should have the same name as the schematic from which the data was generated. Dataset names should be no longer than 15 characters.
• Whenever possible, minimize dataset sizes so that users will not fill up their disk drives with ADS data. Use coarse sweeps and don't sweep over larger ranges than is necessary.
• Check for any of the following files, and remove them if found:
  • Core files
  • Debug files
  • Files with a .bak suffix (especially in the networks directory)
  • Files with a .sync suffix
• It is best to create archive file names that are the same as project names. For example, ModSources_prj should be archived as ModSources_prj.zap.
• Ideally, all DesignGuides should have note saying how long they take to simulate on a particular platform. This is important for DesignGuides that take longer than several minutes to run. Simulation time is a key issue with customers.
• Turn off the grid on schematics. You will have to save the schematic .prf file after turning off the grid. This makes schematics much easier to read.

Writing for DesignGuide Screens

Use a conversational, rather than instructional, writing style for the text you provide on DesignGuide screens. The following guidelines can be used to assist you in writing the textual information.

• Use words like you and your.
• Start most questions with phrases like "Which option do you want..." or "Would you like..." Users respond better to questions that enable them to do a task than being told what to do. For example "Which layout do you want?" works better in wizards than "Choose a layout."
• Use contractions and short common words. In some cases, it may be acceptable to use slang, but you must consider how this affects localization when doing so.
• Avoid using technical terminology that may be confusing to a novice user.
• Try to use as few words as possible. For example, the question "Which resistor do you want to use for this schematic?" could be written simply as "Which resistor do you want?"
• Keep the writing clear, concise, and simple, but remember not to be condescending.

DesignGuide Use Models

While DesignGuides have been created to bypass some of the more labor-intensive areas of ADS, they should not stray too far from the basic ADS use model (create a circuit, analyze the circuit and view the results of the analysis). Review the following use models before you create your DesignGuide.

DesignGuide Use Models Examples

Following are examples of the various types of use models.

Load-and-go-use model

1. Users make selections from the DesignGuide pulldown menu.
2. DesignGuide schematic and data display windows are open.
3. Users modify circuit parameters and/or insert new circuit components.
4. Users run simulations using the standard ADS simulation controls.
5. Users view the results in the data display windows

   Note In some cases, users must select dataset information before viewing simulation results.

Specify-and-go-use-model

1. Users open a DesignGuide and are asked to specify the type of circuit desired via a tab format dialog box
2. A Schematic window opens, displaying the specified circuit
3. Users enter and/or modify circuit parameters based on DesignGuide instructions or current knowledge
4. Users run simulations from the DesignGuide menu or from ADS simulation commands.
5. Users view simulation results in the DesignGuide Data Display window using the View Simulation Results menu selection.
6. Experienced users may create Data Displays to meet their specific needs. The PLL DesignGuide uses this model.

The Passive DesignGuide model

1. Users select a palette from the Passive DesignGuide menu.
2. Users insert circuit components from the Passive Structures palette.
3. Users enter and/or modify the component circuit parameters.
4. Users select the Auto Design palette button and create a circuit.
5. Users may view a sub-circuit of the new design.
6. Users select the Auto Simulate palette button to run a simulation.
7. A data display window automatically opens showing the simulation results.

DesignGuide Wizards

Wizards are being considered for and implemented in many Agilent EEsof applications to help users through complex and/or infrequently performed tasks. As wizards are designed and implemented for our products, it is important to provide a well designed and consistent user interface.

What is a Wizard?

A wizard is a special form of user assistance that automates a task through a dialog with the user. Wizards help the user accomplish tasks that can be complex and require experience. Wizards can automate almost any task. They are especially useful for complex or infrequent tasks that the user may have difficulty doing.

When Not to Use a Wizard

Wizards are not well-suited to teach a user how to do something. Although wizards assist the user in accomplishing a task, they should be designed to hide many of the steps and much of the complexity of a given task. Similarly, wizards are not intended to be used for tutorials; wizards should operate on real data. For instructional user assistance, consider task Help or tutorial-style interfaces.

Wizards Should Not Mask Poor Designs

Do not rely on wizards as a solution for ineffective designs; if the user relies on a wizard too much it may be an indication of an overly complicated interface, not good wizard design. In addition, consider using a wizard to supplement, rather than replace, the user's direct ability to perform a specific task. Unless the task is fairly simple or done infrequently, experienced users may find a wizard to be inefficient or not provide them with sufficient access to all functionality.

Designing Wizards

The following sections provide guidelines on designing effective wizards.

Locating wizards

Wizards may not always appear as an explicit part of the Help interface. You can provide access to them in a variety of ways, including toolbar buttons or even specific icons.

• Where to access wizards
  • Startup dialog boxes
  • Menus
  • Toolbar icons
  • Templates
• Don't force users to use wizards. Wizards should be accessed at the users discretion.

Layout of Controls

The layout of controls should follow standard dialog box design guidelines:

• Controls are aligned to read from left to right.
• Controls are aligned and spaced to provide logical grouping that visually guide users through the tasks.
• The number of controls in a window should be minimized.
  

Page Layout Consistency

Provide users with a consistent view of the wizard:

• Wizard windows should be a consistent size throughout.
• Include default values or settings for all controls where possible.
• Resist the urge to take users out of the wizard into other user interfaces to complete a task.

Page Layout Task Flow

As shown in the illustration that follows, the recommended page layout and task location flow is as follows:

1. The user is provided with information about the task and directions for completing the task.
2. The user enters data relevant to completing this part of the task.
3. The user makes decisions to move on to the next step, review previous steps, or exit the wizard. The user can get help at any time.

Command Buttons

The following command buttons should be used to allow the user to navigate through the wizard. Resist the urge to add additional buttons to the command button location.

• < Back returns to the previous page. (Remove/disable the button on first page.)
• Next > moves to the next page in sequence, maintaining whatever settings the user provides in the previous pages.
• Finish applies user-supplied or default settings from all pages and completes the task.
• Cancel discards any user-supplied settings, terminates the process, and closes the wizard window.

Designing the First Wizard Page

The first page should provide a point of reference (a graphic or roadmap) for users. Set positive user expectations for the upcoming task.

Wizard Identification

• Use the title text of the wizard page to clearly identify the purpose of the wizard.
• Because wizards are secondary windows, they should not appear in the taskbar.
  

Finishing Wizards

You can include the Finish button at any point that the wizard can complete the task. On the last page, indicate that the task is completed and instruct the user to click the Finish button.

Wizard Do's and Don'ts

• Minimize the number of pages that require the display of a secondary window. Novice users are often confused by the additional complexity of secondary windows.
• Avoid a wizard design that requires the user to leave the wizard to complete a task. Less experienced users are often the primary users of a wizard. Asking them to leave the wizard to perform a function can make them lose their context.
• Make it visually clear that user-interface elements that are part of a graphic illustration on a wizard page are not interactive.
• Avoid advancing pages automatically. Wizards are intended to allow the user to be in control of the process.
• Display a wizard page so that the user can recognize it as the primary point of input. The page may need to be displayed over its parent window.
• Make certain that the design alternatives offered by the wizard provide the user with positive results.
• Make certain that it is obvious how the user can proceed when the wizard has completed the process.
• If a large amount of data is entered during the task, consider providing the user with a summary view of all the data.

Final Thought on Designing Wizards

Design your wizard pages to be easy to understand. It is important that users immediately understand what a wizard is about so they don't feel like they have to read it very carefully to understand what they have to answer. It is better to have a greater number of simple pages with fewer choices than a smaller number of complex pages with too many options or text.

ADS Schematic Symbol & Bitmap Creation

Standards have been established for the creation of schematic symbols for ADS schematics and the bitmaps that represent each symbol. The bitmaps are located in the component palettes. To maintain a consistent look and feel throughout the product, designers should follow these standards when creating schematic symbols and bitmaps for DesignGuides.

Creating the Analog RF Symbol

Following are guidelines on creating the symbols for Analog RF components.

12-Step Procedure for Analog RF Symbol Creation

1. When creating an Analog RF Symbol, try to leverage a similar existing symbol.
2. Open the existing similar symbol file.
3. Select the command Select >Select All.
4. Copy the symbol to the buffer ( Edit > Copy/Paste > Copy to Buffer ).
5. Create a new file ( File > New ).
6. Change the mode to Edit Schematic ( View > Create/Edit Schematic ).
7. Paste the Symbol to grid ( Edit > Copy/Paste > Paste from Buffer ).
8. Important : Align pin 1 on a grid point.
9. Set origin to Pin 1 ( Edit > Modify > Set Origin ).
10. Using the ADS design tools (Layer Editor and drawing tools), edit the symbol.
11. Check to make sure all pins are on gridpoints.
12. Save the Symbol ( File > Save As ...) using the symbol naming convention -SYM_Filename.dsn.
    Once you have saved and closed a newly created symbol, to be able to view it again, follow these steps.

1. Open the symbol file ( File > Open <new filename >) You should be able to see the symbol. If you cannot, the design type may not be set correctly if an existing design was not leveraged. You will need to modify the design type to be -1 in the design file. To do this, make sure the number after the line starting with 10 is -1 (e.g., 10 -1 "SYM_abc" 2 954523902 0 0 0 0).
2. To view the symbol, change the mode to Edit Schemati c ( View > Create/Edit Schematic ).

Symbol Grid

Following are guidelines on the symbol grid.

• Symbols most commonly fit into a 1-inch by 1-inch square area.
• The origin of the symbol is always on a grid point.
• The origin is where pin 1 is placed.
• Simulation controller pin is located on the lower left corner (anything without pins) of the symbol, as shown in the following illustration.

The following illustration shows pin orientation angles.

Symbol Pin-Out

Following are guidelines on the symbol pin-out.

• Symbols most commonly fit into a 1-inch by 1-inch square area.
• The origin of the symbol is always on a grid point.
• the origin is where pin 1 is placed.
• Simulation controller pin is located on the lower left corner (anything without pins) of the symbol.

Symbol Pin Dialog Box (Analog RF)

Following are guidelines for use of the symbol pin dialog box for Analog RF.

1. Pins are not named unless otherwise specified.
2. See Pin Orientation angle in the preceding section Symbol Grid.

1. See Symbol Pinout in the preceding section Symbol Pin-Out.

1. Label Each pin Input/Output unless otherwise specified.

Line Thickness (Analog RF)

When designing geometry for Analog RF symbols, always uses line thickness of Medium.

Note The Polyline Thickness Dialog Box Automatically comes up when using the geometry tools. (select Medium ).

Changing Layer/Color

The Layer Editor dialog box is used for changing layer and color.

Creating the DSP Symbol

12-Step Procedure for DSP Symbol Creation

1. When creating a DSP Symbol, try to leverage a similar existing symbol.
2. Open the existing similar symbol file.
3. Select the command Select All ( Select > Select All ).
4. Copy the symbol to the buffer ( Edit > Copy/Paste > Copy to Buffer ).
5. Create a new file ( File > New ).
6. Change the mode to Edit Schematic ( View > Create/Edit Schematic ).
7. Paste the Symbol to grid ( Edit > Copy/Paste > Paste from Buffer ).
8. Important : Align pin 1 on a grid point.
9. Set origin to Pin 1 ( Edit > Modify > Set Origin ).
10. Using the ADS design tools (Layer Editor and drawing tools), edit the symbol.
11. Check to make sure all pins are on gridpoints.
12. Save the Symbol ( File > Save As... ) using the symbol naming convention -SYM_Filename.dsn
    Once you have saved and closed a newly created symbol, to be able to view it again, follow these steps.

1. Open the symbol file ( File > Open <new filename> ). You should be able to see the symbol. If you cannot, the design type may not be set correctly if an existing design was not leveraged. You will need to modify the design type to be -1 in the design file. To do this, make sure the number after the line starting with 10 is -1 (e.g., 10 -1 "SYM_abc" 2 954523902 0 0 0 0).
2. To view the symbol, change the mode to Edit Schematic ( View > Create/Edit Schematic ).

Line Thickness (DSP)

1. When designing geometry for DSP symbols, Use a line thickness of Thin for internal symbol geometry.
2. Always use line thickness of Medium for symbol bodies.

Layer/Color Scheme (DSP Symbols)

Sample Naming Conventions for Symbols (DSP)

1. Normal (SYM_filename.dsn)
2. CDMA (SYM_CDMA_filemame.dsn)
3. GSM (SYM_GSM_ filemame.dsn)
4. Hierarchical (SYM_DSN_ filemame.dsn)

Creating New Projects

When creating DSP symbol libraries it is often desirable to create a new project. This allows separate DSP symbol libraries to be separated by project.

Note Analog RF components are designed in a single project gemini_prj project.

1. In the ADS Main window, select File > Create New Project.
2. Add custom setup files to new project directory (these setup files contain toolbar and layout preferences that have been optimized for symbol creation)
   • schematic.lay
   • schematic.prf
     Both of these files are on the zip disk in the directory labeled custom.

Symbol Text

1. Symbol text must only be created in single line blocks (no carriage returns).
2. Symbol text that should not rotate needs to be created with Center/Middle justification and with the non-rotating flag ON. After component placement, check that Non-rotating text looks appropriate by rotating the component at different angles (0, 90, 180, and -90).

   Note The following scripts were written for ADS 1.3. There is no guarantee that these scripts will continue to work in future releases of ADS. They should not be necessary if the text was created correctly by following step 1 & 2 above.

   These scripts are located on the zip disk in the directory labeled scripts.

• findtext script (script that checks a batch of symbols for multiple line text blocks)
  • Usage ./findtext filename or *.dsn
  • Returns list of filenames with multiple line text blocks.
  • Manually correct text problems.
  • Re-center script (script that fixes that changes Bottom/Left justification to Center/Middle and turns Non-rotating flag ON) is not necessary if the text is created correctly to begin with.
  • Usage ./recenter filename or *.dsn

Hints and Tips

• ADS is not designed as a graphics tool and is a cumbersome interface for drawing. Creating special shapes and geometry often requires creativity.
• Try to become familiar with existing symbols as they may be leveraged to create new symbols.
• When possible try to have engineers supply accurate graphical information (mockup) for each symbol.
• After creation double check symbols to insure quality.

ADS Bitmap Creation

The following sections provide guidelines on creation of bitmaps.

Procedure for Bitmap Creation

1. When creating a new bitmap, try to leverage a similar existing Bitmap. Be consistent with other Bitmaps that may be in similar family grouping.
2. Add graphical content [Design Tools ].
3. Remember Analog RF symbols need corner tab.
4. Save the bitmap.

Colors Used in Analog RF Bitmaps

32 X 32 Bitmap Layout (DSP)

Note Text files 7PXCAPS.bmp and 7PXTXT.bmp are located on zip disk in directory labeled "text".

Bitmap Internal Graphics Use 5 Pixel Text

Note Text file 7pxtext.bmp is located on zip disk in directory labeled "text."

Corner Tab on Analog RF Bitmaps

32 X 32 DSP Bitmap Grid

This grid is to be used for Analog bitmaps also. The image area can be larger than the box. The text area is to remain the same.

User Testing

User feedback is an important part of the design process. This is especially true for DesignGuides. DesignGuides, along with examples and templates, may be a customer's first exposure to our tools. This "first hour" exposure can influence a users long term view of a product. Please review the following usability processes and let us know how we can help you get user feedback.

Following are user-testing techniques:

• Heuristic Analysis. Heuristic evaluation is a systematic inspection of the wizard using a recognized set of design principles. The evaluation is performed by having each evaluator inspect the DesignGuide alone. Findings are reviewed by the project team.
• Cognitive Walkthrough. A cross-functional team reviews the usability of the wizard. The results are reviewed by the project team and defects are ranked according to their severity.
• Low-fidelity user testing. User testing of an interface using paper prototypes. Good test for task flow and general UI navigation. (3 to 6 users)
• Medium-fidelity user testing. First test of the computer interface. Full functionality may not be implemented, but major features may be tested. Good for task flow and specific feature operation. Include documentation if available. (3 to 6 users)
• High-fidelity user testing. Final user testing of wizard. Full product functionality available. Users may test any and all parts of the user interface. (3 to 7 users)

Usability Resources

There are many usability resources available, especially on the web. The following resources are recommended.

• Microsoft Windows Usability
  • Microsoft Usability Resources
    http://msdn.microsoft.com/ui/
  • Windows User Experience: Official Guidelines for User Interface Developers and Designers
    http://www.amazon.com/
• UNIX Motif Usability
  • Motif User Interface StyleGuide
• Other usability resources
• ACM SIGCHI (Special Interest Group - Computer Human Interface)
  http://www.acm.org/sigchi/about.html
• Usability Professionals Association
  http://www.upassoc.org/
• Human Factors and Ergonomics Society
  http://hfes.org/
• Don Norman (usability guru)
  http://www.jnd.org/

Bibliography

1. Apple Computer (1996), Macintosh Human Interface Guidelines. Addison-Wesley, Reading, MA. ISBN 0201622165
2. Helander, M. (Ed.) (1993), Handbook of Human-Computer Interaction. Elsevier Science Publishers, Amsterdam, The Netherlands, ISBN 0-444-70536-8
3. Mayhew, D. J. (1992), Principles and Guidelines in Software User Interface Design. Prentice Hall, Englewood Cliffs, NJ, ISBN 0-130721929-6
4. Microsoft Corporation (1999), Microsoft Windows User Experience: Official Guidelines for User Interface Developers and Designers. Microsoft Press, Redmond, WA. ISBN 0-7356-0566-1
5. Nielsen, Jakob (1993), Usability Engineering, AP Professional, Chestnut Hill, MA. ISBN 0-12-518406-9
6. Norman, D. A. (1988). The Psychology of Everyday Things, Basic Books, New York, NY. ISBN 0-465-06709-3
7. Preece, J. (Ed.) (1998), A Guide to Usability: Human Factors in Computing. Addison-Wesley, Harlow, England. ISBN 0-201-62768-X