Problem/Motivation

Most of time, we have same texts for both Block title & description. "Block description" is a required field, therefore users have to enter same title twice.

blockui.png

Proposed resolution

Present an autogenerated "Block description".

Plan A:
- similar to Add a new content types (admin/structure/types/add)

Plan B:
- add a check box next to "Block description". when it checked, hided the "Block Title" input

Files: 
CommentFileSizeAuthor
blockui.png12.38 KBdroplet

Comments

klonos’s picture

Care to explain plan A a bit further? In the add new content type form, there is a required "Name" field that also auto-generates the machine name, but the description is optional. From what I can see, we follow the same pattern in the add new custom block type form. How does fit in the block case? Perhaps things have changed since past September when this issue was filed.

jessebeach’s picture

In the add new content type form, there is a required "Name" field that also auto-generates the machine name, but the description is optional. From what I can see, we follow the same pattern in the add new custom block type form.

@klonos is right, we should follow the same pattern in the block types UI that we have established in the content types UI.

The content type UI (established pattern)

Screenshot of the content types ui showing a name field and a description field.

I've included the code for the correct pattern as well for folks who can see the image above.

<div class="form-item form-type-textfield form-item-name">
 <label for="edit-name">Name<abbr class="form-required" title="This field is required.">*</abbr></label> <input aria-describedby="edit-name--description" type="text" id="edit-name" name="name" value="" size="30" maxlength="128" class="form-text required machine-name-source machine-name-processed" required="required" aria-required="true"> <span class="field-suffix"> <small id="edit-name-machine-name-suffix" style="display: none;"> <span class="machine-name-label">Machine name:</span> <span class="machine-name-value"></span> <span class="admin-link"><button type="button" class="link">Edit</button></span></small></span>
<div class="description" id="edit-name--description">The human-readable name of this content type. This text will be displayed as part of the list on the <em>Add new content</em> page. It is recommended that this name begin with a capital letter and contain only letters, numbers, and spaces. This name must be unique.</div>
</div>
<div class="form-item form-type-textarea form-item-description">
 <label for="edit-description">Description</label> <div class="form-textarea-wrapper"><textarea aria-describedby="edit-description--description" id="edit-description" name="description" rows="5" cols="60" class="form-textarea resize-vertical"></textarea></div>
<div class="description" id="edit-description--description">Describe this content type. The text will be displayed on the <em>Add new content</em> page.</div>
</div>

The block type UI (anti-pattern)

Screenshot of the custom block UI. The fields are labeled incorrectly as label and description.

The code for the incorrect example is the large the same, except that the correct label name is called label label in the custom block form.

Let's keep the established pattern in place and keep the scope of this issue reigned in.

jessebeach’s picture

Title: Improve UX for "Block description" » Block metadata should use the standard "name" and "description" fields; follow content type form layout as the model

updating the title.

yoroy’s picture

Yep, go for consistency here. (No need to add more descriptive verbiage though! :-)

webchick’s picture

Issue tags: -Spark +Blocks-Layouts

Removing this from the "Spark" tag for now, since AFAIK the Spark team did not introduce this.

Seems like this is probably part of #1875252: [META] Make the block plugin UI shippable, so tagging with Blocks-Layouts.

benjy’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tim.plunkett’s picture

Issue summary: View changes
Issue tags: -Blocks-Layouts

Not actively part of the Blocks-Layouts work.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.