On all project pages there is an activity graph. See http://infrastructure.drupal.org/drupal.org-style-guide/prototype/core.html for an example

What markup should be generated such that it's easy and nice to style?

Comments

sagannotcarl’s picture

Here is a thread talking about producing the graphs: #371987: Implement sparklines for project pages

dww’s picture

Status: Active » Closed (duplicate)

We're not going to generate sparklines in HTML at all. Either we'll use a jQuery sparkline library and render the graphs in the browsers, or we'll use something like the sparkline module and render the graphs as .png files and cache them.

dww’s picture

Title: Figure out what markup should be generated to produce activity graph » Project sparkline meta issue: jQuery lib vs .png generation?
Component: Drupal.org theme » Drupal.org module
Status: Closed (duplicate) » Active
Issue tags: +sparkline

Actually, we still need to figure out if we're going to use the jQuery lib or generate the .png files locally. It probably wouldn't hurt to leave this issue open for that discussion, and in general to keep tabs on other general project sparkline implementation details.

FYI, all issues about d.o sparklines:

http://drupal.org/project/issues/search?issue_tags=sparkline

kkaefer’s picture

At NowPublic, we're using jquery.sparklines.js for creating these graphics. This is because we have graphics that change quite often (every couple of minutes) and regenerating thousands of graphics on the server every couple of minutes is not all that great.

Let's do a short comparison:

Generate PNGs
=============
+ compatibility; basically every device will display the sparklines
~ rendering speed; loading PNG images might or might not be faster than generating them on the client
(I don't think there's a big difference. 10 PNGs have probably the same file size as the compressed/gzipped JS library (4-5 KB)
- A way to flush cached sparkline graphics is necessary
- Server side generation of thousands of PNGs might put some strain on the server

JavaScript Sparklines
=====================
+ flexibility; changing the look, size and format of the diagrams is easy and fast
+ scalable; d.o just has to output the raw data and jQuery/sparkline.js will take care of the rendering.
~ compatibility; most browser support it (including IE with excanvas), but some phones might not. JS is required. But sparklines are not ultra-vital information.

Neither solution is bad, but I think ultimately JS sparklines are easier to implement while still providing enough compatibility.

kkaefer’s picture

jquery.flot.js is an alternative to jquery.sparkline.js

dww’s picture

Sounds good, thanks for the summary. The jQuery sparkline library I know of is here: http://www.omnipotent.net/jquery.sparkline -- is that what you have in mind or do you have another option we should investigate?

kkaefer’s picture

flot (http://code.google.com/p/flot/) might be an alternative.

drumm’s picture

I think we want PNGs. They are compatible and we can put the date in the URL to invalidate old lines.

dww’s picture

Right, for completeness sake, I should point out we're using Google Charts for the usage data graphics, e.g. http://drupal.org/project/usage/drupal. We should probably be able to accomplish the same for these, if we wanted to keep using Google for this. I'd rather not use an external blackbox service for this, but it is another option to consider.

gerhard killesreiter’s picture

I think we should stop using an external service to display these graphs (was this ever discussed?).

dww’s picture

@killes: Of course it was discussed, in the issue queue, like nature intended: #326094: Change usage table of project using graph instead of table. You had every opportunity to object then. But, it was the easiest path to get something working without any major hassles for d.o. If you want to open a separate issue (and provide the code) to change the usage charts to something else, please feel free. This issue is about the project sparklines. I can totally support the idea of not using Google Charts for this, too, but I don't want this issue to turn into a discussion about changing the usage charts. Thanks.

gerhard killesreiter’s picture

gerhard killesreiter’s picture

I also need to point out that I do not regard an issue in the project* queue to be sufficient discussion WRT deployment on d.o. I do not neccessarily follow all p* issues.

aclight’s picture

In my opinion, these sparklines might be useful to sites that use the project module outside of d.o, so maybe this should be implemented in the project module itself instead of just in the drupal.org module. I'll let others make that call, since you probably have a better idea of where this is going than I do.

dww’s picture

@aclight: killes's comments here are why this is an infra issue. It's about what we can deploy on d.o. The actual sparkline-related code will all live in the project* modules themselves.

@killes: All project* issues are deployed on d.o. ;) I suggest you follow them, since I'm not going to duplicate every project* issue with an infra issue: "@killes, can I deploy [#xxxxxx] yet?"

lisarex’s picture

Project: Drupal.org infrastructure » Drupal.org Redesign
Component: Drupal.org module » Code
Issue tags: -drupal.org redesign

Moving to the Redesign project. Check here to see who has been assigned to implement this section and the staging server it'll live on during implementation: http://groups.drupal.org/node/37064

lisarex’s picture

Component: Code » D and E
Status: Active » Postponed
Issue tags: +drupal.org redesign

Assigning to D&E component and marking this as postponed. We can revisit after the minimum viable product of the redesign is live...

dww’s picture

Component: D and E » Home
Status: Postponed » Fixed

Status: Fixed » Closed (fixed)
Issue tags: -drupal.org redesign, -sparkline

Automatically closed -- issue fixed for 2 weeks with no activity.