I am coming to the end of my longest ruby contract so far – building web applications for Warwickshire County Council. It’s been a wonderfully productive couple of years, and I’ve gained a lot from working with the team at WCC. However, I think my most long lasting lesson learnt may come from a mistake.
I am entering the last week of my contract and the main focus is now hand over. A lot of this has already happened, and I’ve detected a common thread. I am being repeatedly asked the same question: “What can users do as admin, and what should developers do as admin?” This morning I have woken up with the realisation that the reason I’m being asked this, is because I’ve made a fundamental mistake with my app designs: I’ve overlooked the need for the super user.
If I’d defined super users in my apps, I wouldn’t now be asked this question.
I think I’ve fallen into a trap of thinking the default access levels for a web app should be user and admin. I’ve only gone beyond this access model paradigm if the project specification has stated that a more complicated model is required. I can understand why I’ve fallen into this way of thinking. Just have a look at a google search for “ruby admin user” and see how many of the results point to examples using just admin and user. For another example, have a look at the Devise README; its examples use just user and admin.
I don’t think it’s the fault of the people writing these examples. It is much easier to write example code using the simplest models, and admin/user is the simplest access model. The mistake is then thinking that the simplest model should also be the default model. Just because a model is useful as an example, doesn’t make it the best model to put into production!
So why do I need a super user? I think the easiest way to answer that is to ask “why do I need an admin user?”. The answer is, I want to make it easy to modify the way the application behaves without having to go to the bother of writing more code – to be more accurate – without having to write more code after I’ve moved on to building my next great application. I hate having to go back to an old code base to modify it. I’d much rather spend my time building swanky new applications.
So I try to build my apps with enough in-built flexibility, that their behaviour can be changed via tweaks at the admin level. Of course there is a limit to this, but in my experience, it’s not that difficult to predict the main ways that an app may need to be modified in future, and to build admin functions accordingly.
There will always be some behaviour changes that either are not predicted, or too complicated to build into the original app. In which case, building the next iteration of the app is the only option. But we have to live with that.
OK – so that’s explained why I have admin users. Why super users?
If you look at the way a web app needs to change through its life there are two types of changes:
- Changes anyone could make, without breaking the app
- Changes that could break the app, and need to be done by someone who understands the consequences.
Type 1 changes could be made by super users, and type 2 changes by admins.
Some examples super user changes:
- Add users
- Assign users to groups
- Modify header and label texts
- Correction of erroneous user data entry
Some examples of admin changes:
- Modification to whitelist/blacklist regex parameters
- Changing oauth id/key pairs
- Modification of data at the database table level
There is some cross over. There may be a good reason why you wouldn’t want a super user in a particular app, to add users. But these examples demonstrate the point.
For an app you manage as admin, the more you can allow super users to manage themselves, the less work you’ll have to do. And you’re not the only one who’ll be pleased about that. The super users will feel empowered too and enjoy using your app more if they feel they have some control of it. It’s win, win!
However, before we spend too much time slapping each other on the back, there is another key point to highlight: admins and super users need different interfaces!
Have a look at the last two examples for each type:
- Super user
- Correction of erroneous user data entry
- Admin
- Modification of data at the database table level
It is too easy to think that the way to give super users the ability to correct erroneous data, is to give them database table level access to the data. If you do that, a super user will break your app at some time. Instead, the super user has to be given an interface where they can safely modify data without breaking the app. That usually means a modified version of the origin data input form.
That means that most web applications need both an admin and a super user portal.
So how do we decide which changes need to be made by admins, and which by super users? I think there is a simple answer. Ask yourself the same question I’m now being asked: “What can users do as admin, and what should developers do as admin?”. All changes that ‘users do as admin’ should be made accessible via the super user portal, and all changes that ‘developers do as admin’ should be accessible via the admin portal.
Finally, consider access control. Super users should be denied access to the admin portal, but for most apps it would make sense to give admins access to the super user portal.
And don’t forget, not every user is a super user. The default model should be three levels of access:
- User
- The people who need to be identified, and do the day to day input and access of data.
- Super user
- The people responsible for the management of the app. This is often the owner of the app – the customer who asked you to build the app – and the people within their team who they delegate to be responsible for the app.
- Admin
- The app developers and the technical team tasked with supporting the app
I believe the main mistake I’ve made at WCC, is to provide apps with a single admin portal that both admins and super users use, and then relying on my direct instructions to super users as to what they should and should not do within the admin portal, to prevent accidents. The handover process has demonstrated to me that this is a poor way of managing things, as it only lasts as long as super users remember the instructions.