On Sun, Mar 22, 2015 at 2:08 PM, Sriskandarajah Suhothayan <[email protected]> wrote:
> Data views and associated widgets need not to be in the same page, I > believe when clicked on a dataview navigating to another page will be more > clear, this is because If there are many data views then the current UI > will not be that user friendly. > Would this mean as an example that on a time based line chart of total sales , a click on the date point can navigate to the bar chart of a sale by the reigon for that date point? Another point is would it be possible to filter by time(hourly/daily/monthly/yearly) through the UI? Since this would be an important visualisation in our analytics story. > > Regards > Suho > > > On Sat, Mar 21, 2015 at 9:11 PM, Dunith Dhanushka <[email protected]> wrote: > >> WSO2 Analytics Dashboard serves as a common place to visualize analytical >> data that comes from both realtime(CEP) and batch(BAM) datasources. Goal of >> this dashboard is to create a dashboard and add visualizations to it with >> less effort. >> >> Below describes the concepts,components and internals related to >> Analytics Dashboard. >> >> Dashboard, Widget and DataView >> There are three major concepts associated with Analytics Dashboard. >> >> *Dashboard* is a container for Widgets and there can be many widgets >> inside a Dashboard. >> *Widget* is the smallest unit of visualization. A widget holds a >> visualization such as bar chart,line chart etc. A given widget can exist in >> multiple Dashboards. >> >> *DataView* is an abstraction that specifies how widget should access >> data at the runtime. Simply put, DataView acts as a datasource for widgets. >> In the design time, widget can specify which DataView it is going to be >> bound at runtime. >> DataView resembles a materialised view in traditional RDBMS domain. A >> DataView can be created using a BAM's Analytics table or CEP event stream >> definition. Let's refer them as Datasources. There can be many DataViews >> created using a single Datasource. Upon creation, users specify which data >> fields(columns) should exist in a DataView and filter conditions applied >> against the datasource. Once a DataView has been created, users would >> generate a Widget and attach it to the DataView. Goal of this approach is >> to provide multiple representations for a single dataset. >> >> For instance, a dataset that is having region wise sales information can >> be represented using a bar chart, pie chart, area chart and a line chart. >> So a DataView can be considered as a self contained package that bundles >> metadata about datasource + collection of widgets that visualize the >> underlying dataset. >> >> >> Dashboard Components >> Analytics Dashboard application consists of following components. >> >> 1. *Widget renderer * >> Renders the widgets in a particluar dashboard >> >> 2. *Widget Generation Wizard * >> Provides a wizard based approach to generate a Widget and add it to a >> DataView. >> >> 3. *DataView Management UI * >> Performs CRUD operations on DataViews. >> >> 4. *BindingSource * >> Manages the runtime data binding for widgets in a pub/sub way. Basically >> this listens/polls the backend and updates the widgets in a Dashboard. This >> is a client side Javascript library. >> >> >> Main User Stories >> Following are the main activities that a new user would follow to add a >> Widget to a Dashboard. >> >> 1. Login to Analytics Dashboard >> 2. Create a new Dashboard. >> 3. Create a new DataView. >> 4. Generate a new Widget and add it to the DataView. Repeat this untill >> user adds desired number of charts to the DataView created above. >> 5. Select the prefered widgets that should go into the Dashboard from the >> DataView created above. >> >> Mock screens for the above steps are attached below. >> >> Run time data binding >> - All widgets in a given Dashboard register themselves with the >> *BindingSource* which is globally available to all dashboards. This >> happens when dashboard is displayed. >> - Widget registers with BindingSource by providing widgetId and the >> DataView name . >> - BindingSource internally maintains a subscriber list which is keyed by >> DataView name. That will look like following. >> >> DataView1 => wiget1,widget2 >> DataView2 => widget3, widget4,widget1 >> >> - There are two types of data providers that push data into >> BindingSource. >> - *PollingDataProvider* polls a remote endpoint while *PushDataProvider* >> listens for incoming data such as Websockets. Upon data arrival, both >> providers push received data into the BindingSource so that it will inspect >> the DataView that data comes from and call update() method of all the >> widgets subscribed to that DataView. >> >> - For batch datasources, there'll be REST based endpoint for data access. >> It'll be having an operation called 'getDataForDataView(dataView)' which >> will return a JSON response. PollingDataProviders periodically poll this >> endpoint to get data for a given DataView. Response data will be pushed to >> the BindingSource so that all widgets subscribed to that DataView will get >> updated. >> >> Artifact storage location and storage formats >> Dashboard and DataView has their own JSON formats. Please refer to the >> attached JSON files accordingly. Those structures will be stored in the >> Governance registry as JSON strings. >> >> Widget Visualization >> All visualizations in widgets are rendered using *igviz.js *library >> which is written on top of d3.js. Plese refer mail thread [1] for more >> information about igviz.js. Currently igviz supports chart types including >> bar,line, area, stacked bar, stacked area, map and bar chart with drill >> down capability. >> >> Extensibility/Customization >> There will be a clientside Javascript API available for the developers >> who intend to create custom widgets. They will bypass the DataView >> implementation and directly talk to the Analytics data service or a >> websocket endpoint exposed by CEP. >> >> >> Any thoughts/suggestions are highly appreciated. >> >> [1] RFC: Building a Generic Configurable UI Gadget for Analytics >> >> Regards, >> >> Dunith Dhanushka, >> Senior Software Engineer - BAM, >> WSO2 Inc, >> >> Mobile - +94 71 8615744 >> Blog - dunithd.wordpress.com <http://blog.dunith.com> >> Twitter - @dunithd <http://twitter.com/dunithd> >> >> >> Analytics_Dashboard_Mockups >> <https://docs.google.com/a/wso2.com/folderview?id=0B_cumaqOYEgufllVUThFUzJLZlR4Z2hrZW5ueUJmd1o4ZktzRzdGRUtONlVrZHdHVUU3OXM&usp=drive_web> >> >> > > > > -- > > *S. Suhothayan* > Technical Lead & Team Lead of WSO2 Complex Event Processor > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards Iranga Muthuthanthri (M) -0777-255773 Team Product Management
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
