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?
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
Comment #1
sagannotcarl commentedHere is a thread talking about producing the graphs: #371987: Implement sparklines for project pages
Comment #2
dwwWe'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.
Comment #3
dwwActually, 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
Comment #4
kkaefer commentedAt 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.
Comment #5
kkaefer commentedjquery.flot.js is an alternative to jquery.sparkline.js
Comment #6
dwwSounds 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?
Comment #7
kkaefer commentedflot (http://code.google.com/p/flot/) might be an alternative.
Comment #8
drummI think we want PNGs. They are compatible and we can put the date in the URL to invalidate old lines.
Comment #9
dwwRight, 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.
Comment #10
gerhard killesreiter commentedI think we should stop using an external service to display these graphs (was this ever discussed?).
Comment #11
dww@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.
Comment #12
gerhard killesreiter commentedhttp://drupal.org/node/428680
Comment #13
gerhard killesreiter commentedI 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.
Comment #14
aclight commentedIn 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.
Comment #15
dww@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?"
Comment #16
lisarex commentedMoving 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
Comment #17
lisarex commentedAssigning to D&E component and marking this as postponed. We can revisit after the minimum viable product of the redesign is live...
Comment #18
dwwAnd the winner is...
#912712: Use open source flot for graphing sparklines instead of Google Chart black box
Just cleaning up the queue.