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 Patterns: Add ability for predefined block layouts to be added to a document #17335

Open
mapk opened this issue Sep 4, 2019 · 38 comments

Comments

@mapk
Copy link
Contributor

@mapk mapk commented Sep 4, 2019

Block Patterns are becoming a requested feature. With the advent of Gutenberg, the blank canvas has become a bit more frightening. Rather than just worrying about content, now people also worry about page layout. While it's easy to wrangle with Gutenberg, the blank canvas leaves more questions than answers.

Adding a feature to include Block Patterns would be ideal!

Themes would be able to register block patterns. With this in mind, this feature could potentially eliminate all support questions of "How do I make it look like the demo?" 😱

Questions:

  1. Should Gutenberg include some default block patterns?
  2. Which UX flow for this system works best? (a couple examples below)

UX Example – Overlay

Prototype

overlay


UX Example – Sidebar

Prototype

sidebar

cc: @epiqueras @youknowriad I'm not sure if this relates to some of the content areas and CPT work you've been doing.

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Sep 4, 2019

These concepts are largely influenced by:

I believe standardizing a UX flow for this interaction would benefit Gutenberg & users.

@epiqueras

This comment has been minimized.

Copy link
Contributor

@epiqueras epiqueras commented Sep 4, 2019

We have support for this, but only per-post-type and the template gets applied on load, with the following logic:

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

I don't see much value in that though and would love to have something like what you just described.

I like the overlay approach more because it has more screen real estate to show off the available patterns.

This feature would be parallel to any block areas work. There could be patterns made for posts and patterns made for templates or any other block area. E.g. a template pattern could be used to quickly change the single post template to a layout with a sidebar.

Gutenberg shouldn't define defaults, but the default themes should definitely ship with them.

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Sep 5, 2019

My initial thought is that this added block pattern would NOT replace any content on the page, but rather just append the blocks to the bottom. This way the block pattern can be added at anytime during the construction/writing of content. This would be a similar flow to Atomic blocks, but I'm hoping without a block that contains all the other blocks as they do it.

@epiqueras

This comment has been minimized.

Copy link
Contributor

@epiqueras epiqueras commented Sep 5, 2019

Yeah, I like it more that way too, for the same reasons you stated.

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Sep 27, 2019

There might be something interesting to learn from this plugin as well. https://wordpress.org/plugins/full-site-editing/ @obenland is the plugin currently up to date?

@obenland

This comment has been minimized.

Copy link
Member

@obenland obenland commented Sep 27, 2019

It's missing the block preview work that we've been adding in the past few weeks but is functional otherwise.

@obenland

This comment has been minimized.

Copy link
Member

@obenland obenland commented Sep 27, 2019

This is what the current iteration looks like, using blockPreview for the large, right-hand-side template preview:

image

@chrisvanpatten

This comment has been minimized.

Copy link
Member

@chrisvanpatten chrisvanpatten commented Sep 27, 2019

@epiqueras wrote:

We have support for this, but only per-post-type and the template gets applied on load, with the following logic:

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

I don't see much value in that though and would love to have something like what you just described.

Just before anyone gets any ideas about this feature replacing block templates, I just want to note that this capability is extremely valuable. It allows developers to specifically define the composition of a given post type. We make extensive use of this functionality at @MeredithCorp where many of our content types are strictly organized.

I think this "Block Patterns" feature is an awesome idea, but want to make sure it's considered as an "in addition to", not a full replacement for the current post type block template functionality.

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Oct 2, 2019

Next Steps:

  1. @melchoyce to communicate her explorations as well.
  2. Diverge: Explore what wpcom is doing along with other examples in the industry (ie. Squarespace, etc.)
  3. Converge: Bring together the stronger patterns into one cohesive mockup and UX flow.
  4. Mockups and Prototype in Figma.
@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 2, 2019

Last year I explored some prototypes for Gutenberg page layouts. My explorations had a couple pieces:

  • Extend layouts to work on pages, not just CPTs.
  • Create a way for theme authors to “declare” multiple templates.
  • Create a way for theme authors to categorize those templates.
  • Create the UI for selecting a layout.

Desktop

image

View Prototype

Note: this prototype was from an earlier round I tried, and some of the elements are outdated.

Mobile

image

View Prototype

The breakdown

