I have tried really hard to make all screens compliant with a resolution of 800×600. I don’t know what percentile of people use that resolution but I believe it’s not negligible. So, at least one template (just a special CSS really) will be aimed specifically at 800×600 users.
Now, I have reached one screen where I can’t fit in 800 pixels and do it gracefully: the month view of the schedule. It has to display 7 horizontal boxes, one for each day of the week, plus the sidebar. Since the real horizontal space I have is 760px (800px - browser’s scrollbar and border) and the sidebar is 160px I only have 600px left. That’s about 85px for each box, which really is too low. Things I tried:
- Removing the sidebar on the month view. Not good because the sidebar has useful information, plus navigational elements. Moreover it’s disturbing going from any other screen to the month view and vice versa.
- Displaying the days one under the other. Very bad, it doesn’t resemble a month view any more. It looks like a list.
So I am leaving it like that for now (in 800×600 either the boxes overlap with the sidebar or a horizontal scrollbar appears). If you happen to have a good solution in mind please advice!
Yeah, calendars stink. I’ve always had a tough time with them. I did notice that in Basecamp their calendars appear to only expand days that have an item and leave the other days as narrow boxes. However, they only show two weeks I think, but it may be something to look at for some ideas.
Comment by Ian Landsman — August 26, 2005 @ 17:58
The best approach I’ve seen is “progressive layout“. Very interesting technique.
Comment by Panayotis Vryonis — August 26, 2005 @ 18:53
I think “800×600″ may be less important than you think. I have a hard time believing that anyone, even in a corporate environment, has that running on their machine. Even 14/15 inch laptops run natively at 1024 x 768.
I do think keeping your app useable under 800 pixels wide is important for another reason. There are people out there, like myself, who don’t like an app/web page to fill up their entire screen. The 800 pixel wide mark should be the goal, but don’t spend too much time worrying about it. You’ve probably got more important things to do with your app than shaving off a few pixels from the width (of one screen!). And if it really does bother you, come back to it after your first beta.
Comment by Michael Sica — August 27, 2005 @ 19:52
Ian: Basecamp indeed solves the problem but in one case they hide the sidebar and in another case they don’t have a “new” task link inside every day (which I want).
Panayotis: progressive layout is interesting but I can’t see how it would solve my problem since I really don’t have the screen estate needed.
Michael: I am not so sure although I would love to see any hard facts on this. Check these recent stats:
w3schools.com
25% use 800×600
utexas.edu
11% use 800×600
upsdell.com
27% use 800×600
weblogs.asp.net
37% use 800×600 (but 2004 stats)
And you can find dozens more… So I am really sceptical about it!
Comment by Dimitris Giannitsaros — August 29, 2005 @ 00:19
The idea behind progressive layout is (if I got it right) conditional formating. When the resolution is too small, asume it is X1 px wide. When it is “normal” use a scaled layout. If it is too big, use a layout that only extends up to X2 pixels wide.
Comment by Panayotis Vryonis — August 29, 2005 @ 01:31
You forgot this one, it shows 24%:
http://www.thecounter.com/stats/2005/July/res.php
(That 37% number is from almost 2 years ago.)
Dimitris, design for 800×600 (like we all are, myself included). But don’t spend a lot of time worrying about it for 1 screen while you’re still in development. Come back to it once all your functionality is complete. I’m suggesting getting your code base complete and bug free before spending a lot of time on making your layout fit in a resolution that most businesses don’t have their machines set to.
That level of nit picking is great once all the code works!
Comment by Michael Sica — August 30, 2005 @ 03:55