<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title></title><style type="text/css">.felamimail-body-blockquote {margin: 5px 10px 0 3px;padding-left: 10px;border-left: 2px solid #000088;} </style></head><body>Am 09.01.2014 15:01:14, schrieb Thomas Pfeiffer:<br><blockquote class="felamimail-body-blockquote">> http://techbase.kde.org/Projects/Usability/HIG/Placement<br><br>Not sure if people would look for size guidelines under "Placement". Maybe we <br>should rename it to "Sizing and Placement"?<br></blockquote><p> The link itself is set for "size and space"....</p><br><blockquote class="felamimail-body-blockquote">> * If the control appears in a dialog or utility window, consider making the<br>> window and the control within it resizeable so that the user can choose how<br>> many items are visible at a time without scrolling. Each time the user<br>> opens this dialog, set its dimensions to those that the user last resized<br>> it to. <br><br>Not sure if "making the window and the control within it resizeable" might <br>lead people to think that controls generally should be resized along with <br>windows, which not all of them should.<br>In fact, we might have to provide guidelines about which controls should be <br>resized when the window resizes and which should not.<br></blockquote><p>Agreed. But I have no idea how to discriminate bith except the modeless stuff as discussed below.<br></p><p> </p><blockquote class="felamimail-body-blockquote">> * Size controls with a minimum of<br>> ** Icon: 16x16px<br>> ** Buttons: 75 x 23px<br>> ** Edits, Drop-downs: ≥80 x 23 px<br>> ** Text boxes: ≥80 x ≥39 px (text should not exceed 80 characters per line)<br>> ** Check box, Radio button including label: ≥80 x 19 px<br>> ** Group boxes: ≥120 x ≥90 px<br>> ** Tree view: ≥120 x ≥90 px<br>> ** List view: ≥80 px (per column) x ≥90<br>> * Make sure your application works with at least 640x480px, which is the<br>> minimum for KDE SC. <br><br>Is 640x480 really still the relevant minimum size for desktop applications? <br>Trying to cram everything into a 640x480 window might even lead to sub-optimal <br>design for today's desktop/laptop screens...<br></blockquote><p>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. ;-)<br></p><p> <br></p><blockquote class="felamimail-body-blockquote">> * Modal dialogs must not be resized.<br><br>Why must modal dialogs in general not be resized? Not all modal dialiogs are <br>strictly question and answer. The File open/save dialogs are modal, and they <br>definitely _should_ be resizeable.<br></blockquote><p>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.<br></p><p><br></p><p><span id="felamimail-body-signature"><br></span></p></body></html>