Integrated turorials

[mfc]

In the most recent study on why OpenPGP mail clients are difficult to use, the authors highlighted the usefulness of having integrated tutorials in a product.

I think we should explore having an integrated tutorial for first-time users. This could run after the installation wizard or be a desktop icon for whenever the user is interested in running it, somehow walking the user through doing useful workflows in Qubes.

[ParadiseBurn]

＼(◎o◎)／！ - Coming into Qubes as a new convert and grinding through a few weeks of the EFI/HW integration wall of 3.0 and 3.1 - Awesome timing on this topic ;) Look forward to seeing an icon, a wizard, an error-free (cant hurt anything) tutorialVM or whatever being available on startup!

I know how hard you guys are working and its awesome the big picture (branding, conversion, promotion, perception, integration etc.) stuff is still in mind. I am a firm believer in Keeping it Simple (Stupid) and cannot think of many better ways to creating a successful result than making it EASIER for people to use or learn something!

Command lines, details, long descriptions...I understand...I get it...I just have to say that theres nothing wrong with adding a few rectangles and arrows in GIMP to some screen shot to show how to do something! Whonix installation and setup was without a doubt the easiest and understandable example of broad stroke instructions I have had in using Qube's so far https://www.whonix.org/wiki/Qubes/Install

I know, low brow pictures , arrows, etc. just cant help it! I need the visual...the read-write is there! Add some kinesthetic and a few auditory beeps and alarms and you got it covered ;)

[mfc]

here is what Gnome has: https://gitlab.gnome.org/GNOME/gnome-getting-started-docs

[deeplow]

@ninavizz @marmarta I'll be focusing on this for my master's dissertation. I'll do a more detailed post at a later date.

[deeplow]

Here's the promised post. Also, is it OK if I basically use this issue to brainstorm ideas? Even if they don't get implemented into the Qubes system in the end, I feel like this is a great place to give some progress updates and ask for feedback.

See bellow my thesis proposal presentation. edit: the name is not final ;)

Why an integrated tutorial?

