Design comps have been completed for the Pidgin web site. Due to the time involved, the site will likely need to launch with something similar in look and feel to this, but please post discussions and comments and we'll try to make adjustments as we go.

seanegan: We anticipate launching this Thursday. If we could have these two pages and a "Donate" page for entering credit card information all at least somewhat functional by then, that would be amazing. E-mail me or IM me at seanegan@… if you need anything.

joekepley: Thanks for all of the great comments that are being added here. Given the short time period, we probably won't be able to make too many changes before the launch, but we'll look these over and try to get things worked in as time permits.

Home Page

​Pidgin Home Page

Notes

• The 'Download Pidgin' link will use javascript to attempt to infer the user's OS and suggest the correct download. In the event that javascript is disabled or the correct OS cannot be determined, the badge will just link to the download section.
• Per the wireframes, several areas have been provided for high-visibility site-wide announcements - this is demonstrated in the header and below the Pidgin.
• The screenshot is a quick toss-in; this will be replaced by a more representative rendering

seanegan: Looks great. With the logo text, and two purple pigeons on the left side, I think it perhaps is a bit too cluttered and off-balance, especially with the two pigeons. Maybe the logo text is a bit too big, also. I would remove the full-body pigeon and either leave that space empty, or perhaps replace him with one of our smileys.

kstange: A friend of mine agrees with this. He suggested moving the Pidgin / download box to the right side to balance it better. I agree the two Pidgins create an unbalanced appearance. joekepley: I think part of the clutter is that we mocked up the home page with the two transient announcement areas populated. The site would usually look more like ​this. Some simple options could also be to ​flip the download box or to ​remove the header logo, just for the home page.

lschiere: I like the header. I think my first choice would be to swap the what is block and the download block, and my second choice the reversed download block you showed.

seanegan: I like the swapped download box!

seanegan: I was about to suggest making the "Download" box a speech bubble, potentially coming out of the suggested smiley's mouth, and then looked closely and realized it already was. This should probably be more obviously a speech bubble, or not one at all.

seanegan: I think in general it would be cool if the design featured our protocol, smiley and status icons. They look really great scaled up to web sizes.

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.

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.

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.

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. :)

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

​Pidgin Interior Page Notes

• The download screen represented in the mock is pulled from the wireframe, and doesn't represent the copy or contents of the download screen. This is just a placeholder to demonstrate the layout of an interior page.

• The left menu demonstrates both selected links (the 'Ubuntu' item is selected) and rollover colors (the 'Red Hat' item is moused over in this example)

seanegan: This looks great!

deryni: These are awesome, though I'm not really sure I like the recessed and pulled in tab for 'currently selected'. I'd say try one or the other, but both seems like a bit much to me.

seanegan: I just want to repeat this sentiment. This is incredible.

Other Comments

elb: For the record, I love these pages.

seanegan: In case it wasn't clear, I do too. As does everyone who's commenting. My suggestions are just picking the tiniest of nits. ;) I'm really impressed.

nwalp: +1! These rock. I can't wait for them to go live.

nosnilmot: +1! Me-too :-) can't wait for 'em.

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.

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).

lschiere: I agree with Joe about fixed width design here. I dislike having to grow my window horizontally to fit a page.

metalzelot?: No one has to grow a window horizontally to fit a page, exactly this is the advantage of a dynamic width. The width automatically fits the screen width. And I've never heard of any high-resolution user who doesn't use their browser full width. I'd really prefer a dynamic width but of course I know that this makes programming a lot harder for you.

jordanm?: I see there's no link to a slackware package - if I can provide one, and one of the devs can test it, would you put it up? (ed: i've created one for b7 already, it seems trivial to provide one for 2.0 at final which works with a default slack 11 installation.)