Re: Download navigation UX

On Tue, Jul 7, 2020 at 6:22 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> On 2020-Jul-07, Dave Page wrote:
>
> > Thanks - committed with that change.
>
> Cool stuff, thanks, looks good!
>

Thanks!

>
> So now we can discuss the addition of 2ndQuadrant and PostgresPro
> installers there, aye?
>

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.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company