Re: [libreoffice-website] A simpler download page

2012/2/11 Anders Holbøll <andershol@gmail.com>

> Hi,
>
> It seems that the download page have been discussed a few times on this
> list (about 6 months and about 12 months ago) and there are also few bugs
> open. The mockups in the wiki all seemed much better than the current page.
>
> But being mockups they seemed a bit "stylized" to me. E.g.
> - I don't think the drop-downs for navigation works when you have 100+
> items and the drop-downs are dependent on each other
> - The background colors on some mockups seemed a bit much
> - The download buttons should signal that all 2-3 packages should be
> downloaded (the gray buttons seem "disabled").
> - One mockup had both a version-drop-down and a version-link, which seemed
> redundant.
>
> So to get some data on what files are actually available for download, I
> looked at the database that the website uses for the download page and
> tried to group the files. I wanted to have user be able to see what their
> options are, at a glance. It seemed to me that files can be grouped into 7
> groups, that can be further grouped in 3 groups:
> Platform-downloads: Base-installer, Language-pack and Help-pack.
> Packaged-downloads: PortableApp.com-installers and ISO-files.
> Developer-downloads: SDK's and source code.
>
> I thought it would be interesting to see what the mockups (I mostly looked
> at Nics and Christophs proposals) would look like with real data. Since I
> am a developer, my mockup tool is code rather than a drawing tool :), so I
> coded it up. This is static versions of what it could looks like when a
> German user arrives on the download page:
> http://andershol.github.com/**cms-code-demo/download-**detected.html<http://andershol.github.com/cms-code-demo/download-detected.html>
> If the user chooses to "Change System or Language", the user is lead
> though these pages. Using separate pages makes it easier to fit sufficient
> descriptions to hopefully make the "Download instructions"-page unnecessary:
> http://andershol.github.com/**cms-code-demo/select-type.html<http://andershol.github.com/cms-code-demo/select-type.html>
> http://andershol.github.com/**cms-code-demo/select-language.**html<http://andershol.github.com/cms-code-demo/select-language.html>
> http://andershol.github.com/**cms-code-demo/select-version.**html<http://andershol.github.com/cms-code-demo/select-version.html>
> Note that as a special case for pt-BR, BrOffice-versions are shown as
> separate versions that this seemed the best way of categorizing them. If a
> pre-release is chosen a warning is given:
> http://andershol.github.com/**cms-code-demo/download-**prerelease.html<http://andershol.github.com/cms-code-demo/download-prerelease.html>
> Note that I will probably remove these static versions in a week or so.
>
> Note that the release notes and feature pages are shown to the right of
> the download buttons (as in Nics proposal) such that sub-menu is not needed
> (pre-releases and portable version are already on page). To make it easy
> for editors, the pages that should be shown can be "tagged" using the
> Meta-Keywords: Putting "download3.4.5" in there for page will cause it to
> show up for the 3.4.5 releases, "download3.4" for all 3.4.x downloads and
> so on.
>
> I believe that the "stable"/"unstable"-language should not be used, but
> instead be called "recommended" and "previous release".
>
> This implementation can be found as patches to the CMS on Github:
> https://github.com/andershol/**cms-code/<https://github.com/andershol/cms-code/>
> I tried to keep it very self-contained to make it easy to try out. This
> mean that the code implementes a new page type (DownloadSimplePage) instead
> of modifying the old such that the new can be tested concurrently with the
> old and it would be easy to revert (just create a new page with the new
> type, and hide the old).
>
> I have not load-tested the page, since I don't know that kind of load the
> download page normally receives. But since the current page is also a
> dynamic page (that have cached elements), this shouldn't be that different.
> The current page is about a 500kb (excluding jquery) while this simpler
> page is about 8kb and far fewer rows a fetched form the database and turned
> into objects on a cache miss, so that might make it a bit easier on the
> server. But on the other hand in the new version data is cached in a bit
> rawer format.
>
> --
> Anders
>
> --
> Unsubscribe instructions: E-mail to 
> website+help@global.**libreoffice.org<website%2Bhelp@global.libreoffice.org>
> Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-**
> unsubscribe/<http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/>
> Posting guidelines + more: http://wiki.**documentfoundation.org/**
> Netiquette <http://wiki.documentfoundation.org/Netiquette>
> List archive: 
> http://listarchives.**libreoffice.org/global/**website/<http://listarchives.libreoffice.org/global/website/>
> All messages sent to this list will be publicly archived and cannot be
> deleted
I found the http://andershol.github.com/cms-code-demo/download-detected.htmlapproach
most interesting, and less cluttered. A geolocation/agent
identifier should indeed dictate the choices given. The «Packages» category
in the current state should be moved to a block in either the right or left
column, with a message like «You can also get …» to better reflect third
party solutions. Information about pre-releases should be present on the
same page as the default download buttons, along pointers to SDK's etc.
This would make it more streamlined, and give it a more modern look.
Exactly how this would work is yet to discover, and it should be tested on
a reference group of less experienced end users to rule out any design
flaws.

– Olav

-- 
Unsubscribe instructions: E-mail to website+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/website/
All messages sent to this list will be publicly archived and cannot be deleted