elementary OS uses consistent user interface elements referred to as widgets to bring a unified and predictable experience to users, no matter what app they're using. Correctly using these existing widgets helps ensure a small or nonexistent learning curve for your app.
Notebooks are a type of widget that lets apps show one of multiple pages (also colloquially referenced as "tab bars").
A Static Notebook is a small set of unchanging tabs, commonly seen in preferences or settings screens. The tabs appear as linked buttons centered at the top of the content area. A Static Notebook should typically contain two to five tabs.
A Dynamic Notebook is a way for an app to provide user-manageable tabbing functionality, commonly seen in web browsers. The tabs appear attached to the toolbar on their own tab bar above the relevant content. Tabs are able to be rearranged and closed, and a "new tab" button is at the start of the notebook widget.
Buttons are an incredibly important widget to understand since your app will undoubtedly contain them.
Tool Buttons are almost always icon-only and do not provide a button border. They should not be accompanied by a label.
All Tool Buttons should have tooltips, since they do not contain a label. This assists users with disabilities as well as giving a translation for an unrecognized icon. Tooltips should be done in sentence case without terminating punctuation.
Like text button labels, a tooltip should clearly describe what will happen when the button is pressed.
If a button has a related keyboard shortcut that will perform the same action, its tooltip should include the shortcut. See Granite.markup_accel_tooltip () for specifics.
Text Button labels should be done in title case.
Like menu items, Text Button labels should consist of an Action or a Location but not a status. Make sure that a button's label clearly describes what will happen when it is pressed.
"Remove Account", "Transfer to Jim's Laptop", and "Import 20 Songs" are good labels.
"OK", "Get more storage!", and "Low Battery" are not good button labels. The "Get more storage!" label has incorrect capitalization and unnecessary punctuation. The other two labels do not indicate what will happen as a result of clicking the button.
Since Text buttons have a clear and explicit label, it's usually unnecessary to give them a tooltip.
See also:
Why The OK Button Is No Longer Okay by UX Movement
Should I use Yes/No or Ok/Cancel on my message box? on UX Stack Exchange
A back button is simply a text button with a special style class. It should be used to navigate back to a previous view, typically from a child view to the main view.
The text of the button should be the title of the previous view. If the button will take the user “home,” then “Home” may be an appropriate label; however a more specific label is preferred, such as “All Settings” in System Settings. Avoid just using “Back,” as the back button is visually distinct and going back is already implied by its unique shape. The button should tell the user where it will take them back to.
When using a back button, it is recommended to use a Gtk.Stack to switch between views. This way you get a sliding animation further representing the backwards progression when activating the back button.
Back buttons are typically seen in header bars, but can be used in other contexts as well.
The Welcome Screen is a friendly way to help users get started with your app.
Typically a Welcome Screen is used for apps like Music or Code where you have to import or create objects in a library before you can interact with them. This provides your users with a clear path to getting started and points out any immediate steps they must take before your app becomes useful.
If your app lets users clear its library, make sure that it returns to the Welcome Screen instead of an empty list.
The Welcome Screen consists of two sets of labels:
The first set explains the situation and what the Welcome Screen will help you accomplish. As an example, Music's Welcome Screen explains that your music library is empty and that in order for the library view to become useful, we must import songs into our library.
The second set of labels consists of the actions that will assist a user in getting started with your app. To use Music as an example again, one possible action is setting your music folder to an alternate location. First we name the action, "Change Music Folder". Then, we describe what the action does, "Load music from a folder, a network or an external disk."
Grouped with each action is an icon that helps to quickly visualize it. Most of the time these will be Action icons, but you can use Places icons when importing or setting a location and even Apps icons if you must open a configuration utility.
Apps that support the searching or filtering of content should include a search entry on the right side of the app's toolbar. This gives users a predictable place to see whether or not an app supports searching, and a consistent location from which to search. GTK provides a convenient complex widget for this purpose called Gtk.SearchEntry.
Search is for filtering the contents of a library, i.e. Music or Videos, to the matching items. Search is typically initiated when typing anywhere in a library view.
Find is for highlighting matching instances of a string, i.e. in a text editor, web page, or Terminal. It is triggered by a keyboard shortcut (Ctrl+F) or with a search icon. The find bar appears in a revealer below the header bar with relevant actions such as find next, find previous, highlight all, etc. The revealer may also contain other relevant actions such as replace or go to line.
If it is possible to include search functionality within your app, it is best to do so. Any list or representation of multiple pieces of data should be searchable using a search field that follows these rules:
Results should be instantly shown as you type. This helps your app to appear faster and is more useful than having to hit "Enter" and wait. Exceptions may be made if the data is not stored locally.
In most cases, the search should be case-insensitive; users should not be expected to provide the exact capitalization. A good compromise is "smart case" where case is respected whenever the user intentionally types lower and upper case letters.
Search fields should contain hint text that describes what will be search. You can set this using the entry property "placeholder_text".
Most search fields should use the format "Search OBJECTS" where OBJECTS is something to be searched, like Contacts, Accounts, etc.
If the search field interacts with a search service, the hint text should be the name of that service such as "Google" or "Yahoo!"
