Tag: UI

Posted on
by

The Twitter-to-Mastodon migration is like going from beta testing the Fediverse to production. Just like a public beta always turns up issues that were missed during development, when going to production you suddenly have a *huge* pool of new users who are going to use the system in ways you didn’t anticipate and haven’t already accustomed themselves to its quirks.

And that turns up a lot more things you need to fix!

Some thoughts on features/user experience for Mastodon and other Fediverse software, based on usage and discussions I’ve seen lately:

1. Missing replies aren’t just an inconvenience, they’re a big problem. Instances really do need to reach out and check for additional replies when someone views a post. I’m not sure how to balance the extra network traffic. Maybe just have a manual “check for more replies” button.

2. Quoting is better than screenshotting. I can read quotes on any size screen. So can screen readers.

3. Lack of quoting hasn’t prevented flame wars or dogpiling, and it there’s no indication it reduced them either. If you don’t want to embed an entire post, at least generate a preview like you would to a website with suitable metadata. And let any third-party clients know they can fetch the message themselves and not hand it off to the web browser.

4. If you really want to keep some friction in the quoting process, don’t add a button, but add the preview/embed on display.

5. Link previews should be generated and displayed during composition, without interrupting typing. Whether the preview gets federated along with the post or re-generated at the destination is another debate.

6. User discovery on third party clients needs work, and autocompletion really needs to be part of the composition UI.

7. Remote interactions on posts that aren’t in the app *really* need work.

8. Basic interactions (profile, follow, like, boost, reply) should Just Work(tm) between different federated software, even if they don’t recognize all the same post types or display them nicely. You can always fall back to displaying a link to the source, like Mastodon does with Article types.

9. Mastodon ought to at least *try* to display Articles as long as the formatting isn’t too complex or the length too long.

10. Mastodon’s “Your admin can read your DMs” notice should make it clear that *most* messaging software has this issue, not just Mastodon.

11. Federated hashtag searching is also more important than the inconvenience I used to think it was.

12. I’ve seen several mentions of the need for local-only posts (which some platforms have) and mutual-followers-only posts, and I totally agree with both.

13. (Added 1/23/23) I want to be able to bookmark profiles, so I can mark people/groups that I want to occasionally interact with, but don’t want to follow all the time – but when I do want to look them up or mention them, I can be sure I got the name right.

Posted on
by

While I’m griping about Instagram, why the heck are the detailed notification preferences split between the app and the system notification UI?

That’s terrible design.

Well, if it’s intended for usability, anyway.

If your goal is to make people see more notifications, though… 🙄

Yeah.

IMO there are two sensible ways to handle granular push notification preferences:

  1. Use the system’s per-app settings for all of it. (Tusky does this, even putting your per-account preferences in the system UI.)
  2. Use the app’s settings for all of it, and let the system just be an on/off toggle for what you’ve chosen in the app (like it was before Android even had UI for it).

Either way, everything’s in the same spot so you know you haven’t missed anything you want to turn off. Or anything you want to turn on, for that matter.

Posted on
by

Interesting idea: The Human Body as Touchscreen Replacement. The downside to using a touchscreen over something with physical controls is that you lose that instant feedback of where the buttons are. (Skip a song on an old-school iPod while driving? Easy. Do the same on a touchscreen? That’s trickier.) Your own location sense plus knowing exactly what part of your hand (or, in another prototype, ear) you’ve touched could really improve usability for applications that are suited for it.

Posted on
by

This is a story on phone menus, though it applies to anything where the user interface can change. I phoned in a refill on a prescription this morning. The phone system lets you choose when you plan on picking it up, presumably so that the pharmacy can prioritize people who are coming in sooner. Generally, it asks you to enter the hour, then #, then 1 for AM or 2 for PM.

I wanted to swing by around noon, so I entered 12, then #, and then without listening for the option, I hit 2. I wanted to pick it up around 12:00 pm.

So I was surprised to hear, “We’re sorry, the pharmacy is not open at midnight.” I flashed back to elementary school, when I was out on the field trying to explain to my friends why noon was 12 PM and not 12 AM as they insisted. Had someone managed to get into a programming position, without clearing that up?

As I re-entered the time, I listened for the options. It turns out that they had anticipated just such confusion, as after I chose 12, the option was, “Please enter 1 for noon, or 2 for midnight.” That works great for people who are using the system for the first time, whether they know noon is PM or not. Unfortunately, for people who have been using it for years and (normally) don’t need to listen to the options, it switches the buttons around. It’s like those WinZip registration dialog boxes that would rearrange the buttons every time, so that you couldn’t just click through, you’d have to pay at least some attention to it.

Of course, then there’s the question of why it even gives you the option for midnight…