Dashboard — Users’ questions and expectations
As the new Dashboard is on the horizon, its time to reflect upon the questions and feedback received in the sneak peak.
From the June of 2017, APInf design and development team has been working on revamping the existing Dashboard to introduce the 3rd version. The process started with the design team sketching out rough drafts from existing usecases and own expertise. Interviewing users who need a monitoring Dashboard went in parallel and results from the interview were put into the evaluation and iterations of the drawn drafts. We finished our primary research and finalized our rough sketches into actual features at the beginning of July 2017. Based on the mid fidelity sketches, Dashboard epic was announced and is now being developed to add up the final touches. Monitoring and Notification part of the Dashboard is yet to be built.
On APIOps Meetup on August 8, 2017, we made a sneak peak of the Dashboard with mid-fidelity sketches in front of the present audience. We found out some insights and feedback about the design and people’s expectations. Today’s blog is all about that.
Audience asked us about the process that actually generates the Key Performance Indicators (KPIs) and other analytics for an API in the Dashboard. The information are obtained from a proxy to which an API is connected to. For example API Umbrella is a RESTful API proxy. Information like an API’s number of requests, average response time, etc. can be obtained from a proxy if the API in discussion is a RESTful one and is connected to this proxy via an API management platform. The information available is not limited to requests or response time only. API owners can drill down API usage based on response headers, IP addresses where calls are initiated from, endpoints to which calls are made and many other things if the proxy makes these information available and configurable.
The second query from audience was about availability of erroneous information and events for an API and their projection on a Dashboard. Again it depends on what information the proxy is able to provide. Also it needs to be known that what API users want to see as error information in the display. Having an API call response as 4XX in HTTP header can be considered as an error. Because with 4XX, the client application couldn’t send the request to the server hosting the API. Users can prompt in dashboard to show or download information about API calls having 4XX responses for all or a particular API endpoint.
The above question led to another query about customizing a Dashboard to show specific information. In our opinion from user data analysis, users should be provided a dashboard with a minimum required information that actually is significant if they want to monitor some trends. For APIs, we found out that API owners mostly want to see API requests, Average Response Time, Endpoint’s condition and perhaps new users who have made calls within a specific time period. A dashboard for monitoring API usage and performance can be displayed with the above KPIs for the start. Lets say, an API owner wants to see number of 4XX responses generated for a specific endpoint for last 7 days. S/he should be able to configure this setting with the use of Widgets. On saving the configuration, that widget should appear along with the main overview information for that particular API owner. A lot of widget ideas are possible to include in a dashboard setting. But we need to make sure the information can be obtained from proxies and the display of a widget maintains the definition of that particular API dashboard’s look and functionality.
The last question was about availability of widgets to mass audience. Are they free? Available for all users or some privileged ones? It all depends on how a company building a dashboard as a part of their API management wants to monetize it. There can be trial period for using all features (including custom widgets) for mass audience signing up to use the API management platforms. Alternatively there can be free and paid usage tiers for the dashboard with extra features available for customers willing to pay for it. For free tier usage, there should be sneakpeaks of possible Dashboard customizations that can be enabled with payment options. For this phase, we mainly focused on building Dashboard for API owners. However, the same idea can be followed to monetize a dashboard specifically designed for API consumers, who might want to track down their usage quota and relevant information.
At the end of the session, Jarkko Moilanen talked about “Flow” API implementation from APInf platform roadmap. The API be collecting all performance and usage information from the proxies being used in the API management platform. API owners, who might not have the preference of using this Dashboard would be able to inject the same information in their own service monitoring platform or development platform. The API in question would be the building block to make information available for projection in those platform specific Dashboards.
Here is the session for Dashboard that was presented in the APIOps Tampere August Meetup:
