On 11/19/2014 07:04 PM, S Page wrote:

Meanwhile the user expectation that searching a Talk namespace will find all content that appears on a Flow board in that namespace[2] seems hard to pull off.

If we don't deliver that, it will be a major negative hit to the user experience.

Matt Flaschen

Thanks for all your feedback, it is really useful. Some comments below:

Regarding the progress indicator:

- The idea is to represent the whole flow discussion and where the matches are, regardless of when the content of those topics is loaded. That means that if there is a match at the very last part of the whole conversation, that will be represented at the end of the bar and the content for it can get dynamically loaded as the user scrolls towards it (or goes directly there using the ToC). That allows the user to (a) identify quickly when there is a big density of matches (to distinguish those as a block to pay attention or ignore) and (b) avoid missing some matches when exploring big flow boards. - I think that with a rough estimation of the length of the topics a fluent experience could be achieved even without a 100% precision. For example (just a possibility): Given a topic A (with 1 message) and topic B (with 3 messages) the bar's first 25% would represent topic A (and matches found in that topic) while the remaining 75% could correspond to topic B. But we need more exploration in that area. - Doing the mapping vertically with the scrollbar would be hard since the scrollbar position would depend on the loaded topics, which would make the position to jump as topics are loaded. - This is the most experimental feature related to search. We may find out that the text indication of the total of matches may be enough, or that there is not an easy and reliable way to provide an overview on where the matches are in the whole conversation. In any case, I think it is worth testing and see how useful/distracting it seems to our users.

Regarding search behaviour:

- The idea is to avoid hidding content when searching but highlight matches over the current content instead. This approach has advantages (there is no context switch and matches are seen in their real context) and disadvantages (on a long conversation text that is not related to the search terms is still there). To compensate the disadvantages some navigation aids are provided: scrolling automatically to the first match, an overview of the highlighted areas, options to move to previous and next matches and a filtered ToC to view just those topics with results. I think that making search to hide content would be problematic (we may be creating the need to go back and forth between modes), but is worth trying if we see that users found it strange that topics without matches remain there. - For the filtered ToC I was planning to add an explicit mention that there are X other topics that don't match the search. That could help to avoid the confusion of not getting a complete ToC when searching. - I agree that the default browser in-page search won't work on infinite scroll and accessing it may be confusing, but we need to be especially careful when overriding default browser behaviour. So I would consider it when once we've identified it is an issue (e.g., by instrumenting how often ctrl+g/f happens on flow boards when flow-search is active and when it is not).

Regarding the ToC:

- I think it makes sense to highlight the topics I'm connected with (those I starred, or participated) as well as those with relevant content (content with new activity). I think that search is a good opportunity to learn about those usecases but if those are useful we want to add them on both since the user is looking for topics in both cases so there is no reason to break consistency. - Regarding the use of space and showing ToC and content both at the same time, I think those are two separate issues. I think that we'll have many opportunities to make better use of space with relevant information (if not when supporting ToC, with other feature). I'm especially interested in which scenarios it would be useful to have both visible at the same time, and how would affect users the consequences of having less space for the ToC (showing topic titles cropped, or less of them). In the current status of talk pages the ToC just appears at the beginning showing the full-titles, which takes most of the real state in long conversations and there is not an easy way to go back to it once you get immersed into the conversations. Do we have info on bugs/requests/comments from our users that illustrate more details about the navigation between topics and content?

Pau

On Sat, Nov 22, 2014 at 10:25 PM, Hhhippo ... hhhipppo@gmail.com wrote:

Hi all,

Re: TOC on the top I see your points: having the title of the currently displayed topic hovering on the top is indeed nice. And expanding this same line into a TOC also feels right. But the combination of the two means that you can see either the TOC or the board, but not both. And that feels very wrong to me. I'd prefer having a similar, a bit more compact version of the whole thing floating on the right side. This might be to some extent a matter of 'taste': just like some people prefer step-by-step driving instructions while others prefer a route indicated on a map, there's also different ways of navigating a web page that work best for different people. So the answer could be to make it configurable. By user preference, skin, custom css or - my preferred option

• a switch on the UI, comparable to the show/hide switch on article TOCs.

One could then maybe collect usage data to see how popular each display style is, and how frequently people switch.

Re: Whitespace on the right A nice start would be to change the behavior for small browser widths: when reducing the width, the first step should be to gradually reduce the whitespace all the way to zero, then reduce the board width, and then the font size. Currently there seems to be some kind of requirement of a certain minimum amount of whitespace, which is only dropped once the font size is reduced. That said, the current behavior is exactly what we wanted if there was something useful in that space (hint, hint ;-)

Re: Showing similar data in regular TOC +1

Re: Will < > be used? Definitely, at least the ">". That's what people do with the browser's search function on non-infinite pages. It would be great to map this function to Ctrl-G. (Actually, this might be a 'must have': otherwise Ctrl-G will repeat the latest native browser search within the loaded content, which is confusing if you did another search in between.)

Re: Infinite scrolling / loading topics In the prototype, topics without search results are hidden from the toc, but still shown on the board. Will that be different in the real version (the board then showing only topics with hits)? I think it should. I agree that the scrolling-up issue is independent of searching or other filters, but there's also a potential search-specific problem here: the set of topics to be shown can change drastically with every keystroke in the search bar. Maybe the reduction of the board to showing only topics with results should only happen when pressing enter in the bar?

Best wishes Hhhippo

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

Hi all,

I created some designs to add more detail about finding topics in Flow (search, ToC, filtering and sorting) based on your feedback (thanks for the feedback!).

I still want to iterate on the design for consistency and other improvements but I wanted to share them earlier. I published the designs at Commons https://commons.wikimedia.org/wiki/File:Flow-search-details.pdf and created a slide deck version https://docs.google.com/a/wikimedia.org/presentation/d/1DQabV3mjE9ReV9zs1qAi8u_A5560QEVX4aK95pc0Whs/edit?usp=sharing to allow comments in context.

With this and the former prototype I think we can start planning some research sessions to check with users which ideas work and which ones we need to focus on improving.

Feel free to provide any feedback.

Pau

On Tue, Nov 25, 2014 at 6:35 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:

On 11/23/2014 08:08 AM, Pau Giner wrote:

...

In the current status of talk pages the ToC just appears at the
beginning showing the full-titles, which takes most of the real
state in long conversations and there is not an easy way to go back
to it once you get immersed into the conversations. Do we have info
on bugs/requests/comments from our users that illustrate more
details about the navigation between topics and content?

I agree having to scroll back to the top (or use the back functionality if you used the link before) to use the TOC is suboptimal, and one of the use cases the Flow TOC solves.

There may be bugs about this (on the old-style TOC), but if not, that's not indication that it works perfectly. People would not (yet) expect something like the Flow TOC on a regular talk page, since nothing else affixes to the top like that.

That doesn't mean that it's not useful, just that people wouldn't know to ask for it (even if they end up liking it).

Matt Flaschen

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

Hi Pau,

This looks really great! I have a couple of comments and suggestions (hope I remember them all), but there are a lot of ideas I like. My very first reaction was "Wow!".

* First, I have to say it again, this looks like the mobile version, embedded in a desktop-version Wikipedia frame. But I can live with getting the mobile version first and hoping somebody will write a desktop skin later.

* I'm not sure I like the phrase "Browse topics": - The equivalent on article pages says "Contents". - When I see "Browse" I would expect more structure than a linear list to choose from. - Sometimes an actual topic title appears in that place, maybe the standard phrase should be formatted differently, like italic or gray?

* Autoscrolling to the first match: will this be done after each keystroke? That could mean a lot of loading of topics.

* The filters are AND'ed, right? (As in "show only topics where all selected filters apply")? Do we need an option for OR as well? The most common case is probably applying only one filter, so users could expect that clicking another one will replace the current one (though the shortcuts in the ToC menu solve that to some extent). For some filters also the inverse would be useful (view only topics that are unwatched, closed, etc.).

* What does "Activity v" do, and what's "Anytime"? Can you filter on different types of activity and then optionally on when they happened? Can you also say "Show me all activity since my last visit"?

* "Showing n topics": n is the number of topics passing the filter, right? They might not all be visible or even loaded at the same time, so maybe "showing" is not quite right.

* Browsing: I don't like the blue background of "Browse topics" when the ToC is open. This looks like a button (actually, it doesn't, but in the same way as buttons on newer parts of the mediawiki UI or on facebook don't, so one might think it's a button). The function of that area is somewhat comparable to that of a 2-state button, but those shouldn't be labeled with a verb that only makes sense in one of the states.

* I don't like the gray text for indicating closed topics. That looks like they're not accessible, e.g. not yet loaded.

* Marking topics with recent activity: the color we're familiar with in this context (from e.g. history pages) is green, not blue. I'd suggest green for new, red for removed, yellow for changed, and blue for search results (with a workaround for colorblind people, like a small icon or a tooltip).

What's the rationale for coloring the icons on the right? This could be misunderstood as 'recently added to watchlist' or 'recently contributed to by myself'. If it is meant to just make the marking of the entire line more prominent, one could instead add a second colored bar on the right edge.

"Recent" means "since my last visit", right?

* Can the ToC and the filter box be open at the same time? Should the footers be unified? This would just need a 'clear' button on the ToC footer. (And maybe a more obvious distinction between filter presets and filter refinements.)

* Can these filters also be activated by URL parameters (so one can link to a certain view)?

* "ToC and Search": Just to make sure I get it right: with the filtered ToC as shown on the slide, the search counter would show "1 of 7", and the ToC icon "3", right? Btw: this example shows another disadvantage of coloring the icons: one could think the blue bar is there because I contributed to this topic, not because there's recent activity in it.

