IE8 Charting Next steps

mike thompson mithomps at redhat.com
Wed Sep 26 18:50:28 UTC 2012


On Sep 26, 2012, at 8:30 AM, Charles Crouch <ccrouch at redhat.com> wrote:

> So my mind is beginning to spin with the options :-) Can I just clarify the different places we display graphs today, and the technologies we use to render them..
> 
> a) Dashboard: Resource Metric Graph portlet [Gflot]
> b) Dashboard: Resource Metric Graph: Live Graph [Gflot]
> c) Inventory: Resource: Summary tab : Activity subtab: Resource Measurements portlet: Sparklines [Gflot] 
^^^ Not GFlot but jquery sparklines -- assuming we would want to consolidate this to our standard and not have a one off (lower priority)
> d) Inventory: Resource: Summary tab : Activity subtab: Resource Measurements portlet (click metric name): single metric chart [iframe from portal war]
> e) Inventory: Resource: Monitoring tab : Graphs subtab [iframe from portal war]
> f) Inventory: Resource: Monitoring tab : Tables subtab (hit Chart Selected Metrics): multiple metric chart (really the same as (d) [iframe from portal war]

g) Timeline - which is really a specialized graph that I'm assuming we wouldn't change
> 
> Is this correct? Did I miss any?
That is it to my knowledge.
> 
> Mike
> -So is the goal you have to move all of the above graphs to a new graphing package? I presume this would give us a win in terms of lines of code to maintain/learn and consistency of user experience, i.e. the graphs on the dashboard work like the graphs on the Monitoring tab.

> -Given Gflot renders 50% of our charts already, can you remind me again of the advantages d3 has over it?
Visual appeal and flexibility. d3 has many more bells and whistles and can even do visualizations such as Resource Trees.  I'm assuming the purpose of GSoC project  was to have slick graphs (http://kraskniga.blogspot.com/2012/06/comparison-of-javascript-data.html). IMO: The GFlot graphs have an aged look.
If you just want to move off of portal.war then GFlot is the least effort way to go.
> 
> Thanks
> Charles
> 
> ----- Original Message -----
>> 
>> 
>> 
>> 
>> Soliciting input for next steps:
>> 
>> 
>> 
>> 
>> I spent yesterday messing with various combinations of excanvas.js
>> with aight.js and sizzle.js (also packaged in jQuery). This was
>> precipitated by the discovery that GFlot (the gwt packaging of
>> flot.js) renders canvas elements in IE8 via excanvas. So, knowing
>> that some form of canvas elements can be rendered in IE8 via a
>> polyfill (excanvas), I tried to add the extra functionality that was
>> needed in addition to excanvas (that I tested alone before) for the
>> d3.js charts to be rendered. This was NOT successful. I have not
>> seen anything in the forums saying there has been success with d3 on
>> IE8. And my three cross postings of this questions in the forums (
>> Quora, StackOverflow, d3 google groups) has gone unanswered.
>> 
>> 
>> The most probable solutions I see for next steps are (in order of
>> worst to best for IE8 users):
>> 
>> 
>> A) The current situation is that I have charting turned off for IE8
>> users in the Monitor Tab. I'm assuming that this means we would
>> leave the dashboard GFlot charts in for IE8 -- unless we want to
>> turn those off as well
>> B) Pursue server-side solution via Batik. This would give us a single
>> codebase, however, it is not proven yet (still a couple days work)
>> and IE8 users would get a static bitmapped rendering of the charts.
>> C) Use d3.js but use html bar charts (via divs) for IE8. The IE8
>> experience would be marginally worse but the codebase would be
>> fairly similiar as both chart types would use d3.js technology but
>> just different graph library solutions (html vs canvas/svg).
>> D) Leave the current GFlot charts in place and render them for IE8
>> giving IE8 users usable interactive charts. This would come at the
>> price of two sets of charting codebase. We would also need to
>> replace the iframe (portal.war) charts in monitor tab to GFlot as
>> well to be free of portal.war.
>> 
>> 
>> 
>> 
>> The solutions choice varies depending on where the priorities lie --
>> with IE8 users experience versus a cleaner codebase.
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20120926/ff23cfbf/attachment.html>


More information about the rhq-devel mailing list