2012/2/11 Anders Holbøll <[email protected]> > 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%[email protected]> > 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 [email protected] 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
