Simple unit converter app aimed at reducing interface bottlenecks common to so many similar converter apps. Built with only web technology and deployed as a PWA for use on mobile devices, allowing state saving and offline operation.
Latest version available here.
After years of using a variety of unit converter apps from the usual mobile app stores, a pattern of basic frustrations began to show itself:
- units are hidden behind a category list
- no way to save favourites
- doesn’t remember last conversion (either units or amounts)
My own need for unit conversion is almost entirely due to the US persisting in using an outdated measurement system, and then people from the US forgetting that the internet also exists outside the US. I often return to the same conversion (e.g. feet -> meters) and am only really checking in passing. As such I don’t need immensely accurate conversion, but I do need it to be fast and with as little cognitive load as possible.
When I open the app, I’m likely already using my short-term memory to hold onto the unit that I want to convert from, as well as the amount if I can manage it. I don’t need the added challenge of figuring out what category my unit might fall under, especially if the categories are named poorly and visually cluttered with icons. And then being punished by having to re-open the category list if I guessed wrong the first time.
A flat list that’s always on screen seems an elegant solution to this, though it does bring its own complications.
Firstly, categorisation needs to be dealt with - though rather than blindly reproduce the common design pattern, we should consider its intended purpose: to make scanning a list faster, as well as keeping related elements near each other.
After some iteration, it became apparent that grouping the units was itself enough to distinguish them as a category, even without the category title present. This aids scanning by foregrounding the unit names (what you’re actually looking for) without losing categorisation (related units are still close together).
Secondly, a flat list has the drawback of locking the two lists together as they scroll. For a category with few units this is fine, though height becomes a problem with larger groups as not all units can always fit on screen. Here the first complicating compromise is introduced to the interface to solve this problem: duplicating the selected unit names rather than simply using the highlights within the list as indicators. Now these are always visible directly under the amount inputs, regardless the list’s scroll position.
Thirdly, a single flat list requires us to scroll the list when recalling a favourite. Thankfully there is a (relatively) new web API for this:
.scrollIntoView() to make handling this far easier than it used to be. When recalling a favourite, the list scrolls to show the top-most of the two selected units.
Statefulness & Favourites
Implementing persistent favourites, as well as remembering the last conversion (aka being ‘stateful’), both require storing data when the page or app is closed and retrieving it when next opened. Again, there’s a web API for this with
localStorage, making this reasonably trivial in a modern browser.
During use, the system maintains a simple
settings object to keep track of changes as they happen and respond immediately. Each time a change is made in the interface, the system waits one second then saves this object to the
localStorage where available. This delay in saving helps reduce performance dips when changes are being made rapidly.
Upon startup, the system checks for the availability of the
localStorage API, checks that its own storage variable is present and that it isn’t empty, then parses the contents to return the system state to the last saved. If any of these test fail, it falls back to the default state.
Visually, settings and favourites are implemented as modal sliding panels, on the left and right respectively with their accompanying icons. The ‘add to favourites’ icon is of course visually similar to that of the favourites one, and deleting a favourite is implemented within the panel as a modal setting indicated by ‘x’ marks on each favourite.
The settings allow for the unit lists to be displayed as either text or symbols, and for the number input to be displayed at the top or bottom of the app. This bottom setting allows the input to be reached more easily with one hand when on a mobile device, though it does mean the input will move on screen when the soft keyboard is active. There are also a number of light and dark colour schemes to choose from.
Though reasonably feature-complete and useful on a mobile device, there are some potential future improvements. Primarily, it would be best to have the soft keyboard always visible as soon as the app opens. Currently, the input must be tapped to open the bring up the keyboard, adding an annoying unnecessary action.
Additionally, being able to open the sliding menus with a ‘swipe from the side of the screen’ action would give a more consistent experience when on Android devices, though this is not currently implemented. There are also likely optimisations to the code which could speed up the loading and initial build time.