| Version 20 (modified by , 17 years ago) (diff) |
|---|
Pidgin Site Wireframes
Blend Interactive has generated a set of wireframes for the new site. Please have a look and make some comments here to help guide us in the right direction.
The purpose of the wireframe stage is to consider the structure and content of the site without any consideration for design; once we've reached some rough consensus on the contents, we can get the designers involved in creating the actual look and feel. At this point we're focusing on where to put things, and why to put them there.
I've broken the wireframe document up into sections below, but here's the whole document if that's easier to read.
User Groups
Questions
- Do these groups accurately represent the expected audience of the site?
seanegan: Yes, and in order of importance too. At each level, the audience both drops to perhaps under 5% of the group above it, and is likely to already have other outside resources.
MarkDoliner: I would say that it even drops to under 1%. The website should absolutely be targeted toward end users. Developers and pidgin developers can probably get everything they need from trac.
- Is there anything that should be added to this list?
- Other questions/comments?
Site Map
Questions
- Anything else that should be added to the site map?
- Other questions/comments?
lschiere: In your site map, you have a section for developer blogs in both "About" and "latest news." Do we want this duplication?
joekepley: I was thinking of the Team page in the about section as something more akin to the 'contact info' page on the current site, perhaps with a bit more bio information. The 'Dev Blogs' page would be more like the current 'planet' site - an aggregation of articles from developers' blogs. So I don't think the duplication is a big deal. In one case it's part of the contact info, and in the other it's there to provide context to the posts.
Home Page
Home Page Wireframe and Notes
Questions
- What's the best way to describe Pidgin in the shortest amount of text? We want to tell people what Pidgin is in a compelling way in as few words as possible. (Users will often gloss over long descriptions).
seanegan: I think your description is pretty spot-on. I think including the list of supported protocols is a huge selling point that immediately adds a ton of relevance over just a description. Good idea.
MarkDoliner: I think showing the logo for each IM network is better than listing them.
- Any good taglines for Pidgin?
Gaim's tagline is "The Penguin Pimpin' IM client that's good for the soul." I don't know if Pidgin has/needs/wants a tagline ;)
- Other questions/comments?
sgarrity: "The current site has "A multi-protocol instant messaging (IM) client" - Not too exciting, but it works.
joekepley: I kept the 'multi-protocol IM client' bit as the start of the description. "multi-protocol" is a bit technical, but I couldn't think of anything simpler without being confusing.
seanegan: It would be fun to change the screenshot on a very regular basis. The silhouette is obviously of the buddy list and a conversation window. It would be fun to be able to change the conversation text frequently to in-jokes/obscure 80s pop culture references/current events. Clearly not a huge priority.
seanegan: It might be nice to have the full text of the latest news post on there instead of just a headline.
joekepley: I had the full text on there, actually, and pulled it at the last minute in order to keep the visual focus on the download and 'about' elements. We can add it back in and just make sure we focus things properly in the design.
MarkDoliner: I think I prefer it without the full text. In fact, I think I prefer it without the "News" area entirely. And without the list of blogs, too.
Download Section
Download Section Wireframe and Notes
Questions
- What types of packages and binaries will be provided for Pidgin?
lschiere: The downloads section also looks good. I'm not sure we would have much in the way of alternates though beyond the source itself. We typically have a collection of rpms, the source in .tar.gz and .tar.bz2, 3 win32 installers (with gtk, without gtk, and debug), and sometimes an autopackage. We have not distributed debs ourselves in the past, mostly because the debian developers have done an excellent job providing packages for unstable.
- Will there be repositories for systems like yum and apt?
lschiere: I had not considered this. I think I'm a fan of the idea though.
Yeah, that's not a bad idea at all, especially for yum and apt-rpm. I still doubt we'll need to package for Debian. Perhaps we may want to offer nightly builds (which might be useful if we switch to mtn which has a high initial pull cost).
- Are there volunteers available to maintain installation instructions for their favorite distros?
lschiere: We have some notes, particularly about getting ssl/tls to work with gaim on various distros. In the past, there have been some patches providing additional information for various distros, but not much.
seanegan: It's mostly straightforward anyway. We only offer rpm's; there are few weird dependencies that ever need to be tracked down---most of what we have is common. But if worse comes to worse, we can bug the packagers for tips.
- Other questions/comments?
seanegan: Where does the user actually click to download the package? Is it possible to download the package directly from the homepage, or do you have to go to this page first? From this page, where is the link to download? For UNIX distros, it would be nice if the home page contained two links, one for the binaries and one for the source... but in a way not to confuse the 15 year old Ubuntu livecd users. ;)
joekepley: For the example page I drew up in the wireframe, the idea was that we had a repository that Ubuntu people should use instead of downloading the tarball; My plan was to explain the recommended install method for each distro in the (2) area, then alternates in the (4) area. So if, say, it's the Windows page, then there would be a big download link there to the installer exe. But if it's a Linux install that already has the latest Pidgin in the distro (or there's a repository provided), then the user should install through those methods unless they have a good reason not to. The sourceforge files page is pretty confusing to those 15 yo livecd users because it's not obvious what the smartest install option is.
lschiere: Okay, I initially liked the idea of having our own repositories, but I have been thinking more about it. If you take a look at the SourceForge? stats, we average around 100Gb/day for the downloads. That is more than this server will be able to handle. FAR more. We must *not* host the primary pull location here. If we start setting up repositories, and making that the suggested option, we are going to swamp this server. That means that as painful as SourceForge?'s release process is, this server does not replace that aspect of SourceForge? for us. We still need their mirror network.
joekepley: Wow, good point on the bandwidth with that kind of traffic; that wasn't something I had considered. We can probably still go with separate install pages where it makes sense, but if a distro's own repository doesn't have the latest version, we can direct users to the appropriate download page on sourceforge.
seanegan: By the way, my question still isn't quite answered. The wireframe doesn't have any "click here to download" link. I think you're saying that Ubuntu wouldn't have one because we don't recommend that they download Gaim from our webpage. What would the Windows page look like? Would it be obvious how to download pidgin-2.0.0.exe, because right now it isn't.
MarkDoliner: In addition to Sean's comments above, I think I'd prefer to see a more simple download page. Maybe the suggested wireframe minus sections 3 and 4. The information is section 3 should be in the trac wiki, and the alternative methods listed in section 4 are basically already listed in section 1.
About Section
About Section Wireframe and Notes
Questions
- What are the features of Pidgin that should be highlighted to prospective users?
lschiere: the status stuff needs a section either here or in support.
seanegan: The screenshots on our current screenshot page are dated, but are a good start. Something like NetworkManager integration probably isn't too good
because it's not visual, but there are plenty of UI things to show off.
joekepley: Agreed on the NetworkManager thing. I just needed a feature to mock up, you had made a recent blog post on it, and I thought it was cool. :-)
- Should the official organization (IMF) that's now behind Pidgin be explained?
seanegan: This should probably just be a link to [imfreedom.org], which would just be a simple static HTML page with everything we need to disclose.
- Where and how can we explain that Pidgin was formerly Gaim, and the reasons for the change?
seanegan: Luke asked if the settlement even allows us to mention this. I think it does; it says we can use Gaim as it refers to "it's past use as a technical term" or some such. In either case, I don't expect any resistance from AOL about doing this. That said, I think the best place would be on the homepage, in the description (labeled 4) and in one of the transient areas. We would then phase these out over a couple of months. Perhaps phase out the alert after a week or so, and the description later. This would ease the initial confusion of people getting redirected from gaim.sf.net.
joekepley: Could we add something to the description? Maybe "Pidgin (formerly known as Gaim) is a multi-protocol IM client..."
- Other questions/comments?
seanegan: It would be great if selecting screenshots refreshed on the page without a reload.
joekepley: You read my mind. I'm thinking that this section could get a little scriptaculous love.
Support Landing Page
Questions
- What are all of the support resources that are available to users having problems?
lschiere: there are definitely going to be mailing lists, and a FAQ. The wiki here at developer.pidgin.im will also have information on figuring out what is going wrong. My hope is to have pages here that are useful to users, but which can help point users interested in doing more in the right direction towards submitting a patch. In the past, we have written various page length articles on various things, protocol descriptions, things like our reaction to skins, plain text passwords, so on. These could remain static pages, or could be pages here with links to them from a Documentation page. I do not know which approach is best. A good search would be awesome regardless.
- What else should be added to the Support section?
- Other questions/comments?
Bug Report
Bug Report Wireframe and Notes
Questions
- Does this seem like a good method to handle bug reports?
lschiere: this is utterly awesome.
seanegan: seconded
- Any other resources that should be searched for solutions?
- Other questions/comments?
Contribute Section
Contribute Section Wireframe and Notes
Questions
- Are there any other ways to contribute that should be highlighted?
lschiere: we are going to be using monotone, elb had mentioned that it might be worthwhile to have a snapshot of the monotone database posted in an automated fashion so that those interested in contributing can get a jump start, rather than the half-hour to an hour initial monotone checkout. I do not know how hard/easy it would be to do this.
elb The generation of the database itself is trivial; mtn pull to an existing, dedicated database to update it (which takes care of not having to lock anything), copy it alongside the current download database, and mv it overtop. A new version will be atomically available to fresh downloaders.
seanegan: That would live within developer.pidgin.im, not on this page. A lot of people have asked if we have "buttons" that they could include on their webpage. Perhaps this sort of thing could be considered a form of contribution.
joekepley: Good idea on the buttons. We can add verbiage and a page for it. With regards to the dev snapshot, we could provide links to the useful bits for new developers in the wiki from the developer page on the site. A quick howto for compiling and developing with pidgin would be great. I tried to run a build off of a recent nightly and failed miserably (but I'm pretty dense so that may not say much).
- Other questions/comments?
News Section
News Section Wireframe and Notes
Questions
- Should the 'official' news remain separate from the blogs?
lschiere: I expect official news would remain separate yes.
seanegan: agreed
- Should we attach author names to official posts?
seanegan: Doesn't matter to me.
