Misc package summary page UX observations and requests, for discussion

[jberryman]

The discussion about hackage supporting READMEs in a first-class way, and how the presentation should work (see #279 and especially #356 , and here, FWIW, is an experimental fork that someone made exploring a page re-design (I don't think it addresses my issues)) got me thinking about my user experience with hackage package summary pages (e.g. https://hackage.haskell.org/package/lens).

I wanted to open this issue to talk about how I use hackage, to present a couple ideas and open a discussion about them (and other ideas people have, based on their own use of hackage). If there is interest and a fruitful discussion, this issue can be closed and maybe individually feature requests could be opened for things there is consensus around.

Here's the way I use hackage, as best I can figure out:

Things I do (nearly) every time I go to a package's "Contents" page

• Make sure I'm at the package's latest version
• Click through to a specific module (maybe going back and clicking through to a different one, etc.)
• Look at dependencies, maybe clicking through

  Things I occasionally do (maybe 15-20% of the time):

• Look at upload date
• Click through to package's github page
• Look at package author (remind myself who wrote it, whether they're also the author of another dependency I'm concerned with; this narrowly makes it out of the section below)

  Things I do perhaps only once, for new packages (maybe 5% of the time)

• Read package description
• Look at number of downloads to get an idea of popularity

So with that said...

Some ideas that might improve my user experience

Sorted from most to least important to me

1. A prominent "Latest" button, perhaps in the form of a clickable banner if not on the latest version

2. Try to keep the following above the fold, prioritizing in order: the link to latest version (and the version number), the clickable module hierarchy, the dependencies list, the package's homepage link (well I really in all cases only care about the link to the github page, but these are often the same), and (less prominently) the number of downloads in the last 30 days. This means...

   2a. Push the package description below the 5 sections mentioned above. (there could be a link to the description below, above the fold)

3. Keep the upload date and version number side-by-side (e.g. I see an issue on github and I know the date it was closed, and now I'm wondering if this package has the fix).

   3a. Present this as just the month, day, and year, unless the package was released today, in which case you can include the time as well

Thoughts on these and other ideas? It might be helpful to specify whether you agree with how I've layed out priorities of page elements above, or how you would prioritize elements differently, and/or where your suggestion would fit into the framework I sketched out above.

[stepcut]

Regarding the 'Latest' button -- you might check out the chrome plugin, hackage-fu which does just that. It would be nice to make those features native.

[bitemyapp]

@stepcut hackage-fu breaks for me here and there, so it'd be better if it was just native. I've considered adding this to Hackage but the way documentation is handled and rendered means you're effectively mutating a foreign document. This also means Hackage can no longer blindly reserve whatever Haddocks were uploaded and now must necessarily care what Haddock does with its HTML. Not good.

It would be better if more emphasis was placed on the Haddock API to extract, cache, and then reinject documentation into a wrapping template rather than directly serving from the tarball.

[gbaz]

I suspect the "latest" button could be more safely injected post-hoc with browser-side javascript? Of course that means "mutating" the already generated html as well, but in this case just with a Githubissues.

Githubissues is a development platform for aggregating issues.