Visualize project issue metrics on project pages

A dev site named 'metrics' is building, it should take maybe 45 minutes. This code can land in drupalorg_project. A solid plan for 7.x is needed.

This is so exciting and great. Thanks!

If Project is going to be providing the metrics in the first place, I think it should be responsible for conditionally displaying them in a sane way on project pages.

Although true sparklines don't tend to have labels, I think it'd be important to indicate the time scale of the graphs. Are these 1 week? 1 year? Could be anything just looking at the mockup.

Also, on the project page itself, "Participants" isn't immediately obvious. I think we need a better heading for that, or perhaps some description text (although I'd like to avoid that).

Do we have any metrics yet for commit activity? Looking at #1497332: backfill metrics collected by Sampler API it doesn't seem that way.

I think it's important to brainstorm some "user stories" for people looking at project pages to decide which of these things to display prominently. I think maybe 3 graphs is the limit for above-the-fold display like this.

However, it'd be great to have the others hidden by default and revealed if you want to look. So, perhaps an expandable box where the first 2-3 are visible but if you open it you see all the per-project metrics stacked on top of each other. Much like the UI bojhan is proposing at #1545922-62: [META] Issue page redesign. Ordering these will be important -- ideally the adjacent graphs will all be somewhat meaningful as you scan them.

Also, now that the dev site is building, should this still be assigned to drumm? Are you going to be driving this home?

Finally, it'd be great to get the UX team to look. Tagging accordingly.

Thanks again!
-Derek

Maybe better place for graphs would be not on the sidebar but beneath module description as on this prototype. There can be 2 (or 3) graphs next to each other and link to show more.

added a section on user stories and a link to http://metrics-drupal.redesign.devdrupal.org

I personally think these graphs are most useful vertically stacked since the horizontal axis is the same timeframe on all of them. So, you can see trends happening at a glance simply by looking up and down the graphs at a given moment in time.

To that end, it might even be better to have the labels "inline" so that there's no vertical interruption when scanning.

-\__/--\  Stuff
---\__/-  Other stuff
...

Instead of:

Stuff
-\__/--\
Other stuff
---\__/-
...

Make sense?

---

re: hunmonk:

- I don't see how providing a block in project* is any harder than doing it in a 1-off fashion in drupalorg_project. Yes, we want to get this live ASAP, so I'm happy to make an exception for our soft "feature freeze" in D6 so we can get this done and deployed. I just think it's weird that we'd provide all the logic to gather the metrics from Project* but then force every site that might care about this stuff to roll their own solution for display, when we could just as easily provide the display code directly in Project*. Nothing about these metrics (or their usefulness for display) is inherent to d.o, so that's not a concern. We're going to have to port them to D7 either way (and that should be trivial regardless of where the code lives). If the only question is getting it past mean old perfectionist dww, a) that's not going to be a problem and b) if it was, it'd be just as much of a problem in drupalorg_project as here. ;)

- Re: timescale -- yeah, I know the idea is 1 year of weekly data points, but my point is no one else knows that just looking at a sparkline without any labels. ;) So yeah, maybe something like "... for the last year" in the block title would be necessary.

- Agreed on commit stats elsewhere, I was just asking. Do you happen to know if we already have an issue about that open somewhere?

- Re: participants -- if all the metrics were about issues, the block title could be "Issue statistics for the last year" or something and then maybe "Participants" makes enough sense. However, there are also metrics about releases. So, not sure what to do there. Perhaps labeling as "Issue participants" will work.

- Re: user stories -- my point is that even deciding which of the 4 we've got now should be visible by default, what should require a click expand, and what order they're listed in, would all be easier if we had an idea who's looking at these graphs and why. I see no great reason to postpone thinking about this to another date. I'm not talking about a week of user research. I just put 4 proposed stories into the summary to get the ball rolling. While I was at it, I added a section detailing the available metrics we're talking about so we can all see that on a single page.

- I'm not sure we need a whole separate page for displaying metrics, at least not yet. I think an expandable box should be all we need for now. But, if that's considered too complicated for the initial deployment, we can punt to a followup issue.

Thanks,
-Derek

"@drumm: A solid plan for 7.x is needed."

"@hunmonk: i'm strongly advocating we aim these kinds of design decisions at the 7.x port of project, and for now on drupal.org, we do something simple in drupalorg_project. "

So, gang, lay it out for me.
1. Will accepting this new feature into 6.x now affect our 7.x branch later?
2. What's the level of effort to up-port it to 7.x?
3. Will it be a block that needs to be placed, or will it be a theme function which outputs directly into the project node's display?

