bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Luis Felipe López Acevedo
Subject: bug#25227: [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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]