Change "private" to "personal" #1377
Comments
|
Reminds me of something related I wanted to suggest earlier: Shall we rename the "Save" button to "Publish", at least when creating a public annotation? Or "Annotate" or "Comment" or anything that sounds less like storing it locally? The latter two options would be suitable both for public and personal annotations, so if we wish not to change the button text those would be my favourites. I'm also wondering if the choice of public/personal should be closer (next) to the "save" button, as all it does is influencing which action that button will trigger. Especially if the button name changes the closeness would make sense. We coud keep in mind any plans for possible future additions, like publishing to a particular group, or into a particular channel. But probably it's better to revise the design again when that time would come. |
|
+1 for everything @Treora just said. I would add that it'd be really sexy if we made personal annotations the default, but have it be "automatic". In other words, it's always saved. We don't warn about losing drafts. We don't lose drafts. Drafts are just personal annotations. Publish is always publishing to a wider audience than yourself. |
|
Love all these suggestions. Personal/private annotations are of course the default now, but yes-- if they were always saved, that would be wonderful. How exactly does something like gdocs work? Background save going on every 5-10 seconds? I think the notion of changing the button to publish when != personal is a great one. |
Ah maybe we did discuss this earlier.. Or did you come up with exactly this same idea as I did? I was thinking a while ago too that we don't need a public/personal selector if we just autosave drafts, so only a publish button will be needed. Later I revoked this idea again, worried that it would not be as obvious to the user: as a user, I would wonder if it is actually stored permanently or just a day or so (for example, GitHub's level of permanency of reply drafts is still unclear to me). Also, does this work out when making multiple private annotations? I think we don't want to retain them as several text area inputs. But rethinking it now, this could actually be done adequately. As soon as (or slightly later) text area input focus is lost, the annotation edit form should turn into a normal personal annotation, which would then look more permanent, but it should be visibly different from a published annotation (something we should do in any case!). As soon as it is clicked, it would be editable again, which should give a very intuitive user interaction, as editing your notes would be as easy as scribbling on paper: no buttons to press, just focus and type. I'm still wondering though if you would want to have a publish button appear every time you edit your personal annotations. We could change the look and make it less prominent, to not feel pressured all the time that you should publish it. |
I'm pretty sure that having a "Save" button someone can click is a nice thing, for exactly the reasons you mention-- even if behind the scenes we're saving it anyway. Annotations that are personal now have a lock icon to distinguish them. We could change the styling, but they are styled now. I think changing Publish makes sense when the mode is changed to public. Really like that. |
I have this feeling to, but started to realise it may be becoming a bit old-fashioned. Instead of a save button, a small symbol showing it has been stored (or is storing), or a gray 'saved' message in a corner seems to become quite common nowadays. I would not mind taking this approach like for example Google Documents does, which has no save button whatsoever. |
|
Notification is great. Ongoing saving is great. I'm philosophically very interested in that being the default, though there are limitations* to have far we can get with the platforms we've got to work with. I can't be certain but suspect that Drive is constantly streaming operational transformations as you type (long live Wave). GMail and other products may be quite a bit simpler about their drafts, as they aren't collaboratively editable. As a first pass, persisting periodically in the background, after blur or after a timeout of no typing, as Gerben describes, is a great way to go. The cost of doing this goes down if you can do it locally. I believe this is omething that Drive does not do at all while GMail does. Frequent, local checkpointing without collaboration is easy because there can be no conflicts. To go down this road, I would want to rethink our storage infrastructure and move toward a model where we partition storage by user/group/consumer and duplicate/transfer to publish rather than manipulating mutable access control lists in a single store. All that aside, we should just change "Private" to "Personal" and maybe "Save" to "Publish" and then open a ticket for the future to add auto-saving drafts. At that point we'll have a conversation about storage. |
|
I'd be interested in the reasons behind this? Have people been confused? We currently don't have any finer grades of privacy than public (anyone can see it) and private (only I can see it). Public/private is an extremely common naming pattern across websites used by Google, Dropbox, Instagram etc to indicate that only you can see something. Changing this to personal doesn't feel like an improvement. When we come to add more sharing levels, we can revisit this but I think there are better solutions. As for the publish -> save change, that gets a 👍 from me. And I'd be interested to look into auto-saving. A note about the save button and auto saving. Generally whenever you have a form it's expected for there to be a save button to submit changes, I've tested forms in the past without them and they always cause confusion. If we want to go down some form of auto save route, we'd need to look at how comments are added to an annotation to make it more of a free text area rather than a form, something like Poetica (https://poetica.com) would work, but might not fit our needs. Google Docs is a good example of this. The main document is constantly saved, but the add comment form has a save button. |
|
Good thoughts, @aron. On a second consideration I'm pretty neutral on "Personal" vs "Private". Combined with iconography I don't see either of these as confusing. Your thoughts about things that are styled like a form having a button are good, too. |
|
Great ideas, all! I'm 👍 on the switch from "Private" to "Personal." Private implies a level of security and safety that Personal (especially in the world of content) does not. Personal content is my stuff written for me. I'm OK delegating storage of personal content. If we've got two +0's and three +1's, then I say we've got our answer. 😄 Also, |
|
So, @aron yes a few folks. (@BigBlueHat most recently). But more importantly I think this is in preparation for there being more than just private vs public. It's the middle ground that has the potential for confusion. Here's a definition of private: "for the use of a single person or group : belonging to one person or group : not public" and "not known by the public or by other people". When the other choice is public, then private seems more "obvious". But when the options include other groups, then how does private relate to them. Certainly something which I share with only one other person is private, right? Is there a word which best captures "only me"? That's what we're after. |
|
"Only Me" is in use as other companies...at least one with millions of user: Certainly stuff on that companies site aren't ever "private." 😁 |
No. In my opinion, in the way we use the web right now, if you share something with anyone then it's no longer private. When we come to look at groups, my personal take would be to approach it from the other direction and change the language to reflect the level at which something has been shared. The Facebook example above is a good one. If we're going to start talking about introducing a third level of privacy where it's not even stored on the web then we're going to have to break this down further because it's going to get a whole lot harder to explain :) Anyway, not against the change, but before it gets merged I'd like to see some ad-hoc user research that proves that it is an improvement on the current naming. |
|
"Only Me" is certainly much clearer. FB probably spent $20k on some user research to figure that out. |
|
👍 I vote we drop the lock icon where it is now, and add the people/group icon with a menu listing (for now): "Public" and "Only Me" Then, once we have Groups in place, we reappraise. 🆒 ❓ |
If this is bothering you that much, then yes, I fully support this suggestion. |
|
Even in the fb example above, the lock is a well-uaed metaphor for "something only i can see". Curious, what's the issue w/ it? |
|
I'll pick my battles more carefully, and vote that we leave it. 😀 Shortish answer: I have a lock icon in my location bar right now (SSL related) and there's one in the sidebar of this page's UI--neither of those relate to what we're talking about. 😕 My guess is no one's found a better visual for "only me" yet. That said, I'd prefer that the "only me" state be made more distinct in the future--so it's clear what is and is not part of a public conversation. But that can be saved for a separate issue. |
|
Relates to #495 |
|
I vote for a tub of ice cream as the new "only me". Or maybe a person on
|
Because?
Uhh-ohh. While I can certainly see the relationship between the wanted
That's more like it. |
|
For discussion:
The term "private" as a term (which I may have originally chosen) for an annotation that only I (as a user) can see is probably misnamed.
"Personal" may be more appropriate. Things may be private between a few people. That's not what we mean here.
The text was updated successfully, but these errors were encountered: