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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee
--
Pau Giner
Interaction Designer
Wikimedia Foundation