[Evergreen-web-team] Downloads page mockups

Fri Dec 13 15:22:40 EST 2013

Working in the same direction as Grace started, I just grabbed the Evergreen Downloads page HTML, HTML-Tidy-ed for better code readability and worked on my mockup by shuffling HTML. Before describing the thinking behind my mockup, I wanted to respond to the "yellow notes" from the original message by Grace Dunbar that started this thread. Please refer to her attachments for more context:

"Can we use tooltips to create popups to give more information?"
Yes, but if they can be avoided by restructuring information in a way that does not require special tips -- even better.

"Should we have sections for librarians and developer/admins?"
No, I think it is best to focus on what we're offering. The same audience might have different needs at different times, so I think we best keep it general. A developer might also be a librarian, and a librarian could also be a system administrator, systems administrators need to download staff clients for testing, and so on.

"Do we need this technology dependency here, or does it belong on the developers' page?"
No, we don't need all the technology dependency on the downloads page. The software dependencies required to install the Evergreen server are quite well described in the installation instructions. Anything beyond that should be on the "developers'" page. There is much that could be done on that subject, I think, but that's a different topic.

"Should this be a separate page? (It is now)."
Yes, I think public demo servers should be listed on a separate page.

"Can we group some things into some sidebar boxes? Does bug reporting belong here?"
YES, that is just exactly what I think should happen. I think that is what the right-hand side of web pages is for - periferal-type stuff ;)

"I would say that the Trac stuff belongs elsewhere - like the developer page and the mailing lists page"
I agree.

So, now to describing my mockup, which I see as sort of a continuation of this conversation. If there was any conversation on this topic that did not occur on the list-serve here, I missed that, so apologies if I am rehashing something that was already discussed or taking this into a direction that is different from what was already agreed elsewhere. Also, I admit upfront that my mockup is not as complete as it could be, but I wanted to get some feedback before sinking more thinking and editing time into it.

I think that basically, the current Downloads page is functional, but if I were to try to identify areas for improvement, I would say the two main problems could be summarized as lack of focus and lack of clarity.

By lack of focus, I mean that there are too many links lumped into the page (various software packages, Git repositories, demo servers, and so on). I think the download page should focus on accomplishing one thing as efficiently as possible: allowing a visitor to download what they need quickly, without having to sift through a hundred similar-looking links or read thousands of words.

By lack of clarity, I mean that it is not necessarily immediately evident what and how to consume what is offered on the downloads page. For example, someone new to Evergreen needs to find out from somewhere else that Evergreen consists of a client and a server or that the Evergreen server requires OpenSRF, or that only Windows clients are built as part of the official release.

The simplest way to try to address the issue of lack of focus, is to well... focus on the audience and on the value of what is being served. I don't have access to precise statistics, but I assume one of the top links there is the latest version of the Evergreen client which would be downloaded by library staff for Windows (or their workstation administrators). So, first step is put the staff client link on top and make it really stand out. In my mockup, nobody has to think or read much to get the client, just click the biggest button at the top. Of course, people may also need older client versions or versions for other OS, so the links to those are preserved. They are easily findable, but with a lot less focus.

Similarly, for the server portion I assume we want to focus on the newest release and de-emphasize other versions, but preserve access to other available versions as well. So, in my mockup, I put the latest version on top and made the download link into a button, which not only gives extra focus to the newest release, but also creates a visual relationship between the latest client and server versions.

To address lack of clarity, I wanted to distill the information that I think is most important to know for likely audiences on this page, most importantly new users. So, at the very top of my mockup I put a quick summary what "Evergreen" is and how to "consume" it. I think for anyone who read that is should be very clear, for example that downloading just the client is not enough to start using Evergreen, for example. I also explain that there are several server versions and cover questions about which version to download.

In the "staff client" section I attempt to clarify what the client does, what is distributed with Evergreen and how to get other versions, all in as few words as possible.

