Design options for dashboard

[bajiat]

As a continuation of dashboard re-thinking, work in dialog with the development team to create at least low-fidelity wireframes for dashboard. Optimally, try HTML mockups with interactivity to try different chart options and see how they feel from user perspective.

Related Issue

2024

[55]

Interested.

[Nazarah]

interested

[bajiat]

I will participate as much as I can, but the main assignees are @55 and @Nazarah

[Nazarah]

a few points discussed with @55 and @philippeluickx:

• does API owner wish to know which services are using her API? web based? app? specific platform? knowing this helps the API owner to decide:
• if security measures are needed to improve for web-based services?
• if API owner shoudd put more emphasis on a particular platform (ex. most API owners are using his API for android, having specific tutorial for using the API for android apps., etc.)
• how to improve and maintain the API as a product? (more tutorial, better documentation, improving performance, etc.)

[Nazarah]

Also showing information about showing API information

• what information and visualization API owner wants to see when s/he ahs only one API
• How an Organization manager wants to see API information when he has more than 1 API to manage? (all APIs? only down APIs? or both Down and Slow APIs).

[Nazarah]

Some ideas on determining overall system status from @kyyberi 's feedback

• If API owner has 20 APIs, and every APIs have an average response time below 30 MS --> System status can be shown OK
• 98.5% calls are below 30ms --> users are happy. (plumber reference)
• 90% and more call responses are below 30ms -> status green

Here is a sample reference about how GitHub shows its overall status

[Nazarah]

We also need to consider the default view of dashboard, now that we have both API Umbrella and EMQ as proxies and chart view would be different for APIs using different proxy. API owners should be notified that Dashboard view will differ from API to API because of the selected proxy. This is applicable if we keep on showing the 1st API when dashboard is loaded for the 1st time. An alternative is to prompt API owner to select an API. Afterwards, dashboard gets loaded.

[Nazarah]

A draft concept have been created about the new dashboard and associated view from ideas combined. After a discussion with @philippeluickx and @55 we have made the following proposals:

• questions and usecases arisen from the discussion should be added as separate versions in the sketch
• (atleast 3) customer journey are needed to show the usecases
• sketches should portray 1-2 usecases and be associated with specific customer journey.

Here are some images of the the combined sketches and questions:

Open Question: pixel perfect final wireframes for specific backlog issues regarding to dashboard epic?

[Nazarah]

Comments from the discussion with @ashakunt from API dashboard usecases

1. We need to consider dashboard features and functionality based on what kind of API we are using and monitoring. Admin API (ex. activating business account / locking an account / creating password), Service APIs (e.g. creating a ticket, submit a feedback) and Organization APIs (doing certain tasks, e.g. an API having an endpoint to send a push notification, etc.) have different purposes. So their visualization and monitoring would be different on Dashboard.

Also Dashboard should be used both for Overview and Monitoring. (suggestion of quick action as well?)

2. Average response time of an endpoint can be important (e.g. an API has 3 endpoints that created ticket by appointment, mobile and paper, respectively. Monitoring individual response time can be crucial)

3. possibilities of realtime action (e.g. Pinging an API endpoint, getting response time for that moment, etc.)

4. No. of calls may be suitable for some APIs, not all.

5. Monitoring specific endpoint. Customization of parameters that can be added to monitor for a specific endpoint. (e.g. Facebook API has 3 endpoints to view timeline in web, android and iOS. So specific services might be using a specific endpoint)

6. Configuration of thresholds for every metrics used in Dashboard.

7. Notification feature: whom to inform, how to inform (audio/video/email), scheduling notification sending time.

8. Time period (DD/WW/MM) may be more important for average response time, not all metrics.

9. Predicting/showing issues that might arise from change in value for a specific metric.

10. History

11. (possible future feature) Geolocation: overview of calls redirected to a specific server location (e,g, server located in Finland. Here, Response time and Pinging can be important in this case to know an monitor CPU overload and bandwidth usage of that specific server)

