The surprisingly bad PhpBB

Ph­pBB al­ways sur­prised me. At every new ver­sion, the pro­ject is rewrit­ten from scratch, which is a good op­por­tu­ni­ty to fi­nal­ly do the in­ter­ac­tion de­sign cor­rect­ly, and still, it's as bad as it was in June 2000 when the first ver­sion was re­leased. The most sur­pris­ing bug is that while the pro­ject sticks with the tree data struc­ture, it also makes it par­tic­u­lar­ly dif­fi­cult to ma­nip­u­late the en­ti­ties in mul­ti­ple nodes at the same time, mak­ing it a night­mare for mod­er­a­tors to use the plat­form.

Trees and sim­i­lar data struc­tures like ex­clu­sive cat­e­gories are the worst al­ter­na­tive in most cas­es. It is pret­ty ob­vi­ous when you com­pare the web ap­pli­ca­tions like Stack Ex­change, made by pro­fes­sion­als, and the clas­sic bul­letin boards which do every­thing to re­main at the same state they were in 2000. But even when a con­straint re­quires stick­ing with trees and sim­i­lar data struc­tures, there are ways to im­prove the in­ter­ac­tion of the user with the data. Here's how.

Case study: Safebox

I'm cur­rent­ly work­ing on Safebox de­sign. One of the fea­tures is to be able to re­voke the en­ti­ties when they are ob­so­lete or when the user doesn't want the trust­ed com­pa­ny to ac­cess those en­ti­ties any longer. Also note that the users will be re­vok­ing sev­er­al en­ti­ties much fre­quent­ly then a sin­gle en­ti­ty: re­vok­ing hap­pens when the pro­ject is fin­ished, when there is a se­cu­ri­ty risk, when the user los­es trust or when all ac­cess­es are changed; in all those cas­es, more than one en­ti­ty be­come ob­so­lete.

Since any user can also be a cus­tomer with sev­er­al pro­jects, she may want to as­so­ci­ate the con­fi­den­tial data she sub­mits with those pro­jects. In the pre­lim­i­nary de­sign spec­i­fi­ca­tions, those pro­jects ap­peared as ex­clu­sive cat­e­gories, i.e. the con­fi­den­tial data were put in zero or one cat­e­go­ry. In the ac­tu­al de­sign, the cat­e­gories were re­placed by tags, but be­low, we will con­sid­er that we kept the old one.

When it comes to re­vok­ing an en­ti­ty, the re­voke but­ton ap­pears at the en­ti­ty lev­el when the user places her cur­sor over this en­ti­ty. To help the user to re­voke all the en­ti­ties in a pro­ject, when the cur­sor is over the cat­e­go­ry, a scope re­voke but­ton is shown.

The scope re­voke is help­ful, but not too much, since it works only in one and one only sce­nario. The most ob­vi­ous sit­u­a­tion: the user wants to re­voke sev­er­al, un­re­lat­ed en­ti­ties in sev­er­al pro­jects. Drag­ging the mouse to mul­ti­ple el­e­ments, wait­ing for the but­ton to ap­pear, then click­ing the but­ton is an op­tion, but couldn't the ap­pli­ca­tion be friend­lier and pro­vide a more el­e­gant way to do it?

Ac­tu­al­ly it can, with the or­di­nary check­box­es par­a­digm.

But still, forc­ing click-click-click is nei­ther friend­ly, nor help­ful. What if the data­base se­cu­ri­ty was com­pro­mised, and the cus­tomer now re­vokes all en­ti­ties re­lat­ed to the data­base?

Adding a sim­ple search solves the prob­lem. Now, all the user has to do is to search for en­ti­ties re­lat­ed to the data­base, then se­lect all the re­sults, and re­voke them. As easy as that.

A more ca­pa­ble search is even bet­ter. What about re­vok­ing every en­ti­ty old­er than one month, or de­liv­ered be­tween 20^th of May and 5^th of July? Or not ac­cessed by the trust­ed com­pa­ny for a while? Or not con­tain­ing a spe­cif­ic tag?