slate blog

I have a secret: I want to tear slate apart. Yes, you heard me. But before you think I’m crazy, let me explain.

I think slate is a great product. It works surprisingly well, and has a bright future. That’s not to say there aren’t kinks in the system, of course, but overall I’m quite happy with how it’s turning out.

Yet, there are some aspects of slate that nag me. Largely, aspects that originally came from a set of specs/requirements (boo!). For instance, we have a rollback feature. We also have a fine-grained permissions system, with roles and all that hoopla. And roles can be assigned to Pages, effectively providing object-based permissions.

This all sucks.

Yep. Not really the implementation (the permissions module is actually cool from a programming standpoint), and not really the interface (which is much better than it has been). No, what really sucks is the whole concept. Permissions suck. And here’s why: they get in the way of the user. They don’t help the user accomplish a task, they prevent it.

Typical slate site

The typical scenario for a slate site is this: one person, which we assign as site administrator, and… that’s it. Perhaps originally we were planning on something a bit more grandiose, but it hasn’t happened. Perhaps we envisioned that site administrators would register multiple people into the site and create unique roles for various tasks in the system. Perhaps we were wrong.

Do you want to know why? I suspect it’s because our users think permissions suck, too. One of the things I read in Designing the Obvious that has stuck with me is this: users aren’t like us – they aren’t using our applications just because the applications are cool. No, users use them because they have to, because it’s their job. Most users just want to get that link posted or that file uploaded and be done with it. They don’t care that there’s a fine-grained permission system under the hood making sure they don’t try anything they shouldn’t.

So, what does happen? If (and I do mean if) more than one user gets assigned to a site, a role is created that has every permission enabled, and it gets assigned to the second person. To me, this is a clear sign to what I pointed out before: users think permissions suck. The site admin doesn’t want to think about whether or not this other user should have the Rollback permission, so he does what any sane person would do – he checks off everything. He’s also fairly confident in his trust for this other user, so it doesn’t bother him. All of those checkboxes just got in the way.

Scrap permissions?

I realize there is a place for permissions. However, the level of permissions that we have in slate is too much. It needs to be severely simplified. If all our users typically do is assign someone “all or nothing”, then that’s all we need. The upside to simplifying is two-fold: our users may actually use the feature because it won’t be so complex, and we can more easily maintain it because there’s less to go wrong.

Rolling back

I mentioned Rollback earlier. This is another bone of contention (is that the phrase? weird…) of mine. I hate to admit it, but Rollback is useless. I mean, not totally useless… it does let you, you know, roll back your content. But why bother?

Here’s another typical scenario: user is assigned site administrator and… well, we wait for content. And then we wait some more. And most sites aren’t being updated, despite the fact that slate makes updating easier than say, Dreamweaver (dealing with FTP, etc.). So, if it’s so hard to get content in there in the first place, rollback doesn’t really serve much purpose. Oh yeah, and the interface sucks (my fault, sorry :-D)

Dave calls rollback a “checklist feature” (I think that’s the expression he uses), which makes me think of a giant rubber stamp that says “File under T for Trash” getting slammed down on it. There is no room or need for “checklist features”. The goal of slate, in my mind, is to be a tight, focused application. That means only the essentials. Everything else will be filed under T.