Rebuilding Noko’s Dialogs for the next 10 years
Noko’s been undergoing a ton of infrastructural changes this year. Not only did we migrate the app to run the latest Rails, we’re also revisiting Noko’s design to give it some extra sparkle, and we rebuilt our macOS and iOS apps to be future-proofed and ready to use the latest features. That’s still underway, but I wanted to talk about a crucial part of the UI we’re revisiting: Noko’s dialogs.
Why start with Noko’s dialogs?
Dialogs are a big part of Noko’s user experience. From project settings, to report scheduling, budgets, entry approval, inviting users,…the list goes on. So getting them right directly improves the everyday experience of using Noko.
So much has changed in the browser landscape since Noko was first launched (2008!) giving us the tools to dramatically overhaul them. And rather than patch together fixes, we want to create a solid foundation to build more Noko features. So we revisited them from the ground up, using lessons we’ve learned from the past 10 years of web development.
The design tenants
They should be easy to work with
Because they’re everywhere in Noko, we want a straightforward pattern that feels natural for our development team. That way, we can spend less time fiddling with code, and more time building great features and tools.
Prioritize Accessibility & Power-user friendliness
The previous version of Noko’s dialogs were not as accessible as we wanted them to be. This is a solvable problem by combining browser advancements and deliberately prioritizing accessibility. An Accessible UI is a power-user friendly UI, which means that you can get more done with Noko, faster.
Fast & stable out of the box
How we’re achieving it
Once we had the design tenants, we worked backwards to build the framework.
The new dialogs use Web Components & some new HTML elements (such as the
dialog spec (hopefully, maybe).
Here’s an example of some of the markup:
<details id='dialog' class='dialog' open> <summary></summary> <cheerful-dialog ...> <button class="dialog-close" data-close-dialog>close</button> <main class='dialog-content'> ... </main> </cheerful-dialog> </details>
I’m incredibly pleased with the results. It feels like writing standard HTML (even if it’s slightly clunky), and it’s easy to debug. Plus, adding or removing a dialog is as easy as manipulating the DOM. No JS methods to call, no weird virtual state to manage. The elements are present in the DOM, or they’re not!
Semantic Markup to the rescue!
As we’re revisiting dialogs, we’re using semantic markup as much as possible. This means that pages are accessible by default, because the browser knows the intent for each element
It’s also easier for us as we spruce up Noko’s design, since we can make the design consistent. Since we’re not dealing with div soup any more, we can style the semantic elements directly. This also means that there will be less CSS to load and process, using less bandwidth (and making Noko even faster!)
Making dialogs part of the browser history
One of the pitfalls with a purely JS-driven dialog framework is that it makes dialogs hard to reach consistently. We try to update Noko’s underlying data in real time as you use the app, but sometimes a page needs reloaded. Previously, this meant that dialogs would disappear upon reloading, forcing you to dig around for it.
Now, dialogs are part of the browser history, which has distinct benefits. Dialogs now have a discrete URL, making it easier to save bookmarks, write documentation for your teems, and speed up your workflows. And if something is out of date, you can quickly reload and get the latest information.
Where’s it at?
We’re going through the app, replacing the old dialogs with the new ones. Depending on when you’re reading this, we might have already finished! But as of this writing, we’ve revamped the Project settings, and the People dialogs are almost finished.