'Blocks' is a funny name for the stuff in the sidebars. Other systems call these things 'widgets' or 'modules' (ha!), but never blocks. Often times when I'm training, I explain these things as "boxes" of content, and propose we change their name to boxes.
In the Drupal world, we already have a module called boxes and Drupal 8's blocks will probably do everything the current Boxes module does - so makes a nice kind of sense that we should steal that name to describe our new blocks anyway.
We need to change the name of blocks, for one major, very important reason. Twig already uses the 'block' name space, to define a chunk of markup that make be changed, see http://twig.sensiolabs.org/doc/tags/extends.html.
If we ship Drupal 8 with blocks in the UI that are completely unrelated to blocks in the code, we are going to make things very, very confusing for everyone.
Comments
Comment #1
heather CreditAttribution: heather commented+1 for the confusion about "blocks" in training. It's one of those drupal-isms which you have to translate to new users.
Boxes, which implies a container, would be MUCH better.
Widgets is, yes, what other people understand from other systems. That would be good too!
To me, widget implies some programming or some wizardry. So a "widget manager" or "widget administration" implies turning functionality on and off, which is not analogous to what the current blocks page does (or what the layout manager will do). So I think I lean towards the generic "boxes" since you configure functionality elsewhere, and you "move around boxes" in the layout.
This seems like a win-win. We avoid conflict with Twig, and make Drupal more learnable.
Comment #2
KrisBulman CreditAttribution: KrisBulman commentedI don't really have beef with the current use of the term blocks in Drupal, as I take it to mean a 'block of content'.
In twig, block tags placed in parent templates allow for new 'blocks of content' to be pulled in from child templates.
However, I definitely see the potential for confusion with new themers if both terms are still present in D8.
Boxes is definitely the logical choice here, at least out of the options provided. And the boxes module has made this term moderately commonplace (73,135 downloads, and 12267 installs).
Comment #3
kika CreditAttribution: kika commentedSome notes:
Until D6 Drupal used to have boxes aka custom blocks. http://api.drupal.org/api/search/6/box
Widget namespace is already taken by Entity API http://api.drupal.org/api/search/7/widget
Comment #4
cweagans-1 to this change. We're going to run into naming collisions whichever way we go. Blocks have been a part of Drupal for a while. Please, let's not change user-facing terminology because developer facing terminology is different. Developers are smart enough to know the difference (especially if we have a documentation page that says "Hey! These are different, so watch out.")
Comment #5
jwilson3I think before we can make an educated decision on the potential confusion here, it would be helpful to see an example of how Drupal might end up using Twig blocks.
I'm having trouble, just now, with all the Drupalisms and existing theming preprocess and newly expanding sub-pattern theme suggestions system, just how a Twig block implementation might work. Assuming some of the core theme system is going away -- its not clear what at this point, when we would get to a point where these twig blocks would really be useful.
Maybe someone with more Twig experience could throw in a code sample here to see what we're potentially talking about?
Comment #6
steveoliver CreditAttribution: steveoliver commented@jwilson3: Here is a simple contrived example for a user login link template:
After the initial dicomfort of changing the Drupal term "blocks", and considering alternatives like "area", I think "box" makes pretty good sense. Not the best sense, in that it makes me think of a 3-dimensional object, but when considering the terms "blocks" and "boxes" together, I enjoy how "blocks go in boxes".
...BUT I'll bet the change in terminology will have most existing Drupal developers, especially when learning Twig saying "Wait, what? Blocks go in Boxes? But blocks are not our old blocks? What are boxes?"
It sucks that we would not only be changing, but inverting our concept of blocks, from containers to chunks of stuff.
The question then is:
Does the benefit of changing "block" to "box" (helping newcomers) outweight the benefit of keeping the legacy term (which may or may not help Drupal devs) and dealing with two things called "blocks"?
Short-term, I resist the change. But long-term, I think it needs to be done.
I'm 99% in favor of changing "block" to "box".
Comment #7
jwilson3Thanks steveoliver. your example makes a lot of sense. Thinking on the term of "box" for sections of content (that potentially do special thing) box sounds more like a container, whereas "widget" "thingy" or "dohicky" implies not just a wrapper around a section on the page, but that that wrapper has its own set of configurations and settings and options. I like "widget" over "box". Further, "page widgets" and "add a widget to your page" rolls off the tongue a lot cleaner than "page boxes" and "add a box to your page". But, at the end of the day, I also like my bikesheds painted red.
Comment #8
mbrett5062 CreditAttribution: mbrett5062 commentedI also think widget sounds better then box, and I am finding a lot of use for that term in other CMS's.
See below for some quotes.
Orchard CMS
New Media Gateway CMS
Kentico CMS
level671 webBuilder CMS
ProWebsite CMS
JefTek.com on Graffiti CMS
Comment #9
heather CreditAttribution: heather commentedDoes anyone know: Did they consider renaming blocks when they converted them all to "plugins", but kept the name "blocks"? #1535868: Convert all blocks into plugins
Comment #10
xjm@heather, no, you are misunderstanding what that issue did. It just changed the architecture for how block types are defined, loaded, and stored. It has nothing to do with the name.
Comment #11
Alan D. CreditAttribution: Alan D. commentedFollowup on #8. If you are looking at other CMS, widget floats to the top mainly because of wordpress that has over 50% share of the market, http://www.opensourcecms.com/general/cms-marketshare.php
I think Joomla's module can be ruled out due to the obvious reasons ;)
Personally, I like element, which has limited use out there. I think Typo3 may use this. This implies a building block that may or may not have any direct integrated functionality. Conflicts with core form elements.
However, I don't think that this should be changed without some UI testing that backs up the need. This should be fairly trivial to set up as it would only require a small number of string overrides.
Comment #12
pounardMy vote for widget. I think it's a generally accepted & used & understood word.
Comment #13
Gábor HojtsyNow that #1535868: Convert all blocks into plugins landed, "block" is in fact used on the UI for two different things. First it is used as a "block provider" or "configurable block" where you should give a unique machine name to the *block instance* and can provide other configuration pieces, and then there is a block instance which can actually be placed on the page. So you need block instances configured before you can place them, and placing them is part of the instance creation. One block can appear in multiple instances. There is no differentiation between these two terms on the UI.
Comment #14
Crell CreditAttribution: Crell commented"Widget" already has meaning in Drupal for something completely different, and changing that too, this late in the game, is not likely to work out well.
I would actually suggest if we're going to change the name that we use the name of the Drupal thingie that is closest to what the new blocks are: Panes. Skip the "content type", "content pane", etc. nonsense. Just call them "panes" (and correspondingly pane types).
Comment #15
pounard@Crell out of curiosity, where is the "widget" word being used in core?
Comment #16
longwaveField UI uses the term "widget" for field widgets on the "manage fields" pages.
Comment #17
effulgentsia CreditAttribution: effulgentsia commentedPer #11, Wordpress seems to use the word Widget to mean something pretty similar to Drupal blocks, and given their dominance, I guess whatever meaning they impart to the word becomes its defacto definition, though I think all of the widget types mentioned on http://en.wikipedia.org/wiki/Software_widget mean something other than what Drupal blocks / Wordpress widgets are.
In HTML and ESI, there's the word fragment, though this might not be a user-friendly term.
In http://groups.drupal.org/node/160144, people gravitated towards the word Component. That word is also being considered in #1875974: Abstract 'component type' specific code out of EntityDisplay for a concept very similar to Blocks, but within the context of rendering entities rather than full pages. In #1818142: [meta] Unified Blocks and Layouts (SCOTCH+WSCCI+Spark+Field UI), there's some desire to unify entity and page display configuration, thereby unifying Blocks and Entity Components, though there's some doubt that such unification can be achieved in the little time we have left for Drupal 8.
Comment #18
effulgentsia CreditAttribution: effulgentsia commentedAlso, if we're considering renaming Field UI widgets to something else, I'll just mention that in D8's new Edit module (for in-place editing based on Create.js architecture), we're currently using the word Editor to mean a client-side thingy that edits the value of a field, because that's the terminology used by the Create.js stack. And, in #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration, we're proposing to use the same word Editor to refer to a text editor (e.g., CKEditor, Aloha). Arguably, Field UI widgets can also be renamed to editors. I don't know whether that would be overloading the word inappropriately, or appropriately, since in all 3 cases, they're referring to a thing that lets you edit a field.
Comment #19
Alan D. CreditAttribution: Alan D. commentedVery little current usage (http://api.drupal.org/api/search/8/component) and usage is very obvious to me. Does this outweigh the existing usage of block or widget though?
I don't actually like widget as it implies a plugin for the system that may or may not have a UI. However, this is probably my own bias coming from a software development perspective.
Though, I really have no issues with block. Normally our clients never need to access this side of the system and when the odd one does, I don't think that anyone has expressed any issues with the name block. I think naming issues are fully related to the persons experience with existing CMS, which does give weight to the name widget sadly.
Comment #20
tkoleary CreditAttribution: tkoleary commentedIMHO this is a usability non-issue.
Given the (many) more important aspects of this meta issue i'm inclined to say this is a bikeshed.
Comment #21
cweagansI think this hits the nail on the head. It's absolutely a non-issue.
Comment #22
pounardI have to unvote for "widget". I agree with #20 and #21, this doesn't really make sense to change "block" name, it's I think actually a good name.
Comment #23
msonnabaum CreditAttribution: msonnabaum commentedTotally agree with #20.
We shouldn't be considering changing our terminology based on naming conflicts with our dependencies.
Comment #24
jibran+1 for #20
Comment #25
cweagansComment #26
Alan D. CreditAttribution: Alan D. commentedThe consensus was to ignore the perceived conflict with Twig, although I'm not sure that this was the main focus of the original issue, rather that this was simply an argument for the change.
So if anyone does want to push a front end UI issue, I would suggest that this is handled in a new issue with real data to back it up, following the steps given in http://drupal.org/ui-standards.
However I am sure that you would really need a strong result from real testing to get this considered by the core team. By real results, I don't mean "clients are confused by the term Blocks", I mean designing and running some form of UI testing with quantitative data such as "from UI tests on new users showed that the term Widget reduced the time to configure a Login block by 34% over the term Block, while using the term Component configuration took 10% longer than the term Block.", etc. Or dangle a carrot to someone from the UI team to look into this on your behalf.
If you are a true Drupal newbie silently listening, let your voice be known rather than be drowned out by all of the crusty old Drupal developers like myself who have been wading the Drupal quagmire for years. Most, if not all of the users that have posted into this thread will have long forgotten their confusion when they first encountered concepts like nodes or blocks :)
Comment #27
jensimmons CreditAttribution: jensimmons commentedI find it incredibly confusing that the enterprise-level web industry uses the word "module" to mean what Drupal calls a "block". It would be a very hard thing to change in the Drupal world, but I'd love to see Drupal change word uses so that:
It's probably unrealistic to think we can change long-used terminology with a wave of a magic wand, but it would sure make life much easier to use these words in the way everyone outside of Drupal uses them, instead of in yet another Drupal-nerds-only way. "Module" means a unit of content in a page design.
Comment #28
pounardI'm not really sure this statement is globally true.
Comment #29
David_Rothstein CreditAttribution: David_Rothstein commentedThat issue already exists (and is older than this one): #1164702: “Block” has no meaning. (New users challenged by use of the term 'block')
For the most part, the usability tests have already been done a long time ago (well, specifically, the ones showing that "Block" is confusing have been done - I'm not sure anyone has tested alternative terms to see if they perform better).