'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

heather’s picture

+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.

KrisBulman’s picture

I 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).

kika’s picture

Some 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

cweagans’s picture

-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.")

jwilson3’s picture

I 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?

steveoliver’s picture

@jwilson3: Here is a simple contrived example for a user login link template:

{# modules/user/templates/user-login-box.html.twig #}

{% block "login-link" %}
<div class="user-login-link">
  {{ link }}
</div>
{% endblock %}



{# themes/stark/templates/user/user-login-box-better.html.twig #}

{% extends "user-login-box" %}

{% block "login-link" %}
<div class="user-login-link-better">
  {{ link }}
</div>
{% endblock %}

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".

jwilson3’s picture

Thanks 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.

mbrett5062’s picture

I 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.

After you created a new page in Orchard CMS, you have the ability to add widgets to those pages from the Orchard dashboard. Widgets are self-contained, resusable pieces of functionality that can be applied to various layers and zones in your website.

Orchard CMS

What's a widget? Well, it's best described as an intelligent snippet of code that helps your site. Find out more by reading on.

New Media Gateway CMS

The widgets give more power to end users and lower the workload of developers. Widgets are components that can be placed onto pages and they provide static, dynamic or interactive content, such as on-line form, list of the latest news, newsletter subscription box etc. Widgets allow users without technical knowledge to create parts or even whole pages without any technical knowledge.

Kentico CMS

Widget based design.
Drag-and-drop to display key elements into any web page with a minimum number of settings. Create advanced pages with no programming.

level671 webBuilder CMS

The widgets are a very simple and effective way to incorporate some sophisticated and complex functionality into any page. A widget is inserted directly in-line with the content and looks similar to an XHTML tag.

ProWebsite CMS

Widgets can be thought of modules which add/modify ways to display content on your site. Think of them like adding a Flickr photo gallery, or a Tag Cloud.

Plug-ins can be thought of adding back end functionality to the site. Some of them include things like auto-generating a Sitemap as you add content, or pinging blog publishing services.

Extensions are additions that can be enabled through Chalk code to display additional information on your site.

Themes are designs which you can upload to alter the visual look of your site.

JefTek.com on Graffiti CMS

heather’s picture

Does 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

xjm’s picture

@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.

Alan D.’s picture

Followup 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.

pounard’s picture

My vote for widget. I think it's a generally accepted & used & understood word.

Gábor Hojtsy’s picture

Now 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.

Crell’s picture

"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).

pounard’s picture

@Crell out of curiosity, where is the "widget" word being used in core?

longwave’s picture

Field UI uses the term "widget" for field widgets on the "manage fields" pages.

effulgentsia’s picture

Per #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.

effulgentsia’s picture

Also, 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.

Alan D.’s picture

people gravitated towards the word Component

Very 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.

tkoleary’s picture

IMHO this is a usability non-issue.

  1. Developers are intelligent enough not to be confused by having blocks in twig and blocks in Drupal and end users will not ever even know that blocks in twig exist.
  2. The semantic change of block to box adds absolutely no new specificity to users who will still need to learn what it is and does
  3. Hundreds of thousands of current Drupal users will be confused by the change (Don't get me wrong, if this was a big win for new users I would gladly sacrifice this but that's not the case here)

Given the (many) more important aspects of this meta issue i'm inclined to say this is a bikeshed.

cweagans’s picture

Developers are intelligent enough not to be confused by having blocks in twig and blocks in Drupal and end users will not ever even know that blocks in twig exist.

I think this hits the nail on the head. It's absolutely a non-issue.

pounard’s picture

I 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.

msonnabaum’s picture

Totally agree with #20.

We shouldn't be considering changing our terminology based on naming conflicts with our dependencies.

jibran’s picture

+1 for #20

cweagans’s picture

Status: Active » Closed (won't fix)
Alan D.’s picture

The 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 :)

jensimmons’s picture

I 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:

  • "module" = what we have been calling blocks, stuff placed in sidebars and such
  • "plugin" or another word = what we have been called modules (WordPress uses "plugin")
  • "block" = what Twig means

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.

pounard’s picture

I find it incredibly confusing that the enterprise-level web industry uses the word "module" to mean what Drupal calls a "block".

I'm not really sure this statement is globally true.

David_Rothstein’s picture

Status: Closed (won't fix) » Closed (duplicate)

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.

That 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).