User talk:Hhhippo/Flow/TOC and filters

Notes

Pointillist's first impressions

Nice work! These seem to be well-thought-out suggestions.

One of my use cases for Flow is to imagine the last nine years of Village pump (technical) ported to Flow. That's over 18,000 topics. Some users have pretty extensive talk page archives too, e.g. Newyorkbrad must have over 2,000 topics archived by now. The volume of data is a big challenge for Flow.

Given such potential for large result sets from your filters it might be necessary to pre-compute, sort and count memberships each time an attribute is changed (e.g. triggered asynchronously when your "archive bit" is set/reset). This would support your proposed TOC user interface, because you could initially display pre-calculated counts rather than lists, e.g.

+ 27 Active topics
+ 577 Closed topics
  + 93 Closed in 2014
  + 216 Closed in 2013
  ...

Counts are a good way of reducing the amount of data returned to the browser, and would be helpful for screen readers, too. It might sometimes be useful to capture contextual metadata about topics when they're closed, to produce counts that can be aggregated and presented in pivot table form (for example, RfA results by year/outcome etc).

It's an interesting design decision whether your TOC should be in a left-hand panel with an infinitely-scrollable list of topics in a right-hand panel, like opening a folder in a file explorer. It's a widely-understood metaphor, after all.

Re "This obviously works only if the board or topic is on my watchlist", "since last visit" and perhaps "threshold time". There should be a unified versioning model for all of these, where the system remembers the versions I last saw of every talk page that I have ever visited, even if it isn't/wasn't on my watchlist. Bear in mind that you can add a talk page to your watchlist even if you've never visited it, via Special:EditWatchlist/raw.
Thanks Pointillist (talk) 00:48, 21 February 2014 (UTC)

Thanks for the comments, I'm glad you like the idea!

Re: Cached TOCs / topic counts: good point, I appended the feature list with some ideas on how to handle such cases.

Re: TOC left/right. I agree it's a well-known pattern to have the TOC to the left of the main content. The reason I went for the right side is that there already is a menu bar on the left, so adding the TOC next to it would degrade the main view to be the third element on the page. It felt more natural to have the actual board in center stage, and different navigational tools around it. Anyway, this is not critical, and should be easy to adjust individually, e.g. with custom css.

Re: Keeping track of last visit on all pages: Yes, that would be nice, but quite some additional database load. It would also be nice to be able to manually mark pages as visited or unvisited, that is to set the 'last visited' timestamp to something else than 'now'. But this applies not only to talk pages/Flow boards, so I mostly left i out of the current proposal. Allowing the user to use their own 'threshold time' if no 'last visited' time is available is kind of a poor man's workaround to sneak some of this functionality in. — HHHIPPO 16:46, 23 February 2014 (UTC)

Maryana's notes

Great stuff!

We've got a (very barebones) start in this direction captured here: add a "sort by activity" feature. Probably something we'll start development work on around the end of this month.

Implementing sorting by various algorithms should be fairly straightforward. The open question is which algorithms would actually be useful for people, and there are a lot of excellent ideas on that front here, so thank you :) Some outstanding questions:

1. What would "archived" mean in the context of a Flow board with infinite scroll? How is it different from "closed discussion" or something like "marked as read"? (I think, based on how others have talked about it, that people want an option to, for lack of a better word, clear out the clutter on their talk pages, get rid of messages that are stale/they don't care about – but maybe you mean some other use-case?)
2. What are the top 3 most important filters people are going to want, just off the top of your head? We might want to do some progressive disclosure thing (e.g., "filter x, filter, y, show more options...") if there are a lot of different filter options. Eventually, we could do some testing to see which filters people click on most, but getting some initial gut-checks on that from you & other editors would be good, so we can prioritize work on the most important ones first.
3. Should read/unread state be explicitly set by the user or something the software just detects? E.g., should we be marking things as read for you under the hood, as Gmail does to emails in long threads, or do you want to have more control over that, like a tick box on each topic that you can set it to "read & archived" or something?

Thanks for putting these ideas together – I'm hoping we can get some simple mocks and/or prototypes out soonish to play around with this stuff :) Maryana (WMF) (talk) 01:25, 13 March 2014 (UTC)

Hi Maryana (WMF), thanks for the reply, It's good to hear you find these ideas useful. The link regarding sorting looks promising, different sort options are indeed a part of this concept, but not the main point.

1. What I mean here by "archived" is what I describe in the "active topics / archived topics" filter pair, that is, something similar to what we're used to from talk pages where a archiving bot is working. In general, topics below a certain age (regarding last activity) would pass the "active topics" filter, all others the "archived topcis" filter. This behavior could be modified by setting a minimum number of "active" topics, and by manually overriding the general filter rules through setting an "archive" or a "sticky" bit for a topic.
   Maybe "archived" is not really the best word to use here, since those "archived" topics will be much easier to access than in the old system (one doesn't have to climb down creaky stairs and fight extinct species of spiders in order to get to the archive...), this filter would just be one example of the "other topics" filter below.
   Re: "in the context of a Flow board with infinite scroll": note that one of the main points of this concept is that it's the viewer's decision if they want to use infinite scolling or browse through one or the other structured view. The "active" filter would be tuned such that all "active" topics can be loaded at once, without infinite scolling. The remaining, "archived" topics could be viewed either in one long, infinite scrolling list, or by going through the subdivisions, each of which would be short enough to load at once. (And for hardcore fans of infinite scrolling, there could be an "all topics" filter with the same functionality as Flow has now.)
2. I think the most important filter is "active topics", as described above. That's what we're using now, and for good reasons. And I guess it would greatly benefit the acceptance of Flow if this feature was available, with additional, new ones to choose from.
   Another obvious choice is "updated topics", including topics that have been created or contributed to since the viewer's last visit. For this filter to work the system will need to know which topics are unread by this user, for example because the topic is on their watchlist or in some advanced next-generation-watchlist-like tracking system, or because the user manually specified a cutoff age.
   In any case there should be a "all topics" or "other topics" filter, to make sure all topics are accessible. It could be "other topics" if a different filter is active, and "all topics" if either "all topics" itself or one of its subdivisions is active.
   These could be the basic filters included in a first version. Then one could implement a way to define new filters on a project (board, user) level to go with more specific use cases, in particular with project-defined workflows beyond simple talk pages. Sorting strategies could be either a part of the filter or an independet parameter that can be selected by the viewer (or a combination of both).
3. As a start, a system like the current watchlists would be fine, where the system stores a 'last visited' timestamp for each watched page and considers anything newer than that as unread. (This will get more complicated if/when Flow starts pulling new comments while the page is displayed.) As an addition, a way to manually mark contributions or subthreads as read or unread would be great. Manually setting the cutoff time to just before/after a certain contribution should be nearly trivial to implement (and would be nice to have also on article pages). Having a way to manually mark any edit independently as read or unread would be a great feature, but that sounds like a database's nightmare.

Thanks for looking at this, I'm very much looking forward to prototypes exploring some of these ideas! — HHHIPPO 22:23, 13 March 2014 (UTC)