“AppnBytes” is a new initiative that provides a rare look into the minds of our developers. Our very first entry is from Joe de Lange, Intermediate Front-End Developer at Appenate.
Let’s dive right in.
Optimising The User Experience
As a largely data capture-driven product, we have to frequently display large sets of data and configurable items in either tables (such as our entries or screens), or in lists with easy-to-use configurable cards (such as our connectors or app catalogue) that have expeditious response times and a smooth user experience. This can be a daunting task with so many models to consider for the different features we offer our customers, one which can make a platform such as ours sluggish with long loading times or sometimes with diminished functionality to keep complexity to a minimum. Our small team has figured out a winning recipe for ensuring our customers are not burdened with these issues.
First of all, start by constructing the basics of your page in pure HTML or CSHTML if your tech stack allows it. Lowering the amount of generated and injected structure and making use of templates and reusable structures will increase the speed at which you can add new features and also gives a good backbone to hang your server-side meat on. This will essentially give you the basic structure to initialise your views, layouts, and any script that might be present in your page of choice. Using this as your first step will allow easy styling of mass-used structures giving your platform a homogenous look and feel, reducing initial page loading times, and reducing the opportunity for tearing and jumping while loading content into your page.
Secondly, you’ll want to filter, render, and calculate as much as possible on your server side. Use partials and templates with custom fields in their models for things like auto-generated unique identifiers and classes for styling and scripting hooks, apply paging and filtering to database call results in your controllers before starting your page loads on the client side and use helpers like the ones offered out of the box in MVC to render repetitive data instead of injecting it when drawing your DOM. At this point, you also want to select the method you want to use to aid your page loading, like lazy image loading which will only start rendering an image into the desired section of your page as it scrolls into view shortening the loading time, or deciding whether you either hide a field or item by using styling or classes or just don’t render it at all leaving the DOM unaware of the item and increasing your data safety. These decisions require consistent behaviour and use throughout your site, also referenced as the convention, and require large overhauls if neglected in your design phase and form part of your site architecture.
Finally, as a user, the site can sometimes become overwhelming if all the data and possible actions are not well structured and the inputs and reactions from your product do not make intuitive sense. This is where best practices and standards come in, largely driven by styling and script in our case, this is what gives the user a sense of comfortability in use. Display descriptive error messages, be explicit about which field is causing which issue and why your site can’t save that form with that error. Use standardised colouring for standard actions. Green means go, red means no, and lastly, don’t show what can’t be used. There is nothing more confusing and frustrating than having too many options, especially if you don’t know if those options actually apply to the item in question. In this case, less is more.