Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
panel-hig [2008/03/03 05:39] – split help and about so that maybe we can get something conclusive on at least one ongardie | panel-hig [2009/01/09 11:14] (current) – removed 88.172.125.130 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Human Interface Guidelines for Panel Plugins ====== | ||
- | |||
- | This page is very much a work-in-progress at the moment. Feel free to contribute. [[panel-hig: | ||
- | |||
- | ===== About ===== | ||
- | |||
- | ==== Rationale ==== | ||
- | UI consistency is an important aspect of a mature desktop like Xfce. On the other hand, there are tons of panel plugins out there, developed by many different people. A written set of UI guidelines will help those developers ensure their plugins maintain some basic level of consistency. | ||
- | |||
- | |||
- | |||
- | |||
- | ==== Process ==== | ||
- | We're trying to do this in a wiki fashion, so everyone is welcome to improve this. When you add something new, put " | ||
- | |||
- | ==== Plugin Classes ==== | ||
- | Most guidelines apply differently based on the plugin class. (" | ||
- | |||
- | |||
- | |||
- | ===== General ===== | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ==== Tooltips ==== | ||
- | * [rfc] Indentation for sublevel entries should be: 2 spaces? 4 spaces? \t? | ||
- | * //ongardie 2007/12/21 01:51 I think I like 2 spaces the best, personally. // | ||
- | * With GTK+2.12 you can add widgets in a tooltip, and therefore labels with markups, for bold for example. | ||
- | * Or maybe a \t with a configurable (plus sensible default) tab width? -- // | ||
- | |||
- | |||
- | Possibly 4 spaces: | ||
- | {{http:// | ||
- | |||
- | No spaces: | ||
- | {{http:// | ||
- | |||
- | 2 spaces: | ||
- | {{http:// | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ==== Context Menu ==== | ||
- | Interface guidelines regarding the right-click menu provided by the panel. | ||
- | |||
- | * [rfc] Help? | ||
- | * //ongardie 2007/12/18 05:51 The current trend is to not include these at all but to put information on the plugin web site. // | ||
- | * [snip] The plugins are simple to use, usually the help is helpless. | ||
- | * Some plugins have a dialog with a Help button which opens a webpage. | ||
- | * To clarify, Mike meant to say they display a Help button in their preferences/ | ||
- | * Help has to be added manually to the context menu, and I agree with Mike in that its almost always unnecessary. I think the guideline here should be "Help context menu items are discouraged. A Help button inside the properties dialog is optional (see ...)" --- // | ||
- | |||
- | * [rfc] About? | ||
- | * //ongardie 2007/12/18 05:51 The current trend is to not include these at all but to put information on the plugin web site. // | ||
- | * // fabian 2007/12/18 22:47 GMT Well, some plugins just run the opposite trend: Disk Performance Monitor, Quiklauncher, | ||
- | * The three plugins fabian pointed out [...] show an About item in their context menu. Each of those about dialogs is rather poor, IMHO. I think the guideline should be "About menu items are discouraged." | ||
- | |||
- | ==== Menus ==== | ||
- | Interface guidelines regarding plugins' | ||
- | |||
- | * [draft] Optionally, display a title \\ If you would like to add a title to your menu, set it insensitive and bold, and place it on top of the menu followed by a separator \\ {{http:// | ||
- | * I'm not convinced I like this. Perhaps we should discourage menu titles instead. --- // | ||
- | |||
- | |||
- | |||
- | |||
- | ==== Settings Dialog ==== | ||
- | Interface guidelines regarding preferences/ | ||
- | |||
- | * [rfc] When to store (save) altered settings? \\ Moved to [[panel-hig: | ||
- | |||
- | * [draft] If possible, settings modifications should immediately take effect. Otherwise, settings modifications should take effect when the properties dialog is closed, and the plugin' | ||
- | * The sensitive part can be dropped, it just works if the dialog is set modal (see [[http:// | ||
- | * Indeed in Xfce it is very common to apply changes immediately unless you are making more complex changes. Please avoid insensitivity or modality where possible. --- kalikiana 2008/01/26 17:06 | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ===== Class B: Button ===== | ||
- | < | ||
- | |||
- | sometimes opening a menu | ||
- | |||
- | examples: menu, places, launcher, window list, mount, ... | ||
- | |||
- | {{http:// | ||
- | |||
- | * The widget(s) should be contained in a box, preferably an XfceHVBox for convenience. | ||
- | * The order of the widget(s), top-to-bottom or left-to-right should be: | ||
- | - image | ||
- | - label | ||
- | * //fabian 2007/12/17 19:22 GMT. Regard other languages such as arabic, they will most probably want the opposite order.// | ||
- | * The box should have a default border (1px). | ||
- | * [draft] The box should have a spacing of 4px. | ||
- | * Plugins known to implement this: | ||
- | * xfdesktop (4.4.2 and trunk) | ||
- | * places (1.0 and trunk) | ||
- | * If there are no objections by 2008-01-19 (two weeks from now), " | ||
- | * I don't think the box should have a border/ | ||
- | * [draft] The image inside the button should be set to the same size as the button (usually the size of the panel) without its padding and border size: \\ < | ||
- | GdkPixbuf *pixbuf; | ||
- | |||
- | size = xfce_panel_plugin_get_size (panel_plugin); | ||
- | size -= 2 + 2 * MAX (panel_plugin-> | ||
- | |||
- | icon_theme = gtk_icon_theme_get_default (); | ||
- | pixbuf = gtk_icon_theme_load_icon (icon_theme, | ||
- | if (G_UNLIKELY (NULL == pixbuf)) | ||
- | return; | ||
- | gtk_image_set_from_pixbuf (GTK_IMAGE (panel_plugin-> | ||
- | g_object_unref (G_OBJECT (pixbuf)); | ||
- | </ | ||
- | * Note: this is more a problem of what to do with the size-changed signal | ||
- | * Use a short label to conserve space | ||
- | * On the label, use capitalization like a title (e.g., "My Button" | ||
- | |||
- | |||
- | |||
- | ===== Class I: Input ===== | ||
- | < | ||
- | |||
- | database queries, command execution, etc from the panel | ||
- | |||
- | examples: verve, dict(ionary) | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ===== Class M: Monitor ===== | ||
- | < | ||
- | |||
- | the resource monitoring ones. Many plugins display a monitor and give the user the option of showing a label, a value reading, or both. For example, the systemload plugin can show labels and monitors for CPU, memory, and swap usage. | ||
- | |||
- | {{http:// | ||
- | |||
- | |||
- | examples: system load monitor, battery monitor, sensors plugin | ||
- | |||
- | * The widget(s) should be contained in a box, preferably an XfceHVBox for convenience. | ||
- | * [draft] The order of the widget(s), top-to-bottom or left-to-right should be: | ||
- | - Icon | ||
- | - Label | ||
- | - Monitor | ||
- | - Value Reading | ||
- | * //fabian 2007/12/17 19:22 GMT. Regard other languages such as arabic, they will most probably want the opposite order.// | ||
- | * //kalikiana 2007/12/17 19:50 I'm not convinced that the Value must be at the very right. The Free Space Checker shows nicely how you can save space by joining Name and Value.// | ||
- | * {{http:// | ||
- | * //ongardie 2007/12/21 00:55 Yes, that's a nice effect. Would it work for any monitor? // | ||
- | * [draft] The box should have a default border (1px). | ||
- | * [draft] The box should have a spacing of 2px. | ||
- | * //kalikiana 2007/12/17 19:39 Space between labels was discussed before and the argument against it was that you can add space via ' | ||
- | * //ongardie 2007/12/21 00:58 Using whitespace is an unclean hack. If 2px is too much, maybe it should be only 1px. Screenshots might help. // | ||
- | * Use a short label to conserve space. Abbreviations are acceptable | ||
- | * [draft] Use all lowercase letters (e.g., " | ||
- | * // | ||
- | * //ongardie 2007/12/21 00:59 CPU is an acronym, so " | ||
- | * I don't like lowercase either. It depends on what the monitor stands for. --- // | ||
- | * On the label, omit punctuation in acronyms and abbreviations (e.g., " | ||
- | * On the value reading, don't include too much precision (e.g., " | ||
- | * [draft] On the value reading, include units if they add no more than 3 characters to the string (e.g., " | ||
- | * //fabian 2007/12/17 19:26 GMT Not possible -- " | ||
- | * //ongardie 2007/12/21 01:47 So should we just say "keep it short"? | ||
- | * [rfc] space between monitor bars? (some plugins combine multiple monitors) | ||
- | * //ongardie 2007/12/21 01:49 Probably about double the spacing we decide on inside the monitor. | ||
- | * [draft] use a -90° angle for monitor labels in horizontal panels and 0° angle for monitor labels in vertical panels. That might save a lot of space. | ||
- | * //ongardie 2007/12/14 06:17 I entirely agree. To clarify, the bar should be vertical and progress upwards for horizontal panels, and it should be horizontal and progress rightwards for vertical panels. // | ||
- | |||
- | ===== Class G: Grid ===== | ||
- | < | ||
- | |||
- | examples: icon box, task list, system tray | ||
- | |||
- | {{http:// | ||
- | |||
- | ===== Class O: Other ===== | ||
- | examples: pager, xfapplet | ||
- | |||
- | * [rfc] Border with other plugins (left/right for horiz. panels) should be ??? | ||
- | * [rfc] Border with panel edge (top/bottom for horiz. panels) should be ??? | ||