Potential UX improvements
With the growing success of our product, and since we use Talkyard for (almost) all customer support, I find myself spending more and more time on the forum.
Often, my task will be:
- Check my new/unread notifications.
- Open tabs for each new notification. It can be anywhere from a few to 30+ notifications since I was last logged on. This number is only going up with every week.
- Answer on each thread and sub-thread.
- Delete drafts.
- Do other housekeeping (manually click on notifications for threads I already saw and/or replied to).
- Manually double check for old threads that aren't yet marked as resolved, since I could have missed something.
There are a host of smaller annoyances with how this workflow is today, that weren't super important to fix in the past, but as I spend more and more time in here, the annoyances become more important because the time I have to spend / focus I lose, adds up.
I've tried to gather a bit of the feedback into this one post. Let me know if we should split these up into individual topics.
All of this is about trying to improve the forum so it doesn't require so much interaction from us on stuff that it could/should handle more fluidly.
Please view this as suggestions coming from a user who spends a LOT of time every single day with your product :)
Popup hints, suggestions seem to not remember being dismissed
Would it be possible to shift this from using cookies (or whatever browser storage method is used today) to something that gets saved on the server so that it remembers that I've already "accepted" the hints.
And/or, would it be possible to move more of them to a less "click needed" approach? Hints system generally is great, but it could save a lot of time if hints didn't randomly reappear.
We use the forum from many different devices so having a solution that works across this seems important.
Notification system doesn't update in realtime
This is a small annoyance but does add up a little bit. I'll get a notification on my phone instantly via the email system, but to see the notification in the forum I'll have to refresh the page. I'm pretty sure this also creates a draft if I was busy typing something, which further makes me have to click more times.
Multiple notifications for the same thread requires me to manually click on all of them
The notifications aren't grouped together like they are on for example Facebook. This means that if 3 users have all answered in the same thread, and perhaps multiple times, I have a lot of "noise" in my notifications. It was more manageable in the past when I didn't have to handle as much traffic, but now I find myself having to just click "Mark all as read" but this sort of defeats the value of even having the notifications since I then more easily lose track.
It would be great if responses to the same thread would be grouped together, or at the least that clicking on one of them would mark all of them as unread. But preferably they would be grouped so there would be less "noise" and the system would scale better with more notifications.
Notifications view doesn't allow for inline/infinite scrolling
If there are more (unread) notifications than I can view in the popup, I cannot just scroll inline to get to the next page, I am forced to open a separate page for all the notifications.
It would be great to have a system that mimics more how Facebook handles this.
If you view content via the notifications PAGE instead of the notifications popup, the "read" state doesn't update in both places
It feels like two different methods are used for computing if I've read the thread or not. If I have too many notifications for the popup, I'm forced to open the notifications page, but then when I'm done in that page, when I click back to the popup, I have to manually mark the notifications as read again.
You can't cmd+click several notifications to open up in new tabs
... because the notification popup immediately closes after I clicked the first time, so it doubles the clicks needed.
It would be helpful for the workflow in which you've received 25 new notifications to be able to click each of them to open a separate tab. You'll now have a clean notification list and each tab will include the threads you need to respond to, so after you're done with each you can close the tab. Job done.
Review system flags content from existing users
Sometimes the review system flags content for review even though it's been created by long time users. This also requires us to spend more time clicking when it shouldn't be necessary.
Draft UI interferes with reading content
We've talked about this elsewhere, but including it here to have an overview.
Right now it isn't an improvement with the draft UI interleaved. It interrupts reading the normal flow of the thread. I don't know if the changes that should fix this has been pushed or not, but I'm still finding myself having to click a LOT all the time (including clicking twice for each draft), and the percentage split of when I actually need to edit a draft that way is about 1% of the time. So it's just incredibly annoying, time consuming and focus stealing right now.
Generally, UX changes that are only half-done means we have to spend time with reporting feedback when we are busy with other things
It would be super helpful if there could be a more well-tested/documented approach for TY to introduce changes to the UX/UI and that all of those changes initially are opt-in instead of opt-out. The current method doesn't feel finalized and it means we have to be constantly on guard for changes that affect users and our own daily workflows. Because we can't opt in to the changes when we're ready, it means the changes often take focus away from the important and time critical things we're doing elsewhere.
TBH it often feels like the production forum is being used for public beta testing - but we are using the forum in a production environment, so it's increasingly needed for a better approach to this.
It's great to have quick development and an easy path for testing, but we would prefer to have a more stable environment for the forum going forward. We still would like to be able to opt in to experiments and new features from time to time, but the keyword is opt-in - so that we can schedule it to fit more with when we have time and resources to make sure that it doesn't break things.
Forum posts don't auto-update
This is perhaps more of a feature-request than any of the other ones.
Once I've started to do the workflow outlined in the first paragraphs often while I'm still in the process of answering more posts, some of the users whom I replied to in the first few posts will start commenting back. Sometimes this is a mess of back and forth between all the tabs etc as people start replying and the pace increases.
It would be absolutely amazing if the tabs themselves would auto-update with the new information and call my attention to those tabs (much like it works with Facebook today).
Edit / comment
All of this are suggestions. While they're not critical to fix, fixing them in the suggested ways or in different ways, would definitely make my life easier. Remember all this is just because we love the forum so much that we use it for everything :)
Linked from:
- CIn reply tochrscheuer⬆:Christian Scheuer @chrscheuer
Wrt notifications. I feel like I'm also seeing that notifications I clicked on in the past tend to not necessarily keep being "read". I wonder if this is due to using different browsers on different machines, or what actually is happening.
But it definitely is weird to have to often click back on things that I've obviously already read, since I've already also answered it.
This also seems related to the draft bugs (which continue to be there, I'm not sure if the update has been pushed or not). It's like TY needs more solid logic on when something has been read.
KajMagnus @KajMagnus2020-02-29 07:21:15.779Znotifications I clicked on in the past tend to not necessarily keep being "read"
Currently this happens if one has different tabs open: the other browser tabs, won't update, when one reads a notification in one tab. — Maybe there're other things going on too, though.
I think the first step in fixing this, could be to use the service worker somehow, so all tabs will have the same view of what's been read or not. E.g. have it message all tabs, once something has been read.
The drafts fixes weren't included in the last release. I didn't have time to code review yet.
B.t.w. Command-Click:ing a notification in one's username dropdown, should work now, would you like to try? (I don't have a Mac.) That is, Command-Click opens the notification in a new tab, and the dropdown stays open so you can continue clicking.
- CChristian Scheuer @chrscheuer
Yes Cmd+Click works - it's such an improvement already - thank you :)
Maybe there're other things going on too, though.
There are other things going on too, but we can take them one at a time if you prefer.I would consider long term a real-time websocket stream of events from the server. This would also mean you don't have to hit F5 to get new notifications.
Like a generalized event system from server to clients, probably powered by redis or message queue on top of your postgres backend.
as an optimization to this you could then have clients that share a service worker also share that connection.- KajMagnus @KajMagnus2020-03-25 15:29:13.992Z
I've looked into WebSockets and Server Sent Events, right now I'm leaning towards Server Sent Events:
- From what I've read, some (rare?) enterprise firewalls with packet inspection break WebSockets.
- SSE gets multiplexed over HTTP/2 — no extra connection needed. Whilst WS needs a 2nd connection.
- SSE automatically reconnects if the connection is interrupted (e.g. going by train through a tunnel, connection lost).
- SSE automatically includes a Last-Event-Id so the server knows where to start again, after a reconnection.
If however the client was streaming many messages per second (e.g. a real time game), then I'd think WS would be better (the server wouldn't need to parse & handle many different requests).
then have clients that share a service worker also share that connection
Yes
- CChristian Scheuer @chrscheuer
I'm not sure what you mean by a 2nd connection for websockets. The connections start out as regular HTTP requests that just negotiate WS as a subprotocol and then continue as an open TCP connection. Not a 2nd connection.
From what I read:
Many more browsers support Websockets. Facebook (and everybody else) uses websockets. There's a max per browser of 6 open SSE connections etc. so your site would break if the user has other sites open that use SSE.
Websockets is much more widely adopted, and it's full duplex, so once you've established the connection, all communication with the server can go through the same socket, no overhead.- CChristian Scheuer @chrscheuer
We use websockets for all connections both internally between SF's app components on the user's computer and with the server.
It's highly portable and there's server support for all major languages. The ability to do duplex communication opens up for all sorts of speed enhancements. Once the connection is established you don't have to do auth for every single request from the client for example.
It's a massive speed bump. But it also means that you can easily port this data connectivity layer to other technologies such as for example mobile.
I would strongly recommend going websockets over SSE. Just my 2 cents.- KajMagnus @KajMagnus2020-03-27 15:54:16.453Z
Ok, thanks for the info. Now I have in mind to start with WS instead.
- Both you (SoundFlow) and Facebook and others prefer it, rather than SSE, and works fine for you.
- Talkyard will be (I realize now when I think more) a bit chatty: "Someone is typing ..." chat status indicators, user presence indicator, and, in the distant future: Real time collaborative editing of the same text. Then it's nice if, like you wrote, the server won't have to parse new request headers for, & do auth, more than once. (E.g. collab editing — could be almost a message per key press)
( This:
2nd connection for websockets ... connections start out as regular HTTP requests that just negotiate WS as a subprotocol and then continue as an open TCP connection
— but that TCP connection is a 2nd connection, right? One http/2 connection for loading the html page and js and css assets, and a 2nd for WS . Whilst I would think a service worker + SSE requests with http/2 would (at least could, theoretically) reuse the initial http/2 connection that loaded the html page / service worker / js css etc, for SSE. Meaning, 1 connection in total for all browser tabs and the service worker (?). — Anyway WS seems better in any case now I think, thanks )
We use websockets for all connections both internally between SF's app components on the user's computer and with the server
If you have time: I'm curious about how SoundFlow's WS architecture with clients, client components and the server(s) works? ( & Redis? Some message queue?)
B.t.w. if you have thoughts about how I could build WS things so becomes simpler to "live stream" chat messages to SF's clients, that'd be interesting to hear
- CChristian Scheuer @chrscheuer
Talkyard will be (I realize now when I think more) a bit chatty
This sounds AMAZING. Can't wait to see what you come up with.
And thanks for considering WS :)If you have time: I'm curious about how SoundFlow's WS architecture with clients, client components and the server(s) works? ( & Redis? Some message queue?)
I'll be happy to give you this info in a private thread.
- KajMagnus @KajMagnus2020-03-27 16:11:06.788Z
I'll be happy to give you this info in a private thread.
Ok, looking forward to :- )
- Progresswith handling this problem
KajMagnus @KajMagnus2020-02-25 21:21:40.554ZThanks for posting this :- ) I'm thinking I'll prioritize Post creation (upsert) API https://www.talkyard.io/-288/post-creation-upsert-api ? (it's more urgent for you?)
And after that, I'll fix things mentioned here? ...
... Except for things that seem quick to fix. For example, there're pending fixes for problems with the drafts (I just need to code review + e2e tests).
And the cmd+click notifications wouldn't take long I suppose.B.t.w. yes which help tips you have seen, is remembered in
localStorageonly — I've been meaning to remember that server side instead.I think we can keep everything in this topic. We can start sub threads about the different issues, in the threaded Discussion section above, and wiki-style update the relevant part of the Original Post, once fixed.
Thanks for the time you spend when writing & thinking about this :- )
Since I've started with fixing some of the Drafts bugs, I'll mark this as Started.
- CChristian Scheuer @chrscheuer
Awesome! Thanks for being open to it :) And yes sounds like a good plan - the API is more impotant yes.