A recent thread on KDE-usability indicates that there's a growing dissatisfaction with the Keramik style's current state, and something less flashy would be preferable (or, at least, improvements to Keramik are sorely needed). It was quickly suggested that deciding on some basic rules for the replacement style was preferable to having everbody simply argue in favor of their favorite theme.
This page will collect all the basic critera suggested on kde-usability. I've avoided listing quibbles with specific styles, except where they suggest a broader UI design principle. I've also interjected some commentary or clarifications (in italics) where I think it's appropriate. Some of the suggested criteria will inevitably conflict with each other. In such cases, we will have to figure out which criteria take priority.
Note that, even if we figure out all the things we'd like in a style/decoration pair, it's probably unlikely that any existing style will fit exactly. In this case, I suggest that the best course is to switch to the closest style/deco pair, and wait for patches. This may mean simply refining Keramik, as several list members have suggested.
Other useful links:
[This seems to be the major complaint with the Keramik style---it's too visually imposing and feels awkward to use. ~keunwoo]
"3D is used in GUIs not just because it looks good" (Simon Edwards)
[I believe that usability studies have actually found that 3D improves the user experience---the human eye is hardwired to perceive 3D objects. Note that 3D need not be imposing---Light 3rd rev. and the Java Swing look-and-feel only incorporate a modest amount of 3D. ~keunwoo]
Different widgets should also be visually distinct from each other. This was raised as a deficiency in the dotNET style. (Simon Edwards)
Ideally, should be known to work with, and have been extensively tested against, both KDE and non-KDE Qt apps. Also, should have been in KDE CVS at least N months (N = 6?) before adoption as default theme. (~keunwoo)
"In other styles, my eye generally has to read from left to right, including the icons, which can confuse me. With the visual distinction of dotNET style menus, I seem to find the menu item im looking for much faster. There is a clear separation from the visual and textual cue, allowing me to use one (icon) or the other(text), and not have to mentally separate them (icon and text)." (Levi Burton)
For example, "Name should not use, by default, a name related to Microsoft (e.g., dotNet)" (Henrique Pinto).
[A name's easy enough to fix. Presumably we also shouldn't use a name primarily owned/associated with any other outside project. More broadly, I think that list members want a style that's got a strong KDE "brand", not some other company/project's "brand". ~keunwoo]
Branding/appearance are not a trivial matter; David Legg notes:
Keramik looks good, and does an excellent job of promoting KDE - that's it's main job. Keramic and the many cool and useful features of Kontact (which is by far and away the best piece of PIM software out there now, free or commercial) were essential in getting buy-in for the use of Linux and KDE on my current piece of contract work.
[I think we can all agree the theme should be good-looking, but this is pretty vague. Everyone has different ideas on what's good-looking. Although I suppose most people want a "modern"-looking theme, so e.g. RISC OS or Redmond are out. ~keunwoo]
The window frame's thickness should also be configurable, and bigger than 1 pixel by default. (William Leese, Levi Burton)
[This probably means using either Windows-style icons or MacOS-style '+', '-', etc. ~keunwoo]
In other words, the titlebar buttons should at least resemble standard button controls. This was raised as a flaw of the MKUltra decoration. (Simon Edwards)
[In other words, the "window actions" menu button should incorporate the application icon, and the default button configuration should include the application icon. ~keunwoo]
Some decorations currently clip the font if it is too large. (Levi Burton)
[The ideal might be to have the title bar resize its height automatically based on the font size, so that the user doesn't have to tweak this manually. ~keunwoo]
Decorations should be large enough to be easily clickable. When the window is jammed against a screen edge or corner, the last pixel on the screen edge/corner should be clickable. Currently KStep is the only decoration that has these properties, although KStep is probably unsuitable for other reasons. Note that this requirement implies that no decoration with curved corners is suitable, unless it captures clicks in the area between the corner and the curved edge. (~keunwoo)
Simon Edwards suggests that this should not be true for irreversible actions, like closing the current window, because you do not want to make it easy to close a window by accident.
[Actually, I do want to be able to close the window by "throwing" my mouse to the corner. If closing the window really results in some irreversible loss, the app should pop up a dialog for confirmation before closing. However, this is an interesting suggestion. ~keunwoo]
Max Howell notes that Windows and MacOS both have the "clickable on screen edge" behavior for window decorations.
switching style at all is a difficult thing and not easy to do due to: screenshots in documentation and websites, pictures in company/corporate literature, users who are used to it being a certain way, projecting a flaky image ...