Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can we improve UX? #109

Open
iFreilicht opened this issue Oct 2, 2024 · 5 comments
Open

How can we improve UX? #109

iFreilicht opened this issue Oct 2, 2024 · 5 comments
Labels
question Further information is requested

Comments

@iFreilicht
Copy link

Question

We all have opinions on the Nix UX, but I think we can agree that it needs improving. I've noticed that in many discussions, we talk about "the user" and our assumptions for what they would expect or understand, without really knowing.

We have no user journeys, no personas, no analytics about how people are actually using Nix which makes good decisions difficult.

Should we focus more on UX than we currently are? What actions would you take to do so?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

@iFreilicht iFreilicht added the question Further information is requested label Oct 2, 2024
@numinit
Copy link

numinit commented Oct 3, 2024

Frankly, I'd go for converting Docker users the most. Show users why Nix can be easier than Docker, but much more powerful, while maintaining some type of Docker compatibility, and we'll get tons of people switching over. The trick is reducing the work required, because few teams will put the time in. It may be a stretch, but doing symbolic execution of Dockerfile commands and ending up with something that Nix can ingest would be awesome.

@cafkafk
Copy link
Member

cafkafk commented Oct 3, 2024

Should we focus more on UX than we currently are? What actions would you take to do so?

I think the steering committee should support any initiatives for improving UX, and should there be any UX experts in the community willing to lend a hand improving the UX experience, they shouldn't be gatekept for being "non-technical", but brought into various projects (such as NixCpp), and their reviews of pull requests should be encouraged and valued deeply.

As authorities on the technical direction of the project, we should aid support and advocate for UX issues contributors raise, and ensure their voices are heard and not dismissed. We should also do so in a way that doesn't become scope creep, where we unduly add new work onto PRs and issues that didn't introduce some problematic UX, but we should strongly encourage new developments to listen to UX concerns, and we should support and encourage making changes that are purely UX related, with whatever tools we find available in the given situation.

I think being able to improve UX will be much easier with a stronger release engineering culture, as it will allow introducing more planned breaking changes.

@mschwaig
Copy link
Member

mschwaig commented Oct 3, 2024

I think contributors incorporating user journeys and personas into how they are thinking about UX would be great, and the topic of analytics deserves its own question, which I will post and and link here (#122).

Where I see Nix failing most significantly in terms of UX is demanding too much from new users, and making it easy for them to go down the wrong path. Quoting from my candidate form:

The intended user experience should be clear and guided, instead of showering users with information and choices.

Let's look just at installation for example:

  • pick between an installer or the familiar distribution repository
  • pick between the Determinate Nix Installer or official installer
  • pick between single- and multi-user installation
  • decide if they want to use flakes and nix-command, or find out they are missing, and successfully enable them

I have seen people get stuck in this process, or coming out of it with something that's not working. I think people are also getting overwhelmed, confused or loosing confidence in us during this process, and walking away as a result.

What they wanted to do was probably give Nix a try, or build some project with a flake.nix, default.nix or shell.nix file, and not learn all of the fine details of the Nix installation process. We should try harder to not get in their way.

@getchoo
Copy link
Member

getchoo commented Oct 5, 2024

Should we focus more on UX than we currently are?

Definitely

What actions would you take to do so?

I think taking three steps would do a lot for end users: encouraging the use of nix-command, improving documentation, and providing more channels for feedback

Nix (IMO) already has a lot of good UX in the nix3 CLI with clearer, more defined subcommands, better logs by default, and overall "prettier" output. It has also been consistently improving with changes made to nix flake update/nix flake lock, nix eval, and nix profile that help all of them fall more in line with what people would expect (i.e., nix eval <installable> not exploding, updating individual inputs with nix flake update <input>, and being able to nix profile remove packages the same way you nix profile install'd them). In contrast, the stable Nix CLI has a lot of functions put into few, individual commands that encourage the usage of vague shortform arguments, which in turn makes things pretty incomprehensible for users unfamiliar with it. This can become quite a major blocker for people trying to become proficient with the tool, all the while nix3 has almost solved many of these core usability issues

Other aspects of the Nix ecosystem (Nixpkgs, NixOS) also have a very good base for making things easier for users (like setup hooks and basically all of the modules system), but without proper documentation their impact is way less than it could be. As I previously explained here, I believe this is one of the most important factors in the future of Nix, and we must improve sources such nix.dev and wiki.nixos.org to fill this gap -- else much of this work may go to waste

Lastly, hearing what the community wants must play a pivotal role in how current and future systems are implemented and changed. A good way to do this would be something similar to the yearly community survey, but more focused on specific parts of the project. These should include things like ranked choices for questions regarding usage and free form answers to more general, "big picture" questions. I would also be interested in possibly collecting some broad usage statistics as mentioned in #122

@proofconstruction
Copy link
Contributor

I mentioned in my answer to #83 that I'd support a desktop UX team to work on improving and upstreaming home-manager, and I believe such a team should also be responsible for gathering data about how people use Nix today and how they'd like to use Nix in the future, then defining personas and user journeys with that information.

We need to meet people where they're at, and that requires actually finding out where that is. I'd want a UX team focused on clarifying these questions and developing good answers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

6 participants