I think most can relate to not having a rough first days on Qubes and then when we finally found that we should read the documentation (most people don't), we felt overwhelmed. Also I saw @ninavizz and @marmarta were particularly focused addressing the other usability aspects so this way we would not step on each-other's toes.

Users lack onboarding

To start off I did some exploratory research, where I interviewed 6 Qubes users with varying levels of experience. The goal here was to understand what were the main challenges when getting started with Qubes and what solved them.

One issue in particular stood out to me, related to learnability. It's best described by one of the users:

“you install the Qubes on the computer, but there is no onboarding. So you are alone with this new operating system [...]"

Additionally, from a bibliographic review pointed to the fact that most users prefer much more learning as they go instead of having to refer to a manual. And the current main way of learning how to use Qubes is via the documentation (and videos as well) - but statistical significance cannot be obtained on such a small sample (so take it for what it's worth).

Gamification component

Gamification has proven to be as an effective motivator for learning. I'll be exploring how this can be integrated into the tutorial and possibly into an achievements companion application. Here are few ideas:

• Integrated tutorial to have a story / theme Instead of just asking the user to complete a set of tasks, give a back-story as to why those tasks need to be accomplished. For example, the user is an investigative journalist and must open an untrusted document.

• Achievements companion application One cannot learn everything in a single lession. So with the user have a small widget in the tray area where the she/he could essentially see what tutorials / features can still be explored. You can see it as a progression path for discovering Qubes features - it will contribute to discoverability of features like split-gpg, for example.

• Rewards for tutorial completion Giving the user a reward for completing a tutorial will incentivise she/he to continue learning.

This will be the most "explorative" part of my project. At first I was quite skeptical of adding gamification components. But I'll test the hypothesis and it may prove to be a better approach.

Next steps

Next up will be designing the tutorials, prioritizing important concepts to be conveyed to the user, then doing iterative design to come up with a high-fidelity prototype. I'll be doing this over the next months.

[deeplow]

Also, is it OK if I basically use this issue to brainstorm ideas?

Unapologetically claiming space for brainstorming :smile:

Qubes Course Design

I've been taking notes of all the main things present on the documentation that could potentially be interesting to teach people coming into contact with Qubes for the first time. I've also taken notes from two video tours of Qubes (Micah Lee's and Matthew Wilson's -- the ones listed on Qubes' website)

Tutorial 1 - Understanding Qubes

We don't know how long people can do a tutorial for. So I think we should aim to provide first the most important things to know in order to be able to use Qubes. I've determined them to be:

• understanding the idea "security though compartmentalization"
• distinguishing qubes / compartments
• starting applications
• moving files between qubes
• copying clipboard between qubes
• dom0 prompts
• shutting down qube

Plot

To give some purpose to the tutorial the idea is to have a story to follow along.

The current tutorial idea is the following:

• Some coworker shared with the user a picture of a cat and the user wants to copy it to their personal cat collection (on the personal qube).

There are probably better ideas out there. I'll have to think more about this, but it has to be something that clearly demonstrates to the user the visual distinction between to qubes.

Steps

1. Open "files" in work
2. Find cat.png
3. copy cat to Other AppVM
4. accept dom0 prompt
5. Open "files" application in personal to see where the picture landed
6. Close all windows
7. Explain that VMs are still running in the background even after losing windows
8. Shut down personal and work VMs.

Note: The goal here is to have two different qubes and highlight the differences. In this case the window borders and title, and then show they are separate computers by showing how their home folders differ.

Prototype

I'm still working on a prototype for this first tutorial. But here's a sneak peek:

One thing that I'll have to pay attention to is to clearly signal what's the tutorial's window and what's the rest of the OS itself.

@ninavizz, I've borrowed some of your artwork (cute cube icons). Hope you don't mind.

Any thoughts?

[deeplow]

Progress update - prototype design

Hi all! It's been a while since I've done an update, but here it is. I've done the first prototype and then did some user testing. So I'm now at the second iteration of the prototype. A few things have changed. If you're curious, you can try it on the following link (doesn't work on Tor Browser):

https://www.figma.com/proto/ITndc11Fg3j6Gk2MXJizjD/onboarding-tutorials?node-id=262%3A796&scaling=scale-down&page-id=0%3A1&hotspot-hints=0&hide-ui=1

Reasoning behind it

On a superficial level by doing the tutorial one would learn to: (1) open an application; (2) copy file from qube A to qube B; (3) close qubes.

While one could think that other things like installing software could be more important. It's a fair point, but my hope (and hypothesis) is that by doing this, it adjusts the user's mental model to how Qubes works. So one is not just learned the contents but ends up

If that happens to be true the along the way the user potentially learns also the following:

• a) Colored borders allow one to distinguish between qubes
• b) Recognize dom0 prompts
• c) Realizing that closing windows does not close the qubes. One needs to manually do that
• d) Understanding that different qubes have different files and can't access each other's files

My inspiration for this came from the book Teaching Tech Together:

Your goal when teaching novices should therefore be to help them construct a mental model so that they have somewhere to put facts. For example, Software Carpentry’s lesson on the Unix shell introduces fifteen commands in three hours. That’s one command every twelve minutes, which seems glacially slow until you realize that the lesson’s real purpose isn’t to teach those fifteen commands: it’s to teach paths, history, tab completion, wildcards, pipes, command-line arguments, and redirection. Specific commands don’t make sense until novices understand those concepts; once they do, they can start to read manual pages, search for the right keywords on the web, and tell whether the results of their searches are useful or not.

Some Screenshots

Major Changes

Provide progress / length information

Showing the user the tutorial has around 35 steps would not be a good idea. Instead we went for a task-based approach, dividing the tutorial into four tasks and showing the user "task X of 4" at the bottom right corner of the screen. On the same window we also add information about the current task and a tutorial exit button, to comply with Nielsen's usability heuristic of "Clearly Marked Exits".

Additionally we also say in the beginning how long the tutorial should be to set an expectation. With these changes we removed the progress bars bellow each tutorial infobox as users did not seem to notice them.

Reorder tutorial