Tagging temporarily so I don't loose this one.

I'm gonna assign this to myself for the time being, since I'm the one tweaking views_sparkline to provide the options we need to make it look like what we need.

One important option that I'm trying to fit into views_sparkline is the option to indicate and label the last data point's y-value as seen on: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR.

So more or less something like this: (obviously not part of bluecheese):

Here's a patch for drupalorg_project that adds three charts to each page.

For now I really think this does belong in drupalorg_project for the following reasons:

1) We need more than just a generic block for each metric, we want a single block that shows just the metrics we're interested in and that's too hard to do in just Project module.

2) Ideally to accomplish #1 we'd need to combine metrics from multiple modules into a single block and I can't think of a good way to do that in a reusable manner in contrib for now.

This patch requires the lastest 6.x-1.x of views_sparkline but should work with the sampler release.

Some better styling.

Whoops forgot to stage the correct hunks.

This doesn't seem to be playing well with some kind of caching. When logged out it seems that jquery.flot.js itself is not included on the page at all. This may be a partial issue with block caching too, since it's not re-building the block on cached pages since the block was built and cached on a page where page caching was disabled.

Ahh, forgot to say that you can preview this on http://metrics-drupal.redesign.devdrupal.org/project/drupal

The only 3 metrics we're displaying are all project_issue-related. I don't see why we can't just conditionally (i.e. if (module_exists('sampler'))) inject these sparklines directly into the "Issues for [Project name]" block we already provide.

p.s. is "Total bugs" really "open bugs"? If so, we should probably label it accordingly. If not, we should probably change it to be "open bugs" since "total bugs" isn't as interesting a metric since it's just always going to climb up and up...

At least in this case it's a tough call, since we're arguably going to want to add a least commits and maybe releases in there once we have that data, so we'd have to implement some kind of hook in project* itself for versioncontrol_project, project_issue and project_release to hook into. At some point we may want to expose some usage data via sparklines as well, so we'd also want to throw project_usage into the mix.

Here's an updated patch that at least fixes the open vs. total bugs label.

Okay, but we can figure out how to display those other metrics once we have them. For now, everything is about issues, so it seems easy to just inject those sparklines into the existing issue block and we'll cross the other bridges when we reach them. Putting this in drupalorg just in case that's the easiest way to generalize it later seems like a bad strategy. If what we want to display in step 0 is all about project_issue, IMHO that's where this should live...

I'd don't like the idea of sticking this into project_issue as I'm afraid that by the time we launch it (get usability and performance review, etc), we could end up with metrics that aren't in project_issue.

If we're going to go to the trouble to move this out of drupalorg and try to find a proper place for it to live, I'd rather just go ahead and move it into project and implement a metrics block in project itself and a hook that allows project_issue, project_release, and versioncontrol_project to add their metrics to the block.

But even that is still a little risky because we may need to change the style of the charts for d.o itself at some point which either means updating all these modules, or overriding all the views from 3 or 4 different modules in the database (or in drupalorg, I'm not sure how to override a view from code, but I'm sure it can be done...).

I'm gonna split this into two issues because I think we're going to need a generic solution sooner rather than later. Anyone that wants to run with adding this to the issue cockpit block should go for it.

http://metrics-drupal.redesign.devdrupal.org/project/ctools has empty sparklines. Not sure what's going on. But, it points out that if we're missing data, it'd be better to not try to render these at all.

That's the block caching for the issue cockpit kicking in. Since it's caching that block there's no call to theme_flot_graph and no call to drupal_add_js and no jquery.flot.js on that page (you can view source and verify that directly). Either dump the caching on the block or apply hunmonk's patch for flot module itself to add it's js on every page. (Worst case, project_issue could add this JS on every issue page if the correct modules are enabled).

Isn't #1565970: include jquery.flot.js globally until flot module does it deployed on this test site? Shouldn't that fix it?

Looks good, such placement looks more logical than on top of the sidebar.
I have one slightly off-topic question - is it possible to make these graphs look like bar chart? (not now and in this issue, just on general)

#1580772: Add option to hide plot if no rows returned seems like a win for what I'm talking about in #27. There are *always* going to be cases where there's no data, and I'd rather we just had a simple if (empty($stuff)) { #bail } approach of some kind than to blindly display empty headers assuming "there's always going to be data". This doesn't seem that hard to get it right, and will help prevent weirdness and potentially angry "bug" reports when we invariably hit those edge cases...