The layout picker, like everything else in Gutenberg, is a block. It consists of a couple elements:

  • Block title / description.
  • Tabs for categorizing layout types (styled after the block inserter).
    • These are theme-defined.
    • When you only have a couple layouts (let’s say, <5), the tabs don’t appear.
    • If there aren’t any categorized layouts, the tabs don’t appear.
  • A list of available page layouts.
    • The layout graphics should be automatically generated based on the blocks included in them.
    • Images are grey boxes, text is darker grey lines, buttons are blue, etc. We should abstract out everything into simple shapes.
  • Finally, the layout itself.
    • In these mockups, you can see theme styles applied to Gutenberg. If theme styles aren’t declared, blocks would fall back to generic Gutenberg styles.
    • You might also notice the global elements on the page — in this case, the site logo, navigation, and footer. These exist for presentation, but are not editable in this first version of layouts. They uneditable and displayed at 40% opacity.

Changing Layouts

I worked through what the flow could look like:

image

image

View Prototype

The breakdown

So wait, I can have more than one page layout?
Yup! You can stack them and combine them however you’d like.

Won’t that get ridiculous?
Yeah, it could. Probably won’t in most cases, though. Being explicit about either overwriting or appending means that folks are less likely to lose content. Deleting blocks is easy, so if they append and want to get rid of older blocks, it’s just a click or two away.

What if they didn’t mean to overwrite their content?
Let’s please please support “undo.”

What about page-specific elements like Features Images and Page Titles?
If appending layouts, we should convert any page-specific elements to their closest generic equivalent. For example:

  • Featured Image → Image
  • Page Title → Header

How about duplicate blocks?
If a specific block (like Latest Posts) is duplicated, we should allow that — folks might want to display another block of posts from a different category.

Generic blocks can be duplicated to your heart’s content.

What do we call a layout once you’ve appended another layout onto it?
We should call it “custom layout,” and re-render the preview image based on whatever’s changed.


There's a lot of outdated stuff in these mocks since they're over a year old, but we might be able to reuse some concepts.

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 8, 2019

Great discussion here, thanks for starting it. I feel very strongly that this can help making page layouts even simpler, and I can't wait for it to land.

I also strongly feel that we should not be adding an additional button next to the block library, because:

  • it dilutes and fragments the block library as the singular place to insert anything on the page
  • it adds additional UI for inserting and to learn, to make accessible and work across mobile and desktop
  • it is added in a place that's already crowded and should arguably be reduced rather than added to
  • it separates the "pattern" from the "block", effectively creating a different type of content, when it arguably could be the same