To better introduce users to the importance of colored borders, instead of opening the files for "work", then copy and only after see the files for "work" we now have the user first open both file managers side by side and then we show a modal informing the user of the meaning of the colored borders.

Previously the concept of colors was introduced in step 15 where the user was presented with an administrator prompt (colored gray with label "[dom0]") which already had a lot of other information for the user to parse. This way we break down the concepts and first introduce the user to the colored borders and only in another step is the user introduced to the administrative prompt (colored gray).

Abstract compartments

Users may want to think abstractly of qubes and not wanting to know the technical implementation. Catering especially for the non-technical users (whom the tutorial may benefit the most), the language virtual machines / virtual computers was renamed to "qube". This includes the removal the step 24 ("how Qubes works") which explained how qubes converged multiple computer's desktop screens seamlessly onto the same user interface. Step 3 was also removed as it introduced the idea of virtual computers. The only exception to this is the step where a user as to click a button called "copy file to AppVM" (where VM referes to a qube) and it happens because the Qubes team has not yet made made the terminology consisten across the system.

personal -> untrusted

We're changing the target qube of the mission from "personal" to "untrusted". This way it respects security rule of only copying information from a more trusted compartment onto a lower trust one.

Safe exit

Many participants expressed some desire to leave the tutorial (even though most stuck through the end), we should assume that in a real-life scenario many will also skip. With this in mind, we should make it easier for the user to know they can come back to the tutorial when they desire (also addresses issue 12). So we have kept the label "skip tutorial" but when the user clicks it, the exit the tutorial and a small information window pops up pointing to a "lifesaver" icon on the system's task bar (top right) where the user can click to do the tutorials.

@marmarta @ninavizz, mentioning you two in case you're interested in seeing the progress update.

[andrewdavidwong]

Coming along nicely, @deeplow!

With this in mind, we should make it easier for the user to know they can come back to the tutorial when they desire (also addresses issue 12). So we have kept the label "skip tutorial" but when the user clicks it, the exit the tutorial and a small information window pops up pointing to a "lifesaver" icon on the system's task bar (top right) where the user can click to do the tutorials.

Perhaps you could add some words indicating that the user will be able to return to the tutorial later before actually exiting. The user may feel some anxiety and uncertainty about the finality of hitting "exit" that will be relieved only after doing so. This could be as simple as saying "You can come back later" in fine print underneath the exit button.

[mfc]

hey @deeplow, it is really exciting to see this progress! it looks really fantastic.

besides some very minor typos, I wanted to flag one aspect: the current story/reasoning for moving the file is not very strong, as it is actually the story to use a disposable qube to view the untrusted file received in work domain.

i understand you are probably trying to use the existing default qubes. i think maybe instead of work -> untrusted, maybe have the story be someone accidentally sent you a personal photo to your work email? and so the user is moving the file from work -> personal.

[andrewdavidwong]

the current story/reasoning for moving the file is not very strong, as it is actually the story to use a disposable qube to view the untrusted file received in work domain.

i understand you are probably trying to use the existing default qubes. i think maybe instead of work -> untrusted, maybe have the story be someone accidentally sent you a personal photo to your work email? and so the user is moving the file from work -> personal.

It might be hard to come up with a real common use case with the default qubes, since they're so separate by nature. If willing to use non-default qubes, a realistic use case might be creating a file in one qube (e.g., a PDF), then copying it to an email qube for sending, or something along these lines.

[deeplow]

Thanks for the feedback!

I wanted to flag one aspect: the current story/reasoning for moving the file is not very strong, as it is actually the story to use a disposable qube to view the untrusted file received in work domain.

I totally agree. To be honest, coming up with a plausible scenario for this initial tutorial. Before I had that the user had been sent a cat picture by a co-woker and wanted to move it to their personal cat collection.

Honestly I prefer @mfc's scenario of the personal photo. But the reason why I change it back was to avoid encouraging from moving files between qubes with (arguably) the same trust level. But coming with a plausible scenario on the default qubes with this requirement makes it that much more challenging.

