Gutenberg: Spec out which blocks need which controls

Created on 8 Feb 2017  ·  18Comments  ·  Source: WordPress/gutenberg

F.ex. Headline won't need bold/italic inline controls, and Image might need some extra alignment controls, such as "full bleed". Let's start spec'ing out the most basic blocks, get those right, then we can add to it.

Text, or Paragraph

Base properties:

  • Basic alignments
  • Basic formatting
  • Inline links

Advanced properties:

  • Dropcap
  • Alternate style for first line
  • Responsive columns?
  • Layout columns?
  • Footnotes?

Heading

Base properties:

  • Headline type/size

Advanced properties:

  • Subheading?

Quote

Base properties:

  • Basic alignments
  • Basic formatting
  • Surface cite attribute
  • Stylish alignments

Advanced properties:

  • Change between multiple quote styles
  • Dropcap in quote?
  • Caption?

Image

Base properties:

  • Basic alignments
  • Stylish alignments, like full-bleed, pull to the side, just wider than paragraph
  • Surface caption

Advanced properties:

  • Alt text, other metadata
  • Parallax
  • Fixed position/Fixed background
  • Crop (maybe converts img to div with background?)
  • If GIF, then show play/pause controls?
[Type] Question [Type] Task

Most helpful comment

Here are a bunch of individual block mockups, showing controls.

Image

image

Text

text

Heading

heading

Embed

embed

Code/Gist

gist

Quote

quote

Gallery

gallery

Much of the UI is being discussed elsewhere also.

In the case of the gallery, this is an early draft showing something that would be wonderful to be able to do — insert text in one of the spots where images would otherwise be. Lots of UI to still h hammer out here — how much can you configure the gallery? Can you select amount of columns? How do you insert text? Hopefully by sharing early we can tackle these challenges together.

All 18 comments

From #core-editor slack by @mcsf:

re https://wordpress.github.io/gutenberg/ and the block controls for each type of block (text, image…), is it desirable to think in terms of reusable traits? i’ll give an example: both ⁠⁠⁠⁠text⁠⁠⁠⁠ and ⁠⁠⁠⁠heading⁠⁠⁠⁠ are ⁠⁠alignable⁠⁠ and thus get the three buttons for left-, right- and center-alignment. but maybe one of those will also have other traits and have a few extra buttons. on the other hand, ⁠⁠⁠⁠image⁠⁠⁠⁠ has different traits altogether and will get other buttons, etc.

Seems prudent to keep this in mind for reusability as we spec out blocks. Particularly important, perhaps, for plugins that add blocks. F.ex. if a plugin adds a "checklist" block, they might apply traits such as compatible-with: list, and alignable-basic: true, things like that. @folletto came up with these ideas, in particular with regards to the switcher.

Traits seem great on theory, but they worry me a bit too much it can add a lot of complexity for both users and plugin makers. Maybe a v2 thing? Maybe I just worry too much about complexity increase?

Let's spec out some more blocks. This is very brainstormy and speculative at this point.

Code/Gist

Base properties:

  • Basic alignments
  • Stylish alignments

Advanced properties:

  • Type of code to highlight, if not autodetected?
  • Style (color scheme)
  • Caption

List, ordered, unordered

Base properties:

  • Basic alignments

Gallery

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Type: slideshow, grid, pager
  • Autoadvance or not
  • Style: circles, masonry, columns

Generic embed

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Change embedcode
  • Width/height/responsive
  • Change aspect ratio

Map

Base properties:

  • Basic alignments
  • Stylish alignments
  • Google Maps/Open Street Map
  • Caption

Advanced properties:

  • Same as all embeds

Separator

Base properties:

  • Basic alignments

Advanced properties:

  • Style of separator, dots, various unicode symbols, thin line, thick line
  • Margin, small or big
  • It could even work just as a spacer, with no visual indicator, just space

Tweet (and variations)

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Same as all embeds
  • Option to disable images/video

Video (YouTube, Vimeo, etc.)

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Same as all embeds
  • Option to autoplay?
  • Option to mute?
  • Use as looping, auto-playing, mute, video background

Audio

Base properties:

  • URL
  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Player style (toggle controls)
  • Autoplay?
  • Autoplay when scroll into view?

Contact Form/Survey

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Change style
  • Actually configure the fields of the form

Table of Contents

Base properties:

  • Basic alignments
  • TOC specific alignment (pin to side)

WP Post embed

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Custom excerpt length

Facebook embed

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Toggle images, or pick preview image

Link Block

Basically a "any unidentified URL pasted" block, basically what all messaging platforms do when you paste a link, turn it into stylish link plus preview, using all the metadata Facebook got everyone to put in.

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • Toggle images, or pick preview image

