How can I see with whom I shared a post? If it’s not a public post I see only “limited” but no further explanation what aspect I chose.
I think we could definitely add a tooltip (at the moment, in the single-post view, it reads simply ‘Limited’) that lists the aspects such as ‘Limited to: Friends, Family’ or ‘Limited to all aspects’.
That is assuming that this is viable from a technical point of view…
1 Like
That would be great!
This was discussed before somewhere but I’m too lazy to look it up.
The big UX issue with showing the aspects the posts were originally shared with, is that it may be quite misleading as you remove or add people to these aspects. Best case is that one doesn’t actually learn what people can see the post, worst case is that a misconception of being able to edit who can see the post, by editing aspects, forms. Then there’s details on what should happen when you rename an aspect and probably more I’m missing right now.
We could list out all the individual people that can see it, but that’s hard in terms of UI and performance, so nothing we would want to do outside the SVP.
I remember the earlier discussion. The most relevant seems to be #4995 on Github.
I think the potential problems you raise can be solved one way or another. One way would be to make this clear in the help section and tutorials (RTFM and all that). If it really is considered a major problem not to have the information that your aspect scope might have changed since they posted the message, we could add a short warning at the foot of the aspect list tooltip: something like:
Only the people in these aspects when you posted this message will be able to read it.
Only the people in these aspects when you posted this message will be able to read it.We’ll need to find a form that can be translated in few words in most languages.
As to the issue of changing aspect names, if the list is produced ‘live’ rather than fossilised in the meta-data of a post, it should be possible to produce a list of aspects using their current names, which I think would be the most useful thing to do. I don’t know whether or not that is possible, however, because I don’t know how information about scope is stored.
Would those suggestions allay your fears, @jhass?
[duplicate post deleted]
Thanks for digging that up!
Not that we should not document it, but documentation is in no way a replacement for a good UI/UX, ever.
I’m not sure I would describe what I said as fears that need to be alleviated. It’s more pointing out potential pain points in this which should be considered on the decision of implementing this at all and if we decide to do it, things to keep in mind when designing the feature. I really just wanted to point out that this is not as easy as it initially sounds.
1 Like
I read over this chain and the Github chain here. I love the idea of having the sharing level shown. I was going to write a new feature request for it actually, especially since it sounds like a relatively easy thing that a newbie like me could try to implement. The discussions got into a very complicated type of path but I think we could go with a simpler implementation that would work well. From the outside reader’s/commenter’s perspective they would be an icon indicating if the post is “Public”, therefore the whole world can see, or Aspect-constrained, therefore they know it’s a potentially more limited audience but at least one that’s logged into the network. The hover tooltip for them would then just restate the icon data (Public or Aspects-Only). If the post author is viewing the post then the tooltip would show either “Public” or the name of the aspect(s) that they originally shared with.
TL;DR
-New Icon showing Public or Aspects-Limited sharing
-Reader tooltip hover on icon stating “Public” or “Aspect-Limited”
-Author tooltip hover on icon stating “Public” or the name of the aspect(s) it was shared with.
Both these exist already. In a stream, the text ‘Public’ or ‘Limited’ is displayed’ in single-post view, a globe icon (with tooltip ‘Public’) or a padlock icon (with tooltip ‘Limited’) is displayed.
The only change proposed would be that the tooltip on a limited post would display the name(s) of the aspect(s) included when the post’s author views it.
The main argument against implementing this is that it would not give you the list of people who can view a post; and, for an older post, this list might be different from the current membership of the aspect(s) included in the post, because the readership remains the people who were in those aspects when you posted it, and would not include anyone you had added to those aspects since making the post. Displaying a list of aspects could therefore be considered misleading.
Wow that info never caught my eye, but I see it now.
The behavior you describe sounds bizarre to me. So there is no way for someone that I just connected with to see my old posts meant for people in that same aspect? Conversely if I remove someone from an aspect they can still see those old posts limited to it even though I no longer want them to be able to see that content? I’m not going to get into the “it’s a feature not a bug because that’s the way it’s designed to work” but that sounds like unexpected behavior from an end-user perspective, and very bad too…
That is indeed intended behaviour. I can’t get into why now (need something to eat), but there have been previous discussions about it.
Nope.
Correct.
Now, let me explain. The first one would be a little bit of unclear behavior. As a user, I might not be aware that someone suddenly gets access to all previous posts and that might be a really bad outcome, so we simply don’t. This also has a technical background: We deliver limited posts only to pods where they need to be, i.e. only to pods with contacts in your selected aspects. Thus, when adding a new contact, their pod may not even have received the post, and they for sure did not receive the ShareVisibility for that. If we would allow new contacts to see old posts, we would literally have to iterate over all posts, and redeliver them to the new contact.
Kinda the same goes for the second question about removing a contact from an aspect. They already have received the contents, so you already have trusted them with sharing that. They could as well have screenshoted all your posts without you knowing, so hiding them would give a false sense of control here.
Once again, my beloved comparison of diaspora* with eMails still holds up. If you add a new address to a mailing list, they do not suddenly receive all the old emails. Likewise, if you remove them, the old emails already delivered to them will not magically disappear from their inboxes.
2 Likes
I understand your comparison to e-mail but this isn’t how any other social media or content sharing system works. That’s not just Facebook/Twitter/Google+. That’d be stuff like forums, blogs, file sharing systems like DropBox, Google Drive/LibreOffice Collabora, S3/Swift, file systems, etc. I get this whole “it’s not a bug it’s a feature” thing, I’ve used it myself on software I’ve worked on. I understand how the system got to where it is based on your description. This “feature” however is very much the opposite of expected behavior on almost any system besides e-mail, several of which I mentioned above. Because of that I still hold that this “feature” is not a good thing.
Thank goodness for that! It’s the better for not being like those ‘services’, in my opinion.
Which is why I then went on to list half a dozen other systems… Is there a more appropriate place for this discussion rather than the support forum? I think there really needs to be some open discussions about this feature/bug?
I don’t. There is this, and this, and this. Ultimately, the current behavior is documented, our users use diaspora* exactly that way and the large majority of users are fine with it.
Funny enough, none of them is federated. Do you want to un-send an email? Or un-send a text message? Un-send an XMPP message?
As @goob pointed out, you cannot compare federated systems with centralized systems for multiple reasons, and you shouldn’t even try. There is no permission system where you could toggle visibilities for some of your contacts as you wish at any time, and there never will be, as it is literally impossible to build that in a federated system.
I’ve explained that before, but I’ll happily do it again: diaspora* gives you the tools to decide with whom you want to share your contents. Once you click the share button, that’s it. You sent the email, you stamped the postcards and you threw your envelopes into the mailbox. Now, you could ask your recipients to kindly forget that you sent them that vacation postcard earlier, but let’s be honest, that’s not going to work out well.
Building a feature that somehow removes posts from other persons streams just because you decide you no longer want to share with them is asking them to forget you sent them the postcard, nothing more. There is no way to guarantee that the post is gone everywhere, and we most certainly don’t want to act this way. diaspora* is about giving users control about their stuff where we can, not acting like they have more control than they actually have. I hate to even think about suggesting more control than there really is.
Once you shared a piece of information with someone, you have shared that information with someone, and unless you’re part of the Men in Black, there is no unsharing of information.
And as for the other part of your suggestion; giving new contacts access to older posts: also no. Most of our users would not expect diaspora* to behave that way, and it’s clear by looking at current usage patterns. Ignoring that, even if we would decide to implement something like this, once again, we would have to re-deliver all past posts, which by itself is a really horrible idea. The amount of posts we’d have to federate is potentially infinite. The only possible way to sanely implement something like that would be to limit the amount of re-federated items, but that would make everything unpredictable for users.
You are, obviously, free to open a new thread under the #features-and-ideas or #federation section, as I’m not going to tell you otherwise. Rest assured, I will comment the exact same response, and I know that I am not the only one with this opinion.
1 Like
None of what you wrote takes into account every day end user expectations. “It’s documented” or “it’s because of this back end infrastructure blah blah” is not relevant to that sort of discussion. The average user doesn’t care about federate or not federated. They care about the user experience. It’s like when I explain to people the eventual consistency problems in these large distributed system. It may be technically correct but users don’t like inconsistent behaviors and only tolerate it to a certain point, which is what is shot for in terms of the time of consistency when building architectures like that.
You say most users are fine with it. Are they or do they just tolerate it? I’m sure I’ll keep using Diaspora but I’m absolutely not fine with it.
Apologies; I misread your comment. I thought you were saying Diaspora’s behaviour is unlike that of FB, Twitter of G+ but is like the other services. I didn’t read it carefully enough.
Just one thing to add to Dennis’s last comment: Diaspora does give users the power to remove content from the streams of people they no longer want to share with, by deleting a post or comment. That will remove it from the view of remote accounts. So there is a ‘remove content’ facility unavailable to the sender of an email or postcard. If you are determined that content should no longer be available to someone who was in the scope of that post, you can delete the post, remove them from the aspect and post it again. That may seem drastic, but keeping things this way at least makes clear and unambiguous what will and will not happen with your data.
One other oddity that would happen if you could retroactively block someone from seeing a limited post: they might have commented on the post, and they would no longer be able to view their comment, nor to delete their comment if they no longer wished it there. So allowing you to block them would remove their control over their data on affected posts.
@HankG, if you can come up with a workable solution that would bring the benefits without the drawbacks mentioned, by all means propose it. But unless it avoids all the drawbacks mentioned here or on any of the threads linked by Dennis, it is very unlikely to be adopted.
Diaspora does give users the power to remove content from the streams of people they no longer want to share with, by deleting a post or comment. That will remove it from the view of remote accounts. So there is a ‘remove content’ facility unavailable to the sender of an email or postcard. If you are determined that content should no longer be available to someone who was in the scope of that post, you can delete the post, remove them from the aspect and post it again.
I guess that’s one way to do it but after a while that would be a lot of deleting content and re-adding just to add or remove one person from seeing it.
One other oddity that would happen if you could retroactively block someone from seeing a limited post: they might have commented on the post, and they would no longer be able to view their comment, nor to delete their comment if they no longer wished it there. So allowing you to block them would remove their control over their data on affected posts.
The way other systems do it those comments are deleted (or at least not visible by anyone anymore).
@HankG, if you can come up with a workable solution that would bring the benefits without the drawbacks mentioned, by all means propose it. But unless it avoids all the drawbacks mentioned here or on any of the threads linked by Dennis, it is very unlikely to be adopted.
I’d be more than happy to bat around ideas of designs if that something wants to do here. If I’m the lone voice here that wants to explore this change, and a brand new one at that, what’s the point of me wasting a single neuron on that at this time?
There’s something interesting to be said about user expectations, I think. First I’ll say that I don’t agree that Dennis’s position on this does not take account of user expectations; rather, it does not take account only of user expectations but also of other important considerations. It’s the same, necessarily, for my position; after all, I am first and foremost an end user of Diaspora.
Anyway, on to user expectations. They should certainly be considered when designing a service, but I don’t believe it’s healthy to design only for them; neither for the service nor indeed for its users. I wish and push for Diaspora to consider first and foremost what is best for its users, as individuals and as a community. This might or might not meet the expectations of users.
Let’s also remember that not all users have the same expectations. You seem to be considering Facebook users in the main (and perhaps G+ users; as all content bar DMs in Twitter is public, that service doesn’t seem to apply here). The expectations of Facebook users are as they are surely because Facebook has conditioned them to have expectations. Go back 11 years, before Facebook became a mainstream communications medium, and people surely did not expect to be able to give the (private) contact details of people they knew to a third party in order for that third party to connect them in a new way. Nor would they expect nor be encouraged to show private conversations to a wider audience. If you’d asked most people about either of those, they would surely have said that both were bad, and that before taking such a step they would at least have asked the people affected if they were happy for this to be done.
However, Facebook has encouraged people to act in this very solipsistic way, with no consideration for other people. And that can be the expectation of those who have been using that platform for a long time. Should Diaspora therefore copy Facebook’s approach in order to attract people from that platform? In my view, no. Diaspora’s mission is not, in the first place, to take people from Facebook, but to try to build a better kind of social experience for everyone who wants that.
You’re not fine with the inability to change the scope of private content after posting. I’m absolutely not fine with the ability to do so in Facebook, and the behaviour that has engendered. If I post something ‘privately’ in Facebook, I now have to add requests to my friends not to share it more widely, because some of them have become so used to doing so that they no longer think of the implications. Another example: let’s say my friend Alice, who I know has a group of 20 people, whom I also know, to which she posts certain content. I comment on this private post, shared only with this group of 20 people. Someone else then @mentions a person in this group who has several hundred contacts, most of whom I don’t know. This person’s several hundred contacts can now view the content, including my comment. I am absolutely not fine with that, and I’m glad that Diaspora doesn’t allow such behaviour.
Another thing that comes up previously, and has again with the recent influx from Facebook, is the complaint that you can’t upload your contact list in bulk and have Diaspora tell you who is registered here. Well, good! This is another case where people have been conditioned to something that may be convenient but actually has pretty negative implications. There are implications for the security of the data of other people – should someone really be able to pass on the personal data of others to a third party in such a way, and without their knowledge? There are also implications for human interaction. If I want to find out who of the people I know is using Diaspora, or to invite people I know who don’t use it to join, which is better? To bulk upload their details to this platform with which they might never have had any interaction and with which they might not want ever to have any interaction; or to write to them to tell them that I am using Diaspora, and to give them my account details, and to say I’d love them to connect with me there? In my view, the latter.
You may not agree with my views, but I hope you’ll agree that user expectations – in particularly, the expectations only of a subset of users or potential users – should be only one consideration when designing a service such as Diaspora.
(This is too long for me to re-read and check/edit, so I hope it all makes sense.)
3 Likes