Overview

UX design is key to ensuring an intuitive and visually appealing website. This page includes both Edensoft-specific and general UX considerations. UX design reviews must be performed by the engineering lead before submitting visual changes, but this page's goal is to list many of the things an engineering lead looks for and hopefully should reduce the number of issues engineering lead has to point out as well as improve a website going forward.

UX design may be subjective in nature, but there are 2 things to keep in mind:

1. Following common patterns found on other websites ([[UX Inspiration]]) can improve UX as the user can be reasonably expected to be able to use common trends.

2. Following consistent design patterns throughout our site can improve UX as once the user learns how to do it in one instance, they can easily use it elsewhere. Note that this does not mean that all existing UX design is (or ever was) good, so sometimes an existing pattern isn't the best choice or can collectively be updated.

UX design is critical as even if the data is perfectly ingested and processed, if the user can't access it intuitively it is all for naught.

Usability

From a high level, UX is exactly what it claims to be: the experience of the user. The user's experience is affected by several things, starting with the usability of the design, take uploading a file for example. Below is an ascending scale of UX:

1. An empty box that a user has to know to drag and drop a file into -> The user may never figure out how to use the upload at all

2. A box that states "Drag and drop files" -> The user now knows what to do but will have to manually go to their file explorer, find the file, and then drag it over

3. A box with a file selector button that states "Select file or drag and drop files". The upload fails sometimes and is extremely slow -> This is an easy to use interface but a slow frustrating experience.

4. Same as the previous but with a progress percentage and failure reasons -> Easy to use and transparent to the user, but still somewhat frustrating to have to wait and retry.

5. Same as before but much faster and automatically retries -> Easy to use with no frustrations.

UX starts with usability as a user who can't perform the task they want to is not having a good experience. As such, usability should be the first and most important consideration. Ask yourself "Is this design easy to use without any explanation?" and/or perform a usability test by seeing if someone else (perhaps a test team member) can use the design without any hints. Again, no matter how great the rest of the design is, if the user can't use the functionality the UX is bad.

After usability it gets more subjective and there isn't another singular item that affects experience. Instead it is the sum of many factors including performance, speed of access to information, amount/consistency of feedback, and visual appeal.

UX Design Categories

The book Usability Matters by Matt Lacey breaks UX into several smaller categories that need to be considered:

1. Context - The most important and most difficult to nail down. Ask questions like who, where, when, and why the users are doing this task and make sure the design supports this.

2. Input - Entering data should be as quick and easy as possible. Ask questions like "Are there any defaults that make sense?" and "Can I provide a list of suggestions/possible values?"

3. Output - Displaying data to a user should be intuitive and easily understandable. Ask questions like "Is the data clearly displayed and easily understood?"

4. Responsiveness - Ensuring the user never feels like the page is just sitting and doing nothing. Ask questions like "Is there any feedback I can give or animation I can show while they wait for this?", "Can I make this faster?", and "Do they need to wait for this action and/or is there things they can do while waiting?"

5. Connectivity - Given our setup this isn't very applicable.

6. Resources - Network bandwidth, server processing, and database access are some of the main resources our software deal with. Ask questions like "Is loading this really necessary every time (lazy load)?" or "Is there a way to reduce the processing required for this?"

Website Consistency

As the website is a single product, it is important to maintain consistent behavior throughout to allow interactions and behavior to be predictable for the user. Deviations from the existing paradigm of the web interface may be allowed so long as there is a good reason that leads to a more-favorable user experience. Below are some ways that the website should maintain consistency to ensure a cohesive product.

General

1. Default sort is usually by most recent.

2. Loading indications should be used anytime an asynchronous action is taking place to ensure the user always knows when they are waiting for something.

3. Searches ideally highlight the matching aspect.
   [[File:HighlightedSearch.png|250px]]

4. Require confirmations from users for major (undoable) actions.

5. Provide feedback for completed asynchronous actions.
   [[File:SuccessfulFeedback.png|150px]]

6. Include submit/save buttons for editable elements so the user knows when they've submitted their changes.

