Re: Download navigation UX

Thanks!

 

I'll be honest (at risk of starting a flamewar)... on a personal level, I really do not want to do that, and I don't think we should.

First though, I want to make it clear that this has nothing to do with the fact that the EDB installers are the ones that are there at the moment, though obviously I do have a vested interest in them.

The reasons I don't think we should do this are:

* PostgreSQL is often seen as complicated and difficult to use - and we know from experience that part of that is knowing what to install and how to install it. Part of my focus at the moment is simplifying that process. So far:

  - I've tweaked the generation of installation scripts for RPMs and DEBs so that it's easy to copy/paste the exact commands required

  - The commit in this thread makes it much easier to navigate the download pages

  - The yum.postgresql.org and zypp.postgresql.org sites have been overhauled by Devrim and I to make them much more readable and up to date.

  - I'm currently working on integrated APT and YUM package browsing on the website to make it much easier to see what's available in those repos.

Planned work includes:

  - Either Vik or I will soon update the SUSE page to match the way the Red Hat one works.

  - Simplifying and minimising the text on the download pages to make it easier for users to understand, particularly non-native English speakers.

  - Considering moving third party packages and less-oft used options to sub-pages to de-clutter the main download pages (this is why I'm currently counting outbound link clicks, so we can make informed decisions).

By adding additional installer options to the pages, we complicate and confuse things for users. Why should they choose one installer over another? How do we explain the subtle or even virtually non-existent differences without adding a lot more reading material? Which should come first and so on?

* By offering multiple installers for the same platform we add confusion and the very real possibility for users to break their systems during upgrades if they're not full aware of the differences, e.g.

  - What happens if someone tries to upgrade an existing installation of one installer with one from another vendor?

  - What happens when a user tries to migrate their Python based application from (for example) the EDB installer which may support Python 3.7 through it's language pack add-on to the 2ndQuadrant installer which is built against Python 2.7 from ActiveState (that's a made up example, but you get the point).

  - What happens when a user tries to upgrade from one installer to another, and it seems to work until they realise the new installer doesn't have the pldebugger extension that they need?

  - What happens when the user switches to another installer, only to find that there is a difference in the toolchain version, so their app that was compiled with VC++ 2017 suddenly starts crashing because they're now using a libpq built with VC++ 2019?

  - When users are asking for support on the mailing lists, the knowledge in the community will become diluted as different users will have experience with different installers.

  - How many first responses to each thread are going to become "which installer are you using" followed by "oh, sorry - I only know the XXXX installers"?

  - Can users be sure that addons like PostGIS are built in a way that is compatible with any of the installer options available?

In short, having multiple installer options will inevitably lead to a significantly more complex experience on the website, potential for users to break their systems if they upgrade or switch to a different installer (inadvertently or intentionally), and make it harder to support those users.