I may need to sacrifice this requirement. After all I only very strict qubes users would not copy from work to personal. And the target audience the the tutorial is aimed for will probably do just that. So why not alleviate this constraint to make the tutorial more relatable?

About the email idea, I could incorporate this, but: a) It would add more steps to an already complex tutorial b) I want to avoid making too much changes to the default qubes c) I wanted to show the file explorers side-by-side I believe that's most likely to give users the realization that different qubes have different files.

If willing to use non-default qubes

On the other hand, per @andrewdavidwong's suggestion using non-default ones will give more flexibility. I will think more about this.

On the original draft proposal I had specific users could play as a persona (a kind of choose your own character). E.g. choose from (a) journalist (b) activist (c) person who just wants more privacy & security. Then the scenario would adapt based on this choice. However, I ended up dropping this idea as I was trying to make the first tutorial with as little complexity (for the user) as possible.

[andrewdavidwong]

Since one of the main goals is to keep it as simple as possible, one option is simply to drop the story aspect and simply say, "Now suppose you want to copy a file from X to Y..." and proceed from there.

The drawback of using a story based on an accident is that it might be distracting (for example, some novices might think, "Why wouldn't I just email it to myself?") or misleading about how common and useful inter-qube file copying is.

[mfc]

About the email idea, I could incorporate this, but: [...]

sorry i didn't mean to suggest you need to add additional steps around emails, the personal photo could come from anywhere and maybe doesn't need to be stated. the point was just to have it be work -> personal.

i don't think the trust levels are an issue -- you will be familiarizing the user with trust levels through other proposed tutorials. what is actually quite helpful to learn at this early state is that every qube starts the same, and only through user action becomes the topic-relevant qube it is called.

this is a very important early concept that i have seen many new users struggle with. teaching the user that through the action of moving a personal photo from work to personal with the two file explorers shown, they are actually embodying the label of the personal qube and making it personally relevant to their set-up.

as for whether or not to have the story, yeah maybe it's clearer to just explicitly state the goal, like @andrewdavidwong suggests. i think making them specific enough to be personas (like "journalist", "activist", etc) is much too specific for this use and that should instead be connected to familiarizing the user with the salt recipe distribution method at a later stage.

[ninavizz]

Blown away by @deeplow's presentation today, covering progress on this project for the Qubes Mini Summit. Amazing work, Deeplow! As back-channeled earlier, it also inspired a mini design-party on my end. The below mockups are quite rough, and also presumes that #6414 has happened (and that dom0 windows are gray, not black, which I don't feel strongly about but also didn't feel like changing for this, heh).

My #1 point of feedback to you, is that—wow—some of the technical stuff (like the circled highlights) do seem quite complicated and hard to achieve in our universe of compartmentalization. That said, such complications I don't see at all as necessary, to get something shipped as a first iteration. "Perfect is the enemy of Done," as the saying goes. But, for your dissertation, you're gonna make it Awesome as your priority, which I wholly respect. :)

My primary realm of "designerly" or usability feedback, is that many users will still see "5 minutes" on your current first page and balk. It feels a bit like the 3 metre deep section of a pool that goes from 1 to 6 meters in depth across its length. So, I created the below as my jab at a 1 metre deep starting point, inspired by the user feedback you shared in your presentation.

What are the very first things users want to do or to learn, when they launch Qubes for the first time? Shown below, are my estimations of those tasks and needs, based on how you framed that experience in your talk (from your most excellent sounding user research!), and my own experiences; all framed in a welcoming and easy-to-consume or to ignore screen.

The technical assumption here, is that eventually a "Tutorial Widget" is built into the task bar (and would have its own TBD menu), that launches the Tutorial application in dom0. On the first boot, that app would automatically launch, and show this.

First Launch

Why this and not a button that asks for 5 minutes? Deliver value immediately, up-front, with the progressive-disclosure patterned popover windows explaining the most basic of basics. Demonstrate to users that you/we mean it, with simple plain-language information not dependent on a Computer Science degree, or experience with Linux.

