Impressions and ideas from a new user

I’ve been using Diaspora fairly heavily since shortly after G+ announced it’s impending departure, and for the most part I’m really happy with it. These are my thoughts and suggestions, and I appreciate any feedback. I also now that I haven’t done any programming since 2003, so I am absolutely not up to speed on things, and may not be technically correct in everything. I’m approaching this from a UX standpoint, not a programmer’s eye. Also note that my job and lifestyle mean I predominantly access the Internet from mobile devices, only rarely using a desktop, and that likely influences my impressions - but amongst non-programmers, this is becoming the norm. Many people predominantly use phones and tablets, and reserve computers for only the tasks that require them.

I’m organizing this like the classic film, The Good, The Bad, and The Ugly. The last category isn’t about the software at all, but rather about the overall experience of a new user (and, coincidentally, where I could help with wiki’s or similar, if I better understood how things were intended to work). As I’m making suggestions, the Bad and The Ugly are more verbose than The Good - please don’t think that means I believe the system is Bad or Ugly, just that I’m focusing on areas to improve rather than what’s already good.

The Good

  • Let me start by saying that Diaspora is a great social network, and I want to thank everyone who’s contributed. Having been a G+ user from its inception, it’s great to see such a small group put together something of similar quality.

  • The ability to follow tags is a great addition over G+ or Facebook functionality. I can see interesting posts about things I care about, even if I don’t follow the users making them. This is a wonderful feature!

  • The website runs smoothly on every platform. It’s quick and feels great. Too many websites feel laggy or slow, especially on mobile.

  • Reliability. Since joining, I’ve seen one pod go down for almost a day, but the network remained stable. I’ve never been unable to access it. I’ve never seen an error message, or had an action flake out on me. I often get error messages across the web - even Google searches sometimes just say “Something went wrong” with a sad robot, but not here. I’m impressed!

The Bad

  • The lack of a true native app means no Android or iOS notifications, which is a major drawback. This isn’t an easy fix, and I understand that, so I’m not expecting change here, but there should be recognition that it’s one of the biggest downsides to Diaspora for a mobile user.

  • There are two versions of the website that can be accessed via mobile, “desktop” and “mobile”. Confusingly, the desktop version changes when viewed on a smaller screen, so it appears different than when viewed on a desktop. There is no clear indicator for a new user which is which, and switching requires pressing a button labeled “Toggle Mobile” but doesn’t tell you which mode you’re in. Yes, eventually I figured it out, but it’s not intuitive. Furthermore, the mobile version lacks much functionality - users cannot mention, vote in polls, block users, ignore posts, preview posts, etc. The desktop version seems to work flawlessly, but as I understand it some people find the text links too small, and others don’t like that it downloads full size images. I would recommend that the fully functioning version be default for new users. I also recommend changing the Toggle Mobile link to be more clear - I suggest that it read “Switch to Full Site” and “Switch to Light Site” or similar, making it clear what happens when you touch it. Calling the full version “desktop” is confusing, because it does not look the same as what is seen on a desktop, even if the underlying code is the same. Every new user I’ve talked to has struggled with this. Remember, for many users, the mobile version is the first experience they have with Diaspora, and providing them with such limited functionality creates a poor first impression.

  • Notifications are often repeated as unread hours after I’ve marked them read. I’m guessing this is a federation issue.

  • Diaspora needs block functionality. Right now ignore appears to prevent new posts from showing in your stream, and (I think) prevent notifications if the ignored person comments on something you’re subscribed to. If a person is really offensive, you should have the ability to see absolutely nothing from them (or ideally) “comment hidden” that can be clicked to view it). Users shouldn’t be shown comments from blocked users on other people’s posts - this will really become a very serious problem if trolls start using the network.

  • G+'s greatest feature was its Collections, and adding similar functionality to Diaspora would set it apart from other social networks. Basically, similar to tagging, posts would be included in various Collections each user made. You could subscribe to some or all of another user’s Collections. For example, I could choose to see all of Bob’s posts about mountain photography, but not see any of Bob’s posts about the Denver Broncos. There are many different ways I can imagine this being achieved, and I’m not suggesting that Google’s solution is the best one, but being able to selectively subscribe to some topics from a given user is an amazing feature missing from Diaspora. Of these suggestions, this is also the most difficult to implement. Aspects lets you choose how much to share with a user, but nothing allows you to choose how much of a user’s content you see.