Playlist

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Poet Block

Alternate version of "preformatted" without the monospaced font, respects spaces (inserts  ) and linebreaks

  • Basic alignments
  • Stylish alignments

Custom Field

Base properties:

  • Basic alignments
  • Stylish alignments
  • Caption

Advanced properties:

  • 🐰🕳

A few notes and ideas about contextual menu approaches (and data architecture of the actions/options)
An old prototype is referenced in the notes, which shows ideas around link types, transformation of link types, inline dialogs and contextual menus that may spark some ideas

screen shot 2017-02-16 at 12 52 02

I took the list and turned in a spreadsheet for ease of editing and reviewing. Comments should be open:
https://docs.google.com/spreadsheets/d/1r4Rfj4D9CyFkxQr0JFi3iVKkRte154M8BkDpkMPysp4/

I feel excited that I found this list. I will work on turning it into a design asset guide in sketch for quick design mockups. Fellow designers might find it handy to throw out quick ideas on element positioning or even UI styles.

I would start something similar in any case, but it's great that we can all align with a common reference like this one.

Another block idea. Perhaps not for launch, but noting for later on:

File Download

Base properties:

Basic alignments
Download file URL (paste inside the block itself)
Caption

Download file URL (paste inside the block itself)

@jasmussen I have been thinking about this _pasting inside the block itself_ behaviour and was considering the default state of a freshly added block as an input context. At the current editor, when you click to add a media, you are prompted to select your media file via the popup. Are we looking to offer a similar -perhaps more simplified- flow but from within the editor block?

Apologies if there has already been a discussion about a different approach and i haven't notice.

screen shot 2017-02-28 at 13 21 29

Isn't this useful for the case of a spotify playlist block and any custom block that may require a basic setup?
screen shot 2017-02-28 at 13 41 24

At the current editor, when you click to add a media, you are prompted to select your media file via the popup. Are we looking to offer a similar -perhaps more simplified- flow but from within the editor block?

Probably some of the answers will present themselves as we start working. But this is probably one of the aspects where we can _remove many modals_.

Image and gallery both are probably the most important ones to get right. One dream instance is that you drag an image from your desktop into the editor, and that's it — that's your image block. Same for galleries, except you're dragging multiple images.

What happens when you drag an image onto another image block? Does it become a gallery? (Wouldn't it be cool if it did?)

And yes, if you click the inserter, click the image, then you should probably get a placeholder just like your mockup. But do we show a button to let you pick the image(s?) from your media library? Or do we show your media library _right there_?

Similarly if you insert an image block using the "commandline" (See #24), then ideally you should be able to pick the image you want using arrow keys and enter. Lots of fine interactions to tune here!

Thanks a lot, this is great. Lots of juice here indeed.

Here are a bunch of individual block mockups, showing controls.

Image

image

Text

text

Heading

heading

Embed

embed

Code/Gist

gist

Quote

quote

Gallery

gallery

Much of the UI is being discussed elsewhere also.

In the case of the gallery, this is an early draft showing something that would be wonderful to be able to do — insert text in one of the spots where images would otherwise be. Lots of UI to still h hammer out here — how much can you configure the gallery? Can you select amount of columns? How do you insert text? Hopefully by sharing early we can tackle these challenges together.

The gallery will become an interesting block. I like being able to add text, and if we go this far, should we maybe allow more things like video? What should and should not be allowed?

The gallery will become an interesting block. I like being able to add text, and if we go this far, should we maybe allow more things like video? What should and should not be allowed?

Actually I think I'm going to pull back a little for V1 so we can ship it on time :D

That is, upgrade and polish the current gallery with 1:1 features. Then we can ensure that the block API and plugin-hooks can ensure we can build a killer "anything-gallery" as a quick block right after.

For the code/gist block, it'd be slick to optionally paste some code or paste a link to a github gist. Also, I'm not sure if the alignments would be needed for code blocks, for example, is there a case when code should be centered?

Also, I'm not sure if the alignments would be needed for code blocks, for example, is there a case when code should be centered?

Excellent point. I was thinking if you were authoring a really richly layouted post, you might want a "wider than the main column" view. But yeah it's probably good to not include the alignments in that one until they become strictly necessary.

Should we close this issue?

Yep, good call. There's still value here, but we can dig it up from the archive if we need it. Much of it is obsolete. Thanks Riad.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hedgefield picture hedgefield  ·  3Comments

mhenrylucero picture mhenrylucero  ·  3Comments

nylen picture nylen  ·  3Comments

franz-josef-kaiser picture franz-josef-kaiser  ·  3Comments

ellatrix picture ellatrix  ·  3Comments