Consider renaming VMs for clarity #285
Comments
|
Risking irrelevance requesting this: in whatever renaming we may do, I'd also like to request mixed-case VM names. I know it's not very nerdy, but it is better for legibility/quick-recognition. :)
|
|
Devil's advocate - how much will these names matter to end-users? Will they be exposed to them very much, or will workflows just be like "Open the client, plug in a USB on the labeled port. Now, click Export." It seems like a failure of the application if less-technically-inclined users have to maintain a mental model of which VM does what. |
|
Oyy... that is the existential project question, if there ever was one! So, like: the user cannot print or export from the Viewing VM, as an example; they have to do it from the Client app. That's a major/common mental model we're breaking from, right there, for security. Likewise, when users do view things in disposable VMs, they need to be mindful to always shut those down to not crash Qubes via memory issues. When the printer is misbehaving, or when the user needs to interact with a print dialog, that will also need to likely happen in the External VM. Really, I would really prefer to shield them from all this, too. For the Pilot tho, some things gotta just ship rough, to get a better sense of the value everything else is delivering on... if that makes sense. |
For when this does get discussed...Below is my scratchpad list of candidate names, for the print/export VM. My primary concern inasmuch as usability is concerned, is of an English language name too closely approximating either the concept of printing or of saving. The VM meets both needs, and too closely hearkening one or the other may confuse users. Saying
I tend to personally bias toward extremes of esoteric or cute, and Erik tends to personally bias toward extremes of technical or generic... however we both want something that is as clear and as human as possible. Memorable would be nice, but w/o calling attention to itself. Intuitive is not necessarily a goal, as none of this fits existing mental models for most humans. Also, above biases not cited in a negative fashion; just an honest part of problem solving! :) Runner-ups
Definite Nays...
|
|
Another thing to bear in mind is that this will be used by folks for whom English is a second language or not one they speak at all, and that people using the system may not be familiar with terms like "mudroom" - not really a word in common use outside of North America. The VM names will almost certainly not be localized, so terse and technically correct (the @eloquence way) is probably the way to go. (A sticker on the laptop can be in any language so that's not as critical.) |
|
Continuing from Send/Hatch/Transfer/Transport, how about something near Egress/Exit/Outlet? That would make it clear that this is the path out of our secure confines; is short and sensible for a port sticker; and translates pretty well in at least a few languages (salida, sortie, Ausgang/Austritt?). I agree that ideally people wouldn't have to think too much about the VM names, but you've got me wondering how much trouble it would be to translate them. 🙂 |
|
Given that folks will be trained to some extent before being let loose on the workstation, could just make the sticker an arrow pointing at the correct port. |
|
🤦♂️ @zenmonkeykstop, laying the polite smackdown on overengineering. Nice. |
|
Context-fail on my part, my bad... <3 @zenmonkeykstop @rmol you both make completely awesome, astute, and relevant points. None of this (to me, at least) is a "Nina's way vs Erik's way" schtick. It's helpful for me to see the feedback you both shared here, tho, to realize that I totally did not frame the exercise appropriately. SO... stepping-back: what's in a name? Names that resonate are clear and hit the mark, for many reasons—but there are SO MANY words in each language, that it is statistically impossible to attain the most successful names by ideating, evaluating, critiquing, and culling, all in one combined process. Naming as an exercise in product or branding development, is typically broken-down into 7 phases.
The best results come when the full team goes all-in on each step, and does the full exercise as a synchronous or asynchronous guided workshop. @zenmonkeykstop Your shared observations on my Unfortunately I muddled things by presenting a list I brainstormed, with a first-pass at editing... but halfassing both steps, and also halfassing how I presented mine and Erik's rationales. Erik is always going to be the most conservative voice, and I'm always going to be throwing myself up against walls to break them down to be the most generative voice, because our collective efforts are the strongest when we each play those roles as ICs; however both polarities are needed, to come-up with the best solutions. It's not that either of us are incapable of wearing the others' hat, but rather that we're intentionally holding to our domain-expertise's polarities to milk the resulting tension, to find that perfect balance. Likewise, because language is such a fuzzy logic kind of a thing, the results of these exercises are always the strongest, when it's more than 2 people participating. If you read this far, does the above make sense? I mostly plopped everything I did, above, because I didn't want those notes lost in my mountains of notes. But I plopped them here w/o context. I'd love it if we could all maybe contribute to steps 0-3 in a bucketed G-Doc... and then perhaps come together for a group workshop to get to that first-pass solution? |
Notes from discussion with Erik
|
|
So, just following up on this, I would propose the following changes for beta:
These could be handled as separate PRs. |
|
^ "SecureDrop Primary" <—if the user is there to use SecureDrop, how is the client VM not what a majority of users should primarily use? I'm very much not a fan of "client" as it's so jargon-y, and makes me think of beige machines from the 1990s (when it was a more common term). Also, "App Viewer" or "Client Viewer"... users won't use that VM to look at the app in, they'll use it to view sent things within—So the referencing back to the client, feels odd. "SD" implies it's all a part of the SD family, and that feels important to keep in mind, to me. Otherwise, why are we bothering with teh SD prefix at all? |
|
^ Oops... Nina shuts her mouth now, and invites others to the mix—as the Erik/Nina spincycle could go on forrreeeeevvveeeer (which I trust we'd both delight in, tbh, but we also both want this change!). @emkll @redshiftzero @conorsch @creviera @kushaldas @rmol @zenmonkeykstop @ro and everyone else? |
|
I like...
I too never liked "client" but can't think of anything more accurate. The reason I like securedrop is because it's an obvious entry point to managing accounts, downloading and reading messages from the server, writing responses, a place to decide which file to print, export, or open externally, etc. It is an entry point/ main place to manage securedrop submissions, etc. I'll stop myself before suggesting
It's accurate.
I think sd-device-manager indicates that it's a place where devices are attached and can be used. There are a lot of ideas here so maybe a spreadsheet would be helpful. I also think it would be easier to spot our vms if we renamed |
|
Thanks for these great suggestions Allie!
+1 from my end to that rename, seems clear.
+1 from my end.
-1 from my end, this is too focused on the internals of the process and not the purpose of the VM (and could lead a technically interested user to believe that the device manager lives in that VM). I still prefer Let's try to close this conversation by 12/9 EOD. We'll bring it up at standup then and see if we have consensus; if not, @redshiftzero can make a final call. Provided we agree to some renaming, I'll take a stab at the implementation during the current sprint. |
|
and curious about people's preferences on using vs we could also use a different naming scheme for vms that users typically don't interact with, but are still part of the securedrop workstation |
|
I'm concerned that on a VM titled I really like your idea of naming the client vm simply Perhaps: ??? |
|
I think we should consider the naming schema for templates as part of this, now that we've introduced a distribution version identifier ( If we add such an identifier consistently, it may also be worth avoiding the use of |
|
I've put together a spreadsheet for VM naming proposals here: https://docs.google.com/spreadsheets/d/1G1aE6lJD0D6ksIqJuP-8e3iw_1VEzRiUX_zIj41yA8c/edit#gid=0 Some names are easier to change than others. Wherever I put "N/A", the name is defined upstream i.e. not up to us. The rules of engagement for this document are basically: if you care, make a column for yourself, and express your preferences where you do care. Please only add one suggestion for each VM. Pick the name that makes the most sense to you -- or feel free to just copy someone else's suggestion. (If you have many ideas, feel free to add them here as comments -- but still pick the one that makes the most sense to you in the spreadsheet.) We'll see if consensus emerges for or against specific changes; if not, @redshiftzero will make the final call as per standard operating procedure. Even if we agree that a specific change would be a good idea in principle, we may decide not to make the change, if it's too much effort for too little gain. @creviera @ninavizz I've tried to reflect your preferences from comments above, but of course please edit as you see fit. |
We're operating with the following constraints:
Due to these constraints, I see limited utility in using a mixed case convention ( This is why I've opted against mixed-case proposals in my own suggestions added to the above document. |
|
We discussed this briefly at standup today and will check in again over the next couple of days. As a reminder, if you do care about this issue, please weigh in with your suggestion(s) on the spreadsheet, or +1 ones which are already there (by copying them into your column): https://docs.google.com/spreadsheets/d/1G1aE6lJD0D6ksIqJuP-8e3iw_1VEzRiUX_zIj41yA8c/edit#gid=0 Cell comments to explain why you think a specific name makes sense are appreciated :) |
|
not to complicate things, but I vote for (pretty similar to allie):
|
|
@rocodes Not at all - would you mind adding a column for yourself to the spreadsheet? https://docs.google.com/spreadsheets/d/1G1aE6lJD0D6ksIqJuP-8e3iw_1VEzRiUX_zIj41yA8c/edit#gid=0 |
|
Hey gang! I put everyone's ideas together in some mockups, so we can see how all the names work with alphabetization and color options. https://invis.io/CAV9UXNBRTJ#/397881981_Naming_-_Today |
|
wrt the different prefixes—that was proposed to facilitate easier discovery in the App menu, not as a schema to articulate to users as a hard-and-fast rule for them to think about (we should never have to articulate schemas to users, on an aside). I don't feel renames would ever be necessary, if the day arose when |
|
We chatted about this a bit on the phone today -- basically the issue with prefixing some VMs with
For these reasons I don't think we should guess about the use of a I think there's a stronger argument for using
Out of conservatism and because the upside doesn't seem that compelling, I am proposing a smaller, more selective rename operation, as outlined above. |
|
I'm taking these changes through their paces:
The change from
Because the user will launch SecureDrop through an icon on the desktop, I'm not averse to a technically precise but less friendly term like |
|
Those are great points, @eloquence. Off the cuff, I'm guessing |
|
+1 to Conor's assertion that those are great points, Erik. It sounds, then, like the core finding from your explos is that in the context of discussion and documentation, the My only objection to We're tentatively naming the client "SecureDrop Desktop," and especially in user-facing documentation I feel it should only ever be called either that, or "the app." How would y'all feel about |
This name could give the impression that it's an entrypoint to a "desktop for SecureDrop", as opposed to a single app. I see significant potential for confusion, especially if we don't have time to rename all the current instances of "Client" (which we don't for the beta). I would favor |
…> sd-viewer See #285 for background and discussion
… sd-viewer See #285 for background and discussion
… sd-viewer See #285 for background and discussion
|
I'd personally prefer SecureBadger Honey Drop, but agree 100% with your rationale on the Thank you all for indulging my desire to shield our end-users from potentially alienating or confusing IT jargon. |
The file extension for export/print archives is still called `.sd-export`
Excluding svs-disp package name for now
The file extension for export/print archives is still called `.sd-export`
The file extension for export/print archives is still called `.sd-export`
…grams Update data flow diagram with new VM names per #285
… sd-viewer See #285 for background and discussion
The following VM names are potentially problematic:
sd-export-usb: In the UI, we're planning to call export to USB flash drives "Export", and print "Print". If the same VM handles both, it should have a more generic name, likesd-external.sd-svs: Existing SecureDrop users may be familiar with the abbreviation "SVS". However, the "SVS VM" in the SecureDrop Workstation is emphatically not the direct equivalent of the old Secure Viewing Station. For example, export is handled in its own VM (see above), and additional VMs may be added in future. Since this VM is chiefly responsible for running the client,sd-clientmay be a more appropriate name.sd-svs-disp: For similar reasons, we should avoid the term "SVS" here. Simply calling these VMssd-viewor something similar may be preferable. Note that "display" is a more natural expansion of "disp" than "disposable", so the use of "disp" here may also cause confusion and users may start referring to it as the "display VM".Let's kick these suggested alternatives around a bit; I realize these names would have to be updated in a lot of places.
The text was updated successfully, but these errors were encountered: