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