Similarly, in the "server" section I attempt to quickly summarize what distributions the server runs on and requirements. (I am not sure, is Fedora "officially" supported?)  I then offer all the current available versions and related links. Only the newest version has the download button. I tried to stick to text-only for simplicity, but this could be presented in two columns with the newest version(s) on top and also a spot for beta-releases, for example. i just don't know what style and formatting options are available with the new skin, so kept it simple.

I didn't spend much time making a mockup of this idea, but I would suggest that "Staff client archives" and the so-called "Code museum" should be merged into one page called "Release archive". Much like it sounds, this page would have links to all the old releases, including all pre-built clients (for all OS available) and servers. I would also include information that is currently missing and/or not linked from either of those two page, like changelogs, release notes, and so on. Through my own experience I found that finding old changelogs, for example, can be challenging. Last time I tried I remember browsing a directory, modifying URLs, etc.

I didn't spend too much time thinking about the rest of the content on that page. To me it seems like there should be a "Source code" or "Get the master" or something like that section maybe with a listing of a few Git commands to get that version as well. I could address that in a later iteration.

As fas as the Bug reports, etc, like Grace already suggested, I think those belong as sidebar boxes.

Anyway, this message is long enough already, hopefully I didn't miss anything that was super important to mention for context.

I am attaching my mockup as a couple of HTML files - you should be able to just save them into any directory on your computer and File > Open file… from your browser to see the pages. The egdownloads.htm is where I did most of the work, but I also include another file "eg_previous.htm", which would be that page combining older windows staff release page with "code museum" for a comprehensive listing of all old releases and accompanying notes and information, like changelogs. The only thing I did on this page was just add a link to prebuilt Mac clients under 2.4. I didn't want to spend any more time on this page before seeking feedback.

So, let me know what you think. If the general idea and direction seems about right, I could continue working on the mockups and examples, including the combined "Release Archive" page, towards a more comprehensive rework of the Downloads and related pages.

Aleksey

On 2013-10-15, at 15:01 , Grace Dunbar <gdunbar at esilibrary.com> wrote:

> I think if we're making the software download page more clearly a developer thing and not  muddying it up where a librarian might get lost in it we can easily add OpenSRF and anything else that makes sense.  I'm happy to do more thorough mockups based on this direction.  Or I can work on the site directly.
>
> Grace
>
>
> On Tue, Oct 15, 2013 at 3:57 PM, Galen Charlton <gmc at esilibrary.com> wrote:
> Hi,
>
> On Tue, Oct 15, 2013 at 12:53 PM, Ben Shum <bshum at biblio.org> wrote:
> I love the mockup for reorganizing the downloads page contents as
> well.  I think the only thing I'd be wary of is that we need to find
> some better way of explaining OpenSRF and getting folks to download
> and install that first beyond just having it as a step in the README
> for installation.  Otherwise, the buttons with current/past/testing
> releases looks much cleaner to my eyes.  And splitting the staff
> clients off from the server code seems logical too.
>
> Agreed.  Either the OpenSRF instructions should be on the same pages as the OpenSRF download links and/or the Evergreen installation instructions should either include or actually link to the OpenSRF instructions.
>
> Regards,
>
> Gaeln
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
>
> _______________________________________________
> Evergreen-web-team mailing list
> Evergreen-web-team at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-web-team
>
>
>
>
> --
> Grace Dunbar, Vice President
> Equinox Software, Inc.  -  The Open Source Experts
> gdunbar at esilibrary.com
> 1-877-OPEN-ILS    www.esilibrary.com<http://www.esilibrary.com>
> _______________________________________________
> Evergreen-web-team mailing list
> Evergreen-web-team at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-web-team

Aleksey Lazar
IS Developer and Integrator - PALS
http://www.mnpals.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-web-team/attachments/20131213/9a8119b6/attachment-0002.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-web-team/attachments/20131213/9a8119b6/attachment-0003.htm>