Hi Suho, Thanks for the input!
Yeah, I understand the point. What I thought of putting dataviews and associated widgets together is to eliminate the extra click when browsing a dataview. And yes I agree with that when number of dataviews grow, the UI will be more cluttered. This can be addressed by using a carousel like structure to display fixed number of dataviews at a time. But anyway having a seperate page to display widgets for a given dataview is more clear and reusable IMO. Then we can buy more space in the new page to display widget related tasks such as selecting multiple widgets, adding them to a dashboard, searching widgets etc so that it'll reduce the complexity of the dataviews page. Regards, Dunith 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. > > 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>* > -- 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>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
