Mumble: Provide better download UX on landing page

Created on 20 Dec 2015 · 20Comments · Source: mumble-voip/mumble

Ideally we would like the main page to present the user with an obvious way to download the current mumble stable and snapshot release. The current stable should be emphasized. Still there should be an obvious way to download the snapshot as well as versions for other platforms (and maybe even legacy versions).

Here a basic mockup of what I have in mind:

(this is what a Windows user with 64bit architecture would see)

Imho the sanest way to implement this would be using some JavaScript which detects client platform and architecture and replaces the old table accordingly (providing proper fallback if something fails). The old table could also be displayed when the user asks for other platforms.

help wanted website

Source

hacst

All 20 comments

Here's a quick prototype I made, feel free to do anything with it (there is no server side code)

JoelTroch on 24 Dec 2015

While keeping your two ideas in mind. hacst's separation of multiple builds but deiced to add 32 bit builds even if it is a 64 bit system, just in case a user wishes to use 32 bit builds and JoelTorch's icons for different OS's. My idea was to try to separate snapshot and stable more, by using two different icons.
mumble

ansome22 on 27 Dec 2015

@ansome22 Nice idea, I would add the current green background for stable and blue for development snapshot like the current page has. Furthermore, does anyone think it would be a good idea to use a darker color to separate architectures ? For instance, having a darker green for the Windows x64/OS X Universal stable.

EDIT: Added a variant of my prototype where the architecture is not detected and x86/x64 builds are together.

JoelTroch on 27 Dec 2015

@ansome22 Imho there's no reason to present the architecture choice to the user by default when we can make a sensible choice for them. Most users won't have a clue what that 32 and 64 thing is about and it has no relevance to them anyways. As long as it works it's fine.

For those who know what they want we display what we guessed so they can choose the fallback option and select from the extensive list.

Imho the whole thing should be as clean and simple as possible for the 95% use-case.

(btw.: IANAL but afaik using the OS logos - at least for Windows and OSX - to advertise the downloads might require permission from the vendor / adherence to some licensing program)

hacst on 27 Dec 2015

@hacst Sorry that is my bad.

If the plan is to make it as clean and simple as possible what will happen to things like What's new?
Download Source Code, GPG signatures, etc?

I also have another question which may be a bit of a silly one but could will third party clients be included into other versions and platforms page?

You are probably also right about the OS logos considering how a few of other free software like vlc or notepad++ avoid using logos.

@JoelTroch it is probably a good idea having a variant for the chance 32 or 64 bit but considering what hacst has said "Most users won't have a clue what that 32 and 64 thing is about". The script will most likely default to 32 bit builds with a message indicating to the user something like 'We could not completely detect what OS you are using'.

Regarding your question about using darker colors for separate architectures, i do not completely understand what you mean, could you explain further?

ansome22 on 29 Dec 2015

@ansome22 No reason to apologize. I just come at the issue from a little different angle.

From all I know architecture detection should be pretty reliable. I'm not aware of a commonly used desktop browser that doesn't expose that information to JS and the technique is used widely. If we can't detect it the fallback would be the full table.

Maybe taking a look at libraries like https://github.com/bestiejs/platform.js to see how they handle the detection might be worthwhile. Probably worth using something like it outright to not have to maintain it going forward. It puts the architecture into platform.os.architecture. For the OS we might have to keep lists of OSses we know and act accordingly.

hacst on 29 Dec 2015

@hacst You do seem to be right it seems to be more the browsers responsibility than the scripts (to be fair, i only skim read it).

What do you mean by "Probably worth using something like it outright to not have to maintain it going forward"? lines 442 to 469 seems to be our list of possible OS's that it can detect and gets put into platform.os.family, that's of course if we will use the script.

To the point of the issue of a better download UX cause so far i get what the UX will be designed around is:

OS and architecture builds are filtered using a script and will give the user a kind of recommended builds for the user.
If the user wishes to find other builds they will click a link labeled "other versions and platforms" that will lead to a table of other builds, i think?
Stable and development builds are colored with blue and green.
We want it to be simplistic and clean.

What i do not know about

On the current site there is What's new? Download Source Code, GPG signatures, View Git Repositories.What will be happening to these?
Will Third Party Clients still be grouped on their own or will be grouped in "other versions and platforms" page?

ansome22 on 29 Dec 2015

@ansome22 I meant that if we find the code that we like in one of these libraries (e.g. platform.js) we might just as well use the library. If some browsers in the future need new special handling having the library do the work for us might save some work down the line.

About the other links: Haven't really though about that yet ;) I guess most would stay visible below the normal download option. The new download box could pretty much just replace the table and leave the rest alone in the first iteration.

hacst on 29 Dec 2015

@ansome22 For the darker color thingy, this is what I wanted to talk about (notice the difference between Ubuntu/Linux):
mumble

JoelTroch on 30 Dec 2015

@hacst I see, that could be a good idea. Lucky for us though we don't have to pick a library just quite yet, which gives us the opportunity to find better ones and for more bugs to get fixed without us having to worry about them.

I'm okay with that, less things to worry about :)

@JoelTroch I do kind of like the idea, it could give the site style points(i couldn't find the word). The only thing i do worry is if we use different shades of colors, people who struggle with color blindness might possibly cause the words and the background to blend into one color and make it difficult to be read.

ansome22 on 30 Dec 2015

I think there are simulators for different kinds of colorblindness out there that could be used to figure that our.

hacst on 30 Dec 2015

Along with that http://designshack.net/articles/accessibility/tips-for-designing-for-colorblind-users/
Gives some ideas on what we could do.

ansome22 on 30 Dec 2015

Choose wisely!

;-)

Zuko on 30 Dec 2015

👍1

The more options you provide to the users, the more confused they will be.

Use JS to detect user's platform and present them with simple download button.

Provide 'all downloads' url, which would point to new page with a table to allow them to pick up precisely what they want.

If you want people to be testers, by default give them dev builds, but make sure those are quite stable.

nvtkaszpir on 30 Dec 2015

I suggest that the OS and arch should be detected and present stable versions only. Snapshots would only be available from the "all downloads" table with the color difference between stable/snapshot (by taking accessibility in account)

JoelTroch on 4 Jan 2016

Could take a look at how Firefox does theirs, where they still offer other builds as well with a single link.