Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto remove empty blocks #1181

Closed
kopepasah opened this issue Jun 15, 2017 · 19 comments
Closed

Auto remove empty blocks #1181

kopepasah opened this issue Jun 15, 2017 · 19 comments

Comments

@kopepasah
Copy link
Member

kopepasah commented Jun 15, 2017

As mentioned in #1171, it is quite easy to create a bunch of empty blocks when typing and it would be nice to remove a block if it is empty, either on focusout or save/publish.

Considerations:

  • When a block loses focus, the user may not want the block to be removed.
@kopepasah kopepasah changed the title Auto remove empty blocks on focus out. Auto remove empty blocks Jun 15, 2017
@aduth
Copy link
Member

aduth commented Jun 15, 2017

Another consideration: From a data / attributes perspective, what does it mean to say that a block is "empty"?

@jasmussen
Copy link
Contributor

I'm reluctant on this one, in part because the user might want that extra space that an empty p provides. Worth thinking about, in context of the influx of feedback we'll probably get soon.

@kristarella
Copy link

I'm reluctant on this one, in part because the user might want that extra space that an empty p provides. Worth thinking about, in context of the influx of feedback we'll probably get soon.

I agree that someone might want to add an empty block. Maybe there could be a "space" block in the Layout Blocks, or an option on the Separator Block to hide the line?

The other thing to consider if empty blocks were to be removed, when would it happen? Presumably there will be autosave and it would be terrible to do it then. Perhaps on publish?

@aaronjorbin
Copy link
Member

Even if not automatic, there should be a way to remove an empty block. If there is a way right now, it's not obvious to me.

@aduth
Copy link
Member

aduth commented Jun 19, 2017

@aaronjorbin See also #130, #1251

It is currently possible in text blocks by pressing backspace in an empty text block, as long as it's not the first. Or by selecting but not focusing the editable field and pressing backspace (a little bit of a challenge, have to click at the border).

@jasmussen
Copy link
Contributor

In addition to making a trash button, should we make the clickable border area bigger?

@kopepasah
Copy link
Member Author

I still believe empty block should be removed. If a user wants an empty space, this should be explicit in a block (agree that separator block might be a good option).

In regards to removing empty blocks, I think this should be an explicit action by the user (clicking a button, for example), rather than an implicit action on save (or other). There might be many cases when a user might add some empty blocks (like image blocks) for a different person to add content later.

@jasmussen
Copy link
Contributor

wpautop could be seen as precedent for "cleaning up" empty blocks on save. But I agree this feels unpredictable. Not sure what the best approach is, I think I still lean towards letting a user insert empty blocks if they want. (Even though removing them on save would solve some other reports)

I still believe empty block should be removed. If a user wants an empty space, this should be explicit in a block (agree that separator block might be a good option).

We have a ticket for multiple styles of the separator block #728, one of them could be just space? That said, I still think this would be discoverable. Peope like their linebreaks, it's what works for creating space in any other editor.

@jasmussen
Copy link
Contributor

jasmussen commented Jun 21, 2017

What if, like also discussed in #1171, we embraced writing prompts even more? Here's a full sequence of mockups:

prompts placeholders
prompts placeholders hover
prompts placeholders continue writing
prompts placeholders continue writing hover
prompts placeholders write in between
prompts placeholders write inbetween hover

Essentially, if a text block is empty and unfocused, it shows a placeholder. That placeholder is different depending on whether it's at the end of the post, or in between text.

Edit: to clarify, this means I'm suggesting we don't auto remove paragraphs, but we make it visible that they exist.

@saracannon
Copy link

The placeholder text is an interesting idea. It will definitely prompt a user to delete if it's empty because the words are not part of their post. When you hover there also be a trash can icon to the right?

@jasmussen
Copy link
Contributor

Yep, the trash can will be there on hover.

@paaljoachim
Copy link
Contributor

paaljoachim commented Jun 23, 2017

It would give the user better control to have just the title. Then the user clicks the inserter to add a text box OR there could be one text box available on a new page.

Having a write or continue writing seems confusing. As it automatically inserts a text box without my knowledge or it wanting to do so. Clicking write and suddenly there is another text box below that again. It kinda seems like a bug and not intended. Having a Write or Continue Writing is assuming that the user wants to add another text box, but that might not be the case.

text-flow-gutenberg

  • Clicking enter twice creates another text box.
    Here I was trying to create a 1 line space between paragraph 1 and paragraph 2 while trying to keep the paragraphs in the same box. The editor forces me to have paragraph 1 and 2 in different boxes. Clicking enter inside a box really should just add a line. When I am ready to create another text box I can just click the inserter and add one.
  • Clicking Write or Continue Writing adds another text box.
    Both of these takes away the control the user has over creating their own layout. Giving the user the feeling that there is a flow they have to follow to do things correctly.

@jasmussen
Copy link
Contributor

@paaljoachim

To be clear, the placeholder is just a an indicator, it isn't actually a textfield until you create it. It's necessary for you to be able to quickly get writing again after inserting an image as the last block. Without it you'd have to click "insert > Text", which gets tired quick.

@mtias had some ideas for how to improve this, though. For example we can show it when you're done typing.

@paaljoachim
Copy link
Contributor

paaljoachim commented Jun 24, 2017

So what I am understanding here is the importance of having a quick way to add more text without having to insert -> Text. Do we need a quick bar or some other visible way to add text and other most used blocks?
There can also be shortcuts for adding the most used blocks. That could perhaps be listed beside the block inside the inserter. Just like a bunch of other programs. I can create a new issue for block shortcuts or add on to the existing issue 71 for keyboard shortcuts.

gutenberg-quickbar3

I am not sure what I think of the above wireframe I just made that includes a most used quick bar. Visually it might just be too much. As we should have as little as possible cluttering the layout screen.

@karmatosed
Copy link
Member

Some apt user feedback from tests:

"I found the Write placeholder initially helpful before I added my first block. After I'd added a block I found it unhelpful & actually confusing. I wasn't sure where clicking the + icon would add the new block"

"I unintentionally created 3 extra blank blocks before properly adding the image blog"

Empty-blockitis is a frequent test result.

@jasmussen
Copy link
Contributor

I'm not convinced empty blocks is a problem. They can be a nice way to add linebreaks. But the "Write..." prompt makes it worse, I admit.

What if the write prompt was only visible if you hovered or clicked the block?

@mtias
Copy link
Member

mtias commented Jun 30, 2017

Let's see how the latest changes help with this before trying something else here.

@youknowriad youknowriad removed their assignment Jul 3, 2017
@youknowriad
Copy link
Contributor

Should we consider this as resolved with the current placeholders showing exactly the empty paragraphs?

@jasmussen
Copy link
Contributor

I think so, yes. We can always reopen if we need to.

@aduth aduth mentioned this issue Aug 30, 2017
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants