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

Feature Request: Restrict box styles to certain container slots #431

Open
arnalyse opened this issue Feb 13, 2017 · 6 comments
Open

Feature Request: Restrict box styles to certain container slots #431

arnalyse opened this issue Feb 13, 2017 · 6 comments
Assignees

Comments

@arnalyse
Copy link

arnalyse commented Feb 13, 2017

Proposal

It would be a great addition to Grid if it was possible to restrict box styles to certain container slots.

Motivation

As we are moving to more advanced designs in modern webdesign, some box styles look gorgeous in large slots (think 1/1, 2/3 or 1/2) but look distorted when squeezed into smaler slot sizes.

Examples of this would be boxes with visually stunning imagery or typographic details, which need space to breathe.

Although the goal of Grid is to be as adaptable as possible, and to make every effort to make every box work in every spot on the users‘s behalf, some box styles just don‘t make sense in small slots, and some smaller ones can certainly feel lost in huge slots.

A restriction of boxes to defined slots would give the user valuable feedback what works and what doesn‘t. Furthermore it would allow the designers and developers to focus there efforts on designing and developing the qualitatively best styles, and keeping requirments and complexity manageable, while not having to compromise on subpar box and slot combinations.

Thus such restrictions can help in the paradigm of »race to running software« as it reduces complexity in theme development.

@benthebear
Copy link
Member

@arnalyse I assume that you do not mean box styles nor boxes, but teaser formats, right?

Besides my former position, I heavily support this proposal. With the Presidential Suite having now around a dozen teaser-formats theming all of them for all slots is madness. And most editorial staff don't want this flexibility.

The central problem to be solved is: What happens, when a place a given box into a slot, choose a teaser format that is valid within that slot and then move the box to a slot, in which chosen the teaser format is not valid? Options for this are

  • Do not allow to drop the box there (slot get's red or so). Problem: The editor doesn't know why he/she's not allowed to place the box there …
  • Automatically fall back to the basic teaser format (which should work in all slot!). Problem: Editor doesn't know, that we changed the format.
  • Mark the Box (red or so) to indicate a problem and until solved, do not allow to save the grid. Problem: Editor doesn't know what's wrong and taking away the save-option is quite unfriendly.

Any further Ideas?

@benthebear
Copy link
Member

@EdwardBock But first … how would you estimate the effort to filter the teaser formats based on the slot the box is placed in, within the UI?

@benthebear
Copy link
Member

@mkernel @kroppenstedt opinion is also welcome!

@arnalyse
Copy link
Author

arnalyse commented Feb 14, 2017

Well, whether it's just the styles or even whole boxes/box types is open for discussion.

(Nevertheless, In my examples above box styles read like teaser formats, yeah.)

@benthebear
Copy link
Member

benthebear commented Feb 14, 2017

Okay … then we do have those Entities that could be limited based on the slot-size …

  • Box Type (Example: No videos in 1/6 slot)
  • Box Style (Example: No "highlight dark green" style in 1/6 slot)
  • Teaser Format (for those boxes that have teasers) (example: no typography teaser in 1/6 slot)

@mkernel
Copy link
Contributor

mkernel commented Feb 14, 2017

I understand the feature request and i understand that the effort to support all combinations of "available screen estate" and "desired output" (to generalize the problem) is not effective and doesn't help except proving a point (that it works).

But: do we really need support in grid for this kind of edge case? There is a preview version of every grid available and every grid editor should (and does!) bring enough taste to the table to "see" shitty layouts. He can already fix the problem by previewing, changing the grid and previewing again.

Whatever we're going to integrate is making grid a ton more complex:

  • You need to tell the user why he can't drop a certain box at a certain slot
  • You need to tell the user why he can't use a certain box style at a certain box whereas he already used it on the same box in another slot/container
  • You need to tell the user why he can't use a certain view mode on a certain box wheras he already used it on the same box in another slot/container

Plus: that's engineering madness. Grid doesn't know about these details, so we're talking about hook-hell here. We need a hook to fire from javascript into javascript to tell the editor that a box can't be placed. Another hook to forbid certain box styles on certain boxes in certain slots (or at least the box style - slot combination, which is just a specialised version of the aforementioned hook). Another hook to disable view modes - which is a box-specific configuration parameter. Grid doesn't know anything about view modes. So hooks in custom boxes, it is then.

And we need to talk about slot styles to be forbidden for certain slots, right? And what about container styles for containers with more than 3 slots?

That's a quite rocky road ahead. And we're not really improving the product from my point of view.
If it is that kind of a big deal, there is a way to implement it. It's not going to make grid easier and integrating it well into a custom theme is also getting more complex.

So there is a tradeoff: support all combinations in layout OR disable those not supported by implementing the right hooks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants