[kde-guidelines] Styleguide: Placement

[Thomas Pfeiffer]

On Thursday 09 January 2014 14:30:35 Heiko Tietze wrote:
> Am 09.01.2014 15:01:14, schrieb Thomas Pfeiffer:
> > > http://techbase.kde.org/Projects/Usability/HIG/Placement
> > 
> > Not sure if people would look for size guidelines under "Placement". Maybe
> > we should rename it to "Sizing and Placement"?
> 
>  The link itself is set for "size and space"....

Size and Space is fine with me, too. I still think we should rename the actual 
page for consistency.

> > > * If the control appears in a dialog or utility window, consider making
> > > the
> > > window and the control within it resizeable so that the user can choose
> > > how
> > > many items are visible at a time without scrolling. Each time the user
> > > opens this dialog, set its dimensions to those that the user last
> > > resized
> > > it to.
> > 
> > Not sure if "making the window and the control within it resizeable" might
> > lead people to think that controls generally should be resized along with
> > windows, which not all of them should.
> > In fact, we might have to provide guidelines about which controls should
> > be
> > resized when the window resizes and which should not.
> 
> Agreed. But I have no idea how to discriminate bith except the modeless
> stuff as discussed below. 

That's difficult, indeed. Maybe there can be no general guidelines for this. 
Actually, I think this whole sentence should just be removed. Resizing is 
covered in its own section, so the sentence "Each time the user opens this 
dialog, set its dimensions to those that the user last resized it to." could 
just be moved there.

> > * Size controls with a minimum of
> > > ** Icon: 16x16px
> > > ** Buttons:  75 x 23px
> > > ** Edits, Drop-downs: ≥80 x 23 px
> > > ** Text boxes: ≥80 x ≥39 px (text should not exceed 80 characters per
> > > line)
> > > ** Check box, Radio button including label: ≥80 x 19 px
> > > ** Group boxes: ≥120 x ≥90 px
> > > ** Tree view: ≥120 x ≥90 px
> > > ** List view: ≥80 px (per column) x ≥90
> > > * Make sure your application works with at least 640x480px, which is the
> > > minimum for KDE SC.
> > 
> > Is 640x480 really still the relevant minimum size for desktop
> > applications?
> > Trying to cram everything into a 640x480 window might even lead to
> > sub-optimal design for today's desktop/laptop screens...
> 
> All values are my best guess, or rather any guess. In general I believe
> designers should discuss the guidelines in this section. But it seems to me
> that KDE has only a few pixel pushers for icons, if at all. ;-) 

Indeed, (UI) designers are a veeeeeeery rare resource within KDE, which is a 
pity. There was a guy commenting on design issues in KDE on G+ a while ago and 
I invited him to join us. He said he'd like to, but he doesn't have time for 
it right now.
 
> > > * Modal dialogs must not be resized.
> > 
> > Why must modal dialogs in general not be resized? Not all modal dialiogs
> > are strictly question and answer. The File open/save dialogs are modal,
> > and they definitely _should_ be resizeable.
> 
> First. the difference between modeless and modal forms has a major impact on
> usage but is nowhere indicated in the UI.  This could be improved by this
> rule. Furthermore, modal dialogs are usually intended to get closed quickly
> - just yes or no, next step etc. Nothing that makes an elaborated
> interaction necessary. Why should such a form be resized? I have to admit
> that your file dialog argument is valid. To keep my line of arguments I'd
> say the file dialog is poorly designed if it needs resizing by users.

One of the major gripes I've had with (applications on) Windows for a long 
time (and still have) is that in many cases they don't allow resizing of 
dialogs (some modal, some not) where it would indeed be necessary (don't know 
if because of some guidelines or just because class XYZ does not support it). 

I agree that probably >90% (or maybe even >95%) of modal dialogs do not need 
resizing because they are indeed just yes/no/cancel dialogs, but I would not 
agree that all modal dialogs do not need to be resized. I believe that such 
broad definitions may lead to dialogs such as those found in the Windows world.
Even if the majority of modal dialogs don't need resizing, I'd still prefer 
having a resize handle I don't use do not having one when I need it.

I find features such as KWin's "darken dialog parent" effect to be better 
indicators for a modal dialog than missing resizeability.