• On first-launch, the "Tutorial" app auto-launches with the Welcome page shown.
• All blue-text items are for hover triggered popover bubbles; unless the external-open icon is shown next to it.
• Items addressed in the 1st launch Welcome screen:
  • How to connect to the internet
  • Introduce the "Devices" widget.
  • In my own user research work with Qubes, I learned that while not-pretty, this is a more intuitive widget than I'd guessed. So, a few sentences introducing it (and where it's located), with a link-out to a deeper-dive section in the tutorial or the docs, felt appropriate here.
  • How to open an app that probably everyone will want to open.
  • Show the app icon as colored
  • Suggest 2 of the pre-installed qubes that match that color
  • Also include in the blurb a popover explanation for how colors work in Qubes
  • Also included in the blurb a link to a popover showing where the appmenu is, and what it contains
  • Introduce the "Tutorial" app with disarming and encouraging information
  • In the hover-over bubble, note that it does not use an internet connection, and may be opened from the Tray icon
• How to get help. Introduce the forums and email lists, as well as mention that we have a CoC and stick to it (to imply that, no, it will not be akin to 4chan with snitty hackers making people feel lousy).
• What the window top-bar formats mean (qube/app/file)
• That, yes, there are a lot of notifications and what that is the case.

Not super elegant mockups

[DemiMarie]

My #1 point of feedback to you, is that—wow—some of the technical stuff (like the circled highlights) do seem quite complicated and hard to achieve in our universe of compartmentalization. That said, such complications I don't see at all as necessary, to get something shipped as a first iteration. "Perfect is the enemy of Done," as the saying goes. But, for your dissertation, you're gonna make it Awesome as your priority, which I wholly respect. :)

Nit: you should escape the # as \#.

[ninavizz]

One more...

@deeplow if you actually like these or would want to work with them, I could polish them up a bit and send you a Figma.

[andrewdavidwong]

Not sure if any feedback on these mock-ups is desired. If so, two things stood out to me:

1. I would not have guessed that I could hover over the margin notes to get verbose tooltips.

2. I think we do want everyone to care about and pay attention to dom0 notifications, as very bad things can happen when users don't.

In general, though, looks very promising!

[ninavizz]

@andrewdavidwong It's increasingly a standard feature on websites, that graphical pop-overs on hover (or click) are an option; like we'd discussed for the glossary items for the docks (waves fist in air at Jekyl plugin that does not exist). "Tooltips" have me think of the simple HTML alt-tag feature. The idea for this, is that it'd be the richer hover/click popover functionality. Probably with a little less text than I'm showing in my admittedly verbose first-pass mockup/wireframes. Much prettier (to feel more "intentional"), and not gray, too.

1. The above were only endeavored as wifreframes—to demonstrate the concept. Not aesthetics. I totally agree, as underlined hyperlinks, one expects... well, those things to link out. Not so much hover. Different visual design fussing and possibly a (?) icon would be needed, I feel, to tie it all together nicely. Definitely a deal of visual polishing, TY for the shared heuristic observation!

2. The notifications are totally freaky, at first. Which I noticed, and my SD users have also commented on. Intent is not to say "don't pay attention," at all. This is just a first jab at the copy, and I appreciate the feedback that your read on my first pass is "Don't pay attention." There's probably too much text, in the above wireframes... but, in that much text, it feels important to communicate to users (imho) that a) You'll appreciate these notifications, once you get used to them and get your head wrapped around the mental model of Qubes, and b) It's ok to be freaked-out by them, until then—but hang in there. Or, something like that.

A thing that gave me some nice pause in Deeplow's presentation, was realizing how much I've probably taken it for granted, that all of the users I'm working with have received hours of training and hand-holding with Qubes, before properly diving in. The whole project is so nice to see, though. This was just one little idea I'd had, as a "Yes, and..." contribution.

So much work, Deeplow. Really excited to see it coming together. Again. :)

[deeplow]

@ninavizz thanks so much for the feedback. Tbh the welcome page is where I spent the least focus, so it's a nice complement your brainstorming here :)

I was also struggling with the fact that I was not providing immediate value to the users and this sounds like a good approach.

