GNOME Bugzilla – Bug 111772
Guidelines for supported screen sizes (and how to support them)
Last modified: 2020-12-04 18:20:49 UTC
The guidelines could do with a warning about making sure that Windows are small enough to be usable on small displays or low resolutions (such as 640x480). This is not just for people with crap hardware (i saved money by not upgrading my monitor until very recently) laptops and other portable devices have much smaller screens. Users who dont use the default font sizes will change the layout of dialogs and there are othere factors too, there is never any reason not to allow windows to be resized, there simply isn't. With a little bit of forethought developers can avoid excluding any users and potentially make any future porting to compact devices easier. I briefly discussed this with Calum Benson many months ago and he suggested that I file a bug report. With a little guidance I would be happy to try and write the necessary information myself.
Because windows size depends on the theme, I don't see how we can say "make sure your window is not bigger than XXX". We could just say "make sure your windows are not full of too many controls, or too much whitespace". But surely we already suggest the use of notebook tabs, and it's kind of common-sense not to have a big empty window. If you can write a paragraph with the advice then we could discuss it.
http://slashdot.org/comments.pl?sid=66217&cid=6095866 Murray, you should take a look at the above comment. I should get organised and draft something for this soon.
The "no larger than" rule can be set against the default theme. E.g., "Ensure that the minimum size of a window is no larger than 640x480 in the default theme." Another matter entirely: " . . . there is never any reason not to allow windows to be resized, there simply isn't." The only resizing that is ever forbidden is direct user resizing. That is forbidden only where it is pointless, in windows without scrollable areas (therefore all alerts). The pointlessness is the reason. Of course if the theme or font changes, the "non-resizable" window should resize. There was never any question about that. (Once again, nothing is obvious.) Non-resizability does not mean hard-coded pixel values. Anyone fixing sizes that way should suffer something horrible for his ignorance. Non-resizability should be enforced by setting the max/min sizes of the window to the same value AND adjusting that value when the natural size (which is determined by Gtk+ based on theme and font) changes. It would be simpler to use the Motif hints, but you can't rely on those to be supported by the window manager. Resizability doesn't help for small screens. Below a certain window size, either controls are invisible or they overlap in a most grotesque manner. (Large workspaces do help, but those are long gone from standard GNOME.)
> Resizability doesn't help for small screens. Below a certain window size, either controls are invisible The controls not being visable onscreen is exactly the problem. > or they overlap in a most I was not suggesting that we force the widgets to overlap. If for example you maximise a the window to try and fit it on a small screen additional scrollbars would need to appear to allow you to force scrolling to the bits you cannot see. I am pretty sure I must have seen this somewhere before (sawfish perhaps). This is only a first draft and it has descended into a very very rough draft and will undoubtedly need to be rewritten in newspeak. Initially I thought I would be able to write this more clearly and state a guideline but gradually I started feeling a need to qualify and argue all my points persuasively, so please treat this only as a very rough draft and leave the arguing and justification of the ideas for later. The heights and widths need to be written in some consistant manner, probably width then height (x then y or i then j, seems reasonably sensible). Anything in Brackets [] was an attempt at Commentary/Editorial. Gnome is used on by many differnent people on a wide variety of differnt hardware. This includes people with older hardware and very small displays. Laptop users and users of other portable devices also need to be able to work on smaller screens. [Not sure how to best phrase this or even if it is worth mentioning but in my case I prefer having a higher refresh rate and full colour to a much larger desktop] Try to ensure that the size of a window is no larger than 480 pixels wide and 640 pixels hight in the default theme (including window decorations). Ideally your appliction should be usable at 600 by 400 pixels which leaves enough room for both top and bottom Panels. While these space restrictions are intended primarily to allow people with smaller displays to use Gnome it is also good discipline to keep windows and dialogs clear with not to many concepts all at once. [Gnome Print is an example of how not to do it. the sentiment of this paragraph might be useful although it would need to be massively rephrased.] The Ratio of the screen width to height is 2:3 and things will look aesthetically pleasing if we can keep (near to) this proportion. [the space take by window decorations largely spoils this idealism] Dialogs [like a properties dialog] should [probably] be 300 by 400. Message Dialogs should be 600 by 200. I cant think if more needs to be said but I think that about covers it, I will try again later at writing this more clearly.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
I've slotted your draft text into the Layout chapter for now (since there's already a guideline about aspect ratios there), with notes to indicated that it still needs work and/or relocation. http://developer.gnome.org/projects/gup/hig/draft_hig_new/design-window.html#layout-window-size Okay to close this bug with this assumption, or do you want more discussion here?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
closing since no more discussion has taken place
and now for the actual change of the radio button like i had promised
This never actually made it into the HIG 2.0 so I dont think it should have been closed. It has basically gotten lost in the meantime. The reason I was reminded to check this was Eugenia was quite rightly complaining about this problem that many developers refuse to recognise: http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00263.html
Calum Benson emailed asking to file a bug report for the HIG component about this issue, but I see that there is already one. Alan, thank you for letting me know of this bug report. So, to recap (however it would be good if you read the discussion as linked above by Alan): 1. Developers don't have a guide about what default window sizes they should create for their dialogs and apps. This is what the HIG is for and that's why it should be updated with a guideline about the issue. 2. 800x600 is still used by 20-25% of the population, which is a huge number: http://www.osnews.com/story.php?news_id=7440 3. I would not bother with VGA support, only ~1% of the userbase uses it. So, please update the HIG and include the following guideline: No default window or dialog should be created bigger than 720x500. This is a window size that fits on a SVGA screen when taking into account: a. Two gnome panels (top and bottom) with 32pix height each. b. A window manager theme up to 30 pixels high. c. One gnome panel (left or right, vertically) or about 64 to 70 pixels (usually users would want it to be "thicker" when a panel is aligned left or right so they can read easier the window titles from the taskbar). The rest few pixels are for the window manager's vertical borders. So, overall, a window size of 720x500 as the maximum size is a good approach to fit on any randomly configured SVGA screen. Please note that this guideline is only true for 99% of the apps out there, but not for high-end/pro graphics and scientific applications. For example, if 3D Studio Max was to be ported to GTK, this guideline would not affect it as such apps require lots of space "by nature". But for all other gnome/gtk apps, INCLUDING the Gimp (which is the main raster app for Gnome and therefore used by most gnome users), their developers should strive for a maximum width of 720 and height of 500, or less. That's for the desktop version of Gnome. Different guidelines apply for the GPE environment, the GTK-based DE for the Zaurus PDAs that uses some ported gnome apps sometimes (220x280 is a good maximum window limit on these QVGA 240x320 devices ).
I learnt Java and HTML (and I learnt proper layout) before I ever looked at GTK or GNOME. Frankly I was appalled that layout must be done using fixed layout or tables. For me a nice flowing layout that could easily adapt to different monitor sizes and text sizes was the ideal and with difficult to program fixed layouts it was no wonder programmers were coming up with such user unfriendly designs. My point is I think we would be better with a shorter less specific entry than what Eugenia has suggested and encourage developers to design things clearly, keeping differnt tasks seperate and leaving open the option of porting their apps to smaller displays. What I wrote would definately benefit from the addition of some of the detail Eugenia has suggested. I think about half way between
>For me a nice flowing layout that could easily adapt to different monitor sizes and text sizes was the ideal Not for me. There are some GTK apps that when you resize their window the widgets resize as well to fit the new window. YUK. I have never seen uglyier interfaces. You see, what is the point of resizing an input box if 100 pixels is enough for it? (e.g. an input box for phone numbers). Resizing it would make it unesessary long and ugly. And it doesn't help the usability either, because the text font size would be the same (the input box's height won't change). And if you do need the extra space, use a textarea widget, not an input box. >keeping differnt tasks seperate Agreed on this > and leaving open the option of porting their apps to smaller displays. No. That creates additional work that is not necessary. I know, I've been there. I constantly maintain two front ends for my site, OSNews.com: one for desktops and one that works without creating horizontal scrollbars even on phones with 128x128 resolution. I can tell you, it's a big pain in the bum maintaining both copies (no, CSS is not an option, we are talking about phone browsers that hardly can render HTML 3.2). Anyways, I believe that beautiful and well integrated dialogs can be created on a 720x500 size (as maximum default, smaller is also good) and there is no reason to create bigger dialogs or have resizing dialogs for no good reason. Besides, smaller, well-designed dialogs would enhance the SDI-ness of Gnome, instead of feeling that the interface is one big MDI thing.
Alan makes a good point here: >Frankly I was appalled that layout must be done using fixed layout or tables. >For me a nice flowing layout that could easily adapt to different monitor sizes >and text sizes was the ideal and with difficult to program fixed layouts it was >no wonder programmers were coming up with such user unfriendly designs. The need to nest things inside multiple containers in order to achieve the HIG-recommended layout is a bad sign. It's messy for developers, and it impedes accessibility because of the proliferation of "purely cosmetic" containers for blind users and assistive technologies to wade through. Isn't there an RFE for fixing this/providing a simpler HIG-compliant layout using gtk+ ?
Eugenia wrote: > So, overall, a window size of 720x500 as the maximum size is a good approach > to fit on any randomly configured SVGA screen. I would hesitate to actually naming numbers in guidelines (ok, HIG has them already in spacing, but still). The reason is simply the nature of humans; give them slack and they'll use it. What this means here is that if you say that it's ok to use 720x500 pixels, developers might consider less as to what they are cramming into their interfaces since it fits to 720x500 and is thereby "ok" (when actually it's not). There's no use to argue that there already is statement that less is more, if you state a number, people will use that instead of their brains. I do agree that the number is probably right, and that 800x600 is the lowest that is reasonable to require (for desktop apps). But instead stating that "design up to 700x500", the guide should say "design as small as possible" and add a note that it's a REALLY good idea to test the interface at 800x600, and that some people like to have large panels but that it should not limit the usage of your application. This makes developers to consider more carefully what they are doing with their interfaces, since they are not really sure if their interface actually works on 800x600, BUT are aware that it should. NOTE: "as small as possible" includes usability and layout considerations
sorry Eugenia I wasn't clear enough about what I meant (but I think Bill got the gist of it, but I was really talking about a gtk problem more than anything else) but that is not important. It is more imporant that we come to an agreement and get something we are happy with added to the HIG sooner rather than later. It is well worth mentioning that many users are still on 800x600 and also mentioning that panels need to be taken into account without necessarily specifying specific pixel values which will hopefully force developers to be more rigourous. I'm a bit of an extremist but I'd honestly like to see dialogs no larger than 600x400. Application windows are another matter and could get away with being quite a bit larger. Incidentally I've noticed that Microsoft Office has toolbars roughly 600 pixels or less, and they have a good dock system which allows users with larger screents to put two 600 pixel toolbar end to end and make pretty good use of their 1024 or 1278 wide displays (currently GTK developers would have to use BonoboDock to get this kind of functionality). Hopefully we can expand on suggestion that Calum was willing to include in the draft and improve it enough so that it can be included in the HIG proper. I'm more concerned about getting it in than getting the details precisely right so I looking to agree with people.
*** Bug 301517 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Related discussion: http://mail.gnome.org/archives/usability/2008-January/msg00014.html
This proposal could also cover the usage of logos in application windows. Some apps have big useless logos in their window - ie. Ubuntu Tweak, Envy. This reminds me of some MS Windows apps. Usage of useless decorations and logos should be prohibited in HIG.
Correction: such logos could be allowed only in "About" windows/tabs/dialogs/etc
Agree that it would be good to have something on supported screen dimensions. I have some draft material that I can work up.
*** Bug 752224 has been marked as a duplicate of this bug. ***
Pushed initial guidance on display compatibility: https://git.gnome.org/browse/gnome-devel-docs/commit/?id=e72e80497abf5529c259e28ef20d073b2e64cead