The Ugly

  • A new user doesn’t know what a pod is or whether it matters. I’ve seen wiki pages that attempt to explain it, but none have done a good job from a non-technical standpoint. Frankly, even after weeks of asking questions, I’m still a little confused. It’s clear that users can follow other users on other pods, but I’m not certain how public posts, searches, and tags work across pods.

  • The same problem exists for the Federation (apologize if I’m using terms incorrectly). I understand there are other networks like Mastodon which interlink with Diaspora. I’ve been told that which pod you are on makes a difference in whether these tools interact, but none of it makes sense to me. Mastadon is, as I understand it, a Twitter-like service with short messages. How would a Mastadon user see the long-form posts from a Diaspora user? If all these networks work together, why does it matter which I’m on? Are they truly interconnected, or just cross-posting?

  • When I created an account on Discourse, a DiscoBot walked me through much of the functionality of the site. Meanwhile, I can’t find a good tutorial for Diaspora anywhere. Guides that I’ve seen appear geared more towards programmers and tech-savvy power users, and not towards ordinary people. Overall, this adds to the general impression (along with the poor mobile experience by default) that ordinary users are not welcome here. There are good guides for Markdown, but not the site itself.

  • Perhaps the most difficult problem for Diaspora to fix is the identity crisis it has. The wiki’s I’ve seen brag about its privacy model, and aspects do a good job of keeping information private. However, keeping information private makes it hard for new users to find and connect to people. Fortunately, Diaspora also has the public post model, using tags to make it easy to be seen. I have no problem with both features being in the same network, that’s a good thing. But new users need to be walked through explanations of these two models so they can make informed choices about how they should be using Diaspora. Instead, they’re told how great the privacy is, and that they should tag posts, with no real discussion helping them make choices.

I’m hoping this doesn’t come off as too negative - I really do like this system so far. But I think that it’s important to hear and understand the experiences of new users, rather than just long time users. Things that are obvious to a long time user might be incomprehensible to someone just arriving without the same background and experiences.

4 Likes

Seems accurate to me.

1 Like

The mobile app for Android is called Dandelion and is available from the F-Droid repository. I installed F-Droid from the Google Play Store, but I understand they’ve removed F-Droid. You can still get it elsewhere though.

Dandelion is useful for sharing from other apps, but it’s really just a wrapper around a web browser. And because it’s locked into the mobile mode (which, you’ll note, I strongly recommend new users not be given by default), a large amount of functionality is missing. I’ve created a Chrome webapp that’s much better, except for the ability to share from other apps.

Regarding g+ collections. There is already a request for an advanced search allowing combinations of users, tags, etc. which would cover this. For example

fred@duaso.org & #java

Would give all Fred’s post on java or even

(fred@diasp.org | jim@pluspora.com) && ! #countyCricket

Would give me everything from Fred and Jim except their posts on county cricket

(I think the syntax is TBD)

@Chris108 Assuming that could be subscribed to and merged into your stream like tags, that would be awesome! As I said, it doesn’t matter which solution is used, it’s more important to give users the power to control what they see. Thanks for the reply!

It appears to be a combination of

And

Hi @LordHedgie and thank you very much for taking time to provide feedback like this.
Your post is huge and I’m currently focused on writing code that’s why I toke me a long time to reply, and I’m not even going to answer to all points yet, but I wanted to reply to you.

So, here we go for “the bad” part:

The lack of a true native app means no Android or iOS notifications, which is a major drawback. This isn’t an easy fix, and I understand that, so I’m not expecting change here, but there should be recognition that it’s one of the biggest downsides to Diaspora for a mobile user.