My primary realm of "designerly" or usability feedback, is that many users will still see "5 minutes" on your current first page and balk. It feels a bit like the 3 metre deep section of a pool that goes from 1 to 6 meters in depth across its length.

I totally see that! And it's also a concern of mine. I may try to include a metric in the evaluation to determine if people were compelled to click on it or not. But progressive disclosure is probably a good idea. One could even ask the user to open the files app for personal and if they do then ask if they'd like to do a tutorial now that they've already made the first step.

@deeplow if you actually like these or would want to work with them, I could polish them up a bit and send you a Figma.

Awesome! So, because of the constraints of what I want to evaluate (the effectiveness of the tutorial) I may keep the current welcome screen just to test-drive the tutorial with users. But when implementing for actual usage within Qubes (if up to the standards of the dev team) this will certainly be the way to go: immediate value + optional tutorial. So I would say, if the summative evaluation shows a tutorial is beneficial, then we iterate on your design :)

A little tweak I'd do is just to give a bit more prominence to the tutorial (so there's no way users miss seeing that there is a tutorial).

Also, I had never noticed the notifications being an issue, but now that you mention it! That's very true. I guess I've been breathing Qubes for way too long. Haha. I think the welcome screen is possibly the best place explain basic things that surfaced during your research (like the devices thing).

We can also brainstorm about where each educational tidbits should go. I think showing them just-in-time (as opposed to decontextualized) could be a good thing. But this is something I didn't explore in my tutorial. One example of this would be to mention the notifications when the actual first notifications show up instead of the home screen. Or mentioning the dom0

Thanks again @ninavizz for taking the time!

[SvenSemmler]

users will still see "5 minutes" [...] and balk I totally see that! And it's also a concern of mine.

mind blown ... are you serious?

So they have a need for security, get a computer that's compatible, install Qubes OS (lots of $ and time) and then investing 5 minutes to learn the basics is too much to ask?

I get what you are trying to do, but from where we are today to the point discussed above feels like worlds apart. What you already did is amazing and so desperately needed, please don't let the perfect be the enemy of the good.

(just worried this will get off track ... sorry)

-- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

[andrewdavidwong]

users will still see "5 minutes" [...] and balk I totally see that! And it's also a concern of mine.

mind blown ... are you serious?

So they have a need for security, get a computer that's compatible, install Qubes OS (lots of $ and time) and then investing 5 minutes to learn the basics is too much to ask?

I know, right? This is the sort of thing that makes "the average user" so easy to dislike.

[andrewdavidwong]

I actually think a lot of this depends on how you frame it. Imagine we open by saying something like, "Congratulations on successfully installing Qubes OS! It's probably taken you considerable time, effort, and expense to get to this point. In order to make good on your investment and reap all the security benefits Qubes has to offer, we've carefully crafted a brief tutorial that will guide you through your new system. By the end of this short session, you'll be equipped to make the most of your experience. This tutorial was designed to respect your time, and we strongly recommend all new users complete it."

I'd like to think that this would make users more receptive, but I'm probably just overestimating the goodness of human nature again.

[deeplow]

users will still see "5 minutes" [...] and balk I totally see that! And it's also a concern of mine. mind blown ... are you serious?

Yes. It's a real concern for me. Even after making the tutorial it can only be effective as long as people do it, no matter the effort I put into the tutorial. Some may just straight up close the welcome screen before they even realize there is a tutorial. That's why there is now a thing that pops-up when the user skips the tutorial saying "If you change your mind, click here to do the tutorial"

Think about cars, for example. Many users are really excited to get their new cars with all the new features. They spent months researching and comparing models and when they finally have it all they want to do is just to use the thing. They can't be bothered with reading the manual, even if that would actually make them be able to better use the car. However in the case of Qubes, they will probably notice mid-way that they don't know where to start "the car". So then they have the chance to change their mind and do the tutorial they just skipped.

I really hope this concern not justified and we'll see in the final evaluation. But if it is true that at least a significant % won't do the tutorial, immediate value and progressive disclosure will have to be the way to go.

Humans just aren't programmable. :laughing:. If they were I'd just do:

