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

We want every part of Noko to feel as snappy as possible. Because the previous version of dialogs leaned so heavily on JavaScript, there were limitations in how performant we could make them. The less JavaScript we use, the faster Noko is.

How we’re achieving it

Once we had the design tenants, we worked backwards to build the framework.

Web Components & minimal JavaScript

The new dialogs use Web Components & some new HTML elements (such as the details element) to render dialogs directly with minimal JavaScript. I first learned about this pattern from the Details on details talk by Mu-An Chiou. It’s an extremely versatile pattern (especially as we wait for a finalized dialog spec (hopefully, maybe).

The JavaScript that is there is a sprinkling of event handling, accessibility tagging, and initializing custom JS for existing UI inputs.

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.