--- Begin Message ---
|
Subject: |
[Website] Package-related pages redesign proposal |
|
Date: |
Sun, 18 Dec 2016 22:12:39 -0500 |
|
User-agent: |
Roundcube Webmail/1.0.6 |
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/
--- End Message ---