Defining our target audience for community guides, accessibility for new users

General Discussion
1

Hi

I would like to initiate a constructive community discussion following some unexpected feedback regarding recent documentation updates aimed at new users.

The goal of this conversation is to collectively clarify: What audience do we aim to serve, and what is the minimum skill level we deem necessary for a successful adoption of Qubes OS?

My perspective is guided by the following points:

Reducing cognitive overload: I would like us to provide tools and guidance to people who have general computer knowledge (coming from Windows, macOS, Android, or user-friendly Linux distributions) and to assist them in their journey with Qubes OS without a heavy cognitive load of “how do I get this done on Linux.” They already have a lot to understand.

All potential users are not tech professionals, nor they are tech enthusiast. Some just want to secure their computer and data. We should help users to focus their energy on what truly matters: understanding and using the security principles of Qubes OS.

Using Windows, macOS, Android, Ubuntu, or even Tails allows users to maintain daily productivity without having to learn terminal tricks for routine tasks. Why shouldn’t this be an equally valid goal in Qubes OS?

I know Qubes OS is not easy and it’s a patchwork of various things tied together that try to be consistent and usable. But we can certainly do something to help beginners to get started.

Providing support to users with less pre-existing knowledge and skills should not negatively affect the experience or functionality for our power users.

I look forward to hear other’s thoughts on this topic. Thank you for your engagement everyone :slight_smile:

3 Likes
2

This isn’t as easy as it sounds. The concept is simple, but nailing down details isn’t. The first question I think deals with Qubes itself. Do we intend to coddle new users or force them to learn Linux basics?

Coddling new users (I say this not in a negative way) is the obvious choice if we want to be new-user-friendly, but that requires intentional OS design, such as making a text editor universal, as in available on all templates (minus minimal) and making it default to present. Then, editing a file can be as simple as “open Application X in Y template.” But we can’t do that with just documentation.

If we decide to go documentation-only, users will have to learn Linux. This is more complicated and invites more questions. Should we point to a one-page doc that explains all the basics, such as editing files and installing packages in he most concise way possible, as a primer to future how-tos, or should we give users many small docs on how to do each individual thing?

If we choose the former, it has the benefit of allowing users to see everything all at once and get a better grip of what Qubes is, which is objectively better as it gives users a mental picture of Qubes and encourages familiarity with the system. If we choose the latter, it is objectively better in that users are not bombarded with too much information all at once all together.

Personally, I’d advocate for the latter, in which case scope becomes the issue. What is the smalles quanta of Qubes knowledge? I think it is best to illustrate Qubes-specific things in computer-generic ways, so that the Qubes knowledge is gained less consciously. “How do I edit a file?” is really answering one Qubes question, one Linux question, and one computer question. The Qubes question is “How do I find and use software already included on my system?”, the Linux question is “What does this piece of software do?”, and the computer question is “How do I edit a file?”

It would be nice to be able to symlink things together so we could answer how to find software in Qubes in its own article, and have the contents of that article show in the aforementinoed guide, and have both be updated together.

These are just the most basic considerations.

4 Likes
3

I don’t think that the definition of the target is the problem. I agree with you but I don’t think we are capable of providing the efforts to maintain quality and updated guides.

I would love it if Qubes OS provided the same kind of documentation as Tails OS. But Tails OS has a very narrow audience: activists (and, IMO, not every activist but only the ones with values in line with the project), journalists & sources and domestic violence survivors, mostly. Tails OS provides specific tools and procedures to follow to “[protect] against surveillance and censorship”. So unless the scope of the project is redefined, I think we currently don’t have the resources to provide the same level of beginner-friendly documentation, that’s why I think it’s better to focus on documenting only Qubes OS tools.

2 Likes
4

The required amount of skill is hard set by current security field and cannot be changed by qubes os documentation. If starting skill of a user is insufficient, determination is tested. Documentation can make this ride smoother, but extensive documentation leads to disrepair (and we have plenty of it in our current docs).

People often need to learn a lot to get into QubesOS. Trading volume in exchange for growing user skill set (especially if a skill can be applied in multiple contexts) might be useful. Not like I know how to do that :slight_smile:

1 Like