Improve UX: Show Use cases instead of tools when advising how to install / use packages

[dwt]

I've started the discussion in #963 on how to improve the usability of the 'how to install / use' section of the search results.

What it boils down to is that the current examples are grouped by tool, but I think this would be much more useful, if grouped by use case instead.

I think this has several advantages:

• New users have a clearer advice on which way they want to go
• It is way easier to group different technologies that achieve the same means in those categories.
• Easier to extend when new ways to use nix come along that we want to showcase without overwhelming the user with choice

For example:

• Run Directly could show nix-shell --command and nix run
• Try without installation could group nix-shell and nix shell
• Permanent installation could group nix-env, nix profile, configuration.nix based install and flake based nix configuration.
• Development Environments could group shell.nix, flake.nix based mkShell and perhaps devenv based installation
• Embedded in Shell Scripts could show how to use nix-shell to add it to a shell script without requiring installation.

Of course the names are up for discussion ,as these examples are lengthy, and the UI doesn't work great on small screens (cough phones cough) as it is.

Inside those tabs, perhaps an accordion could be used for the different ways to achieve this. Ideally a cookie could be used to remember the users choice and use that by default on each search result.

I would greatly appreciate the clarity this gives.

@maintainers: What do you think?

[raboof]

If you're willing to put in the effort to workshop this, it sounds like a reasonable improvement direction to me.

You're right that the names are quite long right now, which might not fit the tabs. Perhaps we should just have Run, Install and Develop, where Run combines Run Directly, Try without installation and Embedded in Shell Scripts, Install has Permanent installation and Develop has information on development environments?

I'm not sure we need to keep documenting nix-env and nix profile.

[dwt]

Embed in Shell-Scripts could also go into the Develop category perhaps?

Regarding nix-env and nix profile: Do you recommend only documenting nix profile or do you recommend dropping both?

I can definitely try workshopping this, as the code that does this seems easy enough (though foreign). But it seems that I do not need to really learn Elm for this, which would be a plus. Still, the html generation looks weird.

[raboof]

Embed in Shell-Scripts could also go into the Develop category perhaps?

yeah that makes sense to me

Regarding nix-env and nix profile: Do you recommend only documenting nix profile or do you recommend dropping both?

I personally use neither, but if you use them regularly and feel that they should be included I'm OK with that.

I can definitely try workshopping this, as the code that does this seems easy enough (though foreign). But it seems that I do not need to really learn Elm for this, which would be a plus. Still, the html generation looks weird.

Cool! I think even just a fleshed-out prototype would be a great help, but if you can turn it into Elm as well that's even better of course. Note that with #972 close to merging it might be good to take that as your starting point.

[dwt]

Here's a prototype to try to better communicate what I'm thinking about.

index.html.zip (Small prototypes like this are just so convenient to do with AI. Even if the code they produce is pure horseshit).

What do you think?

[raboof]

I think that looks pretty cool! It could probably use some more instructions and links to relevant documentation, but I like the general direction.

[dwt]

@raboof What documentation would you link to? Just to https://nix.dev or somewhere else?