Try out a vertical slice of an enterprise-style application meant to display automobile crash data from Washington D.C.
Mockups for a network analytics alerting application, with commentary.
Network analytics is complicated and highly specialized. Setting up an alerting policy to be informed when specific events occur within a network can be intimidating given the terminology and the number of settings that can be configured.
The goal of this design is to simplify creating alerting policy templates as much as possible without sacrificing the customization options for power users to construct their own templates.
The design will also showcase how a team might respond to and interact with an alert once it has been triggered.
This is a typical table view for alert policies. Standard table features like search, filtering, and sorting are present. Many different types of information from the policy could be displayed in the table, but the most relevant data is who gets informed when the policy is triggered (the notification policy) and what happens after that (the mitigation strategy).
The general layout for the application is meant to emulate an IDE with multiple tabs. Network infrastructure is complicated and being able to quickly cross-reference different components is extremely useful. The application is responsive and could also be split into a dual-pane view when needed.
Previous iterations of the application had thrust the user directly into the alert policy template creation form, which could feature up to over 100 form fields depending on which options are selected. Users found this overwhelming and the form was the source of many support requests.
Here, top level categories are presented instead as a first step, allowing the user select the type of policy they want to create. On selection, they will be given further options to drill down into their desired function. At any point, advanced users can click on the Custom Policy button to make their own template from scratch.
Once the user has drilled down to their desired level of specificity, they will be able to select a pre-made alert policy template that handles most of the technical configuration.
Special care must be made in the descriptions of each template so that there is no ambiguity about what the template is doing.
When the user creates a new policy from a pre-made template, the bulk of the policy's form is hidden and only the fields that are relevant for the user to customize are shown. This design allows for 100+ form fields to be condensed down to a more manageable 5-10 depending on the template.
While the fields are hidden by default, a summary of all values appears on the right so that the user will have no surprises regarding the policy's functionality. This will also allow novice users to gradually learn which settings do what.
At any time, the user may click on the advanced mode button to view the full form. Once a template is saved in advanced mode, however, it will remain in advanced mode thereafter; this simplified view will no longer be available.
Advanced mode and custom templates both show the full alert policy form. Previous versions of the form had featured all the form fields on the same screen, but here they have been broken up into steps to make the form more digestible.
This first step mainly deals with the policy's metadata.
As with the simpler template form, the summary remains on the side. Because the form is broken into multiple steps, it can be used as a reference. The location of the save button at the bottom of the summary also encourages the user to review before saving.
The second step involves selecting the devices the policy will use, the metrics that will be tracked, and how incoming data will be compared to historical data to detect statistical anomalies.
While not pictured in this mockup, depending on which selection are made, additional fields may become visible.
Once the data has been select, the alert policy requires thresholds to be set. The thresholds determine when an alert is triggered based on conditions which can compare incoming data to a historical baseline or when a static condition is met.
Then, when the threshold is met, the notification and mitigation policies determine what is done once the alert is triggered.
Multiple thresholds can be set per policy. Again, while not pictured, there are hidden fields that will become visible depending on selections made.
The alerting dashboard is designed so that the system status is apparent at a glance. The 3 cards above the regular table layout each display the most pertinent information.
The table itself has the usual sorting and filtering features and the columns are meant to display the current person responsible for responding and the severity and status of the alert.
The manual alert button would allow a user to manually create an alert instance that does not correspond to an existing policy as there may be situations that occur outside what has already been setup.
Each individual alert instance will feature the relevant data graphed over time. The graph itself is interactive and has a scrubber below to more narrowly select a segment of data.
The red and yellow lines on the graph represent the threshold values specified from the alert policy and the triangles mark when that threshold was triggered.
While the graph above only shows the top data points, the table in the data tab below shows a full summary with additional information.
The timeline tab allows the user team to respond to the alert in a centralized location. System events like thresholds being triggered, notifications being sent, and mitigations being applied are mapped together with comments from the team on a chronological timeline.
The timeline is an essential feature that gives immediate visibility to the alert's status and helps organize a response. It can also be used for forensic analysis after the alert has been resolved.
Junction Gate Legacy is a browser-based science fiction game that is currently in development. Preview a trailer of the main features.
Current and planned features include a full supply and demand economy, a stock market, trading, a starmap, research, a utility AI system, ship building, espionage, combat, and diplomacy.
The video you'll see is a snapshot of a product in active development. The UI is currently being overhauled and features are still being developed. The present focus is to add more visual variety to the game to increase engagement and immersion.
An older project that showcases UX best practices for responsive web design.
Written when Bootstrap was in one of its first versions and when few competitors were available, the UI Framework is showing its age visually. However, despite its outdated visual style, the framework does showcase solid UX practices for responsive web design.
This tour will point out the highlights while allowing you to explore the rest at your leisure. Please keep the historical context of the framework in mind while browsing.
The charting library in the UI Framework is custom and features 6 different types of charts: area, bar, column, line, pie, and scatter charts. All chart types are responsive.
Each chart type has a number of configuration options and full API documentation. Scroll down the page for demos of the line charts.
Even today, there are not many front-end frameworks with built-in form validation. Fields are validated through data-attributes. While such an approach would not be appropriate for a modern framework like React, the focus here was an easy API.
At the time the UI Framework was first created, icon fonts were not widely used. This set features 326 unique icons, laid out in categorical fashion. A few of the icons have a small rendering issue.
One of the small details of the typography for the framework lies in the attention to vertical spacing. You notice that the lines for each column always line up with each other.
The responsive tables are another feature that stands out as each item will be matched with its column heading on mobile sizes, effectively allowing the entire table to be read by rendering it at a width of only two columns.