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

[Block Library/Inserter] Order blocks based on usage stats or content type #1105

Closed
iamthomasbishop opened this issue Jun 7, 2019 · 7 comments
Labels
[Type] Enhancement Improves a current area of the editor

Comments

@iamthomasbishop
Copy link
Contributor

As we've built out the set of block types that we currently have, we've just added them to the grid. Here's what that currently looks like:

image

The Block Library UI (aka Inserter) itself will need a restructure as soon as we have more than ~12-15 blocks. For now, we should consider organizing them, either by how commonly used they are or by type:

Order based on the last usage data I've seen

  1. Paragraph
  2. Image
  3. Heading
  4. List
  5. Video
  6. Separator
  7. Quote
  8. Read More
  9. Page Break

Group them roughly by type (text, media, other)

  1. Paragraph
  2. Heading
  3. List
  4. Quote
  5. Image
  6. Video
  7. Separator
  8. Read More
  9. Page Break

My preference would be to take the second approach (group by content type), but I'm open to other suggestions.

@iamthomasbishop iamthomasbishop added the [Type] Enhancement Improves a current area of the editor label Jun 7, 2019
@iamthomasbishop iamthomasbishop changed the title [Block Library/Inserter] Order blocks based on usage stats [Block Library/Inserter] Order blocks based on usage stats or content type Jun 7, 2019
@hypest
Copy link
Contributor

hypest commented Jul 1, 2019

I'd personally vote for deterministic versus dynamic ordering, unless is a mild one and not aggressively adapt to the block usage. I'm generally sensitive and confused when things troll :trollface: my muscle memory and make me have to look to find them 😃.

@iamthomasbishop
Copy link
Contributor Author

I'm generally sensitive and confused when things troll

Totally agree with you on this point – what I meant was we might order based on most commonly used blocks amongst all users – nothing clever 😄

@iamthomasbishop
Copy link
Contributor Author

Another note: I lean towards the second approach above because it would mean less change over time – If we iterate the order of blocks over time as the usage stats change, that'd get annoying to users. Also, considering we might soon want to re-think the library bottom sheet to scale better anyhow, we might want to keep any changes here to the simplest.

@iamthomasbishop
Copy link
Contributor Author

iamthomasbishop commented Jul 1, 2019

@hypest are we already doing this on the latest GB beta? I just pulled up WPAndroid 12.8 beta and after I add a block on the canvas, that block goes to first in my list on the bottom sheet – it's not this way on WPiOS 12.7 – it's a static list (which as discussed above maybe makes most sense).

@hypest
Copy link
Contributor

hypest commented Jul 8, 2019

@hypest are we already doing this on the latest GB beta? I just pulled up WPAndroid 12.8 beta and after I add a block on the canvas, that block goes to first in my list on the bottom sheet – it's not this way on WPiOS 12.7 – it's a static list (which as discussed above maybe makes most sense).

I think I noticed it too. Probably a web side feature that automagically sees its way to mobile too as we are using more and more of the web side components.

@iamthomasbishop
Copy link
Contributor Author

Ahh, interesting. This mechanism could come in handy if/when we need to show the most common/recent block types in the toolbar, which was part of this proposal.

@hypest
Copy link
Contributor

hypest commented Nov 29, 2019

Closing this as it's functionality already in place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement Improves a current area of the editor
Projects
None yet
Development

No branches or pull requests

2 participants