From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Subject: bug#25227: [Website] Package-related pages redesign proposal Date: Sun, 18 Dec 2016 22:12:39 -0500 Message-ID: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIoOt-0000og-Ey for bug-guix@gnu.org; Sun, 18 Dec 2016 22:14:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIoOo-0002Cs-Hv for bug-guix@gnu.org; Sun, 18 Dec 2016 22:14:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:59485) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cIoOo-0002Cd-Et for bug-guix@gnu.org; Sun, 18 Dec 2016 22:14:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cIoOo-0001hr-7W for bug-guix@gnu.org; Sun, 18 Dec 2016 22:14:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIoNf-0000n1-Ey for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIoNb-0001bX-Hm for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:51 -0500 Received: from mail2.openmailbox.org ([62.4.1.33]:39280) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cIoNb-0001av-8J for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:47 -0500 Received: from www.openmailbox.org (unknown [10.91.130.55]) by mail2.openmailbox.org (Postfix) with ESMTP id F2DFB1052CE for ; Mon, 19 Dec 2016 04:12:39 +0100 (CET) List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 25227@debbugs.gnu.org Hi, I was thinking on improving the package-related pages, and made these=20 mockups: Figure 1. Package list page. https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-vie= w-v0.png Notes: - The gray circles indicate package logos. - The red tag next to the name of a package indicates it has issues (I=20 don't know if just issues as in=20 https://www.gnu.org/software/guix/packages/issues.html or building=20 problems as well). - Packages are grouped in numbered pages because displaying a given set=20 of packages in one page may bring back the page size issue. For example,=20 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=20 don't see categories in package definitions, so I don't know if we could=20 use that. - The option to browse by architecture... I just put it there, I don't=20 know if that's needed. Figure 2. Package detail page. https://multimedialib.files.wordpress.com/2016/12/guixsd-package-detail-v= iew-v0.png Notes: - The screenshots is something I'd like to have, but I don't know how=20 that can be done. - The issues for a package would be in the package page, so the current=20 issues page would be removed. URL paths =3D=3D=3D=3D=3D=3D=3D=3D=3D 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=20 of reasonable size for web browsers to load. Possible problems with the implementation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I mentioned this proposal in bug #25045, and it seems that the amount of=20 pages generated for the filtering part of this implementation could=20 choke CVS, which is used as the deployment repository of the website=20 (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25045#17). I quote Ludovic from that bug report: > Sounds like a good plan as well, though that=E2=80=99s indeed a lot of = web=20 > pages > for that rusty CVS repo to handle=E2=80=A6 >=20 > Medium-term, I think we should consider a solution involving pages > generated on the fly server-side, with a caching proxy (nginx!) in=20 > front > of it. We=E2=80=99ll have to seek assistance from the gnu.org web mast= ers, but > ISTR they were not against that idea. That said, the proposed design, if useful, could be used independent of=20 the nature of the website (static or dynamic). What do you think? --=20 Luis Felipe L=C3=B3pez Acevedo http://sirgazil.bitbucket.org/