Home Home

The surprisingly bad PhpBB

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
July 3, 2012

PhpBB always surprised me. At every new version, the project is rewritten from scratch, which is a good opportunity to finally do the interaction design correctly, and still, it's as bad as it was in June 2000 when the first version was released. The most surprising bug is that while the project sticks with the tree data structure, it also makes it particularly difficult to manipulate the entities in multiple nodes at the same time, making it a nightmare for moderators to use the platform.

Trees and similar data structures like exclusive categories are the worst alternative in most cases. It is pretty obvious when you compare the web applications like Stack Exchange, made by professionals, and the classic bulletin boards which do everything to remain at the same state they were in 2000. But even when a constraint requires sticking with trees and similar data structures, there are ways to improve the interaction of the user with the data. Here's how.

Case study: Safebox

I'm currently working on Safebox design. One of the features is to be able to revoke the entities when they are obsolete or when the user doesn't want the trusted company to access those entities any longer. Also note that the users will be revoking several entities much frequently then a single entity: revoking happens when the project is finished, when there is a security risk, when the user loses trust or when all accesses are changed; in all those cases, more than one entity become obsolete.

Since any user can also be a customer with several projects, she may want to associate the confidential data she submits with those projects. In the preliminary design specifications, those projects appeared as exclusive categories, i.e. the confidential data were put in zero or one category. In the actual design, the categories were replaced by tags, but below, we will consider that we kept the old one.

When it comes to revoking an entity, the revoke button appears at the entity level when the user places her cursor over this entity. To help the user to revoke all the entities in a project, when the cursor is over the category, a scope revoke button is shown.

enter image description here enter image description here

The scope revoke is helpful, but not too much, since it works only in one and one only scenario. The most obvious situation: the user wants to revoke several, unrelated entities in several projects. Dragging the mouse to multiple elements, waiting for the button to appear, then clicking the button is an option, but couldn't the application be friendlier and provide a more elegant way to do it?

Actually it can, with the ordinary checkboxes paradigm.

enter image description here

But still, forcing click-click-click is neither friendly, nor helpful. What if the database security was compromised, and the customer now revokes all entities related to the database?

Adding a simple search solves the problem. Now, all the user has to do is to search for entities related to the database, then select all the results, and revoke them. As easy as that.

enter image description here enter image description here

A more capable search is even better. What about revoking every entity older than one month, or delivered between 20th of May and 5th of July? Or not accessed by the trusted company for a while? Or not containing a specific tag?