We may sometimes be tempted to design our interface as a metaphor, transmuting ideas from the real world to the digital (usually 2D) world. After all, isn’t our entire “desktop” is one big metaphor?

There’s nothing wrong with metaphors in and of themselves, as long as we keep them under our control, allowing them to inspire our visual design, terminology and concepts, but not take over the whole design. We must always adapt our controls for comfortable use with the virtual medium, even if in doing so we miss reality.

For example, a round rotating volume button - enormously common and convenient in the real world - would be extremely uncomfortable to use on music player software.

AppScan’s Scan Expert is a configuration assistants’ tool. It explores application and network behavior, and recommends configuration changes. The concept behind the feature was to productize what an application-security expert might do to optimize the scan configuration for a less experienced user.

Eventually we decided to use that metaphor to help the user understand and identify with the feature, reflecting the concept in the UI - the name of the feature, the splash screen and icons, terminology (e.g. “recommendations” ) and the wording - all fitted to the metaphor.

What do we usually call the termination buttons in a dialog box? Naturally, we call them Ok-Cancel or Yes-No. Well, we shouldn’t. We should name the accept button after the function that the user expects to perform when she clicks the button – Print, Save, Restart, etc. Where appropriate, it is recommended to provide a meaningful label for the other button as well – Burn/Don’t Burn, Install/Do Not Install.

When tasks become “automatic” for users, they tend to hit dialog buttons almost unconsciously and sometimes to their immediate regret. When the wrong button is pressed it can be annoying, frustrating, and even harmful. Allowing the user to make a prompt decision without the need to read the entire dialog can significantly reduce mistakes.

In this case, consistency might be a bad idea.

Unfortunately, the AppScan Standard development environment doesn’t allow for easy customization of dialog termination buttons. Simply put, there weren’t enough resources to remedy the problem. There are still several places in the product that we know trip users up.

The situation is better in AppScan Enterprise edition, where almost every screen has meaningful termination buttons.

However, due to the browser environment, JavaScript dialogs we use are still limited to Ok-Cancel.

Software help should be helpful - straightforward, written using commonly spoken language, and be focused on topics that require assistance and extra detail. Help shouldn’t be treated as the documentation of every button and control.

It’s also useful to consider different assistance methods, including ones that are more contextual.
Examples include:

• Help balloons or tooltips that show up when a user performs a mouse-hover or clicks on a dedicated spot next to the control, or group of controls.
• A column or an area on the page exclusively dedicated to help.
• Expanders and twisties designed to show and hide extra information.

Any solution can be appropriate, as long as it’s suitable for the product and to its users.

Configuring a scan in AppScan can become a complex task. To allow prompt access to more information, we implemented help balloons that show up by hovering over a small help icon. The icon is available in every group of controls, and it also serves as a highlighting bullet for the group name.

The balloon appears when the mouse enters the icon area and disappears after it leaves.

QuickScan was designed for developers to use regularly for validating that their code is secure. The configuration is minimal and clean. In this case, we implemented a solution that better suits its web interface.

After the user clicks the help icon, a new column appears on the right. It can be closed by another click on the help icon or by using the x sign on the top left corner of the help pane.

In order to foster a good understanding of the available interaction with a product, it is advisable to use “affordance” principles. This means building user interface components that “express themselves”.

The simplest example is a hyperlink. When text is highlighted with an underline – you might guess that it is a link. If the text has a distinct color – its purpose becomes clearer. Finally, when the text style changes on mouse-over – there are no doubts left.

Recently, there was a discussion about the different grouping views that an AppScan Enterprise report offers, and the fact that few users are aware of them.

In the original design, one has to look very carefully to notice that the dark blue numbers on the summary line are, in fact, interactive links to those views.

A simple solution, that would highlight the different grouping views, would be to provide the hyperlinks with better (and more recognizable) clues to the functionality they offer.

Placing the hyperlink on the view “description” rather than the number, further explain its purpose.

Poka-yoke (Japanese) - in English ”mistake-proofing” - is a principle for reducing errors by limiting operations that might cause errors, and by introducing constraints that reduce the risk of an operation failing.

For example: disable a particular control if it’s not currently relevant. In a field where only numbers are allowed, make it impossible for the user to type in anything else. Don’t allow a form to be submitted until all mandatory fields are completed.

Perhaps the most common implementation of Poka-yoke principles in UI design is the disabling of irrelevant controls. While we’re used to this, both as users and developers, it should nevertheless be done with care. As developers, we sometimes see the meaning of controls and the connections between them in ways that are not obvious to our users.

Consider this widget from AppScan Enterprise. It’s pretty clear that the top checkbox controls the other two.

However, are these two states (above and below) exactly the same? What’s the impact of the second, inactive checkbox being selected or deselected? Should I, the user, select the Analyze checkbox, deselect the Scan checkbox, and then again deselect the Analyze checkbox? Does it matter?

Under a different state, all three checkboxes are disabled. Is it obvious why I can’t interact with them?

The need for the extra clarification may be a good indicator that there is something wrong with the design.

Poka-yoke was initially Baka-yoke, meaning “fool-proofing” or “idiot proofing”. Here are some nice related quotes:

