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

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/

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

[Alex Sassmannshausen]

Hi Luis,

Luis Felipe López Acevedo writes:

> 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

Overall, I really like this design.  My only immediate concern would be
that it's only showing 6 packages at a time.  Though this probably
somewhat a subjective isuse, especially as the search form would allow
far better paging of results than the current static paging.

After thinking about it some more, I felt it would be a shame to lose
build status indicators on the "overview page".  Do you think it would
be possible/desirable to retain the current build status indicators
beneath each package div?

> 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).

I like this.  Very intuitive.

> - 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.

Agreed.  The P page is problematic too (we already have quite a few perl
packages!).

> - 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.

Previous discussions centered around how difficult it is to maintain
categories for packages.  I think if we went this way we'd want to
implement some form of deductive faceting, where we parse
description/synopsis and try to generate keywords.  But that sounds like
it could quite easily become a can of worms…

> - 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.

In fact, how would the logos work?  Short of having metadata fields in
package definitions (which probably is not desirable) I can't help but
think that these would have to be manual additions somehow, which would
not scale.

Though having logos and screenshots would be huge UI wins!

What about having some form of way to "mine" screenshots/logos (e.g.,
naive implementation: try $homepage/logo.{png,jpg}, else try
$homepage/images/logo.{png,jpg}), and caching those?  Again, quite
elaborate, but perhaps something that could be played with iteratively?

One could try something similar for screenshots, as a lot of package
homepages already contain an "image gallery" anyway.  We'd need to find
a way to automatically locate those, and probably cache those too…

WDYT?  Might be over-engineering this problem… ;-)

> - The issues for a package would be in the package page, so the current 
> issues page would be removed.

I like this.

> 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)

So /packages/z/ is an alias for /packages/z/page/1/?

> /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.

Indeed.  In general, I'm a fan of static pages.  Here, we'd be
generating:
- 1 page per package
- 1 page per 6 packages (paginated overview pages)
- 1 page per 6 packages per category
- 1 page per 6 packages per architecture

(probably a few more than that).

That is indeed a *lot* of pages…

> 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).

How would the search work with statically generated pages?  Unless
there's an approach that I haven't come across yet, you'd *need*
dynamically generated pages for this anyway (and the search would be a
requirement for useability in this design) — so it looks like we may
have to go dynamic from day 1 here?

> What do you think?

Overall, I think this is a great initiative and effort.  I love the
clean and elegant design and think it would be a great win for Guix.
Excellent work.

HTH,

Alex

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

[Luis Felipe López Acevedo]

On 2016-12-19 02:35, Alex Sassmannshausen wrote:
> Hi Luis,
> 
> Luis Felipe López Acevedo writes:
> 
>> 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
> 
> Overall, I really like this design.  My only immediate concern would be
> that it's only showing 6 packages at a time.  Though this probably
> somewhat a subjective isuse, especially as the search form would allow
> far better paging of results than the current static paging.


The six packages there is just for illustration purposes (to make the 
mockup image smaller). The actual limit per page would be around 30 
packages, depending on the resulting page size.


> After thinking about it some more, I felt it would be a shame to lose
> build status indicators on the "overview page".  Do you think it would
> be possible/desirable to retain the current build status indicators
> beneath each package div?


It could be included, I don't see why not. From my perspective, I'd 
prefer to use the red tag to indicate build issues as well. But that's 
just me as an average Joe user, not as a developer.


>> 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).
> 
> I like this.  Very intuitive.
> 
>> - 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.
> 
> Agreed.  The P page is problematic too (we already have quite a few 
> perl
> packages!).
> 
>> - 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.
> 
> Previous discussions centered around how difficult it is to maintain
> categories for packages.  I think if we went this way we'd want to
> implement some form of deductive faceting, where we parse
> description/synopsis and try to generate keywords.  But that sounds 
> like
> it could quite easily become a can of worms…


If that is not possible, we can just ignore it for now :)


>> - 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.
> 
> In fact, how would the logos work?  Short of having metadata fields in
> package definitions (which probably is not desirable) I can't help but
> think that these would have to be manual additions somehow, which would
> not scale.
> 
> Though having logos and screenshots would be huge UI wins!
> 
> What about having some form of way to "mine" screenshots/logos (e.g.,
> naive implementation: try $homepage/logo.{png,jpg}, else try
> $homepage/images/logo.{png,jpg}), and caching those?  Again, quite
> elaborate, but perhaps something that could be played with iteratively?
> 
> One could try something similar for screenshots, as a lot of package
> homepages already contain an "image gallery" anyway.  We'd need to find
> a way to automatically locate those, and probably cache those too…
> 
> WDYT?  Might be over-engineering this problem… ;-)


Seeing the way the current logos from GNU packages are handled, I'm not 
optimist about having logos for non-GNU packages and screenshots for 
applications, any time soon. Too much manual work indeed. So I think we 
can ignore images, to keep it simple.


>> - The issues for a package would be in the package page, so the 
>> current
>> issues page would be removed.
> 
> I like this.
> 
>> 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)
> 
> So /packages/z/ is an alias for /packages/z/page/1/?


Yes, both exist, but have the same content.


