Blocks: wrong word?
public
group: Usability
IceCreamYou@dru... - Mon, 2008-06-02 04:19
There may have been discussion about this before, but I'm not aware of it. I know there's a similar discussion about the word "node."
Something I like to do just to see how "usable" my site is, is to watch someone register and try to use the site without giving them any help. I was doing this the other day, and a user went to edit her profile. Everything was fine until she got down to the section where you can enable or disable blocks; she just skipped it. I asked why, and she said she was confused; she thought "blocks" would "block" information.
That sounded logical to me. Blocks should block. Blocks as Drupal uses the word are more like blurbs - blurbs of information.
So: thoughts? Suggestions for a new word for "block"?
Box?
Box?
Perhaps this type of user
Perhaps this type of user doesn't need to be presented with this type of drupal administration lingo at all?
noun instead of verb?
I generally think of 'blocks' as a noun rather than a verb - like building blocks - as a noun it makes a lot of sense I think.
I've got a feeling Joomla and WordPress use 'blocks' as well but not tried either for a long time now. I'm pretty PostNuke was using blocks to mean the same thing back in 2002/3 or so as well.
That's not to say we shouldn't change it, but I'd be interested to see both what other CMS do, and it'd be a fairly major change.
Had the user you tried this out on ever used another CMS?
For me a bigger issue in Drupal is the relationship between blocks and regions, and that was have non-block/non-region stuff that's displayed on a page: site name, slogan, mission statement, search box, primary and secondary links etc.
Other CMS Example...
Since you asked, I had some training in Stellent's CMS (now owned by Oracle). They use the word "fragment" to describe what is loosely analogous to Drupal's block system. I don't have strong feelings one way or the other as to whether this better describes the function of blocks, but it does at least start to get at the idea that they are typically small chunks of the total page and not the prime-time content.
That's good to know. Just
That's good to know.
Just re-read the first post and realised this was just a test on the user account page. This makes my 'have they used another CMS' question pretty invalid, although it also means that an admin could use string overrides to change the text to something else pretty easily. I'm not sure we can find a particularly better word for 'block' for admins ('fragment' is neither better nor much worse IMO) - but it might make sense to change that one bit of text to something more friendly for site visitors.
Just checked what they use in netvibes (the entire interface is drag and drop blocks, and a bit like panels), and they use "widgets" - although it doesn't differentiate between the content in the block and the block itself. It's a pretty standard term, and it covers the 'little block of content that can show up anywhere' thing, but I'm not sure it works if you're allowing people to enable and disable menus - but does 'block' work for that either..
I don't think the problem is
I don't think the problem is so much "blocks" as it is the "Build" section. If blocks were found under a "Site layout and design" admin section of sorts, the meaning would be much clearer.
++++++++++++++++++++++++++++++++
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
++++++++++++++++++++++++++++++++
work: http://www.onnetworks.com
blog: http
I don't mind the word
I don't mind the word "block" for admin - it's pretty self-explanatory once you get to a page where you have to do anything involving blocks. I think "widgets" would be a good idea; it's the most generic term I can think of, and covers the most common use of optional blocks. If an admin is using optional blocks to allow users to enable/disable menus, then he/she can use string overrides.
Ideally, Drupal should work without string overrides in such a way that any user confusion should be an administrator's fault, so I don't think it's acceptable to just say "string overrides is the answer" and call it a day.
For me the name 'blocks' was
For me the name 'blocks' was self-explanatory enough. I've never confused it with blocking content or something. Nonetheless I really like the name 'widgets'. It's a really catchy, trendy name and I think new Drupal users will directly understand it's purpose.
Widgets vs gadgets
Isn't "widget" typically used for low level UI compenents? See here.
A block is typically larger than a single "widget". I think it is closer to what Windows Vista and Google Desktop (and probably others) call a "gadget". See here.
FYI: Gnome uses the term "applet", but I suggest we stay as far as possible from that term ;)
Aye, widgets as a part of
Aye, widgets as a part of CCK represent the type of UI component with which a field's value is set.
I've also never had a problem with "blocks", and I don't think either widget or gadget or any of the other suggestions are any more explanatory or specific.
So... if it ain't broke... ?
Some description text for the block configuration fieldset to offer some help in context might not be a bad idea, but I don't see a benefit to changing the name. We'll still have to explain what they are and why the user might want to turn them off.
Help text +1, change the word -1
I strongly agree with adding some help text, and strongly disagree with calling "block" something else just for users. Administrators are users too, and users may become administrators. If we use two different words to describe the same thing we're asking for confusion.
I've opened an issue for adding help text at http://drupal.org/node/266153 (It's for 7.x beacause the strings are frozen for released versions of Drupal.)
--
Hilde Austlid, Drupalchick
If the word "block" is the
If the word "block" is the source of the confusion, adding help text is just a band-aid. Remember, just because you (in the non-accusatory, omniscient sense) never had a problem with the word "block" doesn't mean it isn't a problem. Hardly any non-technical users read help text, and the double meaning of the word ("block") still exists.
Try this as an example: ask any random person what they think the word "block" means in the context of the internet. They'll immediately associate it with spam and ads. That's the opposite of what we're trying to achieve.
...
I see your point, and agree with your "Hardly any non-technical users read help text" (actually, I think you can remove "non-technical" from that sentence). If we were choosing Drupal terminology from scratch, I'd probably support you in trying to find another word.
But since the word's already there I think we're creating more of a problem if we use two different words for the same thing. Today's user might be tomorrow's administrator, and go looking for how to create those widgets or blurbs. (And, of course, it's so widespread that it's not practical to change it everywhere.)
Also, while users don't read help text they do read headings -- that's, after all, why we're discussing this in the first place. If we change "Block Configuration" to something more informative that should alleviate the problem. Catch suggested "Block display settings" or "Configure block display" in the issue. I like both those, but we might find something even clearer if necessary.
If they don't want to read
If they don't want to read the help text, then they can just leave the blocks in their default state. ; ) That is why administrators have options to turn blocks on or off by default. A site that is particularly worried about confusing users can just not give users the choice.
Your example is a little loose... that could go for almost any word or term in Drupal. We're dealing with a subset of the internet... Drupal sites... where a block is a block of content on a page. Alternatives? Widget? Gadget? Ask someone what a gadget is and they might say it's a tool that lets you connect to the internet, like a cable modem. A Google gadget? Oh, that goes on my Google page. Our context isn't just "the internet", and site users who get confused can just bone up and read a line of help text, imo.
Well I'm still very much a
Well I'm still very much a Drupal newbie, so maybe my questions can help?
"where a block is a block of content on a page" - so it is a Content Block? Or is it a section of the page?
When someone is playing with the blocks, what are they essentially trying to do with their website? Considering the basic tasks involved might help determine the best way to name it. (I still don't really get it)
Also - try asking people new or unfamiliar with Drupal - if everyone on this thread does, a few interesting new ideas may come up.
In the Drupal usability study I just worked on, we found that experienced web administrators (unfamiliar with Drupal) had a lot of trouble with Drupal terminology - so it's more than a matter of the admin just turning it off - what if that admin doesn't get it?
"what if that admin doesn't
"what if that admin doesn't get it?"
Then they'll have bigger issues. Honestly, they should just make an effort to continue to learn. If they've gone to the blocks configuration page once before, they'll know what the setting in their user account is. I don't think changing the name of blocks will make it any easier for a Drupal newbie to learn... it'll just be more abstract and at odds with the entire history of Drupal.
Things do get renamed, like access control -> permissions from D5 to D6. But that's more descriptive, not less, and it lines up with the actual code and concept that "access control" was representing all along. This just seems like an area where we need education and a little help text but not renaming a major part of Drupal core.
Easiest to use CMS wins
Assume for a moment that everyone writes their own website from scratch, say 300 000 programmers world wide writing their own dynamic website. Then some CMS's or frameworks start to appear as the number of websites explodes from hundreds of thousands to millions to billions.
As the competition has narrowed, we've gotten down to about 80 competitive webCMS's, not including frameworks, social software, or hosted content applications.
So when you say "they should just make an effort to continue to learn", they absolutely will. They will go learn, an easier to use CMS.
For more insight read: http://buytaert.net/ockhams-razor-principle-of-content-management-system...
Cheers,
Kieran
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign
yes and no
If someone can't get their head around 'block' quickly, they may well not understand 'widget', 'fragment', 'applet', 'gadget', 'pane' or any other alternative either. And as mentioned earlier, if something's similar but not quite the same (like desktop gadgets) then it might be confusing/misleading as well.
However, I think block.module has much bigger issues than the name:
If these UI issues were dealt with, then 99% of site visitors, and whatever number of admins might go to an 'easy' CMS might never need to know that blocks are blocks - they'd just be happily clicking and dragging and dropping and deleting and adding them. For example, I had to go over to netvibes, log in, add something and check hover text to see what they called widgets - I'd been using it for a year or so without noticing.
"they should just make an
"they should just make an effort to continue to learn" - unfortunately, many people don't. A lot of people are just going to upload it and play with it, and if it doesn't work work for them, try something else. And those users can be ignored, but it's potentially a lot of users - and making the terminology and interface more intuitive and easier to use is the goal, right?
But maybe changing the term block isn't so much the crucial issue? Most people we tested didn't even get they were looking at the actual website when they tried to post some content...Perhaps it remains "block" but more task centered labeling is used to get the user there....still stuck on determining what the task is here :)
oh wow
We had exactly the same thing with at least one or two evaluators at UMN, which makes that a really, really interesting common issue between the two studies, and one that I'd never have anticipated beforehand. Do you have a write up from the testing anywhere?
Slots from advertising world
I've started using Google new advertising manager product and they use "slot", to describe the place you put an advertisement. Apparently this is a pretty common term in advertising business which is the revenue stream for many websites.
Wordpress uses widget and sidebars to refer to the content and block which contains them.
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign
again
I will repeat myself and say I don't think there is anthing wrong with the word 'blocks.' I think the problem is presenting the user with the term blocks without any additional help or context, leaving them confused. I would think a simple sentance underneath the 'configure blocks' text would go a long way in solving the problem. Something like:
This section allows you to personalize what content blocks you see while browsing the web site
In fact, if it the 'configure blocks' text that is confusing, perhaps changing it to 'personalize blocks' would be helpful as well? Just a few thoughts. I most certainly do not think that changing the block buzzword to another buzzword is the answer here though.
'personalize' could help a
'personalize' could help a lot and would be a big improvement regardless of anything else. You want to file a patch?
could do
I could do, but might not get around to it until the weekend. Where would be the approriate place be to file the patch?
Issue #266153
I made an issue here: http://drupal.org/node/266153 with a suggestion for help text and new heading. I suggest we move discussion about the exact phrasing to that issue.
--
Hilde Austlid, Drupalchick
You might start by posting
You might start by posting the patch here, or (better) filing an issue against D7 and posting a link here.
But what struck me most was Catch's drag-and-drop example. I use both iGoogle and My Yahoo!, and those do an absolutely excellent job with the concept. So does Pageflakes. My Yahoo! even makes it so you don't have to leave the page to add widgets (that's what they call them) -- there's an AJAX dropdown when you click "Personalize."
So it looks like this problem will eventually become irrelevant. For now, I vote to change "Block configuration" to "Personalize content."
"sidebar items" instead of "blocks"
In conversations with normal people, I usually refer to "blocks" as "sidebar items" instead. (This is also what I change the "Block configuration" name to on the user edit pages.) While "sidebar items" is technically incorrect, I've noticed that several clients have been excited to learn that "sidebar items" can magically transcend the sidebars.
I agree with IceCreamYou that the word "block" is too easily associated with blocking spam and ads.
Best practices
So we have basically containers and elements what go inside them.
http://help.blogger.com/bin/answer.py?answer=43708&ctx=sibling
Non-CMS examples
Since we're focusing on end-users here, who don't use Drupal in a vacuum, and more likely use non-CMS systems much more in their day-to-day browsing, we should look at outside applications for examples of what they may be used to as well:
Its too bad we can't use
Its too bad we can't use more casual language, and say that the blocks page "Empowers you to clutter up different parts of your crappy website (regions) with a bunch of random crap (blocks)."
I liked google's usage of the word "stuff".
++++++++++++++++++++++++++++++++
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
work: http://www.onnetworks.com
blog: http://www.nicklewis.org