@55 could you take a look and see if I missed something?

[philippeluickx]

I have the feeling that there's a lot of ideas floating around here. There is the monitoring aspect and then the analytics. There is API content (e.g. response time), metadata (e.g. # of tickets opened on apinf.io). There is different roles and needs.

Would it make sense to first do a broad analysis of all the information that would make sense, outside the scope of dashboard? Think about what questions all the different roles have. After this we can then focus on what knowledge is the most important and would fit in an overview.

[brylie]

After reading and reflecting over the past week, I believe it is important to take a step back and consolidate our thinking about the dashboard project. We have a lot of ideas, sketches, and an active discussion to draw from.

The general overview we should produce is known as a project brief. The project brief describes a project from a high level, taking into account stakeholders, viewers, goals, available resources, etc. I have started to draft an APInf Dashboard Brief document, and contributions are welcome.

[55]

@bajiat should be close this?

[bajiat]

@55 yes, we should close this.

[brylie]

I have expressed concern about the current design proposals during daily. To summarize my concerns:

1. we were only presented with a single design option
   • there may have been other options discussed, but they were not presented for comparison
   • having only one design opption available, conversations turned to defending or shoehorning the proposed design onto customer needs and the 'dashboard' concept
2. developers were excluded from the design process
3. the wireframe does not meet our internal, or common, definitions of the word Dashboard
   • it does not summarize most information for at-a-glance, intuitive understanding
   • pagination is not a common feature for dashboards
   • the design does not help the user intuitively grasp the magnitude of values, rather it simply displays the raw numbers

[brylie]

We met to create a design brief, and created a shared definition of the concept of information dashboard.

[brylie]

Here is the current dashboard design proposal:

[brylie]

Also for reference, here is the current 'detail view' wireframe:

[brylie]

Characteristics of a dashboard

Stephen Few has worked extensively in the field of Information Design, and offers several characteristics common to Information Dashboards:

Dashboards:

• are visual displays
• display information for specific objectives
• fit on a single computer screen
• are used to monitor information at a glance
• clearly state their messages without taking up much space
• are customized to specific requirements (for a person, group, function, or otherwise)

-- Information Dashboard Design by Stephen Few

Dashboard mistakes we may be making

The current proposed wireframe may be making one or more mistakes common to dashboard projects:

• Exceeding the boundaries of a single screen
• supplying inadequate context for the data
• choosing inappropriate display media
• arranging information poorly
• highlighting important information ineffectively or not at all

Information Dashboard Design by Stephen Few

In addition, the current design wireframes

1. fragment the data into large cells and
2. take the viewer away from the dashboard context to get a sense of change over time.

Sharp contrast with current dashboard

The proposed dashboard wireframes are in sharp contrast from our current dashboard.

The change from a rich data representation to a grid of numbers might surprise our users who are already familiar with the data dashboard.

Examples of information dashboards

We can draw on the experience of other dashboard designers, and build a unified display similar to the following:

---

Information Dashboard Design by Stephen Few

---

Information Dashboard Design by Stephen Few

---

Sales dashboard example from Information Dashboard Design by Stephen Few

---

UX Magazine - Four Cognitive Design Guidelines for Effective Information Dashboards

[brylie]

Here is a sketch of one possible dashboard design based on the current wireframes and the UX Magazine article Four Cognitive Design Guidelines for Effective Information Dashboards

[kyyberi]

Close it

[bajiat]

Among the wireframes/designs made by @55 and @nazarah were also such that they had some of the charts incorporated into the overview site along with the numbers. Based on the discussion in the meeting we had as a team, the first view was simplified. So the design alternatives have been shared, but they were shared in a meeting.

Also, I would say that initial design should be made by the designers without the developers. Dialog takes place after the initial design. (Besides, in our case there was a developer involved from the start, since one of the designers is also a developer.)

Closing the design options issue.