Notifications is something which is part of the web for a while now, we don’t need a native app for this. It was added to the desktop (I agree it could be renamed “Full”) version since diaspora* 0.6.2.0 released the 14th December 2016 (see this pull request). At that time, the polling time was set to 5 minutes, to avoid an important load to the servers. Diaspora* should have asked you the first time you opened the desktop version if you accept notifications, and should send you an android notification when you have a new diaspora* notification that happened less than 5 minutes ago as long as you have the tab open in your browser. If that’s not the case, it means either you initially refused notifications (please change the setting in your browser) or there is a bug, in which case we need to investigate together.

This feature has to be improved, first of all to be added to the mobile version, where it is needed the most, and to allow podmins to set the polling time they want. I set mine to 30 seconds as I have a big server for a few users, and it works well.

There are two versions of the website that can be accessed via mobile, “desktop” and “mobile”. Confusingly, the desktop version changes when viewed on a smaller screen, so it appears different than when viewed on a desktop. There is no clear indicator for a new user which is which, and switching requires pressing a button labeled “Toggle Mobile” but doesn’t tell you which mode you’re in. Yes, eventually I figured it out, but it’s not intuitive. Furthermore, the mobile version lacks much functionality - users cannot mention, vote in polls, block users, ignore posts, preview posts, etc. The desktop version seems to work flawlessly, but as I understand it some people find the text links too small, and others don’t like that it downloads full size images. I would recommend that the fully functioning version be default for new users. I also recommend changing the Toggle Mobile link to be more clear - I suggest that it read “Switch to Full Site” and “Switch to Light Site” or similar, making it clear what happens when you touch it. Calling the full version “desktop” is confusing, because it does not look the same as what is seen on a desktop, even if the underlying code is the same. Every new user I’ve talked to has struggled with this. Remember, for many users, the mobile version is the first experience they have with Diaspora, and providing them with such limited functionality creates a poor first impression.

The situation is like this because you arrived during a pivotal period for diaspora* front-end. It is only temporary and is a work in progress. Diaspora* had distinct desktop (working only on big screens) and mobile (the one you currently have) versions. To maintain two versions is more work, so we want to switch to a unique, responsive, front-end. However, with our limited resources, this takes time. So instead of not delivering anything for months, we started building the responsive version and shipping it part by part. So you now have a desktop version mostly responsive, but the work is not over (links are too small, for example), and a mobile version which is still available because it is way lighter especially looking at bandwidth usage. As the two versions are supposed to merge, the more the work progresses, the harder they are to distinct. But your suggestion to rename the “toggle mobile” link is a good one. If others agree, I’ll do that change, waiting for the mobile version to totally disappear.

Notifications are often repeated as unread hours after I’ve marked them read. I’m guessing this is a federation issue.

This was a configuration problem of pluspora and has been fixed by your awesome podmin David with the help of the diaspora* community

Diaspora needs block functionality. Right now ignore appears to prevent new posts from showing in your stream, and (I think) prevent notifications if the ignored person comments on something you’re subscribed to. If a person is really offensive, you should have the ability to see absolutely nothing from them (or ideally) “comment hidden” that can be clicked to view it). Users shouldn’t be shown comments from blocked users on other people’s posts - this will really become a very serious problem if trolls start using the network.

There are many topics open about this (ignore comments, ignore reshare, and already kind of a duplicate) so I will not answer in details here. But since the coming of the G+ users, I think this is the worry which was the most pointed, even if each time someone ask about this worrying to be harass, it never happened to him/her at the moment. It makes me wonder how G+ atmosphere was. Why everybody coming from that network is worrying about being harassed and ask for the tools to defend without even be faced by it? In the worst case, when someone is being abusive, ask your podmin who will warn, temporary ban, or full ban the problematic user. diaspora* is used by thousands of users for height years, we even dealt with terrorism from ISIS, and we successfully survived. Do not worry, people :wink:

