Improve UX for new users who try to drag and drop files between seamless qube windows

[ddevz]

I propose that we could create a new beginner mode... "seamlessless mode"! (or would it be seamy mode?)

The problem you're addressing (if any)

Basically, seamless mode will imply to a new user that drag and drop between VM's will work. It does not. From what I've heard, a new user will assume that they know how to copy files between systems (by dragging and dropping), then be bewildered as to why it doesn't work, and not look for a alternate solution (this being another point where they may give up on qubes)

The solution you are proposing

If there was a beginner mode, that could be flipped on and off, which kept a desktop frame (possibly a fake desktop frame) for each running appqube, that would contain all the user apps that the user lanches. The start button inside the desktop frame could either be enhanced by adding (or possibly entirely replaced by) a popup that says "launch your apps from the 'top level qubes button' ".

The idea is that we are trying to make it so from the beginning they would see each qube as it's own computer so that when they need to transfer a file, they say "I need to transfer a file between computers". I'm assuming that they would not expect drag and drop to work between computers, and they would start looking for a solution. (Note that Qubes actually makes transferring files between "computers"(qubes) easy, it's only hard when you compare it to moving files from one place to another place on the same computer)

This would also give them a chance to develop their workflow, and to develop their security labels (I.E. define what the security colors will mean to them).

Then after they know how to use the system, then have them maximize their usage of screen space by flipping a switch and turning on seamless mode.

Anyway, it's just a idea that I wanted to present.

The value to a user, and who that user might be

Beginners who are going to give up on qubes before they are able to work effectively in it. The value is they might stick around long enough to learn the actual qubes workflow before deciding if it's for them.

[andrewdavidwong]

Basically, seamless mode will imply to a new user that drag and drop between VM's will work. It does not. From what I've heard, a new user will assume that they know how to copy files between systems (by dragging and dropping), then be bewildered as to why it doesn't work, and not look for a alternate solution (this being another point where they may give up on qubes)

Seamless mode is a fairly fundamental design decision in Qubes, and it's quite a valuable feature. I think we should be prepared to reframe this as a UX bug and leave it open to our UX expert (@ninavizz) to determine the best solution. That solution may or may not turn out to be what you've proposed; I can't say. I'd just like us to remain open to the possibility of a UX solution that addresses this problem without dropping seamless mode. For example, just brainstorming, I can imagine that dragging a file from a file manager in one qube to another might present some sort of UX hint or, someday, even initiate a qvm-copy/move operation and prompt the user to confirm it in dom0, along with an explanation.

[ddevz]

I think we should be prepared to reframe this as a UX bug and leave it open to our UX expert (@ninavizz) to determine the best solution.

I agree. I'll leave it to her, and drop it myself. I've presented the idea and don't need to be involved anymore. In fact, is there a way to remove this from my "your open github issues" list, without closing the issue?

or, someday, even initiate a qvm-copy/move operation and prompt the user to confirm it in dom0, along with an explanation.

oOo. Neat Idea.

[andrewdavidwong]

I think we should be prepared to reframe this as a UX bug and leave it open to our UX expert (@ninavizz) to determine the best solution.

I agree. I'll leave it to her, and drop it myself. I've presented the idea and don't need to be involved anymore.

Ok, I've updated the title and reclassified this as a bug accordingly.

In fact, is there a way to remove this from my "your open github issues" list, without closing the issue?

Not that I know of.

[andrewdavidwong]

On second thought, I think it's probably better to frame this as an enhancement but just a more open-ended one. In other words, request the general type of UX improvement desired, not the specific implementation we assume will achieve that broader goal. Updated title and labels again.

[ninavizz]

Oyyy... I would flag an important issue with this, being hardware limitations of most Qubes compatible laptops. Macs, Android devices, iPhones, and most tablets, are really the only devices that have touchpads sensitive enough to do drag-and-drop well. Mice, obviously make it easy to do, too—but would a new user be using an external input device just yet?

I had wanted to do D&D early in my UX work with Qubes, and @marmarta wisely advised me "Go try and do some drag and drop on your ThinkPad, I'll wait." It's not a pleasant experience. Part of that is because of firmware/chip things, and part of it is because of the materials used in the pad's surface, itself (that make it hard for your finger to nicely slide across it).

In any event, we'd tentatively decided to never do D&D in Qubes. We're completely open to reversing that decision, though, should someone make a convincing enough argument (or available hardware improve).

Another thing we learned in user research for the app menu... from security trainers, is that when folks are new to Qubes there's still a lot of mental "training wheels" work to do with developing thought habits, to acclimating folks to "think" in terms of isolation and compartmentalization. Kind of like when you start bicycling everywhere, you re-think routes in terms of hill avoidance, vs most-direct-way (or at least I do, lol).

Without being paternalistic, we do want to encourage users to think more about how they do what, when, and where, within qubes. So, a "qubes first" way of thinking. I'd developed prototypes to allow users to navigate by apps, in one of my prototype videos—and the trainers offered this feedback, in response to that. Which I found salient and applicable across the system.

Does all of that make sense @ddevz? Very curious what @deeplow may think, as well.

I'm honestly optimistic that once we have an integrated tutorial, that "Moving files between qubes" can be one of those Top-5 or Top-10 things we present to users at the outset. I agree, it's "confusing." I just don't want to create more confusion, creating more modes. If that makes sense.

[deeplow]

From what I've heard, a new user will assume that they know how to copy files between systems (by dragging and dropping), then be bewildered as to why it doesn't work, and not look for a alternate solution (this being another point where they may give up on qubes)

Macs, Android devices, iPhones, and most tablets, are really the only devices that have touchpads sensitive enough to do drag-and-drop well.

Not really. My thinkpad works fine. Plus, desktop computers and generally laptops with mice. Even if there is still the alternative (right-click » copy to AppVM) for those cases this has potential to alleviate a big gap in unmatched user's expectations.

I'm honestly optimistic that once we have an integrated tutorial, that "Moving files between qubes" can be one of those Top-5 or Top-10 things we present to users at the outset.

Speaking of which, on one of my feedback rounds (with 6 users) 3 of them expected to be able to drag and drop, but then the tutorial told them how to do it. I think this is a major UX enhancement..

The current inter-qube copy is just too complicated (not to mention, unintuitive). Broken down into steps currently, it's as follows:

• right-click in file explorer "copy to other AppVM"
• dom0 RPC policy confirmation shows
• selects target qube
• hits OK
• navigates into QubesIncoming in the target qube
• chooses the directory named after the source qube (each time I do this I already forgot where I copied the file from)
• finds the copied file

One think I've observed with the tutorial is that some participants are too overwhelmed with the copy process that they just blindly follow the tutorial. So the less steps the better to be honest.

So ideally, if there were a safe way to implement drag and drop that would make the tutorial easier to follow as it would just. I had not thought about usability issues with the ability to drag and drop on some computer / with some users.

I just don't want to create more confusion, creating more modes. If that makes sense.

I agree. Developing one product should already be hard enough. Plus your menu (https://github.com/QubesOS/qubes-issues/issues/5677) is already the "training wheels" of Qubes as you mention.

[deeplow]

@ninavizz I've given a bit of though about this in the past (when I was brainstorming about what to work on my dissertation) but never followed through with creating an issue for it. Here's the drag-and-drop flow I imagined:

• All other qubes' windows would be overlayed with the qubes' color semi-transparently (as the user drags the file). If not possible to transfer to that qube (due to RPC policy) then show a "forbidden" symbol.
• when the file is over the target qube a progress bar bellow the file being dragged starts advancing. (we can call this the "consent progress bar").
• Only once that progress bar reaches the end is file actually copied. This is to prevent a rogue qube from opening a maximised window just at the right moment and stealing the file.

I can try to make a mockup in the future to better illustrate what I'm saying.

Potential implications

• this would paste the file in the exact folder where the user drops it, thus avoiding the cumbersome process of having it go into the QubesIncoming folder, which breaks conventions.
• this would avoid having to show a dom0 prompt to select the target qube (just like the clipboard copy already does)

[deeplow]

A technical implementation for drag and drop in a qubes-like system has already been written about in the a PhD dissertation titled "Securing Graphical User Interfaces" (see PDF section 4.3.5).

[GWeck]

@ninavizz Drag and Drop is very cumbersome if you use it via touchpad or touch screen. On the other hand, it is a very fast operation when used with a mouse. I am alwys using it if available, and for this reason, I always use my laptop with a mouse and even have its touchpad switched off. So I would think that providing this facility in Qubes might enhance its usability mainly for those, like me, who come from a (Windows) desktop environment.

But it should not be implemented in the Windows way :-)

[ddevz]

From what I've heard, a new user will assume that they know how to copy files between systems (by dragging and dropping), then be bewildered as to why it doesn't work, and not look for a alternate solution (this being another point where they may give up on qubes)

Speaking of which, on one of my feedback rounds (with 6 users) 3 of them expected to be able to drag and drop, but then the tutorial told them how to do it. I think this is a major UX enhancement..

@deeplow Did you mention that in a qubes talk? If so, I may have heard it from you.

[ddevz]

Another thing we learned in user research for the app menu... from security trainers, is that when folks are new to Qubes there's still a lot of mental "training wheels" work to do with developing thought habits, to acclimating folks to "think" in terms of isolation and compartmentalization. Kind of like when you start bicycling everywhere, you re-think routes in terms of hill avoidance, vs most-direct-way (or at least I do, lol).

@ninavizz This is what I was thinking of when I proposed the new mode. That adding drag and drop would allow them to skip thinking about the compartmentalization.

Without being paternalistic, we do want to encourage users to think more about how they do what, when, and where, within qubes. So, a "qubes first" way of thinking. I'd developed prototypes to allow users to navigate by apps, in one of my prototype videos—and the trainers offered this feedback, in response to that. Which I found salient and applicable across the system.

Does all of that make sense @ddevz? Very curious what @deeplow may think, as well.

I agree that we need to promote "compartmentalized thinking". My proposal was just a possibility. I've decided that I'll let you guys decide if it was a good possibility or not. :)

