Hhhipppo, thank you for sending these questions. It's awesome to get this detailed and thoughtful analysis.

I can answer maybe two of your questions off the top of my head -- no, I don't think we'll autoscroll as you type, for exactly the reason that you mention; I agree with you about the gray for closed topics; everything else is Maybe, I don't know, Good question or TBD, as appropriate.

But -- even if it takes us a minute to get our heads around the questions and answers -- I want to say thanks, and we'll think about all of this a lot more, thanks to you. :)


Danny

On Thu, Dec 4, 2014 at 2:26 PM, Hhhippo <hhhipppo@gmail.com> wrote:
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


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