Closed bajiat closed 7 years ago
Interested.
interested
I will participate as much as I can, but the main assignees are @55 and @Nazarah
a few points discussed with @55 and @philippeluickx:
Also showing information about showing API information
Some ideas on determining overall system status from @kyyberi 's feedback
Here is a sample reference about how GitHub shows its overall status
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.
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:
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?
Comments from the discussion with @ashakunt from API dashboard usecases
Also Dashboard should be used both for Overview and Monitoring. (suggestion of quick action as well?)
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)
possibilities of realtime action (e.g. Pinging an API endpoint, getting response time for that moment, etc.)
No. of calls may be suitable for some APIs, not all.
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)
Configuration of thresholds for every metrics used in Dashboard.
Notification feature: whom to inform, how to inform (audio/video/email), scheduling notification sending time.
Time period (DD/WW/MM) may be more important for average response time, not all metrics.
Predicting/showing issues that might arise from change in value for a specific metric.
History
(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?
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.
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.
@bajiat should be close this?
@55 yes, we should close this.
I have expressed concern about the current design proposals during daily. To summarize my concerns:
We met to create a design brief, and created a shared definition of the concept of information dashboard.
Here is the current dashboard design proposal:
Also for reference, here is the current 'detail view' wireframe:
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
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
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.
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
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
Close it
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.
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