Posted by icecreamyou on June 2, 2008 at 4:19am
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"?
Comments
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
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
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
--
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.
--
Hilde Austlid, Drupalchick
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-systems
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
--
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
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
blocks, widgets, stuff, etc...
I personally think "blocks" is a bit abstract. When I first used Drupal, I remember seeing "blocks" for the first time and thought it was unusual. The work Lullabot did with Buzzer suggested that "widgets" is more meaningful to beginning users. Widgets is abstract too, but major sites have helped to popularize the term. According to Kika's "best practices" the term widgets is listed twice. Thinking back, "widgets" would have had more meaning to me. Now that I'm more experienced, widgets would still work for me. It breaks down in some cases, but we should always solve for the 80%.
Um, no -- on two levels
Noyz, I agree that the term "block" might itself hinder a new user's understanding of the concept, but I don't agree that changing it to "widget" would solve anything.
The working definition of "block" that first made the concept clear to me is "a container for content." In other words, it's essentially a region in the page layout that can be populated with anything you want. Many blocks are passive. For example, a navigation block just sits there, waiting. Until I click on a link, nothing about it changes.
At least to me, a "widget" is active. If I can add a snippet of code to my page and get a constantly updated view of the current temperature and weather-radar image for my location, then that would be a "widget." To control the appearance of my page, I would put that widget in a block, but the widget is not the block.
The widget is the content. The block is its container.
And the second place I have to disagree is the concept that "we should always solve for the 80%." One of the many things I have learned in developing Web applications and pages is that if even 5 percent -- heck, with a project the size of Drupal, even 1 percent -- of the users don't get it, you won't be able to support it. Yes, there will always be some people who just don't get it, but if we accept a failure rate of 20 percent on each issue we will very quickly have a small minority of people who understand each of the important issues well enough to use the product.
Should we try to find a term that is better than "block"? Yes. But let's not accept one that is only marginally better.
Cheers,
Cliff
I'm trying to leave opinion out of this...
The user testing performed on Buzzer, suggested Widget has more meaning. Other applications although slightly different in nature, would not have used such a word without a significant amount of testing and positive results. I personally don't think any label should go into a UI without some type of testing. Adding without testing is merely assuming. Assuming is designing for yourself and not the end user. If another word is better, I'm all for it. My suggestion would be to run with the standard, test it, see how users relate to it, and if it works, stick with it. If it doesn't try something else, and retest.
80% is a common rule to follow. if you try to design for the 100%, you end up with Drupal. Yes, you have to also design for the other 20%, but the point is, for those cases, it's ok to have a less optimal experience.
I agree on leaving opinion out...
One way to go wrong with usability tests is to not weigh the results of the tests against other knowledge.
I take the results of the usability test to mean that Drupal would work better with a term other than "block." That the people participating in the usability tests suggested "widget" means that one of these is true:
So we need to hear what the users are saying, approach the problem with a greater understanding than they themselves might have, and come up with the best solution. Otherwise, they and we are likely to regret the results.
Create an issue, I think
Create an issue, I think there is enough ground to say we should change it to widget. I think leisa and mark can pick it up in their cycle of testing.
I, too think that "widget"
I, too think that "widget" and "gadget" are too closely associated with live/interactive content -- products like igoogle and desktop "widgets" have ensured that. Blocks are more general in nature, ranging from content display to login to search -- I like the name fine as is, although I agree a bit of help text can go a long way for the confused newcomer.
Context is king
I'd say that is where blocks belong, together with themes. Provide the right context and you don't need help texts.
Widget has wide understanding with other uses
While the term "block" is rather confusing for the non-primary content objects on a page. All content services/tools have their own naming conventions for the primary and secondary content objects that make up a page. While blocks are too generic of a term and it took a while to sort out nodes and blocks, until I mapped the meaning to primary and secondary content objects.
The term widget has another well understood meaning already in the web development world, live/interactive content, most often related to javascript components. This terminology would be even more confusing than the over generic blocks. Widgets are something which could easily sit in a block and be managed in that manner.
Having worked in the web dev and content management worlds for many years, choosing widget would be a giant step in the wrong direction for increasing clarity.
The best suggestion is a simple diagram, which is what triggered understanding for me and explaining them as primary content objects and secondary help too (well, for people with certain content mapping backgrounds).
Why?
Why does the user even have the option of switching blocks on and off?
That seems kind of superfluous from a designers perspective.
Or is that being too much like a chef, agitated that a customer would apply salt and pepper?
I like blocks
I like blocks, I thought of building blocks straight away.
Maybe with some of the icon work going on that there should be some LEGOish looking bricks or otherwise?
Just a suggestion.