871567 - Create front-end for new dashboard metrics

Status: RESOLVED WONTFIX

(Mozilla Reps Graveyard :: reps.mozilla.org, task)

Description

[William Reynolds [:williamr]]

Using the sketches from bug 869017, I'll turn those idea into front-end code, which will be handled in this bug. The front-end code will then be handed off to engineers for adding the back-end implementation.

Comment 1

[William Reynolds [:williamr]]

I got some additional feedback from Pierros this morning with three suggested changes. 

1. Remove the People section, including the people 'cards' and the 'Email Reps' button. Pierros, can you confirm if this functionality is no longer needed or if it should be moved to a different page?

2. Use a non-table layout in the Reports section when a user is only viewing their own metrics (eg: The people filter at the top of the page is set to Mine). I will attach a wireframe later today, and this graphic shows the general direction: http://dribbble.com/shots/346293-Dashboard-Metrics?list=searches&tag=metrics

3. Make the filtering system more clear. The three filters are in three different locations (top left, top right, and half-way down the page). Pierros was wondering if there's a simple way we can change the layout so these are more clear and so it is more intuitive that each filter is applied after the level above it. 

For reference:
- Level one: People (Mine, My mentees, All)
- Level two: Interests (All, Accessibility, Automation, etc.)
- Level three (only the Activities section): Time and country filters

Comment 2

[William Reynolds [:williamr]]

The event attendance chart is nearly complete:
https://github.com/dailycavalier/remo/commit/4d40a9f667606e2792b241567e156c6159a0b1d5

The tooltips on mouseover aren't appearing in the remo codebase, but I created a demo with working tooltips here: http://jsfiddle.net/2nf97/

It seems that the tooltips div is not being appended.

Comment 3

[Craig Cook (:craigcook)]

I've found d3 hard to work with and possibly more complex than we need. A simple demo is just one chart with hardcoded data, but the real thing would need to be dynamic and would need to use the same code to render multiple charts at a time (thus requiring multiple data arrays and keeping them organized). The data would probably need to be fed into the script as json or something. I didn't dig into d3 far enough to work out how to do that, though I'm sure it's possible. It just seems like it might be a pain.

Another script (and what I'm really favoring at the moment) is Visualize, which parses an HTML table and generates a chart in canvas. http://www.filamentgroup.com/lab/update_to_jquery_visualize_accessible_charts_with_html5_from_designing_with/

I've got Visualize working well and it looks great, but the real problem is the data itself and how to structure it. I'm actually not sure a bar graph is the best way to present this information at all. In the d3 example you put together I can't really tell what I'm looking at. It shows me that most events are small, but is that useful to know? It seems like what we really want is a comparison of how many people sign up in proportion to how many people attend, but the chart doesn't show that.

Should we discuss just what data we're trying to illustrate first and then find the best way to illustrate it? Maybe you've already discussed it at length, but as a newcomer I see that bar graph and have no idea what I'm supposed to take away from it. I think we can find a more meaningful representation.

Comment 4

[Craig Cook (:craigcook)]

(In reply to William Reynolds [:williamr] from comment #1)

Sorry for the delays but I'm finally getting there and I'll be able to hand something off momentarily to start fitting in the functional parts. There are a few things I'm still unsure about but these aren't necessarily blocking me from handing off what I've done so far, we can continue to refine and iterate.

> 2. Use a non-table layout in the Reports section when a user is only viewing
> their own metrics (eg: The people filter at the top of the page is set to
> Mine). I will attach a wireframe later today, and this graphic shows the
> general direction:

Do you have that wireframe? Or can you give me some example content and I can work out how to present it?

> 3. Make the filtering system more clear. The three filters are in three
> different locations (top left, top right, and half-way down the page).
> Pierros was wondering if there's a simple way we can change the layout so
> these are more clear and so it is more intuitive that each filter is applied
> after the level above it. 
> 
> For reference:
> - Level one: People (Mine, My mentees, All)

If we're removing the People section, does this go away as well? I assume even if we're not listing all the names we still need this filter, correct?

> - Level two: Interests (All, Accessibility, Automation, etc.)

I assume these are the tabs? I'd consider that navigation rather than a filter, so it's naturally going to be different if it serves a different function.

However, if the tabs are meant to be filters rather than navigation after all, then tabs probably aren't the best way to do this. For one thing, if you have very many interests the tab system falls apart quickly. There's only room for eight or nine tabs but there are dozens of interests and no apparent restriction on how many you can select. Then if you're viewing data for a bunch of mentees and it's one tab for every possible interest, that's not going to scale at all.

So in that case maybe we do have to lose the tabs and treat that as a filter rather than navigation, most likely with another dropdown.

Overall we probably need to rethink the UX for this page a bit and plot out the filtering system. It's a lot of information and you can view this single page in a lot of different states. We need to make the mechanism for switching states easily discoverable, then clearly indicate when the state changes and what state you're currently viewing.

Comment 5

[William Reynolds [:williamr]]

Attachment: Dashboard mockup for Myself view

Great feedback Craig! Some answers below.

(In reply to Craig Cook (:craigcook) from comment #4)
> > 2. Use a non-table layout in the Reports section when a user is only viewing
> > their own metrics (eg: The people filter at the top of the page is set to
> > Mine). I will attach a wireframe later today, and this graphic shows the
> > general direction:
> 
> Do you have that wireframe? Or can you give me some example content and I
> can work out how to present it?

I'm attaching a wireframe with example content. The information is the same as what we show in a table view, but when a user is viewing the metrics for 'Myself' we present this information with larger numbers instead of a table. Feel free to tweak or style as you see fit.

> > 3. Make the filtering system more clear. The three filters are in three
> > different locations (top left, top right, and half-way down the page).
> > Pierros was wondering if there's a simple way we can change the layout so
> > these are more clear and so it is more intuitive that each filter is applied
> > after the level above it. 
> > 
> > For reference:
> > - Level one: People (Mine, My mentees, All)
> 
> If we're removing the People section, does this go away as well? I assume
> even if we're not listing all the names we still need this filter, correct?

That is correct - we still need this filter. Thanks for asking!

> > - Level two: Interests (All, Accessibility, Automation, etc.)
> 
> I assume these are the tabs? I'd consider that navigation rather than a
> filter, so it's naturally going to be different if it serves a different
> function.
> 
> However, if the tabs are meant to be filters rather than navigation after
> all, then tabs probably aren't the best way to do this. For one thing, if
> you have very many interests the tab system falls apart quickly. There's
> only room for eight or nine tabs but there are dozens of interests and no
> apparent restriction on how many you can select. Then if you're viewing data
> for a bunch of mentees and it's one tab for every possible interest, that's
> not going to scale at all.
> 
> So in that case maybe we do have to lose the tabs and treat that as a filter
> rather than navigation, most likely with another dropdown.

Nice idea! Scaling the tabs is an issue as you mentioned. I think using a dropdown to filter by specific interests (or All interests) might be a better experience. Pierros, how does this sound?

Comment 6

[Justin Crawford [:hoosteeno] [:jcrawford]]

Craig provided this branch:

https://github.com/craigcook/remo/tree/bug-871567-dashboard-metrics

Created bug 891418 for integrating this into backend code.

Comment 7

[Pierros Papadeas [:pierros]]

I think this was covered in our in-person meetings. Do I still need to chime in here?

Comment 8

[Michael Kohler [:mkohler]]

I’m closing this issue as this is quite old now and it’s probably not needed anymore I’m cleaning up all issues to make sure we have a good overview of open bugs.

If you think this should not be closed, please feel free to reopen it.

Thanks!
Michael