Dev.Opera - Follow the standards, break the rulesDev.Opera - Follow the standards, break the rules

Login

Lost password?

Sign up

users

Sign up now to post in the forums, comment on articles, submit your own articles and more.

Opera Widgets Style Guide

By Opera Software · 27 Nov, 2006

Published in: , ,

This style guide define requirements and suggestions for how to design your Opera Desktop Widgets. It will help you to make visual decisions for your widgets without stopping you from being creative.

All widgets should have a close button. The close button should be permanently visible, or visible when on hovering the widget. More about the close button, including graphics you may use, below. Widgets not adhering to this requirement will usually not get approved for distribution on widgets.opera.com.

Keep It Small

Screen real estate is valuable - make your widgets as small as possible. Some users prefer smaller widgets to make better use of desktop space. This will also increase chances of your widget staying on the users desktop.

A small widget and a large widget with the same content

Keeping it small - which widget would you rather have pinned to your desktop?

Consider giving your widgets a thumbnail state, from which they may be expanded.

A minimized and normal state of the same widget

A widget in thumbnail and full states - an effective way of saving screen space.

Conserving screen real estate is especially important for widgets that the user is likely to consult often but briefly, such as clocks or RSS feeds. It is less important for widgets that the user will use more rarely but for longer time, such as games.

Keep It Responsive

The widget should respond visibly to the user interacting with it. Buttons, links and other controls should change when the user selects or activates them.

Images depicting normal, hover, active and focus states for buttons

A button with four states.

After the user has selected to perform a task, try to complete the task as fast as possible. If the task will require a long or unknown amount of time to complete, inform the user of the delay and, if available, the expected time of completion.

Two examples for progress bars

Animations and progress bars inform the user that the widget is active and responding.

Users spend most of their time using other people's widgets, they will come to expect the same functionality from yours. Look at previous widget designs. When applicable, use the same symbols for the same functions. Feel free to create your own graphics. Colour, typography and style may and should vary - symbols and their positions should not.

Be Consistent

Icons with similar symbols showing consistency

The style may change, the symbol should stay the same.

Consistency is especially important inside a widget. Keep buttons positioned at the same location, relative to the widget border, even when the widget changes size.

Relative button position

Buttons should retain their position relative to the widget borders.

Two buttons require special care: the close button, and the configuration button. Every widget should have a close button, it should be in the top-right corner, and it shold have the shape of an X.

Close buttons

Placing the close button in the top-right corner will let users recognize it immediately.

Widgets may optionally have a configuration button. Place it to the left of the close button, and use the widget gear as symbol.

Configuration button

Display the widget gear on buttons that open a configuration screen.

Keep It Simple

A widget should do one thing, and do that one thing really well. If the widget gets too complex, consider splitting it into smaller, more specialized widgets.

Complex widget Simple widgets

Controls used in widget user interfaces should provide easily understandable, essential information.

Feel Free to Invent

If you have a good but non-conventional user interface idea, a widget may be an ideal and relatively harmless place to test it out. If it violates this style guide, then forget the style guide. However, "It looks prettier when..." or "It takes me less time to code when..." are excuses, not innovations.

digg Digg this article  del.icio.us Add to del.icio.us

Article categories