Note that I've been learning more about qubes, so my ability to be able to make judgements from the perspective of a new user may be ending soon.

[deeplow]

@deeplow Did you mention that in a qubes talk? If so, I may have heard it from you.

I don't think I referred this specifically.

[ddevz]

@deeplow Did you mention that in a qubes talk? If so, I may have heard it from you.

I don't think I referred this specifically.

I believe the talk was a graph of excitement over time of someone learning qubes, with a picture of someone throwing the computer out the window at the end.

[ninavizz]

@ddevz Deeplow's talk kinda ruled, and I loved his graph as a "dose of honesty," in that it beautifully captured the highs/lows of new folks coming into Qubes. Our baby is so beautiful, she was just born swearing an awful lot, lol.

@deeplow Wow, color me intrigued! Yes, I'd love to do more user testing to learn about drag-and-drop in Qubes. Unfortunately, tho, this feels like a high-cost/high-risk feature to develop, with where the project is at right now, financially—and, with where window management is at right now, with available hardware performance. Like... to get dropshadows on the windows, with available hardware atm, is incredibly expensive for GPU load.

More and more, I just want a magical executive from Asus or Intel or AMD to drop from the sky, and commit to making an i7 chipset w/ FOSS firmware, built into a laptop with Qubes compatibility built-in. Available in the super-cheap "anyone in any global economy can afford this!" version, and in the "Gamer with too much money? This is your dream machine" version. And millions of dollars for a robust dev team to also tackle allthethings like your ideal drag-and-drop flow, too.

In due time. In due time. All, in due time.

I still want to keep this issue open, tho. I also desire drag-and-drop, but still also consider it a risk with the ThinkPad's built-in pad. It doesn't feel like a prudent use of dev resources, to develop features that require use of peripherals, to not mess-up with. But, especially with the use-case you cited Deeplow, it feels like something Qubes should eventually have.

[ddevz]

@ddevz Deeplow's talk kinda ruled, and I loved his graph as a "dose of honesty," in that it beautifully captured the highs/lows of new folks coming into Qubes. Our baby is so beautiful, she was just born swearing an awful lot, lol.

If that was his talk, then when I say "From what I've heard, a new user will assume..." I heard it from him, so consider him the source on that topic, and consider my information about that second hand.