G+'s greatest feature was its Collections, and adding similar functionality to Diaspora would set it apart from other social networks. Basically, similar to tagging, posts would be included in various Collections each user made. You could subscribe to some or all of another user’s Collections. For example, I could choose to see all of Bob’s posts about mountain photography, but not see any of Bob’s posts about the Denver Broncos. There are many different ways I can imagine this being achieved, and I’m not suggesting that Google’s solution is the best one, but being able to selectively subscribe to some topics from a given user is an amazing feature missing from Diaspora. Of these suggestions, this is also the most difficult to implement. Aspects lets you choose how much to share with a user, but nothing allows you to choose how much of a user’s content you see.

This is something I have in mind for years and deeply think it is the most missing feature in diaspora*. Basically, custom streams, with “boolean expressions”: I want all posts with #diaspora but not #diaspora-dev from userX or userY but not userZ. Those are advanced searches, and we could create custom streams by pinning those searches. We really need to help users see the content they want to see, and they will choose it, as we don’t want to go the Twitter or Facebook way of automatically hiding / showing based on obscure algorithms. So to sum up: we want to build that, but it’s a difficult problem from both the UX and the technical point of view. I’ll work on the UX point.

A new user doesn’t know what a pod is or whether it matters. I’ve seen wiki pages that attempt to explain it, but none have done a good job from a non-technical standpoint. Frankly, even after weeks of asking questions, I’m still a little confused. It’s clear that users can follow other users on other pods, but I’m not certain how public posts, searches, and tags work across pods.

If you’re curious about how the federation technically works, there are resources about that. But this is not something a “normal” user has to know. The introduction to diaspora* containing the essentials is the tutorials on the official website. If you feel like something is missing there please tell us. You can open an issue on github.

The same problem exists for the Federation (apologize if I’m using terms incorrectly). I understand there are other networks like Mastodon which interlink with Diaspora. I’ve been told that which pod you are on makes a difference in whether these tools interact, but none of it makes sense to me. Mastadon is, as I understand it, a Twitter-like service with short messages. How would a Mastadon user see the long-form posts from a Diaspora user? If all these networks work together, why does it matter which I’m on? Are they truly interconnected, or just cross-posting?

Mastodon is not a good example as it does not federate with diaspora*. The projects who “speaks” the diaspora* federation protocol are Friendica, Hubzilla, Social Home and Ganggo. That means that users of these project are seen inside diaspora* exactly like if it was another diaspora* pod. Inside diaspora*, it’s not even possible to know if the users you are talking to is using diaspora* or one of those project (you could guess by looking at their pod name but it’s not a proof).

Different, diaspora* is able, when you publish a message, to cross-post it to other services like Twitter, Tumblr, Wordpress and previously Facebook (but they recently removed their API allowing to do so).

If you have suggestions about wording improvements to make the difference between both clearer please tell us but here again, to know how the federation work and that there is other projects than diaspora* pods you are talking to is not essential to use diaspora*.

When I created an account on Discourse, a DiscoBot walked me through much of the functionality of the site. Meanwhile, I can’t find a good tutorial for Diaspora anywhere. Guides that I’ve seen appear geared more towards programmers and tech-savvy power users, and not towards ordinary people. Overall, this adds to the general impression (along with the poor mobile experience by default) that ordinary users are not welcome here. There are good guides for Markdown, but not the site itself.

As said, Tutorials - The diaspora* Project. This link should maybe be added to the /getting-started page. I agree the very first log in experience should be improved. Damn, so many things to work on :stuck_out_tongue:

Perhaps the most difficult problem for Diaspora to fix is the identity crisis it has. The wiki’s I’ve seen brag about its privacy model, and aspects do a good job of keeping information private. However, keeping information private makes it hard for new users to find and connect to people. Fortunately, Diaspora also has the public post model, using tags to make it easy to be seen. I have no problem with both features being in the same network, that’s a good thing. But new users need to be walked through explanations of these two models so they can make informed choices about how they should be using Diaspora. Instead, they’re told how great the privacy is, and that they should tag posts, with no real discussion helping them make choices.