* Should there be a ToC entry for the board header? There might be search results in it, I might have edited it, I can watch the board, and I might want to go there (mobiles don't have a 'home' key). So all the functions of a ToC entry would be useful here as well. Not sure how to call that entry though.

* I'm undecided about the secondary entry point for advanced search. The search dropdown has no name, so it's not obvious that the two are the same. Plus, the advanced search has quite some options, which is good, but can be overwhelming at first. Maybe the entry through the ... menu should be the only entry?

@Danny: I find the sorting very valuable, but I don't change it much, usually leave it at 'Recently active topics' (this actually sounds like a filter, not a sort order). So as long as the state is remembered it's fine to have it tugged away in a menu.

Overall: I think the arrangement could be optimized a bit to make clearer what 'button' does what and what can be found where, to avoid duplication, and to keep advanced options out of sight of unsuspecting newbies (but still easy to access if you want to). But I don't have specific suggestions for a different design right now, and probably won't have the time to come up with something faster than you will.

So: great start, I'm looking forward to seeing something like this in action.

Cheers Hhhippo

On 12/02/2014 11:15 PM, Danny Horn wrote:

Pau, this is awesome work.

It makes sense to put sorting, search and browse all in the same header area. Those features are all doing similar functions -- helping people find the conversations they're most interested in. But figuring out how to squeeze all three into the same space, plus advanced bonus options, is challenging.

Your solution for switching between the neutral/browsing/searching states on the Overview and Search slides looks really good to me. The user gets a call to action for both search and browse when they open the page, and the header switches focus between search and browse, depending on which one is more relevant to what the user's doing.

This design also downplays the sorting element in the header, which has to disappear from the header when the user scrolls down anyway. I don't know how valuable people find the sorting right now; this will help us to find out. :)

I do think that the advanced search and filter features get a little confusing by the end. There's a lot of power and customization in this design, and that brings a lot of signals to process.

For example, on the Browsing (ToC) slide, the topic titles on the left side of the panel use dark gray/light gray to indicate whether a topic is open or closed, but all of the icons are light gray on the right side of the panel -- except for the one that's blue, which indicates that there's recent activity on that topic. When you add in the faint-to-bright yellow highlighting in the next slide, that's a lot of different pieces of information marked by changes in color and contrast.

We may need to figure out the use cases for filtering and advanced search, and do a rough-draft priority ranking -- maybe starting with you, me, Nick, and whoever's interested, and then opening it up for the user research sessions?

And hooray for the user research -- we haven't done any research sessions on new features since I've been on the team, and I really want to. :) How has it worked on other teams?

Danny

On Tue, Dec 2, 2014 at 11:41 AM, Pau Giner <pginer@wikimedia.org mailto:pginer@wikimedia.org> wrote:

Hi all,

I created some designs to add more detail about finding topics in
Flow (search, ToC, filtering and sorting) based on your feedback
(thanks for the feedback!).

I still want to iterate on the design for consistency and other
improvements but I wanted to share them earlier. I published the
designs at Commons
<https://commons.wikimedia.org/wiki/File:Flow-search-details.pdf> and created
a slide deck version
<https://docs.google.com/a/wikimedia.org/presentation/d/1DQabV3mjE9ReV9zs1qAi8u_A5560QEVX4aK95pc0Whs/edit?usp=sharing>
to allow comments in context.

With this and the former prototype I think we can start planning
some research sessions to check with users which ideas work and
which ones we need to focus on improving.

Feel free to provide any feedback.

Pau


On Tue, Nov 25, 2014 at 6:35 AM, Matthew Flaschen
<mflaschen@wikimedia.org <mailto:mflaschen@wikimedia.org>> wrote:

    On 11/23/2014 08:08 AM, Pau Giner wrote:

             In the current status of talk pages the ToC just
        appears at the
             beginning showing the full-titles, which takes most of
        the real
             state in long conversations and there is not an easy
        way to go back
             to it once you get immersed into the conversations. Do
        we have info
             on bugs/requests/comments from our users that
        illustrate more
             details about the navigation between topics and content?


    I agree having to scroll back to the top (or use the back
    functionality if you used the link before) to use the TOC is
    suboptimal, and one of the use cases the Flow TOC solves.

    There may be bugs about this (on the old-style TOC), but if not,
    that's not indication that it works perfectly.  People would not
    (yet) expect something like the Flow TOC on a regular talk page,
    since nothing else affixes to the top like that.

    That doesn't mean that it's not useful, just that people
    wouldn't know to ask for it (even if they end up liking it).

    Matt Flaschen


    _________________________________________________
    EE mailing list
    EE@lists.wikimedia.org <mailto:EE@lists.wikimedia.org>
    https://lists.wikimedia.org/__mailman/listinfo/ee
    <https://lists.wikimedia.org/mailman/listinfo/ee>




--
Pau Giner
Interaction Designer
Wikimedia Foundation

_______________________________________________
EE mailing list
EE@lists.wikimedia.org <mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

On Thu, Dec 4, 2014 at 2:26 PM, Hhhippo hhhipppo@gmail.com wrote: (great stuff as always)

• Browsing: I don't like the blue background of "Browse topics" when the

