RFC: alternative homepage layouts

[ocramz]

Currently the homepage features a rather uninspiring wall of text, much of which could be moved to the various sub-pages listed in the menu bar.

I think we could take some design inspiration from other communities and modernise it a little bit.

I've just substituted some text in two popular package repository homepages as a proof of concept, and this is the result:

RubyGems

Crates.io

[gbaz]

related: #706 and #700

[chrisdone]

Search seems like a good thing to optimize.

Personally speaking, I don't use the Hackage homepage or the browse page at all. I don't read any of the walls of text or look at recently uploaded packages. Here's how I use Hackage:

• Known package I go to my browser address bar and type ha which completes to hackage.haskell.org/package/commonpackageivisit then I'll hit backspace and type the package name I want e.g. hackage.haskell.org/package/text.
• Known module When I know the module I want, I'll just type hackage Data.Text.Lazy into my browser address bar and I get the result I want.
• Discovery When I want to find a new package--once every blue moon--I use the search feature.

I imagine that newbies spend more time on Discovery and Known module, other people's use-cases may differ.

The goal of Hackage as a web site is to let you discover packages and read docs. Installing packages is done by commandline tools. Even publishing is done by tools. The wall of text about rules, contribution and bragging about maintaining a package service could be moved to another page or put below IMO.

If anyone has read anything on the current hackage homepage it'll be the people who wrote it.

---

I do think that the list of "All packages" contains too much information and makes the page take longer to load that it needs to:

On this page, who cares about the downloads, rating, last upload and maintainer? Even tags is a stretch.

[ocramz]

Thanks @chrisdone for the input; here's my Hackage usage pattern instead:

• Haddocks :
  1. search by package name
  2. navigate to definition
• Discovery :
  • browse by category (the http://hackage.haskell.org/packages/ view ), I don't use the tags for navigation at all in fact.
• Upload :
  • The button should be more prominent, and there should be a minimal guide on how to package up and upload something. /u/sclv on Reddit pointed at https://clojars.org/ , which has very effective code snippets IMO

[Tehnix]

I quite like the RubyGems site, edited the page a bit with more of the haskell colors and some of the content in the footer (couldn't get the logo directly in though, because of content source policies...).

As for how I personally use hackage, 99% of the time I come from Google directly into a package to scour its README and documentation. We could easily also take inspiration from RubyGems search, with minor adjustments, putting more emphasis on the package description etc.

I personally like the Guides link they have in the top, where it could point to information, such as how to upload something (as mentioned by @ocramz).

[chrisdone]

@ocramz I'd agree, if you look at the current upload page it's a very intimidating wall of text. The actual upload form is disguised in the seeming title of the page:

It's the word "Upload" in dark purple next to permanently.

But which is besides the point -- who even uploads .tar.gz files like that? Everyone uses cabal upload and stack upload. However, mention of cabal upload is literally at the bottom of the page:

It depends what the intentions of hackage.org are regarding upload. If they want to prevent people from doing so, this is the best job they could do without literally saying "GO AWAY" in red at the top of the page. That might actually be the goal, if you want to reduce bad uploads or something.

If you want people to upload packages, I'd just have a trivial page with the submit form (just in case), and with commandline instructions and a checklist like:

• My package has a version which comforms to the PVP and specifies its dependencies
• I have documented and included a README and a LICENSE.
• I have got a Username/Password for uploading.

Now run cabal upload!

[dbaynard]

Could hackage store pages that a browser has visited and then dynamically present a list of packages and modules on the home page?

I don't remember the last time I used the home page. I often need to return to the same pages, though, and so If the home page supported that I'd use it.

Also +1 for new/popular/updated (as crates.io) although this could be further split into updated major/updated minor.

Other suggestions seem sensible and compatible with each other.

[blamario]

I don't have an opinion on the graphical design, but I can add a few cents on the content.

The most important single item on the front page would be a search box. The second most important would be the upload / sign-in or sign up button.

Package download counts are meaningless. I understand it's a big impressive number, but it conveys no information and it should be de-emphasized if shown at all.

The package count is at least an exact number, if not obviously useful by itself. Its derivative, e.g. a graph of package uploads per week could provide some useful information for people interested in the health of the ecosystem.

Other statistical information that could be useful includes:

• the total number of package dependencies
  • the most depended-on packages
• the total number of documentation page downloads, excluding robots
  • the graph of the above
  • the most-browsed package front pages - this would be skewed against packages on Stackage
  • the most-browsed module pages - ditto
• the most-downloaded packages - this would be skewed against packages in OS repositories
• the packages most searched-for
• the highest-ranked packages
• derivatives of any of the above package measures, e.g. the packages with fastest-growing dependency count

[ocramz]

So, to summarise what seems to be the consensus so far (also gathered from https://www.reddit.com/r/haskell/comments/86j373/rfc_alternative_hackage_homepage_layouts/ ) :

Homepage layout:

• Move package search front and center
• Simplify home page text, move most of it to "How to" pages

Upload page layout:

• Simplify text
• Upload checklist
• Emphasize package upload snippets (e.g. stack upload ...)

New features:

• Module search (e.g. lookup Control.Arrow ..)
  • Can Hackage perform Hayoo searches?
• Package download stats: reverse dependencies, reverse dependency growth rate, ...

[gbaz]

For statistics, c.f. #458 and #107

For revdeps c.f. #723

[gbaz]

Simplifying the upload page is basically independent. It is important that "administrative issues" and "reporting problems" be discoverable, but that doesn't mean the bulk of their content can't be moved elsewhere, if necessary. Even as is, we get people asking "halp, i want to take over a package what do i do" or "who do i contact about an issue with the server" even though the info is on the homepage. In fact, cleaning up the page with a redesign might help them see through the wall-of-text to that more clearly, i would hope. Also, the fact that there is an API seems to get missed often, so a link specifically for that wouldn't hurt too.

[gbaz]

btw, nuno came up with an idea for a hackage "logo" here: #707 (comment)

If we redesign the frontpage, maybe this could get made use of?

[lspitzner]

Friendly reminder, as it changed not too long ago and might be confusing: cabal upload defaults to uploading a candidate. Non-candidate needs cabal upload --publish.

[Tehnix]

@dbaynard that wouldn't be hard at all.

Two immediate routes:

1. store last 10 visited items in your browsers cookie (never stored server-side), and then e.g. feature them on the frontpage in a little box on the right-hand side, if anything is found. This is all entirely client-side JS, and would be super easy to implement. As for what is a "visited" site, it could set the cookie after having been on the page for +10 seconds (with just a setInterval).
2. Tie it to your user login, and store it sever side. This would require DB space for it and code changes server-side, so would be much more involved.

I could easily whip up JS that would do 1., if it's something we want to go with, and then it just needs to be placed on the appropriate sites.