Tags work for limited posts, I don’t see why it should be either “tags” or “privacy”. I post my holidays picture only to a few aspects, they all are tagged #summer2018 and me and my friends can find them easily. At the moment (as said above) it is not possible to filter to say “all posts by @Fla containing #summer2018” so we need to go the hacky way by setting more specific hashtags like #fla2018vacations but I’m confident we will solve this problem in the future :wink:

@flaburgan Those tutorials see really helpful. I may have been wrong, then, in assuming this is a documentation issue, when it may be more of an issue of getting new users to the information. Adding more links to the getting started page could help, or a bot sending a message to new accounts… The method is less important than getting users to the tutorials. Thanks for the explanations, that does help me understand better.

1 Like

I personally have had no issues learning how to use this software; however, I also have a highly technical mind with over a decade of experience. This is something I can’t say for non-tech savvy people. Ease of use is insanely and extremely important.

There are a few things that could be moved around to make things easier to get to and less confusing (I’m talking to you mr. chat functions in the aspects settings when they should be in the chat menu instead :wink: ).

With that said, I think flaburgan did an excellent job at explaining and answering most of your questions and issues.

For the record, I do believe there’s a ‘newbie-tutorial’ available the minute a new user signs up, and if they want to go through it again, they actually can by going here: https://diasporaserveraddress/user/edit and checking the box that says Show "getting started" hints.

All in all I myself am quite happy with Diaspora* and where it’s gone. I can’t help but applaud the dev team for their hard work. :slight_smile: :heart:

1 Like

@LordHedgie for the record, I just opened a pull request which renames “Toggle mobile” to “Switch to full version” or “Switch to light version” depending of the version we’re on. Which wording is the best, “version”, or “mode”?

I also opened an issue about adding the tutorials on the getting started page. I’ll take care of that soon.

@flaburgan Awesome, thanks! That will really help new users!

I don’t think there much difference between version or mode… I would suggest mode, because it’s unlikely but people that someone might think different versions are separate sites, or perhaps forks, but mode is less ambiguous. But I think virtually everyone would consider them the same.

@LordHedgie we’re still debating the wording, can you please give your point of view? Either in github or here once you read the github discussion.

I agree there are two separate issues:
(1) Making it clear which mode you’re currently in, and
(2) What to name the versions

It sounds like the first problem is licked - and solving that one is clearly the bigger problem. If users know which version they’re in, they can try each version. It took me a few days of usage to be able to tell which version I was using at any given time, although some of that might have been from accessing via different devices and browsers, trying to find the best experience.

As far as naming, I’m against calling the mobile version “mobile”. I have read the arguments that the responsive version isn’t 100% functional, but I simply disagree. Yes, hover functionality doesn’t work, but hover isn’t required for any basic functionality. The responsive version can be used to do everything. The mobile version, on the other hand, is missing a significant portion of functionality, and there are no workarounds other than switching to the responsive version. I see the mobile version as useful for someone who wants to quickly check their stream, but that’s about it. There’s no comparison between losing the ability to hover vs. losing the ability to mention, preview, respond to polls, etc.

Ultimately, if I were in charge (and I’m not), I would rename the mobile version to “limited” (but lightweight would also be acceptable). I saw the comment that objected to that term as implying that the version is less functional, and my response is “yes”. It is less functional. New users should be told when they’re accessing a less functional version of the website, or they won’t realize the limitations they see are only limitations of the version they’re accessing. Calling it mobile implies that it’s the best version for mobile, and at best that’s a highly debatable point, and at worst it’s just false.

Another compromise might be “low bandwidth version”, although that’s long and may not fit. The key thing in my mind is a name that conveys that there is a trade-off by choosing that version. Nobody expects a mobile version of a site in 2018 to be missing key functionality, whereas a lightweight, limited, or low-bandwidth site is clearly trading data size for functionality.