bug#25227: [Website] Package-related pages redesign proposal

[Luis Felipe López Acevedo]

Hi,

I was thinking on improving the package-related pages, and made these 
mockups:


Figure 1. Package list page.
https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-view-v0.png

Notes:

- The gray circles indicate package logos.
- The red tag next to the name of a package indicates it has issues (I 
don't know if just issues as in 
https://www.gnu.org/software/guix/packages/issues.html or building 
problems as well).
- Packages are grouped in numbered pages because displaying a given set 
of packages in one page may bring back the page size issue. For example, 
the current page with packages that start with G is already ~1 MiB.
- The option to browse by category is something I'd like to have, but I 
don't see categories in package definitions, so I don't know if we could 
use that.
- The option to browse by architecture... I just put it there, I don't 
know if that's needed.


Figure 2. Package detail page.
https://multimedialib.files.wordpress.com/2016/12/guixsd-package-detail-view-v0.png

Notes:

- The screenshots is something I'd like to have, but I don't know how 
that can be done.
- The issues for a package would be in the package page, so the current 
issues page would be removed.


URL paths
=========

Implementing this would create web resources in paths like these:

/packages/
(Packages home page)

/packages/z/
(First page of the list of packages starting with letter Z)

/packages/z/page/N/
(Page N of the list of packages starting with letter Z)

/packages/categories/algebra/
(First page of the list of packages for algebra)

/packages/icecat-X.Y.Z/
(Page with details about IceCat version X.Y.Z)

This static pagination and filtering would generate A LOT of pages, but 
of reasonable size for web browsers to load.


Possible problems with the implementation
=========================================

I mentioned this proposal in bug #25045, and it seems that the amount of 
pages generated for the filtering part of this implementation could 
choke CVS, which is used as the deployment repository of the website 
(see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25045#17).

I quote Ludovic from that bug report:

> Sounds like a good plan as well, though that’s indeed a lot of web 
> pages
> for that rusty CVS repo to handle…
>
> Medium-term, I think we should consider a solution involving pages
> generated on the fly server-side, with a caching proxy (nginx!) in 
> front
> of it.  We’ll have to seek assistance from the gnu.org web masters, but
> ISTR they were not against that idea.

That said, the proposed design, if useful, could be used independent of 
the nature of the website (static or dynamic).


What do you think?

--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/