A few minutes ago, I tweeted the following: “Starting to feel like any site which requires a separate admin interface is not fully baked. Am I crazy?” A couple people responded asking for more details on what I meant, so I logged into the admin interface (or backend, or CMS interface, or whatever you want to call it) of my personal site, and started this here blog post.
Which is ironic, because the point of my tweet was to say that, more and more, I’m wondering if these kinds of interfaces are necessary, or even helpful.
Recently I’ve been building a lot of apps and have been less focused on content-oriented sites. But these apps do, of course, have content. Some of them have user-generated content. For example, a recent one included a system where ever user gets a blog, and is able to post entries to it. Some users (but not others) can comment on certain entries (but not others). Some users (but not others) have permission to edit and delete some comments (but not others). You get the idea.
In a traditional blog situation, as with many other content-oriented types of sites, you would have the content authors/producers/editors log into a separate administrative interface, where trusted users can perform these kinds of tasks — adding, updating, and deleting various types of content, making configuration changes, etc.
But more and more, that feels — forgive my expression — ghetto. Why should users have to change out of their current context, to a completely separate interface, in order to perform these tasks? Why not just build these tasks right into the front-end of the site or app?
That’s where I was going with my tweet. I’m sure there are still some use cases for separate administrative interfaces. But, I think, the more functionality we can build into the core design — instead of shuttling a person off to entirely different UI — the better.
Overall, I agree with this. I think most actions should be available as added menues or buttons on the regular interface when a user is logged in. If you have a blog and have the right permissions, you should be able to moderate comments right from the blog post or edit the title right on that page.
But I think there is a use for an admin side. Such as for the admins to track statistics or make site changes, like caching settings or looking at logs.
I don’t think having these things is a separate admin interface is bed, really, but what is the reason they, too, couldn’t be baked into the primary interface? Wouldn’t doing so result in more UI cohesion and less back-and-forth for the users?
Of course, there may be a business case for having a separate admin interface. Maybe your CMS provides one out of the box and building the functions into the site will take more time and cost more money. But if all we’re after is the best possible UI, I would think that is achieved by as much cohesion as possible.
I totally agree. Dribbble is a good example of how seamlessly “admin” actions can be integrated directly into the site, eliminating the entire need for a specific place to edit your stuff. If you’re viewing one of your shots, you see an “Edit” link, and if it’s someone else’s shot you don’t. You view a list of your own shots in the same way you view the shots of any other user. It’s one of those things that’s painfully obvious; it seems silly this is only recently becoming a pattern.
But there definitely are uses-cases for separate admin interfaces. I’m working on an online exam tool for high-stakes tests (things like medical certification exams) and there is simply too much complexity to try and wrap it up into one unified interface. Furthermore, the goals of exam administrators and candidates are very, very different, and they are each better-served having specialized interfaces.
(But I think you’re talking more about consumer-facing websites anyway; not specialized web-based products).
I think it’s a question of whether the “users” of your site are also the content creators. The classical example is a newspaper. There’s no reason, IMO, that it’s necessary to shoehorn those admin controls into the rest of the site.
Security. For the government at least, all of clients must have a separate front-end/back-end. We even have to go as far as having separate databases for both ends. Like with today’s Twitter hack, security must eventually be brought up to stricter standard.
For sites that are not concerned with security however, their is still certainly a need for separate interfaces for most. They can have the same design aesthetic, but with most sites the front end user has very different needs than an administrator.
CMS’s such as Joomla! allows users to edit on the front end as well as the backend based on their needs. Drupal has a separate backend but can be designed to look the same as the front-end so the user may think their is only one interface when infact their are two. Backend interfaces are more considered with global mass changes such as scanning through all your posts, where is front-end interfaces are more concerned with individual items such as one post. Different users, different needs.
I know exactly what you’re talking about. And I’ve been giving it some thought lately myself.
Because I’ve used more and more of those “front end admin” systems lately that have felt very seamless. And I’ve thought, “you know, I wonder if over the next few years we’ll phase out ‘admin back-ends’?”
My reaction to that idea is mixed. Like I said, sometimes it’s been seamless and I’ve liked it. But other times I’ve been annoyed by it and WISHED for an admin area.
I think the admin area creates a valuable psychological space.
It’s like anything else…depends on the use case. But I still wonder if eventually all the use cases will shift…
@Alex:
I have a few specific responses, but it boils down to this: I think I agree with your premise, but not your newspaper example.
You say, “there’s no reason, IMO, that it’s necessary to shoehorn those admin controls…” I agree with that. It’s not necessary. It’s probably never necessary to have embedded admin tools. But I do think, given good designers, it will almost always produce the best possible UI.
At a typical newspaper, there are a lot of content editors/producers. I think the more content editors you have, the more reason there is to have embedded admin tools. If you only have one content producer (say, for a typical personal site), it doesn’t matter much. That’s only one person who has to learn and understand a separate UI. But the more editors you have, the more time you’re going to invest in training users on the UI conventions of the separate “admin tool,” and the more chance there is for people to get confused by having two deal with two separate UIs.
Like I said, I do agree with your premise. When users are the content creators, it’s necessary to have embedded admin UIs. Why? Because of what I said above: having that many people to train and not be confused by a separate site would be crazy. And if you agree with that, then you’re admitting that the best possible UI is to have embedded admin tools. There may be business cases for not choosing the best possible UI (and instead, choosing the fastest, or simplest UI), especially in cases where you have very few content editors. But I don’t think newspapers (and I’ve worked for several) fit that scenario.
This is a sincere question (not a disagreement): Why is it not possible to have security at a very high standard with embedded admin interfaces? What about them is inherently insecure?
If two interfaces are designed to look the same, I would argue that there’s really only one interface (which is the way I think it should be).
There’s no doubt that it can be done poorly. But so can backend admin interfaces.
That’s the first argument for admin interfaces I’ve heard that I could be persuaded by. There may be something to this. :)
Some sites really lend themselves to this approach; the example you gave at http://pernothudson.com/admin-de… works pretty seamlessly. But this is a pretty simple site, with fairly simple content.
Its important not to forget that your design should be honed to the task at hand. A user editing and creating content has a different set of goals than a user simply consuming content. You can end up compromising between the 2 and really achieving neither.
For anyone in the Django space who feels the same as Jeff, it’d be worth your while to check out Mezzanine - a content framework built on Django that addresses this issue by making all data inline editable directly in the site itself.
http://mezzanine.jupo.org/
For me, as an admin, I like that God view.
Indo find myself having more and more inline admin functions, but they re mostly pretty low level stuff. I also find caching to be problematic for front end admin functions. Or at least a bit less flexible than having a separate admin.
Honestly, I’d just be happier to deal with admins sections that didn’t suck balls.
I think it’s arguable whether a single cohesive UI is any “better” than two separate UIs. It stands to reason that the more purposes an interface is designed to serve, the more complex that interface becomes. Using the newspaper example, why does a separate but focussed interface have to be any more difficult to learn than a naturally more complex, albeit unified, single UI?
Maybe that’s a generalization and maybe it doesn’t have to be that way - I’m sure there are some examples of very clever embedded admin interfaces out there. But generally speaking I don’t think there’s anything wrong with having multiple interface/experiences designed for specific tasks.
I don’t think there’s anything wrong with it, either. And you’re right, there’s no doubt that designing great embedded admin tools is more difficult than designing a great separate admin interface. It is more complex, and that means it’s more difficult to achieve a truly great design.
But, I believe (and I have no real evidence of this), that given the same great designer, adaptive/embedded admin tools will be more cohesive and efficient, workflow-wise, than logging into a separate site to edit content.
Certainly, bad design could kill an embedded admin system. But, so too could it kill a separate admin interface.
I like your thinking on this, and dribbble is a good example of this done right. I do also agree, however, with the psychological argument. Right now I am building a backend interface that presents a slightly different information architecture based on the priority of things that need to be edited/updated, NOT in the same way it is presented on the site itself. So its more about context of admin of content versus content consumer.
Christopher Beckwith echoes my thoughts about security being a good use case for maintaining a separate admin UI. It’s all about risk management.
I chose the word risk very carefully. Adding support for this comment form increases the risk your site would get hacked. Is it likely? Probably not. You’re comfortable with the risk that came with adding these forms — because the benefits are worth it, and the amount of damage a hacker can do from this form is quite small.
Adding in-site admin capabilities for content creators is a big win for usability, no question. Following best security practices would definitely minimize the risk of admin accounts being hacked, but not eliminate that risk entirely. There is no perfect security. But: if those accounts were compromised, the amount of damage a hacker could do would be very serious.
If anyone considering modifying their site to expose in-site admin features is comfortable with that level of risk, then more power to them. I’m not that comfortable.
I should add: If the conversation was about the UI looking exactly the same as the public site, then yeah, that’s great. I want to see more of that. I just don’t want to see it on the domain that the world can access.
Jeff,
I have been thinking and preaching this same thing for quite awhile. Especially at the last company I worked for, a local news/information/radio company.
The other point I’d like to add in favor of frontend inline admins is that it requires the content producers to participate and see the same part of the site as the people consuming that content. I think this experience causes them to gain a better understanding of the site they are providing content for. This is something completely lost to them when shuffled off to some backend interface.
In regards to the security issues people are raising, how does tailoring the frontend of the site to a user based on their qualifying credentials affect security any differently than allowing them to login to /admin/?
This all makes sense, but how is the chance of an admin account getting hacked great just because the site has in-site admin capabilities? I’m not arguing with you at all — just sincerely curious. From my perspective, it seems like if you admin accounts get hacked, you’re screwed whether the admin tools are in-site or at a separate URL.
I wrote all that, and then read your second comment. So are you suggesting the admin tools should be on a domain that isn’t publicly accessible? Like, it’s restricted only to internal IPs or something? Because, yeah, that would be an increased level of security, no doubt. If so, it’s starting to make sense. :)
Risk comes with two facets: is there a chance the account would be compromised? If it were compromised, how much damage could be done? So, Jeff, done well, the odds of an admin account being compromised would be slim. But if it was compromised, the amount of potential damage that could be done would be great. That sounds too risky to me.
Incidently, hosting the admin on an internal server could just be the start. I could have added lots more security features to that scenario - but I think the point’s been made. :)
I’ve been using Vanilla Forums lately and their approach is front-end admin style. I really like it and it also has me thinking about how more web software should/could work this way. There is an admin area, but it’s very minimal and for global/setup things not content management. Anything CRUD in a CMS I can envision working from the front end.
Thought provoking post, Jeff. It reminded me instantly of what Unit Interactive did with Unify which essentially adds the ability to alter content on the fly.
This isn’t so useful when it comes to publishing but it’s great for clients who may be overwhelmed with a back end system and only need something simple.
This is I think one of the few things still valuable about Zope/Plone: for most users they could add/edit/etc content from right on the page (which editthispage/Manila did well long ago as well) and the admin interface was strictly for true administration of the site, not the content.
Back-end CMS is a very important part of a large websites such as Newspapers, Governments and County Councils. When there is a single feed of information such as a blog, then it is possible to somewhat eliminate the back-end, but for broader websites with deeper levels of information it makes much more sense to have a separate back-end which allows you to see the relationships between areas of the website.
Jeff, I think you’re right about there being a business case for a separate admin. Like most design approach questions, I think this one boils down to purpose.
No question, indirect manipulation sucks in any context (admin, mouse, whatever). If you’re building a web app, (like Twitter, Facebook, et al) the right approach is to integrate your “admin”—in other words blend the reading functions and the interaction functions together. This takes a lot of time and thought, and time and thought cost money. If the goal is a site-building tool (Like WordPress, ExpressionEngine, etc), a baked in admin is a huge win. Less time is spent designing for your editors who will be using the admin interface, and more time spent on designing for your customers, who will be interacting with the front end.
I think the real question is where are your customers? They are the ones we’re designing for, us designers are just backstage putting on the show. If your customers are using the “admin” interface, spend as much time as you can polishing that thing until it shines. If your customers are readers, rather than authors, maybe best backstage tool is an admin interface.
Gordon, thanks for the thoughtful post. In general I do agree with you that from a business perspective it makes sense to put your time and money “where the customers are.” But, for large sites with lots of editors (like a newspaper), I think you have to consider those editors as consumers of the design, too. They may not be paying customers (in fact, you’re paying them), but a simplified UI for them could save you money in the long run (in terms of training, recovery from mistakes, etc.).
It all boils down to what matters in each case. I maintain that the direct-manipulation UI for admin tools gives the best possible user experience. But as with all great things, you have to decide for yourself if the investment in “the best” is worth it in your case. :)
Pointing to: ‘Unify’ by Unit interactive, or ‘MojoMotor’ by EllisLabs, as examples of what I think you’re suggesting Jeff. Correct me if I’m wrong of course! ;)
I agree with the sentiment, there seems to be few worthwhile reasons (if any!) to push users into a whole, different UI when their tasks/functions could be managed on-the-fly on a web site/app itself.
I got to say, that I find the admin interface necessary by several reasons.
What is the alternative? a) Editing in the frontend - might be OK for text edit. b) FTP, SSH and Shell activities requires more then the regular skills
Security issue though more then just the login box a) .htaccess security b) hidden interface URL if possible (many CMS offer this option)
Easy on customer usage a) less work with customers content b) easy introduction to customers
What was the definitiv experience that you let tweet this fact?
All the best, Chris
@Detektei AB: What do you mean by
“What was the definitiv experience that you let tweet this fact? ”
??? Den
As regards Django, I think the motivation of the all-in-one admin was in the following scenario:
No, a “backend” is not always better than an in place editor, but having all the pieces to edit a database-driven web app available from the moment you do a db sync is very powerful from a deadline perspective.
The alternative is to spend four hours working on templates and getting the interface “just right” before any data gets put in. Deadline fail.
That’s it. And of course, if you have access to an auto-gen admin backend, it will always be faster to not have to reinvent the input interface. For a certain percentage of projects this will be good enough, and that’s what they’re for.
Thankfully, django also makes it wicked easy to roll your own input forms if you want to go that way, so the time consuming option is not so awful.
Absolutely. I was working at The Journal-World when Django was in its very early stages, and there’s no doubt that was a key feature to us. I still use that process with clients, sometimes.
No doubt. Like I said above: I don’t think there’s anything inherently wrong with a “backend,” I just think the best possible UI is almost always inline/embedded editing tools. But, as with most things that are the best, the best possible UI comes with tradeoffs in terms of development time, price, and so forth. You may not always need the best possible UI. That’s a totally legit business decision to make. I’ve made that decision many times.
But if you want the best possible UI, and you can afford the tradeoffs, I think you’ll go for embedded admin tools.
I think there is a place for admin tools such as “Edit, Delete”, etc inline but I think there a seperate admin interface makes a lot of sense.
I feel adding things onto the primary visitor-facing interface can clog everything up. It is rarely designed to be that dynamic and in doing so would cause needless compromises.
Not only that but an admin interface gives you the chance to have two proverbial hats. Just as when you are at home and when you are in the office, you have a different feeling… when you are viewing the website and when you are in the admin interface you know your roles have changed.
I’ve actually got to disagree. There’s cases where you may be able to squeeze admin functionality into the main website, but I’ll go out on a limb and say it’s not for the majority of web-apps.
There’s a clear User Experience division between users who view/interact with the content of the website, and the people who run, maintain and add content to that website or webapp. If I’m running a blog why would I want to scroll through each blog post before getting to the comments in order to moderate them, when I could just pull up my admin interface and get a nice summary of new comments that need to be moderated.
It also helps with troubleshooting when the user-side of the website or app looks and behaves the same to admins as it does to users.
A couple years ago we changed our CMS, BlueInk, from using the typical Admin interface to providing an “overlay” sort of UI similar to the one mentioned above in Mezzanine. We took it a bit farther by making “admin” login a keyboard shortcut, and the editing UI less noticeable, but the light-box idea is quite similar. You can check ours out at http://demo.blueinkcms.com/
Keeping our users on the pages their editing has sped up editing time exponentially, made editing functions more obvious, and given the UI repeatable patterns so people only learn a few actions and then repeat them for all types of content. It also helped present our “page is an aggregate of it’s content” concept in a visual way that helped alleviate some of the initial confusion for those used to “editing a page.”
At any rate, I think this UI’s time has come and I hope to see more of it.
As an aside, we’re currently re-writing BlueInk onto CouchDB as an open source project (Apache Licensed) and would love some help from anyone who’s interested: http://github.com/BigBlueHat/Blu…
P.S.: Your comments form doesn’t seem to like “http://blueinkcms.com/” style URL’s (i.e., lacking a “www”) for the “author_url” field.
(Coming a little late to this post, but better late than never…)
Interesting perspective. I think your approach is right on for some tasks where a superuser wants to moderate that comment they are viewing right then and there, and for other similar use cases.
On the other hand, I think there will still always be room for an admin back end where superusers/editors can view batches of content (directory listings, comments, posts, events), review them altogether, and slice and dice them together in one place.
Under that scenario, intuitively it seems to me that a site overseer would want to head for “the admin” where the content is conveniently grouped for moderation.
I had never really though about this before! Quite embarrassing that I just accept the way things are on the web but I think it is a really good point as the more I think about it I really don’t like to be dragged away from a page for administration purposes.
I certainly agree with John Shimek on using buttons and menus on the page you are on as an alternative to being sent elsewhere as this would surely make for a better and quicker user experience.
I also agree that admin panels do have there uses for more major site / content changes but for the simple stuff a front end alternative would be awesome. Thanks for sharing a thought provoking and insightful read.
At least for some instances admin made a big effort on having a security with all those stuff there are effortless admin, but the fact that there are a lot of hackers that has been made a big problems as we all, knowing that through it really help us a lot.
It really depends on the situation and the site design, but I think having the admin interface is important when you are creating sites for clients. A good point was made that the goal of a content editor is entirely different from that of a site visitor. But it goes even further than that. Particularly if we’re talking about a CMS, where you really have to train the client to focus on semantic content rather than style…
Having the client make edits where they view the site sends the wrong message, keeping their focus less on the content and more on the style. Whether using a lightweight markup language like in this comments field, or using a rich text editor, the client will always try to inject style into the content. For example:
? ? ?
MERRY
CHRISTMAS!
? ? ?
Having an admin interface without the surroundings of the site’s design helps keep the client focused on the semantics and quality of the content, rather than trying to tweak the look of it (at least in my experience).
The 37 signals guys share your thoughts on the matter: http://gettingreal.37signals.com…
I think it’s best to use a single cohesive UI. This way you use one interface and the overall project looks great and it is less complex.
I think the real question is where are your customers? They are the ones we’re designing for, us designers are just backstage putting on the show.
I agree with much of what you say, though I personally hate seeing a “log-in” button on the front end of the site if the user is never meant to log in.
That said, you could probably sniff for an admin’s ip, which would make any front-end buttons invisible to those without permission to see it.
it agree to you this thinks is heppens
We know generic presentations suck to the core (if you saw one Joomla Web site, you’ve seen them all), but featurewise, getting stuff done > presentation for admin backends—which makes backends an ideal candidate for generic presentation. Django’s admin backend is one example of something that works ootb for any domain model and makes the content authors and us devs happy.
It’s the future, it’s going naked to the max, it’s green (no full page loads, no editing views), it’s organic (a full content editing experience with no submit buttons, but you won’t even notice it) and it’s not happening anytime soon.
The major feature blocker is creating a healthy yolk between the Web application and the user’s client. You need to define your data, you need your server to be able to generate the initial presentation and you need the client to be able to provide interactive editing and feedback. In-between, there’s a lot of services that make it happen, plus a lot of fallback handling (no JS?). Exactly the stuff that makes the brave stand out in the Web today.
I applaud you for bringing this up, because we need to talk about this some more. This is one of those things that truly empowers the users and the best way to get it out into the wild is to raise awareness with the devs that develop the tools that we, the larger dev communities, use day to day to make things happen for our users.
Inline administration work well in simple situations, but they can get very difficult to implement in more complex situations. I think there is a place for both types, but I do prefer my admin tools to be inline where possible.
I agree, changing from one interface to another to complete work is frustrating at best. A single UI that provides access to all features is surely the best way to go, unless of course the features are to be accessed by different members of the team and there is an inherent trust issue..
Well, there is a lot of admin features that have no place in the front end view. Inline editing or front end admin in certain cases could have sense for content but not for meta informations, options, preferences and the likes. If you have to make lot a changes (say also to the taxonomy, category organization not only the settings) a specialized interface is better. So you have what? Maybe two different admin zones, one for content one for meta informations structure and various settings? Better one than two.
Another thing I don’t get, content guys works more on the admin side than on the public facing site, I don’t think their behavior is disrupted cause they have to change page, probably the first log and add content and after check on the live site (or some sort of live preview) if it’s all right. For normal / casual user (say facebook or wordpress.com) having a place where to consume content (their or their friend’s one) and another to insert content I think is helpful to them. Lot less prone to confusion for the average internet user that generally is not a power user.
Also, modes are not so good as an interface behavior and a client-side integrated administration would be built almost entirely with modes.
Inline editing maybe’s good for very simple site (small portfolio/business website with little content and pages)