Without hesitation, I’d say that NodeBB has evolved heavily over the past 7 years1.
The initial drive those first years was feature parity – bring features to NodeBB that other forums have, and that users expect. After all, how could we sell ourselves as a forum if we didn’t have, say… user accounts… or password changing utilities?
The benefit are plain to see – it’s easy to see what works, and years (if not decades) of user testing has surfaced certain UX patterns that have stood the test of time. For example, the category/subcategory hierarchy, or the use of tags to link disparate items together under a common label, etc.
Our secondary goal was a little less simple – to make NodeBB a forum software like no other. We wanted to iterate on web 2.0 principles that facilitate form over function, ease-of-user, and user retention. We were tired of older forum softwares that locked users in a specific theme or had limited customisability, and wanted to take these pain points and address them from the beginning, with NodeBB. We consider our selection of Markdown, and our robust plugin and theme systems to be hallmarks of this goal.
However, what were we supposed to do after we reached feature parity? Around that time, we launched v1.0.0 of NodeBB, and the future was bright. We could go in many different directions from there.
Build Cool Stuff
We took the phrase “a feature no other forum software has” as guiding light for the next little while, but the downside is that Cool Things™ don’t often stand the test of time.
In addition to the work and goals outlined in out v2 announcement post, we also wanted to step back and view with a critical eye whether some design and feature implementations were the right decisions, and whether a re-implementation is due.
Sounds & Sound Packs
Sounds were initially brought to NodeBB because there was a desire2 for an auditory cue if the forum needed or wanted your attention. The initial implementation had sounds for notifications and chat messages, with plans for additional sounds as the needs rose. You’ll notice that the need never arose for additional sounds.
Later on, we expanded this system to allow for administration of the sounds, and after that, UCP controls to enable or disable sounds.
We even had the capability to download and install “sound packs” in the form of plugins, but in the end, the only community-made sound packs were made by one person (me), and there was no real uptake by 3rd party developers.
Almost all installs stick with the defaults or disable sounds outright, and so we have made the decision to cut sounds from NodeBB 2.0.
?
(but ? silently, because we cut sounds.)
Taskbar
The taskbar was meant to mimic the taskbar on Windows and other popular operating systems. It was meant to facilitate multi-tasking, and enable power users to do things like have multiple composer windows open, multiple chat windows, and have the capacity to handle additional “window-like” constructs for plugin developers.
In reality, there was again, no uptake by 3rd party developers to use the taskbar. Most plugins preferred to use one-off modals that focused user attention and were discarded immediately afterwards.
Even internal designs that required the use of a floating control3 ended up not integrating with the taskbar, because it was too complicated and not worth the effort.
The compounding effect, of course, is that maintaining a taskbar adds additional overhead and code to maintain, alongside the bugs that inevitably crop up over time.
We had to think about just how many users utilised multiple composers, or mixed composers with active chat modals, and switched back and forth often enough to necessitate a taskbar-style control. Only power users would take advantage of such a system, but in the end, it was the added complexity and overhead (not to mention the bugs) that made the taskbar not worth the effort, and so the taskbar is also on the chopping block for v2.
This doesn’t spell the end for multiple composers!
Out of the features we did add, multiple composers did have some uptake, and power users will still appreciate the ability to composer multiple messages at once. We’ll need to come up with an alternative UX for handling multiple composers, but the use of a taskbar won’t be one of those.
Chat Modals
Speaking of which – chat modals are next on the chopping block too!
Our initial vision for chat modals were grand… everybody would have multiple chat modals open all at once, with lots of concurrent chatting. In actuality, while chats were used regularly, they were not used often enough to justify the overhead of maintaining additional code to support them in a modal format4.
As NodeBB matured, we ended up having to maintain two separate libraries – one for the modals, and another for the chat page. Neither received our undivided attention, and so actual improvement to the chats was incremental at best.
Given the eventual removal of the taskbar (see above), we also made the decision to remove the chat modals in favour of the chat page.
Chats were envisioned as the natural evolution of the “private message” system available in many other forum softwares. We still feel chats can support both rapid fire conversations and long-form messaging, and we simply want to consolidate our efforts on the chat page itself.
Settings v3
“Settings v3” is an internal codename we’ve given to repeated iterations of the client/server-side library we use to handle configuration settings for the forum and installed plugins.
Some quick history —
- Settings v1 – the initial library, exposed a single
.prepare()method that searched for form elements that matches a specific style and wired up event handlers and a save button. On the server side, all of the fields would be unceremoniously shoved into theconfighash. The majority of the admin panel still uses v1 - Settings v2 – when the plugin system was added and plugins wanted to save their own data, the need arose to have segregated hashes for plugin settings, lest plugins accidentally clobber the settings of other plugins. v2 exposed
.load()and.save(), and allowed you to specify a hash to save under. Almost all plugins use Settings v2. - Settings v3 – a community-led effort, v3 exposed new controls and enhanced the ability for plugins to save more complicated settings.
Unfortulately, v3 never gained any significant traction, and was too complicated for other plugin developers to use. v2 ended up the de facto standard, as it was included in the boilerplate for the Quickstart plugin.
Its simplicity ended up being a double-edged sword – it allowed developers to easily and quickly wire up a settings page, but was not powerful enough for some applications.
As you can see at this point, our codebase is split between v1 and v2, with limited uptake in v3. We’ll wantto consolidate all of our frontend code to use v2 exclusively, and potentially expand on its capabilities by backporting some functionality to v2.
Building good, performant software is not only about what you build, but also about what you choose to take out. We chose to take the opportunity in our v2 planning to take that critical bird-eye look at our feature set to really see if everything we include is worth the effort. Let us know what you think in the comments – do you think we made the right call with cutting these features?
1 Our very first commit was April 22nd, 2013, it’s all been downhill since. ?
2 I’ll admit it, it was just me. I thought it’d be cool to have NodeBB make sounds, and at that particular time, I had found a neat HTML5 library to emit sounds.
3 The prime example here is the “find in topic” and “fork topic” controls. They expose their own elements into the DOM, but don’t add themselves to the taskbar. In an ideal world, they would’ve been integrated.
4 After chat modals were added, Baris ended up spending the next year or so (on and off) fixing some bug or another involving the modals, whether it be positioning, or active state, z-indices, etc.
Cover Photo Bonnie Kittle on Unsplash