What I’m gonna point out here is the front-end from developer perspective and also, from broader aspect – for all kinds of user interfaces – desktop and mobile, native, hybrid, cross-platform, web, clock devices and more. There is whole another subject, science and aspect of User Interfaces and User Experience about – colors, position of the buttons on the screen and so on. There are studies how different colors triggers more – the users to click. Also important is their position – according to the screen size, how contrasting is to the rest of the page and many more small subtle tricks that one could try when creating interfaces.
In most of the user interface frameworks – there is a in-process soft thread (in some platform it may be hard(OS) thread/process/ that handle the interaction of the user with the visual components. On this thread – we as developers – must never do something heavy. Otherwise – the UI may get blocked, feel failed, non-responsive, stopped working. These operations may be – accessing file system (file/database), network operations, computation-heavy operations, loops and cycles that overwhelm the CPU. It doesn’t matter if your app is a Desktop Application, Mobile App of any kind (pure native, hybrid, cross-platform), Web Application and whatever. On Android – Shared Preferences is deprecated away, there are co-routines in Kotlin, Worker Manager Architecture Component and with the time there will come probably more. In my personal coding experience all meaningful work eventually moved to a Service – a background thread that is not attached to specific screen and every screen is doing stuff just locally (because it is mostly relatively fast – but don’t take it as guarantied).
Flutter’s dart has Futures, async keyword, Delayed functions and more, while currently there is still work on making things background sync/work be coded naturally.
The Web introduced Service Worker – a non-attached to the UI thread that could handle stuff even when the browser page is closed. AJAX and set Timeout are equivalent of AsyncTasks. So it is also evolving to the way apps on native platforms are made.
Always tell the user what you app is doing. There are several loading indicators – circular, horizontal, percentages, indeterminate or/and even just text saying something.
Disable action buttons after click! It prevents double-submit, so no duplication arises from the work of the user. With the combination of some loading indicator is super meaningful user experience.
Load the text based information or user interface frames (basic UI with placeholders ) – where things will appear first. Afterwords – more heavy components like images, gifs, video, audio or whatever that is in size beyond few – less than 50 kilobytes. Dev.to has a visual frame that is rarely changed between screens so they cached it with Service Worker to be displayed fast even with slow internet connection. YouTube is displaying square dimmed blocks where the images of the videos will be displayed. Many more examples could be given about good UX practices.
Cache offline resources, rarely changed data, even important user information/actions that may be postponed and synchronized to the cloud afterwords. As I said before, many of my apps got the need of this behavior – All screens to change only the local copy of the data and to trigger a background service to do the syncing.
Do mostly or even only the work that is presented to the user, especially in the beginning while the user has nothing displayed. I’ve implemented in the past in several apps – detecting how much data could the current device show – detecting orientation, calculating width and height of the screen and the user interface component – and loading the data in such chunks, so minimal work is done for the user to have what he has asked for. After that – depending on the need, more work could be delegated to a background service and it will bring better user experience on every new interaction. I think, this is what chrome is doing – pre-caching the links on the currently displayed page.
Several years ago there was a technical research done by twitter about what is the preferred way to do apps – server-side apps vs client-side apps. The search was – where is better to create the html that is displayed in the browser – on the server and loaded with AJAX directly or should AJAX load only the data and convert the data to html on the client? The result showed that at that time – in terms of speed of showing the content to the user – it was better the server-side approach. The server-side approach is also better for the Search Engine Optimization. No matter that it is a little bigger payload in terms of size (html tags + the data instead of just the data). But – What has won in the long term is the second way and for several reasons:
- The native apps have different and non-standard user interface components. To display the data on them – it requires only the data.
- Web was and in some sense is still a little bit clumsy because of several reasons – UI blocks (html tags), stylization issues, browser implementation differences and so on.
- The data may be cached not only for the purpose of display, but also for some business logic
- Having done the REST interfaces, a new way of displaying the data may be implemented without changing a single line of code on the server. It opens up the way for new ideas about the future – to re-do and to dress up in a new way the old wolf.