“Foolproof systems do not take into account the ingenuity of fools”
-Gene Brown

“Make something idiot proof and along comes a better idiot”
-common saying

“Make something idiot proof and only an idiot will want to use it”
-common saying

A Wizard interface is good for cases when a product needs a clearly defined, minimal set of data from the user, when it needs all of that data, or when it must process data in a given order. In most other cases it recommended not to use a wizard, with its “linear” flow of screens.

If you find yourself designing a wizard flow, it’s recommended to stick to one topic per screen. Text should be straightforward, avoid unnecessary welcome/summary screens, and forget decorative graphics. It’s also a good idea to provide the user with some feedback of his current position in the overall wizard flow.

Despite many debates around the wizard functionality in general, its role and how we should design it, we decided to enhance and redesign AppScan’s old scan configuration wizard to provide better user experience and interaction.

Beyond cleaning unnecessary graphics and information, and redesigning all forms, we reduced the wizard to a minimal set of screens and controls, leaving only the crucial ones. We added a screens/topics list to show what’s accomplished and what’s ahead. And to deal with highly diverse users and scanned application we introduced “dynamic” wizard screens.

By clicking a checkbox at the bottom of the screen the user who’s looking for more options can dynamically add an advanced screen as the next page in the sequence. We intentionally represent the extra screen in a subtle way, to keep a simple appearance.

To further support the need for advanced settings, a link to the full scan configuration screen is always available.

Perhaps we could get even better results with a different design, but for now the wizard has proved to be successful. The majority of our users, both novice and skilled, are using it.

When designing forms, there are three main positions for control labels.

• To the left of the field and left aligned - Easy for the eye to scan the field labels and creates “nice” alignment in the form of a block. Suitable for long forms with fewer fields.
• To the left to the field and right aligned - Creates a close link between fields and their labels. Requires limited eye movement and allows fast and efficient form filling.
• Above the field - Also creates a good link between fields and their labels, requires minimal eye movement, and can make elegant form layout. But it creates a longer form, and one in which it is harder to scan and locate specific field labels.

It’s up to us to chose the right placement for each form and product, and to be aware of the options and differences between them.

Since checkboxes have their labels on the right side of the control, and in many cases enable/disable another set of controls, we usually align them to the left.

Radio buttons are labeled to their right, but sometimes they also require a group label. In such cases we usually treat the group as any other control, and label it to the left, right-aligned.

Overall, (when placed correctly) the right-aligned labels in our configuration screens have created forms that are not only easy to fill and understand, but also aesthetically pleasing.

When building a toolbar, as with any other design, one must take account of the way it’s used and the people who’ll be using it.

In the case of a rarely used product or a “transient” one (admit it, yours might be), there is not usually enough time or incentive for the user to learn and remember icon meanings. It’s therefore advisable to label icons. On the other hand, in a heavily used product, where it is possible for the user to learn and remember the icons, labels can become a (cognitive and spatial) burden.

In order to support different kind of users we also implemented an option to change these default settings into icons-only view or full icons-and-labels view, as well as an option to display larger icons.

Our eyes - or more correctly our brain cells - are programmed to notice movement. It is a good idea to take advantage of the special attention we give motion on screen, in order to convey messages to the user (no, not ads). Animation can clarify important changes as they place, or that have taken place.

For example seeing the product “flying” to our shopping cart makes it clear that it has been added to it. The “Save” button blinking or moving when the user changes details on a form, reminds the user to save these changes. However, animation must be used carefully, as the wrong animation - or too much - can be annoying.

To fix this we added a fake progress-bar. It appears when selecting a new policy file, hides the old policy name for a short moment, gets filled swiftly and then vanishes to reveal the new policy name.

This solution solves our problems. The fake progress-bar informs the user that the function was executed and something has changed, and attracts attention to the new policy name which is proof of the change. It kept the overall feel fast and smooth. Finally, it was a relatively small and “cheap” enhancement for us to develop (but an important one for our users).

Aesthetic Usability Relationships

The more aesthetic a design is, the more usable it is.

On a simple level a product’s appearance affects our perception of its usability, but beyond that it also influences our emotions. It can cause us to be more forgiving and open toward the product, and consequently actually raise our performance (usability values).

The contribution of aesthetics in product development should not be underestimated.

(Bear in mind that aesthetic perception varies between cultures. It is not universal.)

This tip was first published in hebrew on the newsletter of the Israeli UPA chapter

The AppScan Enterprise full featured UI (below left) is mostly for security administrators.

QuickScan (below right) is a discrete part of AppScan Enterprise designed for developers to use regularly for validating their code for security. It has a simplified version of the AppScan Enterprise UI. When we recently redesigned it, it was clear that it must be not only simpler but also more pleasant to work with. An aesthetic touch, amongst other things, helped us achieve that.

Full scan configuration UI style

QuickScan scan configuration UI

Aesthetics is not always about “prettiness”. When we redesigned the AppScan Standard Edition scan configuration screens, our developers worked hard to align controls across all screens on one imaginary vertical guideline. This created a natural, aesthetic feel when toggling between screens.