A slick new UI for Hackage

[ocramz]

This appeared like last week :

GitHub - visortelle/hackage-ui: A fresh look for the Hackage. Follow us:...

I personally think it’s a wonderful initiative and we should all support it.

It looks and feels great, harmonizes Hackage and Hoogle (e.g. try this link Hackage: The Haskell community’s package registry) and is built with modern web technology (next.js). I really wish to see it succeed and that it may one day replace the current Hackage frontend.

The author is also collecting design ideas (taken in part from the Hackage server backlog) in a github issue : Notes and ideas · Issue #1 · visortelle/hackage-ui · GitHub

Incidentally, @Kleidukos too is building an alternative frontend to Hackage, but with a radical redesign in mind rather than feature parity : Flora :: [Package] . They too deserve all our support, but the timeline and integration path with Hackage will be different.

[Kleidukos]

Hi @ocramz, Flora is not only an alternative frontend to hackage, it aims to be an independent package index with the ability to mirror Hackage as a read-only index (although I know I’ve been terrible at marketing it that way ;).

[Las]

Question: I just tried using Flora, but basically everything is broken. Is this expected? Or is my setup somehow broken?

[Kleidukos]

Hi @Las, Flora is still being heavily worked on, hasn’t been released and there isn’t a V1 out yet, so yes, nothing works.

[ketzacoatl]

@Kleidukos just a curious question, how would this differ from stackage.org and why add a 3rd alternative?

[Kleidukos]

@ketzacoatl Sorry I don’t understand your question, could you be a bit more precise regarding the aspects of Flora for which you have a hard time determining the difference with Stackage?

[satoshi778]

While I appreciate the hard work, it lacks an immediate feature :

hackage itself works with the ‘links’ browser - it works with a Web1 browser. This is a virtue : it is accessible by default, it is scriptable (one can make a script query instead of using a browser).

A solution to this problem is to use the standard hackage service/server/software and apply layers of progressive enhancement above (css first, js next, with a lot of fallbacks). If this new slick look is applied at some point, please don’t remove those hackage features.

PS: For instance there is no “search” button in the new look, only instantly refreshed results in the drop-down list. This does not work with a text-only browser, with a visually-impaired browser or with a script. Afaic this is a very web2.0, browser-user centric ux/ui .

[visortelle]

Hello. The project’s author here.

A regular search page will be also implemented and will work with disabled JavaScript.
Regarding automation, I’d rather rely on APIs, not web pages.

After release, I can set aside some time to cooperate with interested people on accessibility improvement. It’s shouldn’t be too much work there.

[ocramz]

Respectfully : I agree web accessibility is important, but we shouldn’t let backward compatibility paralyze innovation. And it’s not even radical innovation, it’s something that other package indices (RubyGems, Crates, pkg.go.dev etc.) have had for many years.

Besides, in its current version Hackage is only broadly accessible by coincidence (since it’s hand-written HTML 1.0), but it lacks established good practices such as semantic HTML elements, or any regard towards information architecture.

Additionally, I would like to point out that most people access the web from a phone nowadays. Why don’t hackage pages have responsive CSS that can accommodate both desktops and mobiles? Plus, honestly, how many people use links ?

[satoshi778]

I agree on ‘links’ usage and mainly agree on your points. Links is just my browser of choice when I want to test accessibility - basically if it works on links and follows aria guidelines you’re good to go.

established … semantic

100% agree : it should follow best practices, including using the right tags - “submit” for instance, which it does not.

To everyone : this is good work, I’m trying to be constructive and make it great / the best work possible by making every possible improvement comment here. I’ll use it with pleasure.

responsive

Agreed !

innovation

Still disagree that “instant search refresh” is an innovation / a plus IF it is the only way - the project author said it : it doesn’t work with javascript disabled. I’m all in for the UX, just trying to preserve what I view as quality.

other package indices

Yes, and for instance npm has no way to get all packages A that depends on package B : you can perform the search, get an “infinite scroll” list of packages which is neitger complete nor paginated … the result being you have to build it yourself by syncing “no-one-left-behind” (the package)

I’ll stop commenting on this point because you understood : please make progressive enhancements, not browser pre-requisites - archive.org is full of “best viewed under IE11” sites that shouldn’t have bet on state-of-the-art UI

[satoshi778]

Meanwhile ! no harm intended, hope none taken !

[visortelle]

Instant search isn’t a feature just for fun.

The plan is to make the search usable in the context.
For example, Hoogle has a “search in scope” feature. The scope can be a package or a set of packages. You’ll can browse package’s documentation and Hoogling over its content without switching context.

I’ll rephrase my previous comment: please don’t worry, there will be a search page that is accessible without enabled JavaScript.

[sclv]

Hackage package pages at least, in the latest redesign, were done with responsive css I believe. On my phone its really only the search results/browse table that shows up poorly, because there’s too much data to really display without scrolling horizontally.

[visortelle]

Using tailwind-css might help attract more contributors, as it is slightly simpler for people unfamiliar with css to use it’s slight layer of abstraction above regular css

I don’t want to introduce an extra level of abstraction here. Modern CSS is good enough itself and is the least problem. I am always ready to help with styles.

You might take interest in using ReScript instead of typescript. There are a few templates ready for configuring nextjs with ReScript

This point contradicts your previous one. I doubt that usage of a less widespread technology would attract more contributors. If I would like to play with such things, I’d rather take PureScript or GHCJS.

Vercel and Netlfiy are pretty much interchangeable, but you might find Netlify’s recent PR commenting functionality useful

You said yourself that they are interchangeable. Regarding comments functionality - I don’t use Vercel as some kind of CMS. It’s just a simple way to deploy a project. I’ll switch the way how I deploy a project when the need arises.

You might want to create an internal page for developers to quickly browse all of the available components

I understand what you are saying and agree that it’s convenient. Moreover one of my projects was a tool for the creation of live documentation for React components. Nowadays I’d rather go with the recent Cypress component testing.

Technical implementation details are the last thing that bothers me on this project now.

[visortelle]

If anyone is interested in the browser extension, can you please check it?

Changelog

[brechtserckx]

I’ve installed it and I’ll test it out over the following weeks - if I remember to use it.
As far as I’ve used it, everything looks really good already!

[ocramz]

It seems hackage-ui took a novel turn and became “Haskell spotlight” (https://www.haskellspot.com/) with a much broader scope. The search features are still there, though.