7. Avoid visual shifts. If a shift is necessary, shift content down so that the user does not lose there place conceptually or with their mouse. This is most obvious in windows where expanding a section may cause the window to need to expand. So in that case the header of the window should remain in place (if possible) and the bottom of the window should expand downwards.

8. 24-hour timestamps should be used when displaying a date/time. For the date, tactical sites use the format ddMonthYY (26Oct20) while our other sites use the two-digit month followed by the two-digit day and then the four-digit year, all separated by forward slashes (i.e. 10/26/2020).

9. For input boxes that have a max number of characters (i.e. 15 characters for an IP address), those controls should be given a fixed-width font and sized to fit exactly that number of characters. This will better inform the user about what they are expected to enter in those inputs.

10. Text alignment in tables (read down until the matching case is found):

    1. If a whole number or equally rounded decimal, right align as integers can be easily scanned with matching places vertically aligned (i.e. 1, 10s, 100s columns line up vertically)

    2. If a list of items or a sentence, left align to more easily allow finding the beginning and/or comparing item by item in a list.

    3. Anything else, center.

Interactions

Consistent interactions are important to ensure that the user knows what to expect when they do certain actions and they know how to do the same action in different places.

Drop-Downs

1. When a drop-down is focused on, pressing the spacebar or enter key should open the drop-down.

2. Once open, the up and down arrows should highlight different options.

3. Once open, pressing the spacebar or enter key should select the highlighted option.

4. The arrow keys used directly on an unopened drop-down, should immediately update the selected item.

Tabbing

Refer to the below example with numbers indicating tab order:

1. When a user tabs through controls, the controls should be focused on in order from top to bottom, left to right (note number order in example form).

2. Only expected/important items should be tabbable. Note in the example that things like the window close button and the cancel button are not tabbable.

3. Tabbing should be used to improve efficiency, so when thinking through the keyboard interactions think to yourself "Will this be helpful to a user performing the expected task?". Note that this often means that adds should be the focus of the keyboard interaction as deletions and edits are more rare tasks.

Buttons

1. Pressing the spacebar or enter key on a button should click it.

