This week I wanted to announce the end of an experimental UI component we attempted to iterate on for the Harmony theme, but ultimately decided to scrap. We wanted to step outside the boundaries of common web interface implementations and come up with a superior way to navigate through topics without the drawbacks of traditional approaches.
We first saw the invention and adoption of infinite scrolling (hereinafter referred to as IS) many years ago, pre-dating the first lines of NodeBB code, as it was something seen as an evolution to the traditional method of separating out content: pagination.
There are many articles that go into detail over whether IS or pagination is preferable, but the consensus thus far seems to be that there are advantages to both, and serious disadvantages to both, e.g.:
- While pagination is easier to visually distinguish progress (i.e. page 4 of 16, 25% of the way through), it is often considered outmoded and has shown higher attrition rates compared to IS.
- While IS increases user engagement (precisely because of the lack of the above progress indicator), seamless cooperation with built-in browser behaviour is spotty at best. How many times have you clicked into a product, clicked back, and completely lost your context? You can thank a poorly done IS implementation for that.
During the initial design stages, we challenged @vladstudio to take a critical look at our theme and turn around and challenge us with new UI elements. Similarly, we also wanted to come up with a UI element that worked alongside IS, while resolving as many of the drawbacks of as possible. The "at-a-glance" navigator was one such implementation that was explored.
NodeBB already had a post navigator, which allowed for scrolling through a virtual track, followed by an asynchronous load of the post (and its context). At the same time, Persona had been updated with a "timeline" style for its post list, which alluded to a navigable component. As explained by @vladstudio:
Right now, NodeBB’s timeline is mostly decorative. I just realised that it has the potential to show progress too! [Looking at a] zoomed-out design of a topic... the timeline is barely visible at this zoom, but potentially, it gives you a good overview.
Vlad's idea was to combine the two disparate elements into a single UI element. The knob and track would stay the same, although when interacted with, the topic presently in view would "minimize" down to a form where each post collapsed down to one line. From there, moving the navigator along its track would scroll the browser window up and down, and you would be able to easily span the entire length of the topic with a simple drag-and-drop mechanic. Posts would load when scrolled into view, and once the knob was released, the topic would "re-expand".
There were a large number of problems solved with this approach:
- IS plays havoc on browser scrollbars. Whenever additional elements are added, and the page reflows, the scrollbar changes position. If you've ever scrolled down a page and all of a sudden, the knob was no longer underneath your mouse, you know what I mean.
- We eliminated the aspect that a page were divided into separate "pages". A topic is a linear flow of content, and pagination breaks up this flow purely for organizational purposes.
- As the posts themselves were loaded while scrolling, you could easily see the context of the conversation and decide at a glance whether you wanted to read more.
- Yes, this is where the name came from.
The new problems
We rolled out a minimum viable product of this navigator as part of the first Harmony beta, with the hope of continuing to develop further on the idea while seeing how it performed with real data.
Unfortunately, we ran into a couple of issues (some of which we had identified prior) inherent in the design we could not solve.
1. Page weight linearly scaled with topic length
The way the at-a-glance nav worked, when a topic was "minimized", we created placeholder elements before and after the loaded posts, so you could scroll to where you wanted to go. It worked very very well in practice — if you wanted to go to the first third of the page, you would just move the knob to the 1/3rd point and you would be dropped exactly where you wanted to go.
However, as the number of posts in a topic grew, so did the number of placeholders we had to add to the page. Eventually, we got to the point where so many placeholders were added that the browser tab started bumping up against the upper limit of how many DOM elements it could maintain on the page at any given time. Our largest topic "Who is using NodeBB?" has 607 posts (as of writing), and while the navigator was still usable, there were increasing delays as the browser did its best to accommodate the newly added elements.
2. Navigator accuracy dropped the longer the topic was
In the version of the navigator on this site, the nav had a set height of roughly 250 pixels, in the sidebar. This meant that we collapsed the entire topic's height into an element of that height. For example if your minimized topic was 25000 pixels (at 1080p that's more or less 25 page-heights of your browser), then every time you moved the navigator a single pixel, the page would jump 250 pixels. Combined with the fact that not many people have the mouse accuracy to be able to click-drag-move a single pixel at a time, this meant that as the navigator knob moved, the page could move unpredictably depending on page height.
The sweet spot was somewhere in the neighbourhood of 20-100 posts. Scrolling up and down, you'd still maintain a rough visual context of where you were. Past that, the minimized topic was essentially unusable. Scrolling even a little bit would have such a jarring viewport shift that all visual context was lost.
Apparently there is no way to comfortably scroll through the long topic using the Navigator, with the immediate feedback.
I realise now it is necessary to split the topic into lazy-loading “chunks”, and “loading all posts in placeholders” idea does not really work.
It inevitably leads to “the knob is out of my control” feeling.
Considering that maintaining that visual context was the whole point of this UI component, this was a serious flaw!
For now, we have updated the navigator so that it is affixed to the right of the topic content. In Persona, we had this navigator exposed only when the navigator itself was clicked. We've promoted the navigator from a component within that modal to one that is always visible, in the hopes that it will be more discoverable. The topic content was already limited in terms of width already, so the navigator is not taking up any additional space:
Regarding the at-a-glance navigator — there were potential solutions to both of the discovered problems, although the second one was complex enough that we decided that any potential solution itself would come with significant drawbacks and unnecessarily complicate the user experience.
In the end we were hoping to come up with "a novel way to navigate linearly through a list of dynamic content while maintaining a one-to-one association with the actual content". We were not able to achieve that today, but it is possible that by releasing our findings, that we could potentially revisit this idea in the future with even more novel ideas
We don't often do many experiments with UI components at NodeBB, so this one was particularly exciting. I'd be happy to discuss more about the idea, what we wanted to accomplish, etc. in the replies.