Frontend challenge

One of the main aims of Dovetail 4.15 was to make life easier for the user. Lucas, our frontend developer shares his story about overcoming a specific part of the user interface.

Lucas: In the former Dovetail versions we had a few actions that could only be done in the Flow Manager like stop, pause, resume for example and others that could only be done on the Flow Designer page, like start draft, start a version. This was forcing the user to keep two tabs open and refreshing them after every action done or going back and forth between manager and designer. In Dovetail 4.15 we wanted to resolve this and improve that interaction. This posed some challenges of course.

How did you overcome this challenge?

Lucas: We divided the solution in two steps: first we renewed how the versions are shown inside Flow designer and gave the user control over versions status with one click. Second we integrated the versions to the Flow Manager. Now the user can control the flow lifecycle from both ends.

Great idea, so it was easily solved?

Lucas: Yes, but it was not as straightforward as it may sound. The integration of the versions into Flow manager caused a code problem. Navigating from the Flow designer directly to a version inside the Flow manager (or visa versa) was a bit more complicated.

The states – the information of each page – are completely separated, they have no connection. We can navigate to the flow, since we have the flow as a parameter in the URL of both pages. But not the version.

So another challenge popped up. How did you solve that one?

Lucas: After some investigation the solution became clear: we should include the version in the URL parameters. Eventually we took it even further and also included other parameters for each page that would help the user to navigate. The parameters we added were: environment, version and tab for Flow manager and version and tab for the Flow designer.

A new issue, luckily we like a good challenge

Lucas: Once we released 4.15.0 we had some issues that were a bit more confusing to fix and I noticed that we had a concept problem. Since we implemented a more transparent URL navigation between Flow manager and Flow designer, we now have two sources of truth:

  • changes in the URL would trigger changes to the state and subsequently to the user interface (UI)
  • changes in the UI would trigger changes to the state and subsequently to the URL

Sounds confusing, but in practice the problem is: the UI must be changed after a change in the URL, but if changes in the UI also create a change of the URL, we can create an infinite loop. And those are not easy to catch.

Together with my fontend colleague Flyn we weighed the different options and decided the best approach for this would be to have the URL as the single source of truth.

That said, the new scenario would be that URL changes trigger state changes and then UI changes. And changes to the UI trigger a change in the URL and then the state.
So now the URL is responsible for making the state change. Even if the change was triggered by the UI, the url is changed first and after that the state is amended based on the URL.

What are the benefits of this solution?

The new solution makes the loading of pages faster. Also users can save urls as shortcuts and go directly to the page they want to go without navigating every time.

Related resources

Infrastructural spaghetti

Of course, the differences between Thai and Dut...

How to replace a library from 2010?

In Dovetail 4.15 we transitioned to Jackson to ...

If you don’t test restores, you don’t have backups

It is as simple as the title suggests: “If you ...

Why did we introduce test automation?

By automating tests, our developers can build c...