ToC is open. This looks like a button (actually, it doesn't, but in the same way as buttons on newer parts of the mediawiki UI or on facebook don't, so one might think it's a button). The function of that area is somewhat comparable to that of a 2-state button, but those shouldn't be labeled with a verb that only makes sense in one of the states.

Me too. Likewise the blue background and shape of the current filters looks like a button. What happens if you click it?

• Marking topics with recent activity: the color we're familiar with in

this context (from e.g. history pages) is green, not blue.

Yes, when you follow a Permalink to a post in a topic, that post has a green left bar (example https://www.mediawiki.org/w/index.php?title=Topic:S12prb6trf24nhkz#flow-post-s6qnyrhqagbuap44). But when you click on a "Hhhippo and 2 others responded" message notification, there's an extra parameter fromnotif=1 that causes Flow to highlight that post and newer ones (example https://www.mediawiki.org/w/index.php?title=Topic:S12prb6trf24nhkz&topic_showPostId=s6qnyrhqagbuap44&fromnotif=1#flow-post-s6qnyrhqagbuap44). I don't like the two colors, we should pick one and preserve the thick bar for the actual reply and a lighter one for newer posts, there was a bug or Trello card comment about it. (A gadget writer could add a client-side "Highlight newer posts than this" action: fame and fortune awaits)

Dear Collaborationists,

Here's another suggestion for the ToC/Search/Filter design. The main idea is to unify the meaning and functionality of the various icons, to hopefully make them more discoverable. There's also some element of progressive disclosure for the more advanced features. I'll describe things in words rather than making a mock-up, hope it becomes clear what I mean:

* Change the blue sidebar symbolizing recently active topics in the ToC to a bullet/circle/clock icon. Move the topic titles a bit to the right, so there's space for this "recent activity" icon on the left. * Change the indicator for search results in the ToC to a magnifying glass. Drop the shades of yellow, see below for the numbers. * We now have 4 possible icons on a ToC entry: new activity, search results, my contribs, watchlisted * Each of these icons would carry several bits of information and give access to several actions: o Main signaling function: the presence of the icon indicates a certain property of a topic o Secondary information: the style of the icon (e.g. color) can contain more details on that property; a number overlaid the lower right corner of the icon (similar to Pau's ToC button) indicates how many posts are matching this property. A mouseover tooltip could describe the meaning in a few words and/or give further details. o Primary action: a left-click on the icon will scroll the board to that topic and mark the affected posts by a colored sidebar on the left. The "< >" buttons will appear in the top bar and allow jumping between these posts (note this applies to all icons, not just search. Very convenient for flipping through new activity!) The "1 of 42" can be skipped since the total number is shown with the icon, and the running counter is not that interesting anyway (or is it? Probably better to have some kind of temporary 'mark as read' mechanism, but that's another story...) To be decided: in which order to jump through the matches. Ascending chronological order would be great for new activity, newest first might be better in the other cases. o There should be some indication which icon is activated that way. One could e.g. remember the good old times when buttons looked three-dimensional and had a very obvious 'pressed' state. To keep the modern look, we could keep the inactive icons flat and only show the active one on a recessed square. Clicking any other icon would activate that filter instead of the current one, clicking the same icon again would go back to the unfiltered board (one-click undo without moving the mouse, nice for discoverability). o Secondary action: a right-click (long tap on mobile) will open a context menu, which offers first the primary action again (or not? not sure), then one ore more related actions, and finally an entry "advanced search". * Each icon would also appear on the top bar, in the same order, and with very similar functions. The difference to the individual topic icons would be o The numbers count matching posts on the entire board, not just one topic. o The primary action would also reduce the ToC to show only topics with matches. * The "recent activity" icon (clock): o Would indicate that there are recently added/changed/removed posts in green/yellow/red ('recently' as in 'since my last visit', this works only if the topic or board is watched) o Reduced to white with outline when there's nothing new (not removed entirely, to still give access to the context menu) o Secondary actions: mark all as read (set watchlist timestamp to the time the page was loaded, not the time the icon was clicked!), pick a fixed timespan from a list (the latter works without watching). * The "search results" icon (magnifying glass): o not shown in topic lines unless there are search results o no secondary actions except for 'advanced search' o has the search bar next to it in the header line, typing here will press the button * The "my contributions" icon (person symbol) o Reduced to white with outline when no matches o Secondary action: show contributions of another user (pick from a dropdown list of all contributors to the topic/board) * The "watchlist" icon (star) o Shows if I'm watching the topic / anything on the board (and the number of posts in those topics) o Outlined if not watching o Actions on topic lines - primary: watch/unwatch topic (this is a bit out-of-line, not sure how to resolve that; maybe ok with tooltip); no secondary actions o Actions on header line - primary: reduce ToC to watched topics; secondary: watch/unwatch board (including different types of watching a board, once available) * The ToC icon would still open/close the ToC, its number would show the number of topics currently belonging into the ToC, which means the total number of topics on the board if there are no filters active (this gives a quick overview how large the board is, e.g. if one should bother with the filters or just scroll down). Note that this is not redundant with the number in the active filter icon, since those count posts, not topics. * This should cover everything except the sort order selection, which could go to the advanced search panel, redundantizing the "..." menu. Together with the removal of "v 1 of 42 < > x", this leaves more than enough space for the three new icons in the header line. * There could be a "help icon" at the very right of the header line, linking to a page that explains all this much better...

I'm not sure if the right-click context menus are discoverable enough, but then, you can do quite a bit without them, and there's a help button. All the icons and numbers could sound like they're overwhelming for newcomers, but: if you look at an unknown board, not watched, not contributed, not searched, then there are only outlined icons and no numbers. All the information will be added in steps as you become involved.

Phew, that became a longer story than I thought. I hope it makes sense, I'll just throw it up here and see what happens...

Best Hhhippo

Thanks for the great feedback (by mail and on the slides). I'll add some comments below, and use your input to iterate the designs, or add research questions http://etherpad.wikimedia.org/p/collab-research to get more clarity on certain topics:

We may need to figure out the use cases for filtering and advanced search,

and do a rough-draft priority ranking -- maybe starting with you, me, Nick, and whoever's interested, and then opening it up for the user research sessions?

That would be useful to identify the relevant scenarios and use those as a base for research. I based the designs on the initial scenarios we discussed, but from I already seen in the comments there may be more that we have not covered yet.

we haven't done any research sessions on new features since I've been on

the team, and I really want to. :) How has it worked on other teams?

It has been very useful. It helps to check whether our ideas align with the user mental models, and help to prioritise since it helps to identify the potential impact of each feature. With Content Translation it was key to understand the details of how users where translating "manually" and which where the points where we could help the most.

* I'm not sure I like the phrase "Browse topics":

I have no strong opinion on the way to introduce the list of topics as long it aligns with the user mental model. Even if "contents" is consistent with the page metaphor of articles, and may work for the classic talk pages (which are content pages repurposed for conversations), I would like to use a concept that is more specific to conversations to clearly anticipate to users what they will see. It will be worth considering those aspects during our research. So I already added them in our research draft http://etherpad.wikimedia.org/p/collab-research to make sure we identify issues on this area.

* Autoscrolling to the first match: will this be done after each keystroke?

That could mean a lot of loading of topics.

We probably need a safety margin in the form of a time delay for example. Not triggering the search immediately also reduces some side-effects of typo correction.

* The filters are AND'ed, right?

Yes. I don't think that OR'ed or complex combinations are needed (at least I'd like to start simple and identify if there is a need for more complex cases).

I agree that we'll need to be able to allow some kind of reversed filters. A usecase that comes to mind is when looking on a talk page those messages I have not replied yet. I'll explore several options (having them explicitly, being able to negate the existing ones).

* What does "Activity v" do, and what's "Anytime"?

For "Activity", the idea is to be able to provide more specific time references (created, last reply, etc.). For cases such as, "what happened to this topic I created last year around Wikimania dates?". Regarding "Anytime" it was intended to be the default value (any activity anytime) intended to allow going back to the default whenever you change the time filter. If that it is the case, it needs to be selected by default to avoid confusion.

Can you also say "Show me all activity since my last visit"?

That is a great idea. Any time period that we can present based on relevant terms for the user sounds more useful than generic buckets. Totally worth adding.

* "Showing n topics": n is the number of topics passing the filter, right?

They might not all be visible or even loaded at the same time, so maybe "showing" is not quite right.

Yes, "showing" means that those topics are not filtered out, those that are visible if the user scrolls the whole board.

From the user perspective, if infinite scroll works fluently there should

be no difference on whether topics are loaded in advance or as they scroll.

* Browsing: I don't like the blue background of "Browse topics" when the

ToC is open.

With the addition of filtering mechanisms, the blue highlighting has become a bit inconsistent. I'll review that in the designs.

* I don't like the gray text for indicating closed topics. That looks like

they're not accessible, e.g. not yet loaded.

We can think on different visual treatments, but assuming the norm would be to skip those we probably want something that makes them less emphasised than the regular ones (e.g., adding an icon can draw too much attention).

* Marking topics with recent activity

We need to be careful not to overload the list with too much color. We need to look for a balance where the list of topics is the main aspect but it is enhanced with some cues that allow you to find the relevant ones quickly.

What's the rationale for coloring the icons on the right? This could be

misunderstood as 'recently added to watchlist' or 'recently contributed to by myself'.

The idea is to provide quick scanability. On the left side you can quickly find topics whit recent activity. The right side is about your relationship with the topics, so you can see the ones that care most to you (participated, or watching). For those which also have recent activity, the icon turns blue too. That helps to focus on topics where you participated and have recent activity without having to do the intersection in your head for each item, just scan vertically looking for blue star icons for example.

"Recent" means "since my last visit", right?

I'm not sure. It makes sense that users are interested in activity since the last time they checked, but if a user follows a link and goes back, do we expect all recent activity indicators go away because the last visit was one second ago? Is clicking on a topic expected to clear the recent activity (becoming more of an "read/unread" status)? We probably need to give more thought on the specific logic.

* Can the ToC and the filter box be open at the same time? Should the

footers be unified?

I would not show both at the same time, but since the effects are reflected on the search bar, the current status is expected to be clear. I was thinking on the ToC footer as a compact version of the filtering mechanism, so the goal was to achieve some consistency while providing this subset of common filters.

* Can these filters also be activated by URL parameters (so one can link to

a certain view)?

That makes a lot of sense. We can even think on exposing a way to get such link on the UI, but at the very minimum I think we should update the URL so that the current view is bookmarkable.

* "ToC and Search": Just to make sure I get it right: with the filtered ToC

as shown on the slide, the search counter would show "1 of 7", and the ToC icon "3", right?

Yes. I'll update the numbers to avoid unnecessary confusion.

* Should there be a ToC entry for the board header?

I'm not sure the header is perceived as another topic in the list, and it is already the first visible element. There may be a need to go back to the top once you start scrolling, though.

I'm undecided about the secondary entry point for advanced search.

That is something we want to check how users use it in practice. If most users find the filtering panel when they need it, we may want to get rid of the secondary entry point. If that is not the case, we may want to either (a) emphasise the main entry point (e.g., opening it on click and remove it when typing if no filters are added), (b) provide a way to access the filtering panel from the ToC (if the ToC is where users look for it) or (c) keep the secondary entry point as a less immediate but safer option for those users not finding the primary entry point.

Likewise the blue background and shape of the current filters looks like a

button. What happens if you click it?

Clicking on the blue filters will open the advanced search, where you can change (or edit, if you prefer) them.

Here's another suggestion for the ToC/Search/Filter design.

Thanks for the input. There are a couple of aspects whose purpose is not clear to me. One is about the need to representing two binary status (e.g., filled and outlined star), presenting one seems enough for the purpose of the ToC (is watching topics something we expect users to do directly form ToC?), and the other is about making each item in the ToC to have multiple actions.

Pau

On Sun, Dec 14, 2014 at 7:17 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:

On 12/06/2014 01:43 PM, Hhhippo wrote:

...

What do you mean by "the actual reply"? Is there a special notification for a direct reply to one of my posts?

I think it refers to "the post that triggered the notification" vs. "things that have happened since I visited the board", or something along those lines.

I'm not sure that makes too much

...

sense at the moment: as long as structured discussions are largely disabled, and many of the reply 'buttons' seem to be functionally equivalent, we can't rely on users pressing the right 'reply', so we're not sure what they're replying to.

What do you mean by "structured discussions are largely disabled"? Are you referring to the 3-post depth limit?

As far as the reply links, they are functionally different (replying to the topic, vs. replying to a post). However, we will soon collect information to determine if users make use of both of them regularly, and thus whether to keep both in the UI.

Thanks,

Matt Flaschen

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

I made an iteration on the designs and built a prototype to better illustrate the filtering mechanism http://pauginer.github.io/prototypes/flow/filters/index.html. In this prototype you can filter the board to view the topics you participated in on different contexts:

- While you are on the ToC - While you are searching (note that input for the search query is simulated since it was not the focus of the current prototype). - While you are searching and in the ToC - From the advanced filtering panel (accessible from the quick filter toolbar that appears below the ToC or the search on focus.

The main changes in design from the previous search prototype http://pauginer.github.io/prototypes/flow/search/index.html are:

- Less blue highlighting. It was used in many places inconsistently. - A quick filter bar is used both when the user access the ToC and the search bar. the quick filtering bar is used as the entry point for the advanced filtering. - Items in the quick filter bar allow filter modifications (e.g., adding both mentioned and not mentioned). That may be too much for a simple bar and we may keep just the basics here, but I think it is worth testing. - The drop-down access to the advanced filters is only shown when there is already a search query (since the quick filtering is not shown at that point to avoid competing with search navigation aids).

Thanks for all the feedback, and feel free to provide more. It has been really useful for iterating the designs, and I still want to go through some your interesting ideas in next iterations. In any case, since these two prototypes seem already useful to try our general design approach for searching and filtering, I created a card on the User Research team board https://trello.com/c/BBgLSFF3/144-finding-topics-on-flow to start to defining our research plan.

Pau

On Tue, Dec 16, 2014 at 9:04 AM, Hhhippo hhhipppo@gmail.com wrote:

Hi again,

On 12/15/2014 12:33 PM, Pau Giner wrote:

...

• I'm not sure I like the phrase "Browse topics":

I have no strong opinion on the way to introduce the list of topics as long it aligns with the user mental model. Even if "contents" is consistent with the page metaphor of articles, and may work for the classic talk pages (which are content pages repurposed for conversations), I would like to use a concept that is more specific to conversations to clearly anticipate to users what they will see. It will be worth considering those aspects during our research. So I already added them in our research draft http://etherpad.wikimedia.org/p/collab-research to make sure we identify issues on this area.

Yes, "Contents" doesn't exactly fit for a discussion space, but with "Browse" I would associate more than a one-dimensional list. I don't have a strong opinion either... How about just "Topics"?

• The filters are AND'ed, right?

Yes. I don't think that OR'ed or complex combinations are needed (at least I'd like to start simple and identify if there is a need for more complex cases).

We can see how much of the standard use cases can be made accessible outside the 'advanced search' panel. If that panel turns into something only power-users use, it might as well host some very advanced features.

• What does "Activity v" do, and what's "Anytime"?

For "Activity", the idea is to be able to provide more specific time references (created, last reply, etc.). For cases such as, "what happened to this topic I created last year around Wikimania dates?". Regarding "Anytime" it was intended to be the default value (any activity anytime) intended to allow going back to the default whenever you change the time filter. If that it is the case, it needs to be selected by default to avoid confusion.

Ah, ok. So this is some kind of two-dimensional filter, where the first part is a dropdown selector, and the second a row of buttons. Not sure about the design details, but the function is useful.

Can you also say "Show me all activity since my last visit"?

That is a great idea. Any time period that we can present based on relevant terms for the user sounds more useful than generic buckets. Totally worth adding.

Well, the idea is basically just a Flow version of what watchlists are doing now. But if done right, Flow could do it better than now :-)

• "Showing n topics": n is the number of topics passing the filter,

...

right? They might not all be visible or even loaded at the same time, so maybe "showing" is not quite right.

Yes, "showing" means that those topics are not filtered out, those that are visible if the user scrolls the whole board. From the user perspective, if infinite scroll works fluently there should be no difference on whether topics are loaded in advance or as they scroll.

Yes, but why not drop the "Showing"? But again, no strong opinion here.

• I don't like the gray text for indicating closed topics. That looks

...

like they're not accessible, e.g. not yet loaded.

We can think on different visual treatments, but assuming the norm would be to skip those we probably want something that makes them less emphasised than the regular ones (e.g., adding an icon can draw too much attention).

Hmm, if a closed topic shows up in my watchlist, that's usually because it has just been closed, and reading the closing statement is the most interesting part of many discussions. This can also be the case for older topics: I might look for answers, topics where consensus has been established and summarized, rather than open questions. So what I want to skip depends on the use case.

• Marking topics with recent activity

We need to be careful not to overload the list with too much color. We need to look for a balance where the list of topics is the main aspect but it is enhanced with some cues that allow you to find the relevant ones quickly.

Agree. Maybe use different css classes which all map to the same color unless customized? This would also help accessibility through supporting screen readers and workarounds for colorblindness.

What's the rationale for coloring the icons on the right? This could be

...

misunderstood as 'recently added to watchlist' or 'recently contributed to by myself'.

The idea is to provide quick scanability. On the left side you can quickly find topics whit recent activity. The right side is about your relationship with the topics, so you can see the ones that care most to you (participated, or watching). For those which also have recent activity, the icon turns blue too. That helps to focus on topics where you participated and have recent activity without having to do the intersection in your head for each item, just scan vertically looking for blue star icons for example.

Hmm, that intersection is pretty much what the watchlist does now, and it should also do that for Flow content. I'm not sure if we need the same intersection emphasized in the normal ToC. How about giving the whole entry a faint colored background, corresponding to the color of the bar (or icon) on the left? (Just throwing up more ideas to confuse you, they're not necessarily consistent ;-) In my icon-based concept, the user can very easily make intersections by clicking one icon in the header line and then looking for the other one in the filtered Toc.

I still think, with your current design, I as a reader might be tempted to do the intersection in my head anyway: blue means new, star means watched => blue star means newly watched, and analogous for my contributions.

"Recent" means "since my last visit", right?

I'm not sure. It makes sense that users are interested in activity since the last time they checked, but if a user follows a link and goes back, do we expect all recent activity indicators go away because the last visit was one second ago? Is clicking on a topic expected to clear the recent activity (becoming more of an "read/unread" status)? We probably need to give more thought on the specific logic.

Fully agree about the "more thought". A good way for marking things as read/unread, either automatically or manually, in a situation where topics can be individually watchlisted but shown together, is very non-trivial (but worth figuring out). It works ok, but not perfect with the current watchlist system. How Flow currently interacts with Echo and the watchlist I can't really tell, which is not good.

I'm undecided about the secondary entry point for advanced search.

That is something we want to check how users use it in practice. If most users find the filtering panel when they need it, we may want to get rid of the secondary entry point. If that is not the case, we may want to either (a) emphasise the main entry point (e.g., opening it on click and remove it when typing if no filters are added), (b) provide a way to access the filtering panel from the ToC (if the ToC is where users look for it) or (c) keep the secondary entry point as a less immediate but safer option for those users not finding the primary entry point.

Here's a more general idea about users finding things on the UI, inspired by the way Pau's slides are arranged: One of the things we could put in the white desert to the right of a Flow board is some kind of help / context help / tutorial. The user could collapse it to a button once it's no longer needed (and expand something else instead, or put the ToC there).

Likewise the blue background and shape of the current filters looks like

...

a button. What happens if you click it?

Clicking on the blue filters will open the advanced search, where you can change (or edit, if you prefer) them.

Hmm, so all these buttons do the same? Sounds not quite optimal yet.

Here's another suggestion for the ToC/Search/Filter design.

Thanks for the input. There are a couple of aspects whose purpose is not clear to me. One is about the need to representing two binary status (e.g., filled and outlined star), presenting one seems enough for the purpose of the ToC (is watching topics something we expect users to do directly form ToC?), and the other is about making each item in the ToC to have multiple actions.

Two binary statuses? I meant only one: each icon is either "there" (filled), or "not there" (outlined or really not there). In some cases one might want to provide an entry point to some action even though the binary status is "not there", therefore the outlines. The watchlist icon is a bit special, I agree, since it's a purely per-topic property, not per-post. So the standard primary action "show watched posts" doesn't make sense, therefore I suggested watching/unwatching. One could also leave this icon without any action, depends a bit on the result of the "how to mark things as read/unread" brainstroming. Also the number of watched posts isn't too useful, one could have this icon without a number overlay, and instead show the total number of posts for each topic on the very right, outside the star.

Multiple actions: the idea is to have the (hopefully) most obvious action on left-click ("show me the posts that cause this icon to show here"), and other, very related actions nearby in the context(!) menu. This would move the more common filter actions out of the advanced search panel and leave the latter for even more advanced things. I expect you don't like the old-fashioned right-click menu. One could also have everything (explanation, primary and secondary actions) in a mouseover menu like the "..." ones. That would slow down using the primary action though. I'm not sure. This isn't a fully thought through concept yet, more a bunch of ideas.

Cheers Hhhippo

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

On 12/15/2014 06:33 AM, Pau Giner wrote:

We probably need a safety margin in the form of a time delay for example.

This will be simple to do with jQuery throttle.

Matt Flaschen

On Sat, Dec 6, 2014 at 10:43 AM, Hhhippo hhhipppo@gmail.com wrote:

Hi S Page,

Yes, when you follow a Permalink to a post in a topic, that post has a green left bar (example https://www.mediawiki.org/w/index.php?title=Topic:S12prb6trf24nhkz#flow-post-s6qnyrhqagbuap44). But when you click on a "Hhhippo and 2 others responded" message notification, there's an extra parameter fromnotif=1 that causes Flow to highlight that post and newer ones (example https://www.mediawiki.org/w/index.php?title=Topic:S12prb6trf24nhkz&topic_showPostId=s6qnyrhqagbuap44&fromnotif=1#flow-post-s6qnyrhqagbuap44).

... What do you mean by "the actual reply"? Is there a special notification for a direct reply to one of my posts?

I don't think so, whether you're watching the topic or someone replies to your post you get the same 'flow-notification-reply' "Xxxx responded", and if there are additional notifications then Echo's notification bundling transforms them into one 'flow-notification-reply-bundle' "Xxx and N others responded". The topic from the first notification becomes the permalink.

(A gadget writer could add a client-side "Highlight newer posts than

this" action: fame and fortune awaits)

Yes yes, got the hint already last time ;-)

It's my general exhortation to the crowd.

Yeah, I was pushing for putting a stationary Table of Contents in the right rail for a while. The thing that changed my mind and made me like having the fixed header ToC was having the title of the topic that you're reading at the top of the page. That feels internally consistent -- there's one place on the page that shows where you are, and gives you a place to navigate from. It feels right to me. Here are a couple screenshots from the current version as we're building it, so you can see what I mean.

The empty right rail is something that's been on my mind for a while. We're either going to put something useful there, or allow people to choose a wider layout, or both.

Danny

On Wed, Nov 19, 2014 at 2:44 PM, Hhhippo ... hhhipppo@gmail.com wrote:

Hi Pau,

This looks great! A bit like https://en.wikipedia.org/wiki/User:Hhhippo/Flow/TOC_and_filters , just with a filter I didn't think of yet. I really like the idea. A few comments anyway:

As I said already at https://www.mediawiki.org/wiki/Talk:Flow/Table_of_Contents_spec , this TOC layout looks very much like the usual MediaWiki TOC *on mobile*. On a desktop/laptop screen a TOC that overlaps the board while the right half of the browser window is completely empty looks just wrong.

I like the little indicator bar showing where the results are. In the final version, will the dark grey bar showing the current position be limited in width to the currently displayed range? One could also think of putting it vertically next to the actual scroll bar and using the slider as position indicator, but that might be difficult with infinite scrolling. Or an additional medium grey region indicating parts that are loaded, but not on the screen right now (kinda YouTube-style)?

If one scrolls down to a search result far down on a long board, a lot of topics have to be loaded. Maybe there should be a way to load and show only topics with hits?

I can't think of any cases where your concept wouldn't work right now. What will surely come up at some time is searching for wikimarkup used when composing a post. This might be quite expensive if the markup is not in the database, but that's not really the topic here.

Best wishes Hhhippo

On Wed, Nov 19, 2014 at 7:48 PM, Pau Giner pginer@wikimedia.org wrote:

...

Hi all,

I created a prototype to illustrate some of the concepts for searching a flow board: http://pauginer.github.io/prototypes/flow/search/index.html

The basic ideas are:

• Show first result as soon as you type and avoid context changes

(i.e., highlighting the matches on top of the current conversation instead of going through a specific "results page")

• Integrate search with table of contents. The table of contents can

act as a de-facto search results summary you can open after searching to have an overview of the topics where your query was found (and information on whether some of these topics were in your watchlist or you participated in them).

Note that the prototype is intended to reflect the basic interaction elements so several aspects are missing or broken. It also simulates a limited workflow, so you may want to follow these instructions:

1. This is a flow board about the Rapa Nui article. Please, access

the list of all topics and go back to the flow board (the prototype won't let you jump to a specific topic). 2. Search for "moai" to find out which conversations are related to those nice statues. 1. You can go through the results by the next/previous controls or by scrolling. 3. While you are searching, get an overview on which topics are related to your search.

Feel free to provide any feedback. At this moment we are specially interested in usecases for search where this model may not work, so examples to illustrate those would be really useful.

Thanks

Pau

-- Pau Giner Interaction Designer Wikimedia Foundation

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

Yeah, this model of Search will have the same problem that we're having with ToC -- how to load topics when you bounce down to a faraway topic and then scroll up. But hopefully we're going to solve that for the ToC. :)

On Wed, Nov 19, 2014 at 4:16 PM, S Page spage@wikimedia.org wrote:

On Wed, Nov 19, 2014 at 2:44 PM, Hhhippo ... hhhipppo@gmail.com wrote:

...

If one scrolls down to a search result far down on a long board, a lot of topics have to be loaded. Maybe there should be a way to load and show only topics with hits?

The way I understood the prototype is if you've searched, the board and the TOC only show topics that match your search; note how the TOC gadget changes to show 3 matches.

If there are dozens of matching topics matching your search then

• the topics will be loaded in batches ("infinite scroll")
• if you bring up thethe "TOC of matching topics", scroll down and click

on a topic, then we have the problem of filling in the gap in topics above that topic if you scroll upwards.

We have to solve the same loading issues when you're not in search mode.

-- =S Page Features engineer

---

EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee

On 11/19/2014 05:44 PM, Hhhippo ... wrote:

I can't think of any cases where your concept wouldn't work right now. What will surely come up at some time is searching for wikimarkup used when composing a post. This might be quite expensive if the markup is not in the database, but that's not really the topic here.

Quiddity specifically mentioned that this would be useful to him as well. It's not really a question of whether it's in the MariaDB database (it's not, Parsoid HTML is). CirrusSearch won't hit MariaDB anyway when responding with search results, so the question is whether it's indexed (or can be) in CirrusSearch.

Matt Flaschen

On 11/19/2014 06:54 PM, S Page wrote:

Which raises the question[1] why not show similar information in the regular TOC?

+1, I think we should do it. This seems very useful (especially the one that shows if I've participated), and may actually make implementation easier, by letting us reuse client-side code between regular TOC and search TOC.

view-topiclist will need to be augmented to add this information, but that's fine.

Matt Flaschen