45. Charting Library
• Flash, Silverlight etc are not the only option
25 | RUBY CONF 2011 | Sept-29 | Public
46. Charting Library
• Flash, Silverlight etc are not the only option
• Web based standards for building high quality charts
25 | RUBY CONF 2011 | Sept-29 | Public
47. Charting Library
• Flash, Silverlight etc are not the only option
• Web based standards for building high quality charts
• Should work on multiple platforms including mobile/ipad
25 | RUBY CONF 2011 | Sept-29 | Public
48. Charting Library
• Flash, Silverlight etc are not the only option
• Web based standards for building high quality charts
• Should work on multiple platforms including mobile/ipad
25 | RUBY CONF 2011 | Sept-29 | Public
49. Charting Library
• Flash, Silverlight etc are not the only option
• Web based standards for building high quality charts
• Should work on multiple platforms including mobile/ipad
25 | RUBY CONF 2011 | Sept-29 | Public
57. Configurable Charts
Chart Attributes
Dimension for x-axis
31 | RUBY CONF 2011 | Sept-29 | Public
58. Configurable Charts
Chart Attributes
Dimension for x-axis
Dimension for y-axis
31 | RUBY CONF 2011 | Sept-29 | Public
59. Configurable Charts
Chart Attributes
Dimension for x-axis
Dimension for y-axis
Filters for x-axis
31 | RUBY CONF 2011 | Sept-29 | Public
60. Configurable Charts
Chart Attributes
Dimension for x-axis
Dimension for y-axis
Filters for x-axis
Filters for y-axis
31 | RUBY CONF 2011 | Sept-29 | Public
61. Configurable Charts
Chart Attributes
Dimension for x-axis
Dimension for y-axis
Filters for x-axis
Filters for y-axis
Data on x-axis
31 | RUBY CONF 2011 | Sept-29 | Public
62. Configurable Charts
Chart Attributes
Dimension for x-axis
Dimension for y-axis
Filters for x-axis
Filters for y-axis
Data on x-axis
Data on y-axis
31 | RUBY CONF 2011 | Sept-29 | Public
86. Analytics and UX
• Power v/s Normal users
42 | RUBY CONF 2011 | Sept-29 | Public
87. Analytics and UX
• Power v/s Normal users
• Data focussed
42 | RUBY CONF 2011 | Sept-29 | Public
88. Analytics and UX
• Power v/s Normal users
• Data focussed
• Pareto Principle in context of UI: 20% of the functionality
is used 80% of the time
42 | RUBY CONF 2011 | Sept-29 | Public
89. Analytics and UX
• Power v/s Normal users
• Data focussed
• Pareto Principle in context of UI: 20% of the functionality
is used 80% of the time
• Interface design
42 | RUBY CONF 2011 | Sept-29 | Public
90. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
91. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
92. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
93. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
94. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
95. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
96. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
97. Build for ALL
43 | RUBY CONF 2011 | Sept-29 | Public
98. Build for ALL
IE6, IE7, IE8, IE9, IE10
43 | RUBY CONF 2011 | Sept-29 | Public
Next slide --> must be wondering why I have put emphasis on the word Enterprise\n
Next slide --> ruby in enterprise\nBefore we dive deep into the session, let me introduce the penetration of Ruby in the Enterprise.\nWe have been doing Ruby work for more than 4 years now.\n\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
Next Slide --> We had few design philosophies. The first one is simplicity\n
Next Slide --> We had few design philosophies. The first one is simplicity\n
Next Slide --> We had few design philosophies. The first one is simplicity\n
Next --> portability\n
Next --> security\n
Next --> consistency\n\n
The consistency in interface design is very important. For analytics appln, there are other irregularities which has to be taken care:\n     - Consistent unit of data\n     - Data format\n     - Abbreviations should have clear meaning\n\nNext --> scalability\n
Next --> multi-dimensional data\n
\n
\n
\n
Next slide --> Lets me share how we built the data platform.\n
3 step process to build the platform\nNext --> scalability\n
- Massaging, cleaning and aggregating raw data from various sources which are parked on raw staging tables.\n\n
- Build Kimberley Style Dimensional Data Warehouse\n\n
- Build application specific tables and olap cubes which were consumes for analytics\n- tables were flattened materialized views\n- cubes for analytics in the appln\n- due to security we had to make sure data is scedure which meant we have to segregate the aggregated and patient level data\n- in the upcoming slide I will show how data flows from source to application tier\nNext --> data mapping\n
\n
- safe haven for data\nLinking -- Sets of data from which the identifiable data has been separated and a ‘key’ added so that the data can be re-connected with its identifiers\nPseudonymisation -- replacing the patient identifiable components with pseudonyms so data processing can happen\n\n
\n
\n
Let us move on to something more interesting. Solving the problem building interactive charts using this dimensional data.\nNext --> Chart Types\n
\n
The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
\n
\n
Next --> Configurable charts\nThe business problem was to simplify the chart creation process. It should be possible to do a new custom chart with arbitrary dimensions (given an existing cube / table of date in the DW) and add it to the app with a few hours work.\n
\n
\n
\n
\n
\n
\n
\n
\n
So, few hours of chart configuration by power users would enable data visualization in different kind of chart.\n\nThe only problem left here to solve was communication between ruby and OLAP cubes in MS SQL Server AS.\n\n
SQL Server Analysis Servies exposes XMLA interface to communicate to OLAP Cubes.\nFor consuming cube data from SQL Server Analysis Services into our ruby application we had 2 choices. \n
Use existing libraries like olap4j which sits as a service between our app and Analysis Services. This would have meant, we would have bite the bullet of porting the app to JRuby \n
Build the ruby xmla interface ourselves, kind of olap4r\n\nNext slide --> Some principles we kept in mind while designing the XMLA interface in ruby\n
- the library should output data in JSON format for the charting library to consume\n- It should be agnostic to XMLA interface\n- Data security because cubes had dimensional data\n- MDX is pretty complex language. Stay away from becoming mdx validation.  \n\nNext Slide --> In the following slides we would see some code samples explaining the communication between AS and Ruby.\n
- the library should output data in JSON format for the charting library to consume\n- It should be agnostic to XMLA interface\n- Data security because cubes had dimensional data\n- MDX is pretty complex language. Stay away from becoming mdx validation.  \n\nNext Slide --> In the following slides we would see some code samples explaining the communication between AS and Ruby.\n
- the library should output data in JSON format for the charting library to consume\n- It should be agnostic to XMLA interface\n- Data security because cubes had dimensional data\n- MDX is pretty complex language. Stay away from becoming mdx validation.  \n\nNext Slide --> In the following slides we would see some code samples explaining the communication between AS and Ruby.\n
\n
- discover method\n- request type (mdsschema_cubes)\n
- discover method\n- request type (mdsschema_cubes)\n
- discover method\n- request type (mdsschema_cubes)\n
\n
\n
\n
\n
Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