if start_qubes_os and first_time:
  do_tutorial()

And problem solved.

Also I like @andrewdavidwong's approach of marketing the tutorial as something to make the user's time worth it :)

[h01ger]

deeplow very much describes how I usually approach things, why should I read the fine manual, I'll make that go away and will explore the system on my own :)

[ninavizz]

@deeplow The notifications OMGWTF thing came up more casually, not in formal research efforts. It's something I first noticed, then had a discussion with colleagues about... then observed users commenting on in chat threads. It's one of those soft things that I feel isn't "essential" but could serve to help users feel validated with some initial discomfort.

A lot of security software overwhelms users with stuff that's not really important, and it's easy I feel to dismiss the notifications as among those things. It helped me, having one of the SD devs explain to me why they're important. I don't feel it's obvious enough to people new to opsec. I've also observed our SDW users adapt to them. Somehow flagging them as a thing to not relegate to cognitive fatigue, but to be ok being uncomfortable with at first, feels like it could just be nice. Like a pillow mint, perhaps, heehee.

[ninavizz]

@andrewdavidwong @svensemmler Guys, I just saw your comments, up above.

mind blown ... are you serious?

So they have a need for security, get a computer that's compatible, install Qubes OS (lots of $ and time) and then investing 5 minutes to learn the basics is too much to ask?

No. However, it's fundamentally problematic to expect a person to spend even 5 minutes doing something when they're not ready to spend that five minutes. Especially if it is desired for users to remember what they learn. Agency is important.

I don't have the above opinion out of speculation, nor as a judgement of the reasonableness of the ask "to learn a few things." The above is just known as a reality of how humans use computers. It's also something I've observed in my many years doing user research.

When a person is booting Qubes for the first time, they have likely spent hours researching and working towards that moment with learning about hardware needs in the days/weeks before, and in the hours leading up to the first boot working with the installer and bios tweaks. It is entirely reasonable to expect a user would then want to poke around and explore a bit, as @h0lger alludes to, above. Progressive Disclose is a proven, successful pattern to invite users in, and on their own terms.

Seriously. Design requires iteration. This is not trying to get "perfect" at the expense of "done." Everything Deeplow's done is amazing. My mockup is just a suggestion for that first moment when a user first boots; it's an "out of box" intro, and just one suggestion.

"Congratulations on successfully installing Qubes OS! It's probably taken you considerable time, effort, and expense to get to this point. In order to make good on your investment and reap all the security benefits Qubes has to offer, we've carefully crafted a brief tutorial that will guide you through your new system. By the end of this short session, you'll be equipped to make the most of your experience. This tutorial was designed to respect your time, and we strongly recommend all new users complete it."

I'd like to think that this would make users more receptive, but I'm probably just overestimating the goodness of human nature again.

1. That's waaaaay more text than most users would get through in an OOBE. Adjectives ≠ good, in UI text. It is a wonderful intro. It really is. The bulk of the text is just more than brains want to process in the context of a task, though. The latter, is the key to that ascertain.
2. The goodness of human nature is not the problem. The reality of how our attention spans have been trained by marketing BS, is. It doesn't matter that this is Qubes and not "that kind" of org/product. People responding to visual cues in the context of a UI, is more impulsive than it is thoughtful.

Design for human behavior is hard. Human weirdness is my job security, yet the bane of trainers and educators, everywhere. I value what Deeplow is doing, so so hard. Please do not take my "yes, and!" feedback, as a derailment.

[andrewdavidwong]

@andrewdavidwong @svensemmler Guys, I just saw your comments, up above.

mind blown ... are you serious?

So they have a need for security, get a computer that's compatible,

install Qubes OS (lots of $ and time) and then investing 5 minutes to

learn the basics is too much to ask?

No. However, it's fundamentally problematic to expect a person to spend even 5 minutes doing something when they're not ready to spend that five minutes. Especially if it is desired for users to remember what they learn. Agency is important.

