Changes between Version 18 and Version 19 of WebsiteDesignComps

Timestamp:

May 2, 2007, 2:44:33 PM (17 years ago)

Author:

joekepley

Comment:

--

WebsiteDesignComps

@@ -22 +22 @@
 > [wiki:seanegan]: It would be cool if the page matched the Tango style guidelines ([http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines]) the same way that Pidgin does. In particular, the "download" and "learn more" buttons are a bit too shiny.
 
->>> [wiki:kstange]: If it's possible to detect the browser platform without Javascript, I think it would be better to generate the download box on the server-side, though I'm not sure if the User-Agent would provide enough information.  I'm likewise not certain you can tell someone is using Ubuntu/Fedora/DistroX even if you do use javascript.  The arch and platform should be determinable with the User-Agent alone.
->> [wiki:seanegan]: What difference does it make if it's done client-side or sever-side? I posted a link somewhere in Trac to client-side tricks you can do to see what IM clients are already installed, so that the protocol list can be prioritized. Certainly not crucial, but probably a fun hack.
-> [wiki:kstange]: I prefer not using Javascript when it's not necessary in order to prevent client-side inconsistencies, but that's just a matter of opinion.  If there are things we'd like to do that can't be done that way, I am certainly not going to try to stand in the way of them. :)
+>>>> [wiki:kstange]: If it's possible to detect the browser platform without Javascript, I think it would be better to generate the download box on the server-side, though I'm not sure if the User-Agent would provide enough information.  I'm likewise not certain you can tell someone is using Ubuntu/Fedora/DistroX even if you do use javascript.  The arch and platform should be determinable with the User-Agent alone.
+>>> [wiki:seanegan]: What difference does it make if it's done client-side or sever-side? I posted a link somewhere in Trac to client-side tricks you can do to see what IM clients are already installed, so that the protocol list can be prioritized. Certainly not crucial, but probably a fun hack.
+>> [wiki:kstange]: I prefer not using Javascript when it's not necessary in order to prevent client-side inconsistencies, but that's just a matter of opinion.  If there are things we'd like to do that can't be done that way, I am certainly not going to try to stand in the way of them. :)
+> [wiki:joekepley]: Our policy with respect to the use of Javascript is that it should provide an enhanced experience, but the site shouldn't *need* it in order to function if it's at all avoidable. The plan would be to render the page server side with a generic message linking to the root of the download section, and have a javascript event that fires as the page renders to detect the OS and switch in the proper link if it can. This could be done server-side as well, but the benefit of doing it client-side is that you can statically cache the page on the server to a simple HTML file, thus saving the server and the CMS the extra processing. This will make sure that the site can handle decent traffic volumes on commodity hardware.
 
 == Interior Page ==
@@ -49 +50 @@
 > [wiki:nosnilmot]: +1! Me-too :-) can't wait for 'em.
 
-> [wiki:rlaager]: cool++; My only comment is that I'd hate to see this as one of those websites that doesn't properly expand with the browser window. It's really frustrating having a widescreen computer and seeing websites take up 1/3 to 1/2 of my browser horizontally when they're scrolling vertically.
+>> [wiki:rlaager]: cool++; My only comment is that I'd hate to see this as one of those websites that doesn't properly expand with the browser window. It's really frustrating having a widescreen computer and seeing websites take up 1/3 to 1/2 of my browser horizontally when they're scrolling vertically.
+> [wiki:joekepley]: We do typically design for fixed width. While nearly everyone supports at least 1024x768 these days, most people find it less comfortable to read blocks of text that are excessively long horizontally. Also, many high-resolution users don't tend to use the browser maximized. Based on our experience, users tend to prefer vertically scrolling (mousewheel) to needing to resize the window to make the text reflow to a comfortable width (find resize handle, click, drag, repeat for next site with different layout).
+