Add focus and refine feature to article listing page

RESOLVED FIXED in 2012Q3

Status

support.mozilla.org
Knowledge Base Software
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: atopal, Assigned: rrosario)

Tracking

unspecified
2012Q3

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=user c=wiki p=1)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Users need a way to focus and refine the view once we show them all articles for a certain topic.

The requirements for this are from: https://wiki.mozilla.org/Support/Kitsune/Features/Auto-Nav#You.27ve_selected_a_Topic_and_a_Product_-_Article_Listing_page:

I'm attaching Bram's mockups for this.
(Reporter)

Comment 1

6 years ago
Created attachment 657823 [details]
Focus and refine closed
(Reporter)

Comment 2

6 years ago
Created attachment 657824 [details]
Focus and refine expanded
(Assignee)

Updated

6 years ago
Whiteboard: u=user c=wiki p=
Target Milestone: --- → 2012Q3

Comment 3

6 years ago
Here are my replies to Ricky’s emails.

> Can we add a button that the user clicks when done making selections?

Yes.


> It sounds like what we want to do is select one topic at a time that
> narrows down the list of articles and regenerates a list of topics to
> refine further down.

Yes. This what what I understood from the requirements document, as well.


> Clicking a topic in the refine and focus section reloads the page with
> less articles and less topics to refine and focus down to.

I didn’t know that clicking a topic inside Refine and Focus will reload the page.

Would this be similar to the behavior on YouTube?
http://www.youtube.com/results?search_query=Firefox&uni=3

Try clicking around the links on the Filter area, and watch the entire page reload.

When I first worked on this feature, I thought that the article list will be reloaded without an entire page reload. Similar to how things work at Google.
http://www.google.com/#q=firefox&tbs=qdr:h

Try clicking around the links on the sidebar, and watch the article list only reload.

I think either way is fine, and we should pick the method that’s more technically achievable. But if we are to reload the entire page, versus just reloading the list of articles, I might have to design the entry point and position it differently. I do want the box to maintain consistent positioning and expanded/closed state. This way, the user is not confused when the page refreshes and the Focus and Refine box is minimized.


> Given that, I think it's better if these were links and not checkboxes.
> There would also need to be a way to clear out previously selected topics.

This idea makes me nervous, because then we would need to list the previously selected topic in a separate area, and provide a way to “erase” that topic. In other words, it asks user to be familiar with the concept of search scope, and narrowing down and widening up search.

Putting in a checkbox is in my opinion better, because we’ll give the user a mental model of “check this box to narrow down, uncheck this box to widen”. It’s not perfect, but it’s simpler.

If need be, we can even fake the appearance of a series of checkboxes while having a completely different way of refining in the backend. These checkboxes are a tool to help users visualize search scope, where we use the checkbox itself to indicate what’s being selected, rather than using another page indicator (like a search scope banner) appearing on another part of the page with an ‘x’ symbol to the right of it to erase that search scope.