Once you learn the block UI, you learn how to do everything, was a guiding principle from early on, and although it should be refined still, it has scaled relatively well. Just yesterday we discussed how treating the site itself as a block (#16998) could be beneficial as it re-uses existing UI. If instead of treating a "block pattern" as a new feature, but instead treat it as just another block that happens to be pre-designed and have child blocks inside, suddenly it's not a new feature, it's a refinement to an existing feature, which seems both pragmatic and sensible, scope-wise.

To me, the Block Library seems the obvious location for this interface. What changes can we make to it, to better accommodate block patterns? It already contains reusable blocks, arguably precursors to patterns like these, and any improvements we make will likely benefit those too. Is there a Block Patterns tab? Is the block library wider — as wide as the block library and the new preview pane together? Do block patterns need a separate preview window or can we leverage the extra space of that preview pane?

Another exercise is to flip the question on its head: what is it about the block library as it exists today that suggests we need a new UI for block patterns?

Another interface, and Mel very elegantly touches on this, is to tap in to the placeholder interface. What if the Site block, by default, let you pick base template?

The following is, as is no doubt evident, not an exceptionally considered idea, but just a quick sketch showing how it would look if we added a "type selector" dropdown to the block library, allowing you to search both blocks and block patterns together:

blocklibrarypatterns

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Oct 8, 2019

To me, the Block Library seems the obvious location for this interface. What changes can we make to it, to better accommodate block patterns?

Thanks for diving in, @jasmussen! Figuring out that question is key. Recently, Happiness Engineers shared that some users don't even scroll the Block Library to find other blocks outside of what is front-and-center. This is another problem, but something to consider in relation to adding anything else to this very small interface.

what is it about the block library as it exists today that suggests we need a new UI for block patterns?

I'd say it's the very size of the Block Library that makes it difficult to add full page block patterns there. Right now, the user views a block icon and a tiny preview of the block. It works because it's a small area of the page that is focused. Block Patterns work much better when the user can see most of the page and how these blocks exist together. The size of the Library makes this difficult.

The concept of a "Site block" sounds rather interesting. Many blocks have a placeholder, so a Site block might be able to have a placeholder with layout options too. This idea works well for new pages, but not so much for pages that have existing content. But here's a quick mockup around this anyways.

Block Placeholder (for reference):

Screen Shot 2019-10-08 at 1 53 58 PM

Site Block Placeholder:

Placeholder

This really jives with @melchoyce's mockups above.

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 9, 2019

Good thoughts, thank you.

Recently, Happiness Engineers shared that some users don't even scroll the Block Library to find other blocks outside of what is front-and-center.

That's a good insight, and all the more reason to improve the block library together with any improved designs we make for block patterns.

I'd say it's the very size of the Block Library that makes it difficult to add full page block patterns there

That rings true. I took a little time to try and mock up a little bit based on that feedback, but combining this with the idea of a singular block library. Don't put too much weight in the high fidelity of this mockup, partly this is my comfort zone, partly it's a way to make it "feel real". So just because it looks done, doesn't mean it can't be rejected based on further feedback:

Block Library

What you see here is the same singular block library that you press the (+) Add Block button. This makes it available in the editor bar, at the end of the document, whenever you make a new paragraph, or if you look for the sibling inserter.

The UI builds on what we have, but adds two tabs in addition to the search field:

  • The Blocks tab is default, and the content is what we have today
  • The Block Patterns tab sits next to it, and instead of having a separate preview pane, this one shows rendered previews as the block pattern thumbnails itself.
    • There's a category dropdown, which is a good way for plugins to categorize their offerings.
    • Thumbnails have fixed widths (2 columns), but varying heights, masonry-style.
    • The entire popout window has been made bigger, and by not showing a preview pane we get even more real estate. We can even explore responsive tricks to size the dropdown according to available screen real estate.
  • When you search, you search across both Blocks and Block Patterns.
    • Block results are grouped separately, and show up first
    • Block pattern results show up below that

Again, while this looks high fidelity it should not be taken as gospel. It is intended to simply further the conversation. I was inspired by some of @shaunandrews work for Full Site Editing, and I'm sure he'll have thoughts to share too.

Hope this helps! Thoughts?

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 9, 2019

Alright, so based on the above explorations, I see us breaking this down into two tasks:

  1. Previewing and choosing a page layout when you create a new page
  2. Adding new block patterns afterwards, via the inserter

@jasmussen has some excellent inserter explorations in #17335 (comment) that we can iterate on for the inserter.

@shaunandrews also shared this idea that he's working on for WordPress.com with me:

pick-template

When you create a new page, you'd be presented with an option to select a layout. The preview is a nice addition that neither @mapk nor I have explored yet.

One question we should think through: should full page layouts just happen for pages, not posts?

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 9, 2019

should full page layouts just happen for pages, not posts?

One aspect is what we default to, another is the technical distinction. I.e. it's very probably technically trivial since it's the same under the hood, so merely a question of deciding what we allow. The benefit of allowing it everywhere is that it's a predictable flow that's the same everywhere. The downside is: we probably don't want you to create a new Post that uses the Blog Homepage template.

Perhaps the template, when it's registered, decides itself which taxonomies it should be allowed on?

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 9, 2019

Perhaps the template, when it's registered, decides itself which taxonomies it should be allowed on?

Good idea — then templates could also be used for categories/tags, and CPTs.

(A template picker on taxonomy pages could be cool!)

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 10, 2019

Tangentially related to block patterns — sections of content — a friend shared some thoughts on the sibling inserter, the plus that appears on hover between blocks, noting that it would be more usable when always visible when the block was selected. The reason this is not the case right now is because that conflicts with just wanting to click text to edit, and with the resize controls present on Spacer and Cover blocks. Key here being that everything is a block.

A couple of screenshots of the GoDaddy site builder were shared, where a similar interface exists and is permanently visible on select. The main difference being that this UI differentiates between small blocks (text, images) and bigger sections, and shows this control only on the latter:

siblinginserter

section

As we continue on block patterns, it would be interesting to think about whether this concept opens the doors for further simplification of the base UI at the addition of features to the larger sections.

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 11, 2019

@jasmussen Can I grab your file for #17335 (comment)?

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 11, 2019

Yes of course. I put it quickly together in kind of a messy Figma file, so I copied it here:

https://www.figma.com/file/VaSKQJDS70ov87XY1alOVs/Block-Library-w.-Block-Patterns?node-id=0%3A1

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 11, 2019

Thanks!

@shaunandrews

This comment has been minimized.

Copy link

@shaunandrews shaunandrews commented Oct 11, 2019

Been toying with a few ideas:

I started with the idea of a dropdown and tried a single list of blocks:

image

Along with this I tried both a two columns and a single column for patterns, using thumbnails for the patterns in the list:

image

I then decided the search was in a confusing spot, and took a step back. I tried adding a dropdown next to the search and tabs below the search:

image

With the tabs below the search, I also tried showing thumbnails of patterns in both a landscape and portrait orientation.

image

I do like what @joen did with the more interesting layout of patterns so I also tried a quick mockup with that:

image

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 11, 2019

Great explorations. I think the tabs work a little better as a pattern, because the dropdown next to search makes it look like the two are tied together — like, I can only search within patterns or templates, not change my view by selecting one.

@felixarntz

This comment has been minimized.

Copy link
Member

@felixarntz felixarntz commented Oct 12, 2019

I thoroughly enjoyed reading through this issue, the ideas read and look great!

I'd like to flag the related issues #15623 and #17512 which focus on providing the necessary block types and infrastructure respectively for enabling full site editing.

While block patterns as discussed here make sense in both contexts (individual post vs entire template), I think we need to differentiate between two types of templates:

  • Template Parts (e.g. to be implemented with a wp_template_part post type internally, similar to how the Full Site Editing plugin does it):
    • Template parts should be able to be used in various places, and it should be possible to append them to other content (as discussed here before).
  • Templates (e.g. to be implemented with a wp_template post type internally, see #17513):
    • Templates are supposed to represent entire templates, including all the semantic markup that makes up an HTML document. There need to be some restrictions on how these can be placed, for example full templates do not make sense in individual post content, and also it shouldn't be possible to append a full template to somewhere else - a full template should always override the existing content, and their main use-case would be at the very start of creating a new template with Gutenberg (i.e. "Select your starting point").
    • While we still need to figure out how to generally encourage (enforce?) solid semantic markup (via the aforementioned issues), I believe we should also consider this scenario here.

So far this issue seems mostly focused on the template parts, and that makes sense, but it would be great if we could also think about how to expand that to full templates in the future.

@mtias

This comment has been minimized.

Copy link
Contributor

@mtias mtias commented Oct 13, 2019

So far this issue seems mostly focused on the template parts, and that makes sense, but it would be great if we could also think about how to expand that to full templates in the future.

One clarification — the "block patterns" setup is less about template parts (which are structurally meaningful) and more about general design elements made of smaller blocks. Once inserted they are not stored separately. For example, a "Cover" image that combines a few blocks to achieve a specific look that would otherwise take users some work to accomplish. Think of it more as a collection of designs that can be added anywhere without necessarily representing a reusable part of a theme template.

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Oct 14, 2019

A quick and dirty exploration, taking @shaunandrews' and @jasmussen's ideas and applying them to a modal instead of a popover:

image
image

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 15, 2019

I dig the tabs and search layout, though I must admit I personally always use the search in the block library, so as a data point of one, I would prefer search first.

The modal dialog inserter definitely brings the space. That's good. But it also loses a little bit of the visual context of where your cursor is/where the block or block pattern will be inserted. Additionally it opens up the question of whether this becomes the global behavior for the block inserter, or for example just what you see when you use the sibling inserter or a variant like the "section inserter" suggested above. And if we do fragment the behavior, is that good?

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Oct 16, 2019

Your exploration there, @melchoyce, really helps! Thanks! I have a couple thoughts around this.

In one instance the modal communicates the many blocks available which is something people struggle with exploring right now. But on the other hand, seeing all these blocks like this becomes a bit overwhelming. A modal feels right for the patterns, but not for individual blocks. But the mockup also shows the accordions open, so it may completely change if only showing one open as we do on default.

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Oct 17, 2019

As much as I like the added space of the dialog version, sleeping on it, it doesn't feel like the right approach to me. It removes all context from the content, and feels overwhelming when you're inserting simple blocks like paragraphs or images. I increasingly feel the same way about premade blocks, or block patterns — they are just collections of blocks and should be inserted the same way.

While #17335 (comment) isn't necessarily the way to go — the categories start to feel pointless, and there's a lot going on — I do feel that improving the block library to accommodate complex blocks (and avoiding a modal dialog) is the way to go.

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Oct 18, 2019

I do feel that improving the block library to accommodate complex blocks (and avoiding a modal dialog) is the way to go.

Now that we have the Help Panel which provides more space in the library, we can probably work with that a bit. Maybe patterns are another tab to separate from the individual blocks, but the preview area still remains in the Help panel side that can be vertically scrolled if necessary.

@Wingo5315

This comment has been minimized.

Copy link

@Wingo5315 Wingo5315 commented Oct 20, 2019

I like the idea of "Block Patterns" (maybe it should be changed to "Block Layouts?") but I don't like adding a new block using a dialog box - it's too distracting! (If Block Patterns were to be added this way, I'd be fine with it.)

@richtabor

This comment has been minimized.

Copy link
Contributor

@richtabor richtabor commented Oct 21, 2019

I’d suggest that the Block Inserter should remain a small popover (as it sits today) while Block patterns should be a different component altogether - as the context in which each is used could very well be different: one for building pages (patterns) - the other for adding blocks/tweaking those pages.

It could work within the inserter, but we may find that the interface becomes more complicated and confusing - and not to mention, the inserter is quite small. Bringing in tiny previews of patterns may not be the best experience. We need to be able to show more than one pattern (to provide proper context for the user to choose from), but also make the previews big enough to actually see.

Perhaps we tweak how we’re doing things a bit.

Just thinking aloud here, but what if we had the Inserter at the top left, as it’s stands today, and introduce a new UX pattern in-between existing blocks - where folks may add block patterns/layouts (whichever we call them). This would replace the on-hover block inserter (+) that currently resides between blocks, and remain visible (not hide when not hovered).

Here's a screenshot (with actual Gutenberg content) on what that could look like:

patterns-1

There’d need to be some thought behind where exactly this would take over. Would it be between every block? I'm not sure.

Opening up the pattern inserter would fire a modal from which the user may select a new pattern to add to their page. Here's an exploration of the modal, using a top-level categorical selection, though I'm not 100% here on what this would look like.

patterns2

This pattern (or parts of it at least) is seen on GoDaddy's Website + Marketing offering, as well as SquareSpace (and possibly elsewhere). It's worth an exploration.

@eduardoarandah

This comment has been minimized.

Copy link

@eduardoarandah eduardoarandah commented Oct 27, 2019

A block and a layout should be DIFFERENT.

A layout should leverage the css framework it’s using.

Examples of layout:

  • Column/row
  • Grid
  • A slider
  • A container
  • Tabs, accordions

A block May live inside a layout or not.

A pattern might be a layout + blocks ?

@youknowriad youknowriad referenced this issue Nov 3, 2019
3 of 9 tasks complete
@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Nov 6, 2019

Here's how the Blocs App does this. It uses a much larger Inserter. Just sharing more research.

blocs 2019-11-06 11_35_16

@mapk

This comment has been minimized.

Copy link
Contributor Author

@mapk mapk commented Nov 6, 2019

More looking at what others are doing out there.

Qubely uses a button in the Top Toolbar to open a modal.

qubely 2019-11-06 11_51_50

@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Nov 7, 2019

Great shares, Mark.

I would note that the Qubely approach is one I would think we should avoid, and it's an approach a number of other block collections take. The approach assumes the user is on a desktop screen and isn't using the "Top Toolbar" option, or even the future "show labels for all icons" option. So if we were to add an actual separate button, we would likely want to add it in direct context of the block inserter, and we should probably look at how we could reduce the other buttons present in that space.

@richtabor

This comment has been minimized.

Copy link
Contributor

@richtabor richtabor commented Nov 7, 2019

And here's a snapshot of how SquareSpace does has a separate interaction for page architecting and content editing, providing context to my earlier comment.

And here's a continued conversation (Slack) that we discussed through yesterdays design meeting:

I've been thinking a lot about a pattern interaction vs. a block interaction. Moving patterns as the top-level "building" interaction, while maintaining blocks as the "adding/tweaking" interaction. Sure one could build "patterns" with blocks obviously, but it's not exactly simple and requires many more interactions to accomplish. So what if there was a distinct different between page architecting and content architecting?

ss

@gziolo gziolo added this to Backlog in Phase 2 via automation Nov 8, 2019
@jasmussen

This comment has been minimized.

Copy link
Contributor

@jasmussen jasmussen commented Nov 8, 2019

Thanks for sharing that, Rich. It seems the balance to walk is between making it trivial for users to insert large helpful sections of content to quickly build out pages when they mean to, but have trivially intuitive access to individual blocks when that's what they need.

To me, the key take-away from the Squarespace GIF is that while the duality between two libraries exists, it is tempered by contextuality. I wonder if we can do even better, though, so as to avoid two completely different-looking block libraries. For example when you insert a Navigation Menu block, it feels intuitive that the block library becomes a tool to insert only Menu Items inside. Is there a similar way we leverage context in the editing canvas itself?

@Wingo5315

This comment has been minimized.

Copy link

@Wingo5315 Wingo5315 commented Nov 8, 2019

As to how to add a layout, maybe in the Settings area of the Documents tab, there could be a list of layouts with a graphic showing the user what the layout roughly looks like?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Phase 2
  
Backlog
You can’t perform that action at this time.