>> /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.
> 
> Indeed.  In general, I'm a fan of static pages.  Here, we'd be
> generating:
> - 1 page per package
> - 1 page per 6 packages (paginated overview pages)
> - 1 page per 6 packages per category
> - 1 page per 6 packages per architecture
> 
> (probably a few more than that).
> 
> That is indeed a *lot* of pages…
> 
>> 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).
> 
> How would the search work with statically generated pages?  Unless
> there's an approach that I haven't come across yet, you'd *need*
> dynamically generated pages for this anyway (and the search would be a
> requirement for useability in this design) — so it looks like we may
> have to go dynamic from day 1 here?


Generate JSON files with packages grouped alphabetically, and display 
results in the current page? But yes, the limitations of static sites :)


>> What do you think?
> 
> Overall, I think this is a great initiative and effort.  I love the
> clean and elegant design and think it would be a great win for Guix.
> Excellent work.

Glad to hear that, Alex. Thanks a bunch for taking the time to give some 
feedback :)

So I see that some parts of the design could be used in the current 
static site, advanced filtering and search may have to wait for a 
dynamic site, logos and screenshots may be a can of worms.


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

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

[Ludovic Courtès]

Hello!

Luis Felipe López Acevedo <felipe.lopez@openmailbox.org> skribis:

> On 2016-12-19 02:35, Alex Sassmannshausen wrote:
>> Hi Luis,
>>
>> Luis Felipe López Acevedo writes:
>>
>>> 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

Awesome, I really like both mockups!

>> Previous discussions centered around how difficult it is to maintain
>> categories for packages.  I think if we went this way we'd want to
>> implement some form of deductive faceting, where we parse
>> description/synopsis and try to generate keywords.  But that sounds
>> like
>> it could quite easily become a can of worms…
>
>
> If that is not possible, we can just ignore it for now :)

We already have categories for GNU packages, and in theory it might be
possible to get categories for non-GNU packages from the FSD
(directory.fsf.org).

But that’s just theory, so yes, probably best to keep it as future
work.  :-)

In the meantime, we can try to find Someone willing to see how we could
get data from the FSD.

> Seeing the way the current logos from GNU packages are handled, I'm
> not optimist about having logos for non-GNU packages and screenshots
> for applications, any time soon. Too much manual work indeed. So I
> think we can ignore images, to keep it simple.

Agreed.

In the future, we could also try to get logos and screenshot from some
other database: FSD, Debian/Ubuntu, WikiData, etc.

> So I see that some parts of the design could be used in the current
> static site, advanced filtering and search may have to wait for a
> dynamic site, logos and screenshots may be a can of worms.

I’ve started a discussion with the Savannah folks (Cc’d you) to see
whether/how we could have those pages generated on the server side.

Thank you for the great work!

Ludo’.

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

[sirgazil]

Hi,

I'd like to summarize the status of this proposal.

Parts of this proposal that have been implemented in the website source 
(https://git.savannah.gnu.org/cgit/guix/guix-artwork.git) include:

* Paginated list of packages (available both in gnu.org and guix.info).
* Individual package pages (available in guix.info only).

Using individual package pages in gnu.org continues to be a problem 
because of the CVS limitation. However, here is a recent comment from 
Ricardo Wurmus, one of GNU Guix maintainers, about a possible future for 
the Guix website 
(https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00107.html):

 > Eventually, I’d like guix.info to disappear and to be replaced with
 > guix.gnu.org, but that new domain isn’t ready yet.  Eventually,
 > the DNS records for guix.gnu.org and all subdomains should be managed
 > by us and be hosted on our servers, so we no longer suffer from
 > limitations imposed by the use of CVS, for example.

Finally, the following parts were not implemented, but could be in the 
future:

* Category and architecture filters.
* Package issue indicators (lint, build issues).
   (Actually, page templates have the code to display the indicator
   and list lint issues, but the `package-lint-issues` procedure is a
   stub.)
* Package logo and screenshots.

I think this proposal could be closed once guix.gnu.org is available and 
the current implementation deployed to it. The parts that were not 
implemented could be reported as individual issues if necessary.



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

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

[sirgazil]

Hi,

I'd like to summarize the status of this proposal.

Parts of this proposal that have been implemented in the website source 
(https://git.savannah.gnu.org/cgit/guix/guix-artwork.git) include:

* Paginated list of packages (available both in gnu.org and guix.info).
* Individual package pages (available in guix.info only).

Using individual package pages in gnu.org continues to be a problem 
because of the CVS limitation. However, here is a recent comment from 
Ricardo Wurmus, one of GNU Guix maintainers, about a possible future for 
the Guix website 
(https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00107.html):

 > Eventually, I’d like guix.info to disappear and to be replaced with
 > guix.gnu.org, but that new domain isn’t ready yet.  Eventually,
 > the DNS records for guix.gnu.org and all subdomains should be managed
 > by us and be hosted on our servers, so we no longer suffer from
 > limitations imposed by the use of CVS, for example.

Finally, the following parts were not implemented, but could be in the 
future:

* Category and architecture filters.
* Package issue indicators (lint, build issues).
   (Actually, page templates have the code to display the indicator
   and list lint issues, but the `package-lint-issues` procedure is a
   stub.)
* Package logo and screenshots.

I think this proposal could be closed once guix.gnu.org is available and 
the current implementation deployed to it. The parts that were not 
implemented could be reported as individual issues if necessary.


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

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

[sirgazil via Bug reports for GNU Guix]

Closing this, since guix.gnu.org is available for several months now.