In a website UX pattern, a dialog is an interruptive piece of element, usually interactive, shown to cover a page while the rest of the page are not interactive. Dialog can be treated like a “page” overlaying the current page. Sometimes, this dialog that got treated like a page gets its own route in the navigation stack. I call this “dialog route”.
Route
By assigning a route to a dialog, now user can easily share link to the page with the exact dialog opened. I find that this is really helpful in a page with lots of interactive elements.
I noticed this behavior from Trello. In Trello, card description is shown in a dialog of a board.
I adopted this pattern in my own project Ikuyo, where activity, accommodation, and day plan are dialogs with its own routes. Before adopting this, each activity is just a dialog in timetable page so it’s hard to share the activity to others since the URL doesn’t capture the exact activity.
Why use a dialog instead of a separate page?
I think it’s subjective, since I feel some part of UI element couldn’t exist without a “base”. In Trello’s case, a card always belong to a board, so I think it makes sense to always show the card description as a dialog of the board.
Navigation
User can also use browser back-and-forward navigation to navigate around. However, I feel like this part is a bit weird. As a user, I expect that dialog pushes to the navigation stack and when I close the dialog, the dialog should be popped off from the navigation stack.
However this is not true if I assign a route to the dialog, where opening and closing dialog both push to the navigation stack.
In my project, I tried hacking around the navigation stack behavior to no avail, since some parts are just browser behavior that couldn’t be customized.
Adoption
Adopting it is surprisingly simple, basically have another layer of route matcher inside the page that contains the dialog, and if it matches the dialog route, then show the dialog.
As an example, my project Ikuyo shows activity dialog in a timetable page.
At application root, my routes look like
<Switch>
<Route path="/trip/:tripId/timetable" component={PageTimetable}></Route>
</Switch>Then in my timetable page:
// ... rest of timetable codes
<Switch>
<Route path="/trip/:tripId/timetable/activity/:activityId" component={ActivityDialog}></Route>
</Switch>With that, when someone lands on “/trip/ABC/timetable” they will be in the timetable page, however if they are on “/trip/ABC/timetable/activity/DEF”, they will stilll be in timetable page, but the activity dialog of DEF will be opened.
Not all dialogs are suitable
Now that I learned about this pattern, I got tempted to put all dialogs as routes, but not all are suitable to this. I find that those that act like a page (like showing information) are more suitable, and those that require interactions, like forms, are not suitable for this.
This is mainly due to the back-and-forward navigation behavior. Those form dialogs really need this push-and-pop stack behavior and it could get annoying if it gets the push-and-push behavior. For example, when I create a new activity in a timetable page, I fill in a form in a dialog. I expect after submitting, I will be navigated to the activity dialog (which is a dialog route). I expect by closing this activity dialog, I go to the timetable page. However, if the form was a dialog route, then closing the form will lead me to the activity creation dialog, which isn’t what I expect.
Conclusion
Dialog routes is a pattern of assigning route to a dialog, by treating it like an independent page while not really independent. While the obvious benefit is that user can easily navigate to the dialog directly, there are also some drawbacks mainly due to the mismatch of navigation pattern of a dialog. Therefore, one must be cautious in adopting this pattern.
I initialy wrote this inside the post Ikuyo: Plan Your Next Trip but decided to spin this topic out of that post