<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Breaking the 800&#215;600 resolution</title>
	<atom:link href="http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/feed/" rel="self" type="application/rss+xml" />
	<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/</link>
	<description>Rapid Signal: a micro-ISV venture</description>
	<pubDate>Tue, 06 Jan 2009 22:00:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Michael Sica</title>
		<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/comment-page-1/#comment-123</link>
		<dc:creator>Michael Sica</dc:creator>
		<pubDate>Tue, 30 Aug 2005 00:55:03 +0000</pubDate>
		<guid isPermaLink="false">http://rapidsignal.com/blog/?p=92#comment-123</guid>
		<description>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 800x600 (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!</description>
		<content:encoded><![CDATA[<p>You forgot this one, it shows 24%:<br />
<a href="http://www.thecounter.com/stats/2005/July/res.php" rel="nofollow">http://www.thecounter.com/stats/2005/July/res.php</a></p>
<p>(That 37% number is from almost 2 years ago.)</p>
<p>Dimitris, design for 800&#215;600 (like we all are, myself included). But don&#8217;t spend a lot of time worrying about it for 1 screen while you&#8217;re still in development. Come back to it once all your functionality is complete. I&#8217;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&#8217;t have their machines set to. </p>
<p>That level of nit picking is great once all the code works!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Panayotis Vryonis</title>
		<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/comment-page-1/#comment-107</link>
		<dc:creator>Panayotis Vryonis</dc:creator>
		<pubDate>Sun, 28 Aug 2005 22:31:46 +0000</pubDate>
		<guid isPermaLink="false">http://rapidsignal.com/blog/?p=92#comment-107</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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 &#8220;normal&#8221; use a scaled layout. If it is too big, use a layout that only extends up to X2 pixels wide.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dimitris Giannitsaros</title>
		<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/comment-page-1/#comment-106</link>
		<dc:creator>Dimitris Giannitsaros</dc:creator>
		<pubDate>Sun, 28 Aug 2005 21:19:10 +0000</pubDate>
		<guid isPermaLink="false">http://rapidsignal.com/blog/?p=92#comment-106</guid>
		<description>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:

&lt;a href="http://www.w3schools.com/browsers/browsers_stats.asp" rel="nofollow"&gt;w3schools.com&lt;/a&gt;
25% use 800x600

&lt;a href="http://www.utexas.edu/teamweb/reports/screen_resolution/" rel="nofollow"&gt;utexas.edu&lt;/a&gt;
11% use 800x600

&lt;a href="http://www.upsdell.com/BrowserNews/stat_trends.htm" rel="nofollow"&gt;upsdell.com&lt;/a&gt;
27% use 800x600

&lt;a href="http://weblogs.asp.net/dburke/archive/2004/04/14/113458.aspx" rel="nofollow"&gt;weblogs.asp.net&lt;/a&gt;
37% use 800x600 (but 2004 stats)

And you can find dozens more... So I am really sceptical about it!</description>
		<content:encoded><![CDATA[<p>Ian: Basecamp indeed solves the problem but in one case they hide the sidebar and in another case they don&#8217;t have a &#8220;new&#8221; task link inside every day (which I want).</p>
<p>Panayotis: progressive layout is interesting but I can&#8217;t see how it would solve my problem since I really don&#8217;t have the screen estate needed.</p>
<p>Michael: I am not so sure although I would love to see any hard facts on this. Check these recent stats:</p>
<p><a href="http://www.w3schools.com/browsers/browsers_stats.asp" rel="nofollow">w3schools.com</a><br />
25% use 800&#215;600</p>
<p><a href="http://www.utexas.edu/teamweb/reports/screen_resolution/" rel="nofollow">utexas.edu</a><br />
11% use 800&#215;600</p>
<p><a href="http://www.upsdell.com/BrowserNews/stat_trends.htm" rel="nofollow">upsdell.com</a><br />
27% use 800&#215;600</p>
<p><a href="http://weblogs.asp.net/dburke/archive/2004/04/14/113458.aspx" rel="nofollow">weblogs.asp.net</a><br />
37% use 800&#215;600 (but 2004 stats)</p>
<p>And you can find dozens more&#8230; So I am really sceptical about it!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Sica</title>
		<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/comment-page-1/#comment-104</link>
		<dc:creator>Michael Sica</dc:creator>
		<pubDate>Sat, 27 Aug 2005 16:52:23 +0000</pubDate>
		<guid isPermaLink="false">http://rapidsignal.com/blog/?p=92#comment-104</guid>
		<description>I think "800x600" 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.</description>
		<content:encoded><![CDATA[<p>I think &#8220;800&#215;600&#8243; 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. </p>
<p>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&#8217;t like an app/web page to fill up their entire screen. The 800 pixel wide mark should be the goal, but don&#8217;t spend too much time worrying about it. You&#8217;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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Panayotis Vryonis</title>
		<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/comment-page-1/#comment-102</link>
		<dc:creator>Panayotis Vryonis</dc:creator>
		<pubDate>Fri, 26 Aug 2005 15:53:18 +0000</pubDate>
		<guid isPermaLink="false">http://rapidsignal.com/blog/?p=92#comment-102</guid>
		<description>The best approach I've seen is "&lt;a href="http://pro.html.it/articoli/id_620/idcat_31/pro.html" rel="nofollow"&gt;progressive layout&lt;/a&gt;". Very interesting technique.</description>
		<content:encoded><![CDATA[<p>The best approach I&#8217;ve seen is &#8220;<a href="http://pro.html.it/articoli/id_620/idcat_31/pro.html" rel="nofollow">progressive layout</a>&#8220;. Very interesting technique.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian Landsman</title>
		<link>http://rapidsignal.com/blog/2005/08/26/breaking-the-800x600-resolution/comment-page-1/#comment-101</link>
		<dc:creator>Ian Landsman</dc:creator>
		<pubDate>Fri, 26 Aug 2005 14:58:04 +0000</pubDate>
		<guid isPermaLink="false">http://rapidsignal.com/blog/?p=92#comment-101</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>Yeah, calendars stink. I&#8217;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.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