tagging so it's easy to find all the d.o-metrics related issues at https://drupal.org/project/issues/search?issue_tags=metrics

Needs latest screenshot.

tags

Here's the "Issues for [foo]" block (and the start of the "Resources" block) on the dev site (linked above):

http://metrics-drupal.redesign.devdrupal.org/project/ctools

Adding back tag, then.

This is really interesting! I would love for these visualizations to be available on the project page.

For doing this it is interesting for everyone to read, http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Obviously data visualization a field on its own, I have limited experience in this with only in financial applications. But in general its used for a quick overview, to possibly communicate a large event/trend - rather than small nuances. I am trying to avoid, using any design lingo here - feel free to slap me if something isn't clear.

With that in mind, we need to quickly evaluate whether there are large event/trends in these graphics. After looking at a bunch of projects, it seems to me that participants is in 80% of the time rather uneventful - with that communicating very little. So I would suggest leaving that one out, or picking a different time span.

In general, I feel we can communicate far more if we have these in the content area at full width. Just like designed a long time ago, by Mark Boulton. However dww told me, that we want to avoid iterating over this to much because of time constraints - so I am fine with initially doing it in the sidebar, and as time permits do a block in the content area.

I would love to know if we have any statistics on how often links in the "All issues" block are clicked. It seems like we could potentially combine the sparklines and issue statistics. Right now I find this area of the sidebar, rather hard to scan - it grew organically and it feels a bit cluttered.

----- Review of the actual UI

I don't like putting text on both the left and right of the sparkline, since it seems to have negative impact on the readability. Mostly because vertically, there seems to be no alignment to the size of the graph and the text next to it. For more background on this you can see the link I provided, its common for graphs to align to the vertical bottom of text when you have text on both sides.

I am aware that we have little to no control over the text size, so I would argue for placing the text to the right with "new issues: 11". That should solve most of the readability.

:).

Thanks for the review, Bojhan!

Yes, this block is getting a bit full, but I fail to see how putting these sparklines into their own block makes sense (as I've already explained above). And I'm *really* opposed to using different time scales for these graphs, since I believe one of the main benefits is the ability to scan and quickly identify trends + significant events. If there are multiple time-scales in use, you can no longer compare the metrics with each other.

It's true that the # of unique participants is probably going to be mostly uninteresting, but in the cases where it is interesting, it's interesting. ;) At some level, we're just guessing here. I'd rather release early and release often then try to map out exactly what's most useful/interesting for months without any actual practical data on if/how these visualizations are being used.

In terms of the sparkline labels, the point of the "11" is to label the red dot at the end of the sparkline so you have some sense of the vertical scale without actually bloating this into a full-blown labeled graph. With Master Tufte as our guide, we could have the "11" in red to match the red dot in the sparkline, although that might clash a bit with the color scheme in bluecheese, etc. That said, some of the sparklines in Tufte's examples use the title on the left, graph in the middle, and the end point label on the right, just like we've got. But, if you really think the order is making it hard to understand, we could attempt re-shuffle things.

However, I'm concerned about spending a bunch more effort in here. I'd rather not have perfect be the enemy of the good, and this is already way overdue for deployment.

Also, a full-width chart inline with the body seems like visual overkill, dwarfing things like the project description, download table, etc. While I think metrics are useful and important, I don't think they should be the MOST OBVIOUS thing on the project page. Views currently has 2031 open issues, 659 of which are bugs. Is that because it's buggy and broken and will break your site? No, it's because it's the most-used contrib in all of Drupal, has a gigantic user base, and a relatively small team of maintainers to triage the queue. These can be subtle distinctions that not everyone is necessarily going to have the context to understand. So, if you open up this project and see a big obvious chart showing "659 OPEN BUGS" and the end user thinks "oh, crap, I can't use this!", we're doing them a disservice.

This whole project quality initiative is complex. We certainly can and should give people better tools, but ultimately, people need to be able to weigh a ton of different inputs and come to a reasonable conclusion. It's not going to work if we over-emphasize a few things as if they're a silver bullet to understanding the complex terrain of Drupal contrib.

I support dww in that we should not spend too much time on this right now and just deploy what we have. I look at this as a temporary solution with a plan to come back to the layout after D7 upgrade is done. I would love if after the upgrade we would take a look at the project page as a whole instead of discussing separate small bits of it.
Personally I'd love to have these graphs inline with the body and in a bar chart style instead of sparklines.

