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

Analysis of micro-interactions in Gutenberg #2279

Closed
anna-harrison opened this issue Aug 8, 2017 · 10 comments
Closed

Analysis of micro-interactions in Gutenberg #2279

anna-harrison opened this issue Aug 8, 2017 · 10 comments

Comments

@anna-harrison
Copy link

Hello! This issue is related to a number of separate but related items ( #2156 #2259 #2148 #2151 #467 #539 #2248), and focuses on trying to identify the root causes for some of the user feedback Gutenberg has received to date.

We started with an analysis of user feedback collated to date, including #1550, #1950 and #1419. One of the core themes that comes up from this feedback is that the Gutenberg editor is heavy, distracting, breaks writing flow, feels visually cluttered and generally delivers a "nervous and restless experience".

This may sound overwhelming, but it's possible that a lot of these user concerns can be sorted by tweaking the timing of the micro-interactions in the editor. @mtias alludes to this in #2156:

I'd like us to focus on improving the writing interactions first before trying to make larger changes to the UI of blocks, because I think a lot of the issues at the moment come from seeing any UI when you would rather see none (because you are writing)

We ran some user tests, and collated this short video (2 mins) which compares writing in Gutenberg to writing in Medium

Our key takeaways from the comparative analysis:

  1. The timing of when things pop up in Gutenberg needs to be refined. Right now, menus pop up when we are trying to type. They ought to pop up when we are trying to do something to words that have already been typed
  2. Keyboard navigation is needed to prevent breaks in flow. In particular, ENTER to create a new (default type) block, and tab/arrows to navigate between blocks
  3. When typing in a block, all decorations from previous blocks should disappear. This will reduce the distraction that a user senses when typing
  4. Block decorations should not appear on mouseover, only on block selection. Again, this will reduce the distraction and heaviness that users report right now
  5. Menus should not appear on mouseover or on block selection, only on text selection. This likely needs wider discussion
  6. Insert menu should appear on a new line (not be permanently visible under the paragraph that is being typed). This likely needs wider discussion

cc @karmatosed @melchoyce @mtias @EphoxJames @tg-ephox

@ellatrix
Copy link
Member

ellatrix commented Aug 8, 2017

They ought to pop up when we are trying to do something to words that have already been typed

This is what #2248 was trying to address, by showing the toolbar on selecting words, while still keeping the toolbar available at other times ender the ellipsis.

In particular, ENTER to create a new (default type) block, and tab/arrows to navigate between blocks

Can you elaborate on ENTER? Which case?

When typing in a block, all decorations from previous blocks should disappear. This will reduce the distraction that a user senses when typing

Which "decorations" are still there from previous blocks? I'm not sure if I understand this one.

Block decorations should not appear on mouseover, only on block selection. Again, this will reduce the distraction and heaviness that users report right now

I've agreed with this one from the beginning. I find anything that changes based on mouse movement quite distracting.

Menus should not appear on mouseover or on block selection, only on text selection. This likely needs wider discussion

That's what #2248 suggests, I guess.

Insert menu should appear on a new line (not be permanently visible under the paragraph that is being typed). This likely needs wider discussion

I tend to agree, it's definitely not needed all the time. I do miss having an inserter on enter, which would handle (I think) most inserter needs, and I agree that it's good to show it in the main editor toolbar as well for discoverability. I also do like how bottom one kind of introduces you to it, but after a while it becomes annoying like a tip that keeps popping up when you know how it works.

@ellatrix ellatrix added the Design label Aug 8, 2017
@anna-harrison
Copy link
Author

Re ENTER: example here was typing in title and pressing ENTER (does not go to next block/paragraph) (around 1:15 mins in video)

Re decorations: from about 1:30 mins in the video. Typing in a block still leaves the block outline+cog+bin decoration visible in previously created blocks

@StaggerLeee
Copy link

StaggerLeee commented Aug 8, 2017

I am sorry if you did not meant this issue as user feedback, please be free to delete or ignore mine. Will write it very short, how I personally experience Gutenberg. Do not find myself in some statements from above, of other users.

  • I do not find Gutenberg "heavy" at all.
  • I do not find Gutenberg distracting.
  • I do not think Gutenberg breaks any writing flow. When you need licence for a truck you do not complain aroud that they are breaking your driving flow. (With reserve that I misunderstood "writing flow")
  • I do not think Gutenberg is visually cluttered, no matter how many blocks you add. It is organized in an way number of blocks does not matter.
  • I do think Gutenberg is dead simple to use, for everyone. So simple it does not even need any help documentation.

On the other side, not mentioned around:

  • I do think that there are to many blocks for all Roles under Admins, and that users got to much power to mess with everything on website. First thing on all websites I will do is to remove "widgets" blocks, all of them. Not because users will not know how to use them, are distracting, clutters, but because of misusing.
  • I do think that it will be great confusion (even for me) if you insist on mixing content and old Metaboxes. And I mean what I say real great confusion. Old Metaboxes cannot be Gutenberg blocks, unless third party developers want it for some reason. (If you go this way Metaboxes need not to be inside Inserter, and have clear, very clear, visual-design separation from content area)
  • I do think that to not be experienced as a step backward Gutenberg has to have collapsible (remember state per user) and movable sidebar tabs, and metaboxes. It is a minimum.

@karmatosed
Copy link
Member

@StaggerLeee thanks for your thoughts. One point I would like to get you to think about is these tests aren't being reported from @annaephox's single view. I notice you are saying what you feel, that's great but we really also have to start looking at what other users to ourselves are doing, thinking and feeling. I'd encourage you to observe someone, to step outside your own interactions and see what Gutenberg is like for others.

@StaggerLeee
Copy link

StaggerLeee commented Aug 8, 2017

I understand all this @karmatosed. Jus saying any so big change meet resistance (very legitimate and morally allowed stand), and not to be mixed with how difficult is to use Gutenberg. All my opinion can summarize as "dead simple" to use. Majority of my writings here is about people I did websites too. I know how they think, what they do in backend, what they need or not. Like I would care otherways. My only private website that I own is built with Drupal.

@melchoyce
Copy link
Contributor

Thanks so much for gathering this feedback, @annaephox <3

@nic-bertino
Copy link

The biggest reaction I had to @annaephox's material (namely, the video) is that the interface requires a lot of processing. Composing paragraphs really shouldn't be that noisy, and a side-by-side comparison with Medium really reiterates how much is packed into the interface (and "close" to the user at all times).

I feel like a content creator should never, ever, have to think about basic text elements as blocks. Paragraphs in particular, but I think that this extends to headings and other simple formatting such as lists. The content itself should feel cohesive in the editing experience, which is something that is lost with such literal block visualization as it exists now.

Massive thanks for collecting, analyzing, and contributing this information. It's incredibly important.

@karmatosed
Copy link
Member

karmatosed commented Aug 9, 2017

Thank you so much for this @annaephox - it's a lot to dive into and really I second that iterating, getting the micro-interactions right is important. I see this as the type of refinement post version 0.9/1 can bring. That said, it's great to start to think about it right now.

A few things I am slightly obsessed with is having an animation pace, story and consistency to interactions. Just something to throw in when looking at micro-interactions. I've also been doing some self thinking about what the 'feel' the emotion of Gutenberg should be. The one I keep coming back to is 'calm' and 'supporting'. Just another thing to throw in when looking at these smaller details.

My thoughts above aren't as in-depth as your analysis deserves, but it got me triggered into writing this down. There's a lot here and I would love to see maybe individual issues spun out we can really dive into from this.

@steveangstrom
Copy link

Forgive me for this "beginner's mind" question, but why are paragraphs instantiated as blocks? Why are they not a monolithic block which can be split into two blocks if required? I understand the intent of blocked paragraphs is : so that if a user wishes to move the paragraph, or transform the paragraph, but I think those transformations are not primary actions. How frequently do we need to transform paragraphs? I'd estimate 80% of paragraph creation does not need transformation, and those that do are a transformation initiation request. I feel the UI is starting from the wrong half of that split by creating paragraphs as if every one required transformation always.

@karmatosed
Copy link
Member

As we have issues split out for this, lets close this ticket as it has no actionable - those are in the issues made.

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

7 participants