Redesign Download page

[nurupo]

There are several issues with the current Download page

1. When a you open the page, the first thing you see is "Thanks for downloading!", which confuses people as they thing that the download process has already started, when in fact nothing is being downloaded.
2. The page categorizes all clients by a platform, displaying a|long|bar|separated|list|of|downloads|for|each|client|as|well|as|alternative|download|methods under the platform, for example, here is Linux platform
   
3. The Debian/Ubuntu instructions use lsb_release -cs in them, which causes issues for people using Debian-/Ubuntu- derived distributions who don't know what lsb_release -cs does. e.g. on a Linux Mint system, lsb_release -cs would print "sarah", "rosa", "rebecca", "qiana" or "rafaela", on Trisquel it would print "belenos", on Elementary OS "freya", etc. Even on Debian/Ubuntu it could print "wheezy", "precise" and "trusty", depending on what version of Debian/Ubuntu you use. None of these outputs of lsb_release -cs would work though, since the package repo supports only "jessie", "stretch", "sid", "vivid", "wily" and "xenial", as the text on that page says (well, it wasn't updated to mention Xenial yet), but no one reads the small text and just copy-pastes the instructions into the terminal, seeking help later on IRC, GitHub Issues, etc.
4. The .html page and os-detection .js duplicate download links, which means that a link might get fixed in one but forgotten in another.

---

Proposed ways to resolve the issues

1. Just change "Thanks for downloading!" to something else or remove it. Something along the lines of "We detected your OS as Windows, here are all Windows downloads ... (see downloads for all platforms)" or "We couldn't detect your OS. Here are downloads for all platforms." for when JS is enabled and "Here are downloads for all platforms" for when JS is not enabled would be great.

2. Instead of categorizing by platform, categorize by client and have a list of platforms under each.
   
   This will keep things simple and the bar|list will be very short, as there is a finite number of platforms (in contrast to the number of Tox clients).

3. Well, first of all, every client should have its own modal-view, and for Linux modal-view, each client should list only distributions and versions of distributions the client is available for, to the point that the user has to select specific version of a distribution to get the instructions without lsb_release -cs (lsb_release -cs should be replaced by the appropriate string for the selected distribution) for Debian/Ubuntu. e,g, to get a qTox for Debian Stretch, one would find qTox on the Download page then go though Linux -> Debian -> Debian Stretch menu to finally get the instructions and the instructions will say stretch instead of lsb_release -cs.

   Here are some quality MS Paint mock-ups to get the idea : P

   When user clicks on "Linux" under "qTox", user is presented with distributions this specific client is available at (i.e. different clients can have different list of distributions).

   

   When a user selects Debian, user is presented a choice of specific Debian Release.

   

   When user selects Debian Stretch, user is presented with instructions specific for Debian Stretch

   

   Note the stretch being in place of where we currently have lsb_release -cs. and note the specialized apt-get install instruction for that specific client, i.e. a Linux modal-view for uTox would say apt-get install utox.

   It would be great to be able to utilize the Jinja2 template engine we use for our website and describe a client on Download page as a python dictionary, with a list of supported platforms, list of supported Linux distributions, list of supported versions (assuming the distributions' instructions are version-dependent, otherwise this set is not needed) of each of the supported distributions, specify package name for each distribution, specify kind of downloads available for Windows (32-bit, 64-bit, etc), download links, and so on. Just create a Client python dictionary and have single template generating code which looks at every Client dictionary and generates the appropriate html, e.g. a Linux modal-view for qTox which lists only distributions qTox is available on and only versions of distributions it's available on, etc.
   Just an example of such a Client dictionary list to get the idea across

   clients =
   [
       {
           'name' : 'qTox',
           'platforms' : ['Windows', 'Linux', 'OS X'],
           'Windows' :
           {
               'stable' :
               {
                   '32-bit' : 'https://example.org/qtox-stable-32.exe',
                   '64-bit' : 'https://example.org/qtox-stable-64.exe'
               },
               'nightly' :
               {
                   '32-bit' : 'https://example.org/qtox-stable-32.exe',
                   '64-bit' : 'https://example.org/qtox-stable-64.exe'
               }
           },
           'Linux' :
           {
               'Debian' :
               {
                   'tox.chat\'s pacakges' : 
                   {
                       'stable' :
                       {
                           'Jessie'  : { 'packages' : ['qtox']},
                           'Stretch' : { 'packages' : ['qtox']},
                           'Sid'     : { 'packages' : ['qtox']}
                       },
                       'nightly' :
                       {
                           'Jessie'  : { 'packages' : ['qtox']},
                           'Stretch' : { 'packages' : ['qtox']},
                           'Sid'     : { 'packages' : ['qtox']}
                       }
                   },
                   'qTox OBS packages' : 'https://software.opensuse.org/download.html?project=home%3Aantonbatenev%3Atox&package=qtox'
               },
               'Ubuntu' :
               {
                   ...
               }
           }
       },
       {
           'name' : 'Toxic',
           ...
       },
       ...
   ]

   You can see from that example of what a Client dictionary might look like that I have split Debian for qTox into "tox.chat's packages" and "qTox OBS packages" options, and the "tox.chat's packages" option is further split into "nightly" and "stable", which means that the html generating code should be flexible enough to be able to generate as many choice selection screen as needed.

4. Not sure. Can't we keep the download links only in .html?

[optimumtact]

yes to all the things you said

[SkyzohKey]

+1 to everything. But IMHO the current website code is just crap and should be done the right way. Let's be realistic 10 seconds, static websites are cool but not efficient. That's why we should really think about developing a REAL website. Feel free to ping me on Tox if you need help.

[email protected] | DFB4958A86122ACF81BB852DBC767DB8A3A7281A8EDBC83121B30C294E2958699E4F6C8327FA