Harmony: User Management
When we set out to make Harmony, our upcoming website management system, we wanted to solve some of the more annoying issues that we had run into with managing content on the web. User management is one such issue.
The administrative utility of adding users to a management system is commonplace. And there’s nothing particularly difficult about it. But we feel there are a few ways to simplify the process for content managers and developers alike. Keep in mind that we’re talking here about people who manage the website from the administrative interface, not ‘public facing’ users, like forum members for example. Also, Harmony will start off, at least, being a hosted management solution, so many of these features become more powerful in that environment.
Permissions
Let it be known that both John and I are both fiercely opposed to granular permission levels. They add over-complexity for their little usefulness, and are only in place to help paranoid managers. John and I like to say that “we don’t write software to solve social problems.”
That said, there will be a few basic permission levels where they make the most sense.
- Account Owners: Owners will have access to anything in an account, including managing billing information, users, and sites.
- Administrators: Administrators are nearly identical to account owners, but won’t have access to the billing section of the account. They also can’t remove/demote account owners. Just like account owners, they will have access to manage any site in the account, including sites that are added in the future.
- Site Managers: Site managers are assigned to only one or more specific sites in an account, but will have full access to add users and manage content on those sites. The specific sites assigned to these users will stay the same, even as more sites are added to the account in the future.
One other key feature is that users can be identified as developers, which will show all the template tools and advanced theming utilities. If a user is not assigned this developer flag, these tools will simply be removed from the interface to simplify management for those at a non-technical level.
One Login
After working with content management systems for years, specifically working with single-installs of either custom software or open-source tools like WordPress, maintaining content across a distributed set of accounts and servers is a nightmare. Remembering your login for each separate instance is a pain, but even if you use tools like 1password, or simply have the same username/password everywhere, you still have to go through the login process at each location. Harmony will be different. Your user account, be it with your email address and password or your OpenID, will be completely unique to the system. You may belong to only one main account, or you may have several that you manage. All you have to do is login once, and you’ll have access to everything you need from one administrative interface. Finally.
As a developer, you’ll have options on how to serve your clients with Harmony. You can have a large account for your business, host all your client sites in that one account, and bill your clients to cover the cost, or profit from, your single account. If you prefer to avoid the monthly billing scenario, you can have your clients sign up for their own site account, and grant you administrative access. In the interface, the accounts and sites will be organized and easy to access, no matter which method you use. Or you could even blend the two, with almost no difference in how you, or your clients, manage their sites and content.
Convenience
Our CMS survey showed that the average number of sites being managed was typically not less than 4, and often times more like 20 or 30. Starting with user accounts, we’re trying to make the process of managing your websites as convenient as possible. We have many more ideas that are being built into Harmony, so if the project interests you, watch out for more updates.
Post and Author Info.
Published September 16, 2008 by:
Commenting is currently off for this post.
So far there are 14 comments.
[RE: Permissions] “They add over-complexity for their little usefulness, and are only in place to help paranoid managers.”
Amen! There are many ways to go about user permissions, and I always struggled with the idea of doing ACL (or some other user management) on a website that needed simple administrative rights.
September 16th, 2008
Steve, can’t wait to see what you folks come up with, ping me if you need beta testers =)
September 16th, 2008
Looking forwards to see how this works out. I´m currently a Textpattern user, but excited about the possibility of an app that can make things easier with sites all over the place:-) Hoping it will be easily customizable and maybe sport some nifty plugin capabilities…
Good luck and looking forwards to hear more about this!
September 16th, 2008
It’s interesting to hear how you’re looking to tackle permissions. I think there’s a place for more granular settings but is usually targeted to larger organizations. I don’t think it’s an issue of paranoid managers otherwise, why have any permission system at all.
In a CMS I built, I ended up using a Windows-style approach to security where you could restrict access at a particular point in the branch which would apply to the whole branch. Having clients with 20+ teams managing a site with 1000+ documents, sometimes more granular control is necessary. (You wouldn’t want somebody to update the wrong page because they didn’t notice what section they clicked through on.)
September 16th, 2008
I work on an CMS, and user management is definitely one of the things we need to work on. Trust me, you’ll need more granular user access permissions than the levels you have listed here.
You should add a content-level account that allows a user to only access documents within a certain folder, or something similar. Sometimes you’ll have clients that need accounts for people who simply need access to edit texts on the site, who you wouldn’t want to let have access to any other settings.
Paranoid? Maybe, but when you’re safeguarding your company’s web site, especially if you use it to sell your products, then you NEED to be paranoid.
September 16th, 2008
@Snook: Hopefully we can make the administrative interface easy enough to navigate that that shouldn’t be an issue. :)
@George: We won’t be incorporating any more granularity than specified, for the reasons given in the post. We don’t write software to solve social issues. If you don’t trust someone, don’t let them edit your website. End of problem.
September 16th, 2008
@Steve – Well said. :)
September 16th, 2008
I really like this simplified approach to user management. In the system I use at work I have to wade through permission hell to let a client access the features of their site.
I like the idea of being able to flag individual pieces of content as editable only by the author (and users above him like Administrators) but I understand the desire to keep the whole system simple. I certainly wouldn’t call that a deal-breaking feature, but I guess I could see where it might be for some organizations.
September 16th, 2008
Just curious, what, if any, open source framework(s) are you guys building your cms on top of, or are you hand-rolling your own?
September 16th, 2008
@Brad – From scratch in Rails.
September 16th, 2008
Enough yammering, what’s the ETA here boys?
September 16th, 2008
@Steve – We blog as we build. We don’t have an ETA because we aren’t done and don’t know how long it will take. :)
September 16th, 2008
Will you be able to assign particular piece of content to a particuar user? I think that’s one important feature because you may want to allow one user to edit a piece of content. For e.g: A website with a listing of some product might want to give some user more control over editing aspect of the listing so that he can add more information.
September 29th, 2008
@Muhammad – No. Either you trust someone to update the website or you don’t. Anyone who has access to the site can edit any piece of content on it. If you don’t want them to update a piece of content, just tell them not to. Like Steve said in the post, we won’t be solving social issues.
September 29th, 2008