As some of our users have pointed out, it is frustrating to only be able to change the topic tracking at the bottom of a topic. The problem scenario was outlined as follows:
Set auto track rules to something like 4 minutes in topic.
Browse from a touch device, such as a tablet.
See a new long topic that piques your interest. get 10 or so posts in and realize that, while you are interested in the topic, you aren’t interested enough to devote the time in the topic now.
You haven’t yet spent 4 minutes in the topic, so it hasn’t auto-tracked. Being on a touch device, you can’t use the keyboard shortcuts. Down to the bottom of the topic you go to set the tracking-status manually.
Now that you’ve been at the bottom of the topic, your furthest read position is the last post. The topic does not show in the Unread list. Your position in the topic is lost.
To combat this, the idea of adding the ability to change the tracking status from the top of the topic was suggested (thank you @boomzilla). Adding the selector to the topic summary area would seem a logical place to double this control, and would resolve the above scenario fairly easily.
I’ve had users lament about this too, and I agree it’s a problem.
[quote=“abarker, post:1, topic:28512”]
Adding the selector to the topic summary area would seem a logical place to double this control, and would resolve the above scenario fairly easily.
[/quote]Hmmm, interesting idea. Could you make a mockup of how it might fit in there though?
The great thing about this option is that it can be put in place for both desktop and mobile UIs.
These sound like acceptable ideas for desktop, but then what about mobile? The entire point of putting the control in a second location is that it is currently only accessible at the bottom for people who have no keyboard access. Most users who have no keyboard access are on mobile, which means that the sidebar solution won’t help them at all.
There is definitely lots of prior art on putting controls at the top and bottom, we already have a fair number of controls in the topic summary and it is collapsed by default for shorter topics so I think duplicating it there is a good idea.
The bookmark idea is interesting too but it would not be very discoverable, and I assume it would only apply if you bookmarked the topic? Feels a bit magical to me, not discoverable.
I was thinking either - you could bookmark a post or the topic itself and it’d watch the thread either way. It’d be similar to reading for x minutes or replying, another way of indicating interest that switches the thread over to watched mode.
I’m not married to the idea or anything though, this isn’t a use case that’s particularly relevant to me so if putting the control at the top works better, it works better.
The initial complaint I saw did mention this, but then said they discarded the idea because the bookmarks get lost among all their other bookmarks. The idea is to have the topic appear on the Unread list.
That seems problematic to me. When setting a bookmark, does the user want to watch or track the topic? Maybe they were checking out a new topic, found a post with some information they want to hold onto, but found the topic as a whole useless, then the topic should be left as regular. What if they’re bookmarking it to flag later, should the tracking status be changed for that?
There are so many different potential uses for bookmarks that changing the tracking status when a bookmark is set seems like the wrong approach.
In light of the new vertical timeline, I think we should re-consider this. It’s even in the spec’s mockup:
Right now we’re occupying that space with the admin’s topic wrench, but I think the tracking button is more important. In fact, I’d say there’s still room for both. And when the sidebar is collapsed, the wrench can be moved down into the paging-widget.
This has always been the plan from the start. (That is why it was in the original mockup.) It just takes time for Robin to work the code into shape to make it happen.
