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