For the readability issue, maybe we still could give a try to smaller text size? So relation of the number to the dot was more obvious (see screenshot).

Ok, just commit it.

@tvn: nitpick -- "sparkline" refers to the size/density of the chart, not the chart style itself (bar vs. line vs. up/down vs. whatever). It's entirely possible to have bar-based sparklines. I believe views_sparkline already provides a mechanism for those. However, I'm not sure they're going to make these charts more readable -- seems like using more pixels without conveying any more info.

@Bojhan: sorry you're frustrated. I'm not trying to ignore your input, I'm just trying to manage scope and not let perfect slaughter good. If you think this isn't even good, please say so. If you think it's good but not perfect, let's at least get it done and then revisit perfect when we're not all stressed out trying to get d.o ported to D7. ;)

Thanks,
-Derek

@dww No worries, I don't get frustrated over d.o issues. I am long past that point :) If you don't want to incorporate my feedback that's fine.

I don't think I should argue for good vs. perfect, that question in itself is already biased. I always strive for us to do the best we can, for both small and large issues.

This one looks ready to commush and deploy, eh?

So I added an option to sampler to allow padding with zero or null values for missing data less than the items_per_page setting from the pager. I've testing this a bit locally and to simulate a new project with no backfill of old data, I took the token project and deleted all the data over a year old for the metric shown on the project page:

(For this example, ignore the bad data on the right side of the lines, since my database dump is about 2 months old I obviously don't have any activity in the last 8-10 samples.)

For the chart above I set the options in views_sparkline for left padding and to use zero for the pad value. This causes a line to be drawn at zero when there is no data, instead of making the line start only when there is data present. I'm not sure which option we will want for d.o, but I thought I'd include that for reference. Here's the same chart with the pad value set to NULL.

I'm also planning on adding more options for positioning of the labels inside of sparkline settings, so that it's easier to change things around by adjusting the view settings. (i.e. whether or not to vertically align the label on the last point, options to set the text for the labels using token replacements, etc)

Also, it'd probably be good to refresh the dev site at http://metrics-drupal.redesign.devdrupal.org/ and test this with up to date data from the live site before launching.

I spoke to hunmonk yesterday and he wanted to drive this home. He said there were a few other fixes he needed to make. Just trying to clear out my needs review queue. ;)

How much work will it take to get this stuff ported into D7 *before* launching it on drupal.org in D6?

A) Port the code in project that displays these graphs = ___ time.
B) Upgrade the flot module to D7.x = ___ time.
C) Upgrade the views_sparkline module to D7.x = ___ time.

Regarding B: flot has a Drupal 7 version with "better" views integration

No complaints with the patch.

Nice! :D

Now all we need is project ratings + reviews to add to this, and we'll have knocked off the #1 feature request for the Drupal community!! YEAH!

Great job! Know this will be very useful.

Excellent addtion, but I've noticed a problem with it on my dashboard:

I have two Issues blocks set up, one for one of my modules and one for core issues immediately below it. The graph for core issues appears in my module block, and the core issue block has no graphs at all. Screenshot attached.

@lambic, sounds like you've discovered a bug on your dashboard. Would you please open a bug report about it so that this ticket can remain as a 'fixed' task that's already been deployed to the prod site?

The problem mentioned by @lambic in #60 is continued here: #1743032: Dashboard issue blocks not displaying metrics correctly

FYI: if anyone wants to help port this to D7, please join the fun over at #1998044: Port issue metric sparklines in statistics block on project pages to D7 ;)

Thanks,
-Derek

copied info on the available metrics into a new section so we can see what we have to work with from a single page.

I think they went missing and need to be added back after the upgrade.

1) I know that sampler has been ported to D7, but I don't know where the individual metric plugins with D7 Project* are at.

2) That being said, I don't know if drupal.org is running the new sampler and plugins.

3) I still need to port views_sparkline to D7. :(

There are some patches there to start which is good #1770356: Port views_sparkline to D7

1) Some basic work has been done on them, but they have had little QA since they are not visible.

2) Sampler's nodes, comments, and users; and project_release's new_releases metrics are running. project_issue's new_issues_comments_by_project OOMs.

3) We don't necessarily have to use views_sparkline. If there is a well-supported module that fits our use case, it can be considered.

#1998044: Port issue metric sparklines in statistics block on project pages to D7 is the 7.x issue.

Just out of interest what module was used to render the sparklines in the end?

Ahah, https://drupal.org/node/1998044#comment-8578121 explains all. Sorry for the noise!