Jump to: navigation, search

Difference between revisions of "UX/PatternsLibrary"

< UX
m (Patterns)
m (Reverted edits by Sohan.singh040 (talk) to last revision by Piet Kruithof)
Line 34: Line 34:
== Patterns ==
== Patterns ==
Why UX design patterns work and how to use them.
First impressions are critical since users know within 10-20 seconds if they'll leave your site. Patterns communicate function and intent as clearly as possible within that window of opportunity.Here's how it works. Let's say a user wants to accomplish a task, like to book a hotel.
Take a look at a possible series of user actions:
A travel site presents the user with a list of possible places to stay.
The user taps the photo of a charming bungalow. Nothing happens. Lesson learned: Photos do not lead to more information about each property.
The user continues to explore. He or she may look for a "more info" link or tap on the nightly rate. They may try tapping the photo again, just in case. Left on their own, a determined user will continue to tap different elements in search of more information about the bungalow.
Finally, they tap the hotel name (perhaps presented as a button or link), and they're redirected to a more detailed page. The user sees a charming atmosphere but no complimentary breakfast. It doesn't fit their criteria, so they keep searching.
Now, here's where the pattern kicks in. Having learned that one thumbnail photo isn't tappable, but the hotel's name is, the user now knows exactly what to do.For more information [http://www.techved.com/uae/ux-design-agency Click here.]

Latest revision as of 06:23, 22 December 2016

Horizon Visual Specification

The intent of this wiki is to provide overall guidelines for implementing patterns for Horizon.


  • The patterns will assume that the dev is using angular.js.
  • The patterns are intended to provide some guidance, but will not be overly prescriptive.
  • Patterns should be vetted through the community before being included in this wiki.
  • Community members should feel comfortable adding/editing this document.

We are specifically trying to reach a compromise between being too prescriptive and having a portal that has an inconsistent experience.

Number of Clicks

A discussion around the numbers of clicks required to complete a task is appropriate because of the tendency to use it as a measure the efficacy of a design. For example, arguing that a design requiring three clicks instead of four is always better for users.


"The 3-click-rule is the Freddy Kreuger of web design advice. You think it’s finally dead and then it comes back and starts slashing up sensible debate about usable design. I’m hoping to convince you to stop talking about the 3-click rule. I don’t mean substituting it with the 4-click rule or the 5-click rule. You should stop counting clicks as a measure of usability altogether."

"If there is a scientific basis to the Three-Click Rule, we couldn't find it in our data. Our analysis left us without any correlation between the number of times users clicked and their success in finding the content they sought."

There are other ways to measure usability that correlate well with customer satisfaction. For example, there are a number of standardized questionnaires that provide ratings for individual tasks or overall experience.



Details Panel

The Details panel contains detailed information for an object in Horizon and is typically opened by clicking on the object name from a list in a panel. For example, you would typically click on an instance name from the Instance panel to view specific details for that instance.

Overall, you would need a Details panel if there is too much information to easily fit within a row in a table. For example, an Instance includes a source, flavors, quotas, and networks; way too much stuff to fit into a single row. In addition, the details panel should allow users to take an Action on a object based on the information displayed in the Details panel. For example, a user should be able to update the flavor for a specific instance within the Instance details panel.

Instance Details Panel.png

A: This area should only include descriptions and tags that describe the entire object. For example, Instance No. 12 is active and not content within one of the tabs. On the other hand hand, the amount of Ram within a flavor should be in the Flavors tab.

B: Tabs should represent resources that make up the object. For example, Instances are built from Images, Flavors, Networks, etc.

C: This area should only include content specific to that tab. For example, a tag describes the number of VCPUs within that specific flavor belongs on the Flavors tab.

D: Link to Details panel for the m1.small flavor.

E: Only include Actions that impact the entire object such as creating a Snapshot or Terminate Instance.

F: Detailed descriptions are important to new users. This is particularly important in OpenStack where the terms varies significantly from other cloud solutions.

G: Only include Actions that are related to content within the tab. For example, it is appropriate to include Resize Instance, but Create Snapshot would belongs at the top of the Details panel.

Wizard Modal

The wizard is a specific kind of modal that is intended to guide users though relatively complex actions such as launching an instance. They typically have steps that must be completed before the user can complete steps later in the workflow.

You should fight the temptation to combine steps in the menu to the right and found that design became visually cluttered and confusing to users. In some ways, the UI is a compromise between accommodation first time users, who want some hand holding, and advanced users that want to complete the wizard quickly. There is also the argument that more advanced users will likely use the CLI for these kinds of Actions.

Wikipedia has a description of wizards here.


A: The navigation to the left should display which steps need to be completed before the user is able to launch an object. Users should be able to complete these steps without having to complete previous steps.

B: In general, the step heading can have more text than is displayed within the menu. The rationale is that the menu has space constraints while the header can generally have more text.

C: The description should be as specific as possible. Please remember that not all users will be familiar with this UI or the vernacular user by the community.

D: Cancel button should always be aligned to the left side of the modal

E: The Back and Next buttons should be to the immediate left of the Action button. The Back button should not visible in the first step.

F: Launch Action should always be aligned to the right of the modal. It should be disabled until all required information is completed.

Simple Modal

Responsive Tables

Return to OpenStack UX Wiki