backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

[UX] Layout UI: Collapsible block groups. #1691

Open klonos opened 8 years ago

klonos commented 8 years ago

I've been reading the various issues people have recently opened about problems they are facing while trying to work with translation of various things in order to build multilingual sites and I honestly feel their frustration. Things are already hard enough to achieve in D7 with the help of contrib modules like l18n and its ecosystem of modules, but it will be even harder and more frustrating in Backdrop since i18n has not been ported yet.

I'm not even sure if l18n is the right solution for us since we moved to config. You see, when i18n started off, it was designed with having in mind as granted whatever was planned for D6/D7 and that did not include CMI back then. Perhaps we'll head to a different direction in Backdrop and that might be totally irrelevant or incompatible with i18n. So taking into consideration the size and complexity of the i18n module, it might not even be worth porting it to Backdrop at all.

The workarounds that we have so far:

In websites with 2 or 3 languages this might not be a big deal, but when reaching close to a dozen languages, that makes the Layout UI really cluttered and just horrible to work with. Just imagine all the scrolling required to reach the footer region with so many blocks placed in the header (times 2 because you have language-specific header blocks and also the same amount of menu blocks). And it gets even worse when someone needs multiple menus in their site (#1690).

Anyways, until Backdrop 2 starts being a reality (that's when we plan to extend the language support to menus and other things like the site language), we should at least make the life of multilingual site builders a tad easier. So, can we please have a way to group multiple blocks together and somehow collapse them so they don't get in the way all the time. That way one could create a "Main menus" group of blocks that would include all the language-specific menu blocks they have created and a "Header blocks" group for their language-specific custom header blocks.

I was thinking that these could perhaps work the way you can group icons on iPhones/iPads and on Android phones by dragging a block in another block instead of dragging it to another region. In that case, after releasing the block, a dialog would pop up asking for a block group name.

I realize that my proposal here is in order to solve a problem that will be moot once we have proper language support for menus and header etc., but that will take a long time while people using Backdrop need to create multi-language websites now. Besides, I'm hopping that this feature here will be useful in other use cases too.

Thoughts? (especially @quicksketch and @pablo-romero)

ghost commented 8 years ago

Backdrop has already an easily translatable thing : field So, if

it will be a big step forward

maxmeno commented 8 years ago

In websites with 2 or 3 languages this might not be a big deal, but when reaching close to a dozen languages, that makes the Layout UI really cluttered and just horrible to work with. Just imagine all the scrolling required to reach the footer region with so many blocks placed in the header (times 2 because you have language-specific header blocks and also the same amount of menu blocks). And it gets even worse when someone needs multiple menus in their site (#1690).

I would tackle that problem just cloning the layout - one per language. Lots of work, still, but not much clutter.

Too easy?

klonos commented 8 years ago

I would tackle that problem just cloning the layout - one per language. ...Too easy?

I thought of that, but then each time you'd want to add, remove or edit a block, you'd have to do it as many times as the number of languages you have. Not easy at all.

maxmeno commented 8 years ago

Not easy at all

well, as I said, that was only to reduce the clutter.

klonos commented 8 years ago

How this could look/work (margins intentionally added to the mockup in order to have all titles and text visible):

backdrop-issue1691-mockup-create_block_group_added_to_region_actions

This for people that what to create block groups and add blocks to them as they go. For those that want to add blocks and then group them together, we should support dragging a block to another block. This action should then trigger the "Create block group" dialog.

Similarly for the "Ungroup blocks" action: it serves as a bulk operation to save users having to repeat the action for all contained blocks - those that need to move a single block outside a block group can simply drag it out into the region.

klonos commented 8 years ago

This is how the block group would look with the contained blocks collapsed:

backdrop-issue1691-mockup-collapsed_blocks_inside_a_block_group

...it would help in situations like #1690 where there are a lot of blocks added to a region.

klonos commented 8 years ago

...I mean, the difference might not be obvious in my previous mockup because I have all that help text there. Here's how it would actually look:

backdrop-issue1691-mockup-collapsed_blocks_inside_a_block_group-no_help_text

ghost commented 8 years ago

I like it! But I'd suggest calling then simply 'Groups' instead of 'Block Groups' to make it easier to differentiate with all the words 'Block' on the page...

klonos commented 8 years ago

...although calling them "groups" would simplify the UI, that word is to generic and could cause confusion down the road. Being specific to what type of groups we are referring seems a bit more future-proof.

klonos commented 8 years ago

...another useful thing we could do with block groups besides being able to set visibility conditions etc for all contained blocks via a single dialog is this: once we set them to be reusable (#1886), they would show up in the block browser in the "Add block" dialog. So, adding a same set of blocks in another layout/region would require less steps.

quicksketch commented 8 years ago

I would much, much rather have the "reusable block groups" being discussed in #1886 than having the collapsing of block groups be a visual-only improvement. Having them grouped and managed entirely separate from the main UI would prevent a lot of clutter and solve the problem of needing to update 10 different layouts if you decided to make a change to the header everywhere.

klonos commented 8 years ago

@quicksketch yep, but this one here scratches a different itch: until we get full, multilingual support (for blocks and menus for example), people will need to resort in having not multiple similar blocks across different layouts (that's what #1886 aims to solve), but multiple similar blocks within the same layout, within the same region...

Currently, there is no way to avoid the clutter in a website that has 3+ languages and needs to have 3 different menu blocks, one for each language. If we had this feature here, one could call each menu "Main menu: [language]" and then group all these menu blocks in a block group called "Main menus (all languages)". Then, once they have configured the language visibility conditions for each menu block, they could collapse the container block group and have some sanity in their edit layout UI.

klonos commented 8 years ago

...and I just said 3 languages because that would be a common case scenario, but imagine a website with a dozen languages. These guys would need both features: the grouping together for UI sanity + the block (and block group) reusability so they can configure everything one time instead of once per layout.

Al-Rozhkov commented 7 years ago

I think this idea is perfect fit for Layouts. It's like Mini-panels and Field Group but with much better UX. I can imagine Blocks (field as block) inside Group with style "Horizontal tabs" or even "Slider". Plus if it could be reusable... Wow! There is no needs for Copy Region or Copy Block features, just put any block inside Group and make Group reusable.

jenlampton commented 5 years ago

This issue may be a duplicate of https://github.com/backdrop/backdrop-issues/issues/2119 which is getting at sort-of the same thing.