4. Why HTML5 Charts?
No back-end configuration
Don’t require admin privileges to deploy
Can be heavily customized – or not
Can be extended
Are supported by a wide array of 3rd party
tools, many of which are free
5. Agenda
The Web, HTML5, JavaScript, and charting technology
Technical underpinnings
3rd Party libraries
Browser implications
Simple demos
SharePoint as a data source
REST, CSOM, SharePoint Web Services and roll-your own
Case study – agile development team sites for Enterprise Project
Management
6. Out of Scope
This is a short (45 minute) talk!
Deployment
In depth analysis of code
8. Scalable Vector Graphics (SVG)
XML-based markup that is part of HTML5 specification
SVG-based markup becomes part of the browser’s DOM
Performance degrades with very large sets of data
Can attach DOM events (onhover, onclick, etc)
Can be manipulated in jQuery or any other javaScript Library
9. Browser implications – SVG
Chrome / Firefox – it “just works” in all cases
Internet Explorer – supported in version 9 and up
IE 8 and lower – most 3rd party libraries will detect SVG support
and revert to VML output.
SharePoint 2010
SharePoint 2010 will render VML output for ALL versions of Internet Explorer
10. HTML5 Canvas
Part of HTML5 specification
Graphics elements drawn via a JavaScript API
“Fire and Forget” – drawn elements do NOT become part
of the DOM
Can handle high-volumes of data with better performance
No interaction from JavaScript – must redraw entire
graphic
Cannot attach event receivers
11. Browser implications – HTML5 Canvas
Chrome / Firefox – it “just works” in all scenrios
Internet Explorer – canvas support starts with IE 9
IE 8 and lower – no canvas support and no fallback
SharePoint 2010:
Canvas will not work in Internet Explorer
12. Vector Markup Language (VML)
Developed by Microsoft for Microsoft Office (“save as HTML”)
Implemented in IE5,6,7,8 – but no other browser
Replaced by SVG support with IE9
A necessary evil
13. Popular 3rd party Libraries
Canvas
Chart.JS
rGraph
Flot (a jQuery plugin)
SVG/VML
RaphaelJS
Google Charts
HighCharts ($$ but includes great documentation and export capability)
14. Third Party libraries in action
Link to the library
Declare an element (either <canvas> or <div> (for SVG))
Create and populate an array of JavaScript objects to
store your data
Create an options object
Make an API call with your options object, data, and
container
17. The Data Layer – getting data from
SharePoint
REST Interface
Client Object Model
SOAP Web Services
Roll your own
18. REST Interface
Speaks the native language of the web server - HTTP
url-based, REST-ful query syntax
No CAML!!!
Based on ODATA standard
Works really well with jQuery
Can be used asynchronously or synchronously
Can access (in 2013):
List and site data
Social Feed
Search
External Lists
Taxonomy, Workflow, and more
20. Client Side Object Model (CSOM or JSOM)
Quasi-object-oriented API which wraps the REST interface
Familiar interface for .NET developers who might be afraid of the REST
interface syntax
Asynchronous only
Can access:
List and site data
Social Feed
Search
External Lists
Taxonomy, Workflow, and more
22. SharePoint SOAP Web Services
Have been around forever
Were the only way to get data in JavaScript in SharePoint 2007
Deprecated, but still VERY heavily used
Code written for 2007 will still work in 2013*
Can do a TON of stuff
Heavy payload, may have performance implications
Usually used in conjunction with SPServices
http://msdn.microsoft.com/en-us/library/sharepoint/jj193051.aspx
http://spservices.codeplex.com/
(* - more or less)
24. Public web services and “Roll your own”
Query services from sources such as Azure
Data Market or Programmable Web
Write your own web services, in
SharePoint, in the cloud, or wherever
25. Case study – Agile Project Management
Sprints and Tasks
Are we progressing toward our goal for this sprint? (Burndown Chart)
Breakdown of finished / unfinished tasks for a sprint
Drilldown capability to drill down from chart to individual tasks
27. DEMO - Burndown Chart
Current state – a SharePoint site with sprints and sprint tasks
Allow the user to select a sprint, and for the selected sprint,
Show the total number of story points and the ideal path
Render the progression of story point completion throughout the sprint
28. DEMO - Task status breakdown
For the selected sprint,
Show the uncompleted story points in a chart grouped visually by the
developer assigned to those tasks
When a developer’s “wedge” is clicked, show all the tasks assigned to that
developer for the sprint in a list
When a task is hovered, show the display form for that task so that executives
can see the comment history and other metadata.
My name is Derek Gusoff, and I have been working for Sogeti USA for the last five years, spending much of that time building client-side solutions on SharePoint.I live in Hell, Michigan (yes, really), with my wife and two three daughters.
Back in 2011 I was a part of a team that was using SharePoint to implement an Enterprise Project Management solution, which included agile projects as part of its mix. Since Agile relies heavily on charts, I thought it would be a perfect opportunity to use HTML5 and JavaScript to produce fast, attractive, easy-to-use charts that would provide easier access to data than ever before.Alas, we ended up implementing these reports in SSRS, and while they looked OK, I always thought we could have done something that was better-looking and better-performing and more functional. Today, I’ll show you what could have been.
Charts allow us to present data in a manner that visually conveys information to users better than raw data. There are a number of ways we can build charts in SharePoint: SSRS, Excel Services, Chart Web Parts.HTML5 Charts are an attractive option because they:Require no back end configuration – they can be deployed in something as simple as a content editorDon’t require elevated privileges to deploy – a user with contribute permission can deploy thisCan be heavily customized – or not – use the default options or roll your ownCan be extended – you can add click or hover events to drive additional functionalityAre supported by a wide array of 3rd party tools, many of them free.
In this talk we will discuss how to leverage the technology of the web to create dynamic, responsive charts. We will discuss the specific technologies that make it possible, and introduce some 3rd party libraries that abstract away much of the complexity. Then we’ll touch on browser support for these technologies and think about how to make the most with the browsers we have to support. We will also look at some simple demos that demonstrate how to use these libraries.Next we’ll focus on SharePoint and look at the array of possibilities for accessing data in JavaScript. Finally we’ll examine some real-world scenarios by implementing some use cases based on a site for agile project management.
Since this is a relatively short talk – 45 minutes - we will have to work quickly to get through all of the material. This talk is meant to be a high-level overview of the technologies and how to put them together in a SharePoint context, so you can implement a variation in accordance with your own business requirements.We will need to gloss over a few things, like:Deployment. The solutions can be deployed in a number of ways. They can be pasted into a Content Editor. They can be deployed in a custom Web Part. They can be deployed as HTML/JavaScript files in Farm or Sandbox solutions. They can be custom SharePoint Designer pages, as I have done here, or they can be deployed via a SharePoint 2013 App. Which approach is best for you is going to depend on a number of factors related to your environment and development skills.Step-By-Step. I am going to show you representative code for a couple of typical solutions, along with high-level descriptions of the technologies involved. It’s not a step-by-step because your requirements will undoubtedly be different. But if you understand jQuery, AJAX concepts and custom objects in JavaScript, you should be able to follow along.
There are two separate technologies that can be used to visualize charts in HTML5 and another older technology that is still around for backward-compatibility reasons. They evolved to solve different problems. It’s important to understand the strengths and weaknesses of each in order to make the best decision on which to use
Vector markup language was developed by Microsoft in the late 1990s and used in Microsoft Office applications for its “export to HTML” options, among other things. It was implemented by Microsoft in Internet Explorer 5 through 8 but was never supported by any other browser.VML is the only technology available in Internet Explorer prior to IE9, so it must be included in any solution that renders graphics. Fortunately it is usually implemented as a “fallback” technology in most of the commonly used charting APIs.
Rolling your own Canvas or SVG charting engine is possible, but not really necessary or feasible. A number of third-party libraries, many of them free, can be used to create dynamic charts in web pages.(might be useful to highlight some advantages/disadvantages of each one)
The REST interface works with the way the web is architected – request and responseThe REST interface is URL-based – you send a url to the server, it sends a raw responseIf you tell the server via the header to send JSON, it will send JSONThe JSON data object is accessed easily using dot notation
Code written in 2010 against CSOM will continue to work in 20132013 has expanded the functionality into Search, BCS, etcAsynchronous operation can quickly lead to complex ‘spaghetti’ code if not careful
One of agile’s biggest draws is its claim of transparency and communication, which is accomplished in part with the use of charts to show at a glance a team’s progress toward its objectives.With a burndown chart, teams can see early on in a sprint if they are tracking behind, and can closely monitor progress throughout the sprint.
During an agile sprint, teams can measure progress against the sprint’s goals by displaying their progress on a burndown chart. Generally a burndown chart shows the ideal progression of a sprint’s tasks (represented in “Story Points”) alongside a graphical representation of the story points completed at any point of the sprint. B y looking at the burndown chart teams can easily see whether they are on track for a sprint’s goals or falling behind.A burndown chart is normally represented as a line chart, with dates listed along the x axis (the bottom) and story points along the y axis (up the left side). The straight diagonal line represents the ideal path, and the other line represents actual progress against the sprint objectives.
The burndown chart consists of:A canvas elementJavscript code that fetches the range of values representing the ideal path of story point completionJavaScript code that fetches the number of outstanding story points at every day of the sprint.A call to the CanvasJS library, passing the element’s ID and the two arrays of valuesSome styling and option data.
Since we have user interaction baked into this use case, we should use SVG because it supports DOM events, while Canvas does not.To implement this, we need:A <div> element to serve as the chart containerCode to pull the tasks and sort them by developer and completed statusA call to Raphael that constructs the pie chartA click handler that opens the list of tasks and renders them to the pageCode that attaches a hover handler and “screen scrapes” the selected task’s view page