If we want to limit the search scope to two maximum, we can even gray out remaining boxes after two clicks.{

What about YouTube and Google, who both uses links rather than checkboxes?

In their cases, these links make sense because each item under a subhead is exclusive. That is, they cannot stack on top of each other. For example: duration is either <4, 4–20, or >20. Sort method is either by date, by view count, by rating or by relevance.

On YouTube, user cannot search for both the most recent and the most viewed videos. It has to be either one, but not both.

At SUMO, user can narrow-down one topic, and then put another topic “on top of” the first to narrow it down more.

And this is why using links is potentially more confusing than using checkboxes.

Comment 4

6 years ago
Here is my reply to Kadir’s email:

> I just looked at the article listing with the new iA, and it
> seems to me that even selecting just one topic to refine
> would already get the article count down to something
> so short that any further refinement would seem like
> unnecessary overhead.

If the number of articles refined by selecting just one topic is already small enough to be useful, then we can replace the checkboxes with the link. Plus, it might make development easier?

I was designing, though, on the scenario that user has the ability to refine by more than one topic. But that was then. If it needs to be reevaluated now, then the refine and focus model might need to change.


Do you reckon it’s helpful to bring Matt and Verdi into this discussion, to help us decide whether one topic is enough, or if we need more than one?

Comment 5

6 years ago
Created attachment 657997 [details]
Refine and focus - links - expanded

This mockup visualizes the Refine and Focus topics if they were links rather than checkboxes. The currently selected item is bolded and colored black gray, and cannot be selected.

This mockup works in situations where we want to give user the ability to refine by just one topic rather than multiple ones.

Comment 6

6 years ago
(In reply to Bram Pitoyo [:bram] from comment #5)
> Created attachment 657997 [details]
> Refine and focus - links - expanded
> 
> This mockup visualizes the Refine and Focus topics if they were links rather
> than checkboxes. The currently selected item is bolded and colored black
> gray, and cannot be selected.
> 
> This mockup works in situations where we want to give user the ability to
> refine by just one topic rather than multiple ones.

Matt and I talked about this. We think refining by just one topic is all we need (at least until we have many many more articles than we have now).

I like this version with "All" being a choice so that you can undo your filter. In fact, after picking a second topic we might change that "All" to "Undo (All topics)" or something.

Comment 7

6 years ago
Sounds good. If refining by just one topic is all we need, then these mockups are good to go?

‘All’ is always a selected first choice. This way, user can back out of a topic selection without relying on the ‘Back’ button.

I should note that the mental model we use now is different than the checkbox.

Instead of saying “click to narrow down, unclick to undo”, we’re using the mental model of of “click to narrow down, click another to go to another topic”. This is not bad; just different. Navigating laterally, rather than vertically. It’s like we’re switching from using checkboxes to using radio buttons.

Since you can unclick a checkbox, but you cannot unclick a radio button; and since link behaves similarly to radio button in that only one can be selected at a time; then having a link called “undo” is confusing.

It is different when the current selection is displayed elsewhere, usually below the sort and filter box, with an “x” right next to it. This “x” would allow user to erase a particular facet from the search result. But this system only makes sense if we allow user to select from multiple facets.

The really simple solution is to not worry about putting an “undo” link anywhere. To undo a filter, user can simply click on “All Topics” again, or hit the back button (which is not a taboo. Users love the back button). But make sure that the current selection is not clickable, and not colored like a link, so it’s not confusing.
(Reporter)

Comment 8

6 years ago
Great, it looks me like we are all on the same page then. Thanks, Bram!
(Reporter)

Comment 9

6 years ago
Ricky, for some reason this does not show up in scrumbugs, could you make sure we put this into one of the next sprints?
(Assignee)

Comment 10

6 years ago
(In reply to Kadir Topal [:atopal] from comment #9)
> Ricky, for some reason this does not show up in scrumbugs, could you make
> sure we put this into one of the next sprints?

I already had it in the next sprint :)

http://scrumbu.gs/t/sumo/2012.18/
(Assignee)

Comment 11

6 years ago
(Discussed with Rehan) Mostly common styles here, we just need to tweak the view to filter by an additional facet. 1pt
Whiteboard: u=user c=wiki p= → u=user c=wiki p=1

Comment 12

6 years ago
(In reply to Kadir Topal [:atopal] from comment #8)

Awesome. I am sure that implementation questions will come up when this bug is worked on, so please ping me when that happens.
(Assignee)

Updated

6 years ago
Assignee: nobody → rrosario
(Assignee)

Updated

6 years ago
Priority: -- → P2
(Assignee)

Comment 13

6 years ago
Landed and deployed:

https://github.com/mozilla/kitsune/commit/855a2bb6932800e6317185695749b381d35e82b1
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 14

6 years ago
Yay! This will help a lot of users tame huge lists of article.
You need to log in before you can comment on or make changes to this bug.