Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By Jose Reyero on
I've recently run into some discussion about some functionality and some options for site administrators related with a patch I've post to Drupal core. But please, this is not about we are right/they are wrong and that. I just think this subject deserves some further discussion.
So what's Usability?
Wish I could give a good definition from myself, but it's not the case, so better try google for that. I just have a few ideas about the subject:
1. Usability is about users.
2. Usability is about getting the job done.
I mean, we could think of some abstract definition of usability and also about some abstract definition of users. But when it comes to reality you just cannot say whether your web site has good or bad usability whithout knowing at least who are the users -or who you want them to be. And the same aplies also about what are they suppossed to do with your site, that is, which is the job.
About which are the goals of the site, there's about one for each site out there.
But who are the users? Do they know maths or programming? Can they read and write fast? Are they faster with the mouse or with the keyboard? Are they children or grown up? Do they know what HTML means?
So guess you know who are the users, what they can and can't do, so you could know, in theory, which option is better at least for your 'average' users, and is good enough for most of them.
Then problem solved?
Well, if all of the users are supposed to do the same tasks, and they dont learn at all from one visit to the next, that would do.
But in practice, you have first time users, experienced users, you can have content editors, administrators, moderators....
So the problem has no solution?
Yes and no. When building a general purpose CMS system, I think that is Drupal, we can think of users as just average web users -if that exists- and try to have an interface that most people get the most of. That should be good enough.
But if we think a little bit more about that users, we could agree that at least, at the very minimum, a Drupal site is going to have two very different kinds of users with very different profiles: a web site administrator and regular users.
So the first real point -I put it in bold in case you've skipped that long intro ;) - is this one:
1. Usability for regular users is not the same as usability for web site administrators.
I mean, while hiding too many options from users or adding some additional explanation here and there may be good in general for most of them, at least site administrators are suppossed to be much more advanced users who can deal with greater complexity at least when it comes to web interfaces, and are willing to give a try to documentation...
As an example, replacing old links by that nice tabs that are now everywhere may be great for normal users, but are not that good for site admins when they require an additional click every time they want to edit a story from a listings page.
And second point here:
2. We can, and should, empower site administrators to be able to addapt a site for it's intended audience thus improving usability for end users, which is the real goal.
This is, while usability for site administrators is good, there's a higher level goal, which is usability for end users.
BTW, did I tell you that I recently had to patch Drupal for some site just to get 100 word teasers when that config field could very well have been a free text field? -think it was in the past... not usability?
So... coming to a conclusion? Maybe.
Mine is this:
Providing more options for site administrators to customize the site can produce better usability for end users That, of course, assuming site admins know what they do, what the site is about, and have an idea of who are the end users... I'd take the risk.
And this small one:
Let's not worsen usability for site admins thinking of them as end users
I.e. Several lines of help text under each config field dont help too much the tenth time you visit the settings page... or how many clicks requires to edit settings for a node type in 4.6... or that nice screen where I could configure the workflow settings for all content types at the same time... -These are just examples, and agreed I didn't say a word when it was the time...-
Well, I just wanted to raise this subject, and know what you think about it. Please, let me know. Thanks.
Comments
summary
Your story is good, it explains the theory behind HIG rule number 2:
Enable frequent users to use shortcuts
to increase the pace of interaction use abbreviations, special keys, hidden commands, and macros
Since its number two, we should (and will) not forget about this.
[Bèr Kessels | Drupal services www.webschuur.com]
Familiarity
I agree with most of your points, but power-users are quite horrible for usability. You see, they tend to reject anything that isn't exactly the same as what they are used to, even if the replacement is much better and consistent. It's a short, big pain versus long, small pain thing. Oddly, most people prefer the second.
It's all about managing expectations. I also didn't like the extra click for node editing at first. Now, I don't notice it, and I think the tabs put the editing in a much more logical, more visible and more consistent location. To edit something in Drupal, I know I have to to go a view showing that item specifically, and that there will be an "edit" tab then. This applies to nodes, users and more.
Your "admins vs users" comparison is a bit narrow minded though. When Drupal is used as a blog, the users are most certainly the administrators. When used as a multi-tiered intranet, this is not the case. You cannot make much generalizations as far as Drupal's users go.
Take a look at the "separate admin interface" issue; only looking at it from a usability point of view and not from a CSS positioning point of view (because IMO it won't solve that problem at all).
Everyone wants something different:
We simply can't make everyone happy. IMO the underlying issue is simply that rare tasks are mixed with common tasks, which has very little to do with whether the admin interface looks separate or not.
As far as the dropdown vs editbox issue goes: dropdowns have one big advantage in that you can tell the user implicitly what range of values is acceptable. A textbox can have at most a single default value. If you want to specify more, you need to add more of the (according to you) useless help text. With the upcoming Ajax stuff we can also look towards static comboboxes (select from a list or enter a custom value) rather than the more complicated interactive ones.
--
If you have a problem, please search before posting a question.
Ajax: who, what, where, when?
Who is doing Ajax work and how far along is it? I've completely missed this - thanks for the heads-up.
- Robert Douglass
-----
www.robshouse.net
www.webs4.com
Ajax: the tragically named technology
Could someone explain why this tech is named after a man that stabbed himself to death when he failed to acheive his goals?
http://www.google.com/search?hl=en&lr=&c2coff=1&rls=GGLD,GGLD:2004-19,GG...
*grin*
Better explanation: http://www.adaptivepath.com/publications/essays/archives/000385.php
Thanks for that first link
Are there developers integrating Ajax principles into Drupal was my question.
- Robert Douglass
-----
www.robshouse.net
www.webs4.com
JS in Drupal
A few independent forays into JavaScript in the Drupal core have begun. Some of this has spun out of the usability sessions in Antwerp. Chris Messina has done some work with it in CivicSpace themes. I've got a demo of some Ajax functionality here (try the table sorter). There's a lot of work to be done to make absolutely, positively sure that things degrade beautifully on all non-supported browsers, however we end up using the technology.
Wow!
Life is exciting!
- Robert Douglass
-----
www.robshouse.net
www.webs4.com
It would be best if this were optional...
... since any AJaX interaction model is likely to have some serious cross-browser compatability problems.
Can you please point out
Can you please point out where the Ajax functionality is implemented in the code tablesorter.inc ?
Any live example ... how to test it?
Telemonian
The code name for my Ajax work so far is "Telemonian." I figured about three people outside my Great Books course would get it. :-)
Dude...
...that's wicked funny!
...well, for us in the Discovery:Civs watchin crowd it is...
...all three of us...
~Tat~
Your "admins vs users"
Agreed, I didn't think of that one and just generalized too much with that "admin vs users" but also, a user managing his own site is a different user profile so he should be somewhere in the middle.
Completely agree with you here. So maybe we should find a 'middle way', like having 'basic options' and 'advanced options' for each of that config pages. I still think scrolling down a web page is much more preferable to have to try tabs just to see what is hiding there. And that two level tabs... :( :(
The only think I would really separate is content administration from site/content types configuration.
About drop down vs editbox... Drop downs are nice for what they are intended, which is a discrete -not countinuous- list of values, and maybe when different actual values/displayed values are needed. Getting back to my example, having 'Teaser length' as a drop down has the only advantage that it can be managed by a five year old, while unnecessaryly limiting everybody else. I just remember some forum in which someone asked how to get rid of teasers, so I suggested 'try set up teaser length to zero', and someone else made me notice that it was not an option.. :-)
Anyway, I will have to take a look at that Ajax
So I think I agree mostly with your points and in that 'we cannot make everyone happy' and some compromise is needed, just I see latest developments too unbalanced in the sense they tend to make no difference between site administration and the final user's view of the site, thus restricting useful options for site admins, which could produce a site better suited for each use.
And maybe yes, I usually "feel the site is a product of the CMS", though I had never thought of it this way, so thanks for this very interesting idea. I think that's because of the kind of sites I usually work in... so maybe I still have to make up my mind about that...
https://reyero.net
Usability for a site admin
Usability for a site admin is a personal peeve of mine. I think that developers tend to load unrelated tasks on site admins. When I click on something as a site admin I want get and see what I clicked on not something else or a labyrinth of controls.
The two things as an admin that irritate me the most when it comes to Drupal usability is:
1) The administration block. I hate it. It is the cause of hundreds of extra clicks per day.
2) returning to view rather than the edit area after an edit. The edit area shows the changes just as clearly as the view and allows for further changes without clicking back to edit and waiting for a browser load again.
Ajax is nice but most of what is wrong with Drupal administration usability can be fixed with better planning of routines. Ajax speeds things up but you cannot fix bad usability with speed.
---------------------------
Hivemindz CMSopedia
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
"admin" vs. "users" is ARTIFICIAL
The holy grail of a community site is a community where there are many "small admins." You have one person who's responsible for moderating comments; another who's responsible for posting stories about some type of news; someone else who runs polls or mailings; etc.
For that to happen, there must, MUST be an erosion of the distinction between "user" and "admin."
This is not a blue-sky idea; this is what you have to do unless you want to have one or two people who do nothing but web stuff. Without this type of organization, you develop bottlenecks in either web maintenance, group operations, or both.
Right now, Drupal is not conducive to that kind of organization. The fact that people manage to make it happen doesn't mean that it works well and that they don't lose cycles and hit bottlenecks. They work past them and go on -- "small pain over a long time", I think someone said up-thread. That's bad. In design, it's always important to remember that people don't always prefer what's better for them. In his tests back in the 80s, Jerod Pore found case after case where people preferred less-efficient, less-usable designs.
Usability is also about good
Usability is also about good semantics. Knife sharp exact wording usually leads to problems. Nor should it go the other way and lead to a new language. Things should not always be named for what they do unless there is a naming conflict. Otherwise you find yourself trying figure out what the hell a mambot is >:[
Oh no, ' component' is too similar to 'module' so lets call them 'mambots'. Which sounds like something from Al Bundys nightmares.
---------------------------
Hivemindz CMSopedia
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Usability is also homogenity
Dear users/administrators
General
Usability is also homogeneity. Each CMS is like a new tool. User has to learn it. Unfortunately, too often the use of a new module brings new problems and learnings. Briefly, as long as Drupal will not tend to function with more homogeneity between modules, it will remain a complex tools for most users. Thus, a “common” user will simply wait that more ergonomic Blog or CMS include the technologies and ideas originally developed into Drupal. At the opposite, abnormal users, experimented and passionate users of CMS :-) , can continue to enjoy Drupal capacities and hack code.
Specific
Personally, I really like the concept of the contextual help. However, the contextual helps is not so helpful especially when it doesn’t give information about what to do, but solely act as a unnecessary contextual dictionary.
Sincerely
This is a really good point...
This is what makes good products better - familiarity. Why force a user to learn something new if for the most part you can emulate what they are already used to.
Perhaps I just haven't found it, but maybe what Drupal really needs is a "common design principals" document - an agreed upon way of designing UI across all modules. Most companies I have worked for have something like this and it just makes sense. I think all the nuts and bolts are there by default, in the way the reusable code in drupal has been developed. But there is still alot of room for an individual to enforce thier design ideas - for good or ill. Obviously not all things are going to fit a common mold - but at least by defining a design strategy, in the same way as the coding standards has been provided, then you can start to look at how much you can make the same, and recognize what really needs to be different...