2. When a button performs an action in place (i.e. doesn't cause a postback or open/close a window) consider where the focus should be afterwards.

Windows

1. When opening a window, the user should be focused on the first element of importance.

2. Pressing the escape key on a window should close the window.

3. When a window contains separate sections to navigate through (i.e., a forward or continue button exists), pressing the enter key should click the forward or continue button even when not focused on.

Mouse

1. All interactive elements should have hover and focus effects (usually these should be the same). Ideally these effects raise emphasis ([[#Emphasis|Emphasis]]) often by changing to a brighter color or adding additional size/color via a box-shadow.

2. All interactive icons should have a tooltip label on hover.

3. Disabled elements should be obviously disabled by reducing emphasis ([[#Emphasis|Emphasis]]) and should not have any mouse or keyboard interaction.

4. Visualizations should have consistent mouse interactions but the exact choices are still being decided ([http://qacomplete/Common/?ProjId=11874&Tab=AgileTasks&Form=AgileTasksListing&Action=Edit&id=29545&subaction=edit Outstanding Task]). Until finalized the basic interactions are:

   1. Single click for selection

   2. Left click + drag for pan

   3. Scroll for zoom

   4. Double click to zoom in

Hamburger Icon

1. The Hamburger icon, or the icon with 3 lines stacked on top of each other, can either have the purpose of providing less used setting/O&M information such as the PTT GUI on Tacta or the setting bars for most search engines, or it can also complete complex management of the most used portions of the system like in the current Amazon GUI. In the first case, the hamburger icon should generally be found in the upper-right of the screen, which is less regularly found and used. In the second case, the hamburger icon is usually found on the upper-left, in order to open a larger page of options which are more regularly used.

Validation

1. An input should be validated when the user leaves it (i.e. blur or input event).

2. Validators should be hidden once the user begins to edit the invalid value.

3. On submission of a form, all fields should be validated.

4. Displaying overlapping validators is not ideal but is not an expected occurrence for a real user and so the look/layout of the form should not be hurt in order to avoid this.

5. After submission of an invalid form, the user's focus should be automatically placed in the offending element to allow for quickly fixing the issue.

Color Selection

The color scheme is currently still being hammered out and no official guidelines are decided upon. Until then see [https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/dark-mode| IOS Dark Theme] and [https://material.io/design/dark-theme.html%7C Material Dark Theme]. The finalizing of the color scheme is currently technical debt. The website uses a dark color scheme, as such, pure white should be avoided in all cases and the lighter colors of the spectrum should be used sparingly.

Color Guide:

• The white color scale should mostly be used for text or icons throughout the site as it is a high contrast and thus a higher emphasis.

• The base color scale are for larger areas, with the importance and level (darker for elements directly on the background and building lighter from there) dictating which brightness to use.

• Black should be used for shadows and for contrasting with some of the brighter colors (i.e. text or icons whose background is a brighter color).

• The primary color is a shade of blue and should be used in two cases:

  1. To indicate clickability

  2. To draw attention to an important item on the page

• Yellow is used for warnings.

• Red is used for errors. Note red errors imply that either they (the user) or our software has had an error, so it should only be used to indicate actual errors and not just unexpected or bad states as that would make us look guilty where we aren't.

Emphasis

One of the hardest and most objective parts of UX design is putting the appropriate emphasis on items.
This is important because to make an intuitive design, a user's focus must be drawn to the items that they are going to need. An element may be easy to understand but if the user never finds it, they won't be able to use it.
Test this by taking a quick glance at the page and seeing what jumps out and is noticeable right away (emphasized), compare that list to the most important actions on the page and make sure they line up.

When considering emphasis, ensure the important actions or information are what get the most emphasis and that minor elements don't receive more emphasis than they need.

Emphasis is driven by several factors, including:

Position

Users generally start in the top left, scan the top of the page, and then scan down the page from there. Placing an item in the bottom right corner therefore majorly reduces its emphasis. Inside a table the rules are slightly different. The two left-most columns and the right-most column are the three most emphasized columns.

Size

The bigger (relative to other items on the page) the item, the more emphasis given.

Color

The brighter the color, the more emphasis. In addition, the higher the contrast of the color with nearby elements and its background, the more the emphasis.

Motion/Animation

Used sparingly in our site to avoid feeling tacky, but can effectively raise emphasis.

Specific Design Tips

Whitespace

Whitespace on the page is critical to a page layout and the effective display of information. Whitespace should be intentional, not accidental.

Whitespace should:

1. Group items on a page. A lack of whitespace naturally groups items and added whitespace naturally separates items.

2. Improve readability. Good use of whitespace improves readability by making the page scanable and easily digestible.

3. Not be just wasted space. There should always be thought behind the use of whitespace on a page.

Screen space is often called "real estate", but it's not just any real estate. It's <i>beachfront property</i>. Use space to create the design you need, but do not waste space. It is immensely valuable and coveted.

Efficiency

An often-overlooked aspect of web pages during design and implementation is the amount of bandwidth they require when they are sent across the network. Web pages that are less flashy but require less bandwidth are nearly always preferable to pages that are content-rich but require more bandwidth, so web pages should be designed and implemented with efficiency in mind. In a similar vein, we should try to keep processing on the server low whenever possible so that we can process pages faster and keep more resources available for other processes/operations.

Use Lightweight Controls When Possible

There are often multiple controls which have similarities and can serve the same purpose. Their differences tend to come down to the amount of flexibility and customizability that they offer, usually with the more flexible and customizable controls requiring more logic and processing and producing more HTML markup in the end. If a simpler output is all that is required, it would be preferable to use the simplest control that suffices. For example, a Literal control emits directly onto the page as markup while a Label control creates a <span> tag around itself to allow for formatting of the contents of the control, so if all that is needed is to put text on the page without formatting, then the lower overhead of a Literal control would be preferable. A similar comparison would exist between an HTML table element and a Telerik RadGrid, with the HTML table being preferable if the grid doesn't need sorting, paging, or user interactivity.

Use AJAX When Possible

There are instances where a web page will need to periodically query the server for the status of an operation or for new data. When a web page needs to poll the web server, AJAX functionality should be used to minimize bandwidth usage since there is little overhead in the request and response. The most common method of using AJAX requests would involve the page methods feature introduced in http://ASP.NET 2.0. Page methods allow static methods for a page to be called directly from the client. It essentially involves the creation of a temporary web service for the page that handles the page method calls from the client. Controls can use Web API instead of page methods. If an update updates multiple pieces of the page, an AJAX partial postback can be used if there isn't a way to update the elements using a page method/Web API.

Disable Control ViewState When Possible

http://ASP.NET ’s ViewState is used to persist programmatic changes to controls across postbacks. The contents of the ViewState are stored in the page as a hidden field, so the ViewState for the page is sent to the client on each page response and resent back to the server on each page postback. There are a handful of situations where this is necessary, but for many controls, the ViewState does not need to be used and may be bloated unnecessarily by including data for these controls. The ViewState is enabled by default for all applicable controls, but if a control is known to not need its properties persisted across postbacks, then it is preferable to disable the ViewState property for them to save bandwidth.

Do Not Send Unnecessary Controls to Client

There are two ways in which controls on a page may be hidden from display to the user. The first option would be to apply CSS styling on the elements to not display them in the browser, which would involve setting the "display" style to "none" or the "visibility" style to "hidden". The second option is only applicable to server controls (those controls with the runat="server" attribute) and involves setting the "Visible" property on the control to "false" so as to not render the markup of the control to the page at all before serving it to the browser. Between these two options, the preference should be to use the "Visible" property and not render the markup of the control in order to keep the page size smaller if the control won't need to be displayed on the client between postbacks to the server.

Cache Files by Version in Query String

Cacheable file URLs should include a query string containing the release number. Cached files are beneficial for users because they avoid re-downloading files that they already have and that don't regularly change, such as JavaScript files, style sheets, and images. Content expiration for cached files should be set to a year, but since these files may change between releases, there needs to be a way for cached files to be retrieved anew whenever a new release is deployed in case those files did change. We accomplish this by including a query string for the resource URL that includes the version number in it so that it is different for each new release. For example, a JavaScript file called CommonFunctions that is located under the Scripts directory would have a relative URL that looks like “../Scripts/CommonFunctions.js?id=15.9.1.2”. For HTML markup (such as the JavaScript <script> tag reference, the constant will need to be included in the aspx file directly by including a server block such as <%= Constants.CacheableFileQueryString %> (or whatever constant name is used for the version number) to the end of the filename when referencing it. For server controls, the query string will need to be appended to the end of the URL from within the PageLoad event in the code-behind file. Be sure that this is wrapped within a “if (!Page.IsPostBack)” block so that it is only run once or else the query string will be appended multiple times on each postback.

User Feedback

Feedback should be regularly provided to the user for any action that they take or whenever the user is waiting on the system to do something. Responsiveness of the system is important in this regard as a long delay between the user performing an action and them seeing a result or response is time that the user is left wondering whether the system is working or not.

Provide Feedback for Errors

When an error occurs on the web interface, a helpful error should be displayed to the user. Ideally the error message would be direct enough such that the users can provide useful information to an FAE about the error that had occurred, but it shouldn’t be too technical. If the error involves something that is expected to resolve itself, then the error message could direct the user to try again later. If it is something that requires intervention, then the user should be instructed to contact the vendor. In this situation (as in any situation when an error occurs), an alarm should still be added to the database. Words like “Please” should be avoided in error messages. In general, keep error messages short and to the point (see [[Economy of Words]]).

Provide Feedback During Long Waits

There are many times on the web interface where a delay for the user will occur between the period when a user performs an action and the response is received from the server. Whenever one of these actions occurs and a long wait is expected, the user’s cursor should change to an hourglass, and a message should appear to the user indicating that they should wait for the page to finish. Examples of the types of actions where this message would be shown include clicking menu navigation links and clicking web grid paging links.

Validators

See [[#Validation|Validation]]

http://ASP.NET validators can perform validation on the client, server, or both. Before determining whether a validator is valid, it is best to explicitly call the validation function to ensure that the validator correctly reflects the current state. For the client, the built-in JavaScript ValidatorValidate(validator) function can be called (or the ValidatePage JavaScript function wrapping it that we've created can be called instead). For the server, the built-in Page.Validate() method can be called to validate all of the validators, and Page.IsValid can be checked afterwards to determine whether the validators are valid. When input needs to be validated, it is safest to validate the input on both the client and server. Client validation provides a better user experience as the error feedback is immediate, and server validation provides more security since client validation can be manipulated, circumvented, or disabled by users with advanced understandings of web pages.

Ease of Use

The web interface should strive to have walk-up usability where anybody unfamiliar with the system should be able to walk up to it and be able to figure out enough from the web interface to be productive and accomplish a given task.

Do Not Limit File Size Uploads

It is usually not possible to foresee the max size of a file that may be uploaded, especially when scalability is taken into consideration. For this reason, it is preferable to not include a limit on file size uploads. Since a value must be set for this in http://ASP.NET ’s web.config file, it should be set to the max allowable value of 2097151 KB (2GB). This value is set by the maxRequestLength attribute of the httpRuntime element under the system.web element of the web.config file.

Do Not Limit Web Page Timeouts

It is preferable to not include a limit on the timeout period for web pages since it is not foreseeable what the max size of a page may be or the max amount of time it may take to process. Web pages that are content-heavy and are viewed over a slow connection may take a while to be received by the client. Since a value must be set for this in http://ASP.NET ’s web.config file, it should be set to 31536000 seconds (1 year). This value is set by the executionTimeout attribute of the httpRuntime element under the system.web element of the web.config file.

Export in CSV Format

Whenever there is an option to export data from a web page, the data should always be in CSV format. This will allow the web interface to provide consistent behavior with exported files and also allow the user to easily import the data into Excel.

Remove Unnecessary Whitespace

Unnecessary whitespace tends to extend the length of the page and may lead to scrolling, which is not desirable since it hides information. Eliminating whitespace tends to lead to a more-compact design that can hold more information. For this reason, it is also important to remove unnecessary horizontal whitespace in addition to vertical whitespace.

Displaying New Reports

Whenever a page is being displayed that contains a report of some kind, it should appear in a new tab, window, or pop-up. This is because the user may want to mine info from it or compare data from that page to another page, and we would not want the user to have to navigate away from the report that they had just displayed because it had replaced the original window that they had open.

Avoid Page Scrolling When Possible

Requiring a user to scroll on a page increases mental burden since they cannot see everything at once, and it may even be possible that page options that are not readily visible when the page is loaded may not even be discovered by the user at all if they don’t scroll the page down to see them. For this reason, we should be biased against having scrolling on pages. There are some cases, though, where scrolling is inevitable, such as if a user chooses to display hundreds of rows of a grid. In cases such as that, we should either 1) place buttons or other user-interactive elements above the content which would cause scrolling, or 2) placing the content which would cause scrolling into a separate scrollable container which leaves room beneath it for the buttons or other user-interactive elements to be displayed without scrolling.

Avoid Unnecessary Levels of Precision

The user attempting to import records may in some cases care how many terabytes or gigabytes are being uploaded in a particular import, but the likelihood that the user cares about the number of bytes in an import is quite low, and would also be quite large. Engineers may have the desire to be as precise as possible when providing results to an analyst, but an important question when gathering requirements will be the level of precision actually needed. If the level of precision needed is only the whole number provided by the system, the user should not be provided six decimal places to be unnecessarily precise and take up large amounts of space.

Responsiveness

Actions Shouldn't Take Longer Than 3 Seconds

Users will get annoyed and frustrated if they have to wait too long for the web site to respond to their actions. For public web sites, studies have determined that a majority of users will abandon a site if pages take longer than 3 seconds to load, and this goes to show the level of user tolerance and frustration for having to wait too long on web site pages to load. Additionally, many long wait times also have an impact on user productivity using the system.