KDE4 Guideline Requests
As I mentioned before, one of the goals for my break this winter is to specify an ambitious number of interface guidelines. By the end of the break, I hope to have a list to pass on to the HCI-related and Core-devel communities to comment on before committing. The current list of “topics” for the KDE4 HIG I have is huge, and working on random ones may or may not target immediate needs of developers.
What are specifications you have looked for or would like written? What are GUI questions you have stopped to ask yourself and wish you could go look up? Here is an opportunity to give me an idea of which guidelines or interface examples are the most important/immediate/interesting and should get drafted and finalized before nonpertinent items.
Please limit your request to one idea or concept, I would like to have a list which has attainable closure ;-)
Hi, Celeste!
I’d like to have better idea on how to design my application dialogs so the end-user likes them best. I think that’s one of major topics, and you have it on your list anyway, but still let me mention it here ;).
And if there’s something particular you can say about usability in games (I’m one of kdegames module commiters) I’d like to here about this too.
Cheers,
Dmitry.
Hi Celeste,
What actions should I put in a toolbar?
When to use a Close button?
Ok, stopping there as you said not flooding you with requests!
Have a nice winter break,
Anne-Marie
Hi,
My suggestions:
- how to lay out option dialogs
- what options to put in the first panel/tab, which in other tabs.
- what to do with “advanced” options, leave those out, use a tab or button for a sub dialog
- when to use frames to group, when not.
- how many sub dialogs should a configuration dialog open?
- what to put in a context menu (right click menu), what to put only in the main menu.
hope these are not too many questions, but also inspiration for the topics to write.
Thanks,
Diederik
Things like service menus (I think that is the right name) should only be appearing in appropriate circumstances, at the moment too many of them appear where they shouldn’t, e.g. “Download file with KGet” appears for files local to my machine… I suppose this is part of what is said above about “what to put in a context menu”
Also, menus bug me in a couple of ways… one, where the first item in a menu has a submenu, it’s hard to mouse over to use it, because if you deviate up a few pixels, it jumps and selects another menu entirely, while further down, it would just jump up to another menu item and be much easier to correct. Secondly, long menus (e.g. bookmarks) shouldn’t extend over the menubar that spawned them (where possible). Otherwise, doing a click on the menubar, then slide along to look for where some option or other is hidden won’t work. This causes the additional problem that a click and release on my bookmarks menu title will activate something, a deviation from regular behaviour. Also, really long menus need some better failure state. I got one of these by importing all the squarefree.com bookmarklets into my Konqueror minitools, where for some reason the folders aren’t respected, and a bit of wrong mousing now results in a screen full of menu items.
I’m not sure what guidelines (or just bugs) these map to, but these are the things that currently annoy me the most.
Hi Celeste!
I think this idea has already been a point of discussion but I just add it here to clear things up.
At the moment I have a few of resources in Korganizer, 2 of them are .ical files on a website. When this laptop is not connected to the internet I get these 1-button, blocking, dialogs all the time. This tends to be a huge problem to a lot of people I talk to.
Amarok nicely works around this problem by using these ’sliding’ dialogs (don’t know the name of the widget) which very kindly notify users without blocking the complete window.
I hope this issue will be taken into consideration. Thanks in advance!
Niels
Hi Celeste,
I would like to see a guide, which explains how to deal with multiple scrollable objects in an interface.
There seems to be different approaches. Some applications use the frame of the scrollable widget itself and some add an extra frame.
Sometimes a frame is used to group two scrollable widgets.
Also Scrollable Widget occur in TabWidgets which have an own frame like in Konqueror.
When would it for example be better to use just a TabBar instead ?
I would appreciate a guideline that brings some consistency int this field.
-sthiele
Hi,
I do not know if there is already a guideline for that but for me this feels strange as it is in 3.5.
When opening a context menu a leftclick somewhere beyond the menu closes the menu (so far so good).
Currently this leftclick also takes action where it is set (opens menus, selects checkboxes, paints in Krita when a painting tool is selected).
Same happens if a menu from the menubar is open… but if a submenu is open, the click doesnt affect the outher world.
So I suggest to make a leftclick only affect the opened menu (whatever menu is open), not the rest of the elements.
cheers
Hello Celeste.
Here are a few things that have recently been brought up in #koffice and where further clarification in the guidelines or directly from usability folks would be great:
- Configuration dialogs
More thorough specification of the preferred behavior and look of the configuration dialog.
- Ellipsis in menu items
There was a recent discussion in #koffice about when a menu item should have an ellipsis (…) appended and when it should not. The KDE guidelines are pretty sparse on this, only a couple of lines. It would be nice if the KDE guidelines would clarify if there are any cases where a window is shown as a result of pressing the item, where ellipsis should _not_ be shown, what’s currently said is that “A simple confirmation dialog is not considered a dialog that requires additional information.”. The Microsoft guidelines for this are much more verbose [1].
- Widgets side by side with the status bar
A “view bar” is in the process of being added to KOffice (or at least to some of its applications such as Krita). This consists of a few buttons and a numeric input for the zoom level, and it’s placed side by side with the status bar (technically inside it actually). What do the guidelines have to say about placing widgets in this area? It can be seen in applications like Inkscape and Photoshop.
- Interactivity of numerical zoom input
If the user interface directly offers a numerical input for the zoom level. When should the zoom be updated? When the user presses Return or Tab in the input widget? Continously as the number is typed in? After a certain number of milliseconds of keyboard inactivity in the widget? For the “view bar” described above it was (for now) decided that Enter or Tab is required for the zoom to be updated, but would be great to have usability folks’ input on this.
Regards,
Aron
[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch14d.asp
My suggestion is to have some kind of configuration not only for
the window decortaions and drawing properties of the widgets, but
also for the menus, toolbars and widgets that an application could have.
The programmers does not need to care much about the widgets, as they
are drawn using the choosen theme. The first time you use KDE 3 you see
a wizard that lets you choose the level of decorations and effects that you
want for the widgets.
I would like to see a similar wizard for the user experience with computers, from
iliterate, novice, intermediate to system administrator, and then show the user
a very simple KDE, a customizable KDE, or a fully customizable KDE.
The idea is to have the same kind of freedom choosing the decorations as choosing
the way the application works. As I do not know the QT4 toolkit, neither the KDE4 libs,
I can not say if this is possible or not.
The idea is similar to the linux distributions, when they choose the applications, the menus
and the options shown, but in a programmable way.
Let me explain with an example:
In a normal KDE, you see Konqueror with tabs (with or without closing widget, with out without ….), it can view doucments, ……
In a very simple KDE, Konqueror uses tabs without the closing widget, cannot split views….. (for example)
In a normal KDE, you can choose from several options when you try to print a document or scan something.
In a very simple KDE, you can choose from draft, normal when printing and the type of documento to scan when scanning….
I hope you understands the idea and it is possible, if not for KDE4, for KDE5.
Best Regards.
Menus:
- wording
- grouping
- icons
- submenus
- accels
I would have another thing for the menus.
There are several ways to mark things that can be shown or hidden.
IMHO the ones that say “Show Menubar” resp. “Hide Menubar” are a bit messy. One has to read the text carefully (maybe in some languages the words look quite similar) to recognise what a click will do.
The way where there is a ‘X’ in front of e.g. the word Menubar, it’s pretty clear, what a click will do. It’s the same behaviour as every checkbox.
For the menu there could be a better hint for the items that are not marked, instead of just no ‘X’, there could be an empty box (again like checkboxes).