Sure, of course. For example, if you're in the middle of something, it's annoying to be disturbed. We all understand that. But if that's what happens with this tutorial, it just means we put it in front of the user at the wrong time or in the wrong way. Maybe a gentler approach with a softly pulsing icon in the corner that communicates "there's a tutorial available if and when you want it" would be better in this regard.

I don't have the above opinion out of speculation, nor as a judgement of the reasonableness of the ask "to learn a few things." The above is just known as a reality of how humans use computers. It's also something I've observed in my many years doing user research.

It's two separate ways things: reasonableness of learning things vs. UX implementation. It's unreasonable to expect not to have to learn anything. It's reasonable not to want to learn something right now.

When a person is booting Qubes for the first time, they have likely spent hours researching and working towards that moment with learning about hardware needs in the days/weeks before, and in the hours leading up to the first boot working with the installer and bios tweaks. It is entirely reasonable to expect a user would then want to poke around and explore a bit, as @h0lger alludes to, above. Progressive Disclose is a proven, successful pattern to invite users in, and on their own terms.

Yep, I don't think anyone is disputing this. Progressive disclosure is fantastic.

Seriously. Design requires iteration. This is not trying to get "perfect" at the expense of "done." Everything Deeplow's done is amazing. My mockup is just a suggestion for that first moment when a user first boots; it's an "out of box" intro, and just one suggestion.

"Congratulations on successfully installing Qubes OS! It's probably taken you considerable time, effort, and expense to get to this point. In order to make good on your investment and reap all the security benefits Qubes has to offer, we've carefully crafted a brief tutorial that will guide you through your new system. By the end of this short session, you'll be equipped to make the most of your experience. This tutorial was designed to respect your time, and we strongly recommend all new users complete it."

I'd like to think that this would make users more receptive, but I'm probably just overestimating the goodness of human nature again.

1. That's waaaaay more text than most users would get through in an OOBE. Adjectives ≠ good, in UI text. It is a wonderful intro. It really is. The bulk of the text is just more than brains want to process in the context of a task, though. The latter, is the key to that ascertain.

I figured this would be the objection, but the solution should be obvious: progressive disclosure. The game Control handles this marvelously when the player tries to turn on "assist mode." They have text similar to what I provided above broken up into a few progressive steps. The idea is basically to communicate to the player that they designed the game to be challenging but not punishing and that they'd like you to try it out without assist mode for a while first, but it's up to you. It's incredibly effective.

Obviously, the first-draft text provided above would have to be tightened up, but you get the idea.

2. The goodness of human nature is not the problem. The reality of how our attention spans have been trained by marketing BS, is. It doesn't matter that this is Qubes and not "that kind" of org/product. People responding to visual cues in the context of a UI, is more impulsive than it is thoughtful.

Design for human behavior is hard. Human weirdness is my job security, yet the bane of trainers and educators, everywhere.

True, it's not just "human nature" in the sense of something innate. The main causes are probably poor education and underdeveloped mental discipline. However, it's important not to be fatalistic about this and to recognize that most people have the capacity to become better if they apply themselves. But they won't get better if we don't expect better of them. Sometimes, it seems like we work under the assumption that users are so inexorably helpless that our solutions become overly-infantilizing.

In the case of Qubes, explicit security compartmentalization requires at least some thoughtfulness by design. Unlike a lot of other software, impulsivity alone won't cut it here. I suppose it's your UX challenge to determine how best to help users bridge that gap.

[andrewdavidwong]

deeplow very much describes how I usually approach things, why should I read the fine manual, I'll make that go away and will explore the system on my own :)

This is a very common preference and a very understandable one. Most people would rather "learn by doing."

The holy grail is to make software so intuitive that no explicit instruction is necessary. Users just naturally understand it.

Perhaps the polar opposite of that is separate written documentation, like an instruction manual, which most people don't want to read. This is why it's bad to rely too much on documentation. Our ultimate goal should be to eliminate the user documentation, not maximize it. (Of course, this is just an ideal. In practice, we would never actually eliminate it.)

Integrated tutorials are a big step up from separate documentation, but they're still a form of explicit instruction. Think of them as the best we can do for now until we improve the features and UX of Qubes enough that no docs or tutorials are necessary for most users.