Show Advanced KnowledgeHide Advanced Knowledge

ILIAS Page Editor: Column Layout

1 Initial Problem

This ILIAS blog post gives a good introduction in what can be done with the page editor to create a reponsive layout with multiple columns / cells. The result looks very good.

In this feature request I will just call it grid instead of responsive column layout.

However there are two problems with these technique, which can also be seen in the blog post

1. editing a page with grid layout is complicated and at times confusing
2. creating the neccessary content styles for the grid layout is a complicated procedure and requires a good level of CSS knowledge

In this request we will only address the first problem, because this is more pressing, because it is faced repeatedly. Problem 2 is only faced once and the solution can be exported / imported to other platforms in theory.

2 Conceptual Summary

There are plans to do a major overhaul / revision of the editing GUI of the page editor. Therefore this feature request tries not to introduce new editing concepts in the page editor. The editing part in ILIAS is inspired how tables and accordeons are handled in the page editor and deliberately kept simple.

This solution is heavily based on the Bootstrap v3 grid system with 12 columns.

The basic concepts used in this feature are explained in the following introduction.

A new page element grid is introduced.

• It can be inserted like an advanced table or accordeon.
• any grid contains a variable number of cells.
  • each cell can span over one or multiple columns of the grid.
  • the cell width can have different values for each viewport range xs / sm / md / lg.
  • the smallest viewport xs requires explicit values for cell-widths (default: 12). All larger viewports don't need explicit values and default to inheriting the cell-width from the next smaller viewport (sm inherits from xs etc.).
• all grid and cell settings are centralized in the edit screen of the grid itself

Using bootstrap v3 definitions eliminates the need to define custom css classes or even generate them on the fly.

ILIAS skins will be able to change certain aspects of the bootstrap grid system, since they contain all bootstrap css: 

• bootstraps breakpointsmay be changed by ILIAS skins
• the @grid-gutter-width: 30pxmay be changed by ILIAS skins
• however, the number of @grid-columns: 12must not be changed by ILIAS skins. Note: ILIAS as it is today already has this requirement implicitly.

Summary

• This approach takes out-of-the-box experience serious and uses default styles and breakpoints according to bootstrap standards. The default breakpoints and gutter width can be modified by ILIAS skins. Future extensions of this approach are possible and sketched as follows.

Discussion

• alternative names like e.g. grid layout or responsive grid instead of grid can still be sugessted and discussed. The author of this request prefers to just use grid.
• It is possible that multiple skins are in use for the same content and define different breakpoints, gutter width, etc. This may lead to inconsistent rendering - however this is not a new aspect since any skin can differ in available content width and other things like font styles etc. ILIAS admins have to keep that in mind already.
• ILIAS content styles can define their own media query ranges which are not used by the grid. This can lead to inconsistent behaviour of different elements of the page editor. To close that gap in the future the bootstrap breakpoints from the ILIAS skins could be imported into content styles automagically (see ideas for later extensions).

ideas for later extensions - not included

• a better editing mode of grids and cells is left open to the planned general revision of the page editor. Current ideas include
  • explicitly selecting a media-query-range in preview and editing mode and being able to edit the grid in a simulated viewport, which matches that media query exactly (like this example in the top-right corner).
  • changing cell-order via drag and drop
  • changing cell-widths via some resizing-handle directly in the editor (requires explicitly selecting a media-query-range in editing mode)
• ILIAS skins could publish their breakpoint values for small, medium, etc. in their manifest file. That would allow to hardwire these skin-dependent aspects into content-styles, which could then reuse these aspects for their definitions. This would also make much sense for other key aspects like primary colors, etc.
• each grid instance could generate its css classes on-the-fly by compiling bootstrap based less files. This would allow customization of @grid-gutter-width: 30px and @grid-columns: 12per grid instance. However, this would also require some clever caching mechanism of the generated css, which can still be skin-dependent due to breakpoints. It will also require a less-compiler on the web-server.
• each grid cell comes with these extra settings (all optional). This allows for extra customization of grid layouts - see bootstrap documentation for details.
  • push/pull: 0 to 12
  • offset: 0 to 12

3 User Interface Modifications

3.1 List of Affected Views

• Any place which supports the page editor (container objects, blog, wiki, portfolio, ...) > Edit Page

3.2 User Interface Details

3.3 New User Interface Concepts

Only existing concepts are used (cf. page editor > table + accordeon)

4 Technical Information

Killing, Alexander [alex], 25 Oct 2016: I do not see any technical issues. Since we would like to use the "semantic" terms of the device widths, which seems to change with bootstrap 4, we may use the bootstrap 4 terminology also in the user interface now (small, medium, large, extra large as in bs4). The current alpha docs of bs4 still use px for the breakpoints, but this seems to be outdated. Other tutorials are mentioning em-sizes, see e.g. http://www.quackit.com/bootstrap/bootstrap_4/tutorial/bootstrap_grid_system.cfm.

5 Contact

• Author of the Request: Kiegel, Colin [kiegel]
• Maintainer: Killing, Alexander [alex]
• Implementation of the feature is done by: Killing, Alexander [alex]

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• Hesse, Joel [Joel_Hesse], Parfümerie Douglas GmbH

7 Discussion

Killing, Alexander [alex], 21 Sep 2016: I support this request.

Kiegel, Colin [kiegel] 2016-09-21: The bootstrap grid (as proposed in the alternative) indeed strikes a good balance between expressiveness and ready-to-use styles. However it relies heavily on the fact that multiple css-classes can get applied to one cell. We would need to model that and we need to explain some 101 / basics about how they work. One cool thing about bootstrap grids is the ability to switch the order of cells depending on the breakpoint or to add spacings (via push/pull and offset-styleclasses).

However we have less flexibility to customize things like paddings, but people could still use blocks inside of cells if they really need to add more styles.

Kunkel, Matthias [mkunkel], Oct 05, 2016: I highly appreciate to introduce a generic option to create responsive column layouts. But I do not see a grid becoming a new page editor element like a text, an image or a list. For me it is an underlying and unique element of the entire area under IPE control. Tables or media object could use the grid (and in this case I would favour the BS grid). But IMHO it does not make sense to add such a grid to a page, a block or a table cell of an Advanced Table. This is totally confusing because grids of several sizes would appear on one page. A good example of a grid based layout is implemented by Contao CMS. It can easily be attributed by CSS classes and always produces a proper layouted page design.

Kiegel, Colin [kiegel] 2016-10-05: I totally agree that a grid does not make sense everywhere, especially not in tiny table cells. However it does make sense to have nested grids or no grid at all. And I could even imagine some use cases for putting grids into accordeons or blocks. That's why I see it as a page editor element (like a table).

PS: I tried the Contao CMS Online Demo http://demo.contao.org/contao/, but I could not find any way to model responsive grids. I only looked around for 5 minutes..

Kiegel, Colin [kiegel] 2016-10-18: Protocol of todays Jour Fixe Workshop:

• There are early thoughts to do a major overhaul / revision of the page editor editing GUI. It was discussed, whether it makes sense to delay the implementation of a responsive grid until all the details of this editing GUI revision are settled. However this delay would be unpredictable and could easily take longer than the release of 5.3. We prefer to finalize the responsive grid concept first, because it is more advanced and there seems to be a big demand in the community to simplify creation of responsive content. As Alex Killing explained a later migration to a different user interface should not pose a big issue, even if this happens within the same ILIAS release. As a result this concept should try not to introduce new concepts in the editing GUI which could interfere with the revision. Instead existing concepts of the editing GUI shall be used. The following ideas are postponed to the editing GUI revision:
  • switching between media queries in the editing GUI
  • resizing grid cells in the editing GUI
• We prefer to reuse the bootstrap grid logic instead of utilizing manually created css styles.
• The grid should use the standard set of bootstrap breakpoints, which details can be modified by skins. As a future outlook these standard set of breakpoints could be made acessible within content styles, but that does not need to be within the scope of this feature implementation.
• We still have to clarify the naming of the feature as the name grid can lead to different associations. A grid-based layout in print design works a bit differently from the bootstrap grid system. And there is even a CSS-grid-system in the making. So let alone the name grid is at least ambiguous and it is unclear whether users will understand the right thing. This point however seemed quite controversial.
• A mockup of the edit screen should be included for the bootstrap-based variant.

Kiegel, Colin [kiegel] 2016-10-21: The proposal has been reworked according to the Jour Fixe workshop. Awaiting feedback from the maintainer and scheduling for Jour Fixe. The old proposal can still be found in the accordeon below.

Killing, Alexander [alex], 25 Oct 2016: I fully support the idea.

Kunkel, Matthias [mkunkel], Nov 03, 2016: My favourite label for this feature is 'Multi-column layout' because that is what I get as a user.

JourFixe, ILIAS [jourfixe], Nov 07, 2016: We highly appreciate this feature request and schedule it for 5.3.

• We would like to use the future semantic terms for the breakpoints (Bootstrap 4):
  • We start with small, medium, large and extra large. With the introduction of BS4, small will be split into extra small and small.
• We still keep the discussion open about the UI labels for the feature: "Grid" or "Multi-column layout"

Hilbert, Mirco [mirco.hilbert], Jan 18, 2017: From a usability point of view, I would absolutely beware introducing a new page editor element "Grid".
Instead, I would propose to add an option called for example "responsive" to the advanced table element settings. Therefore, the author can decide how a table should behave when changing the size of the browser window. Either the columns stay side by side and a user has to scroll horizontally, or the table breaks at certain columns.
If introducing a new page editor element (as proposed in this feature request) it is impossible for the author to easily change from one kind of behavior to the other. Especially concerning existing content, authors have a big workload to get all their existing tables responsive when they have to recreate them using the new grid element.

Kiegel, Colin [kiegel] 2017-01-18: I understand the concern and I agree that this is a big issue! The problem is, that a responsive grid behaves differently than a responsive table would most likely do. And we need completely different settings. Having one page element for both use cases would be a huge technical burden. However it would be very interesting to have a dedicated "convert table to responsive grid" action somewhere. I think that would help a lot of people in that situation.

Killing, Alexander [alex], 15 Feb 2017: I completely agree with Colin here. Tables are a different concept with different properties (row/column headers, diffent row concept/behaviour, border, css classes, ...). And the term "responsive table" usually refers to responsive data tables and not to grids.

Kunkel, Matthias [mkunkel], MAR 08, 2017: I assume cell 4 is placed under cell 3 because it is not very high and 3+4 are not higher than cell 2 (other than shown on graphic), right? So one problem is the behaviour of floating cells with different height. How about adding a behaviour to our cells that give them all the same height - related to the highest cell. This would also be helpful for the layout of the element as you could give a background colour to all cells, with the effect that equal surfaces are displayed. We could keep the Bootstrap grid behaviour and do not to implement an alternative solution.

Amstutz, Timon [amstutz], March 16. 2017: I would prefer to not change the bootstrap standard. It's what you would expect from a bootstrap grid. If this is a serious issue for the page layout, one could always create multiple grid layout elements and so create mulitple rows, which would get rid of this behaviour. 

E.g.:

Element 1:
<div class="row">
  <div class="col-xs-6 col-md-4">.col-xs-12 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-12 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-12 .col-md-4</div>
</div>

Element 2:
<div class="row">
  <div class="col-xs-6 col-md-4">.col-xs-12 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-12 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-12 .col-md-4</div>
</div>

Obviously, this does break in some cases, such as:

Element 1:
<div class="row">
  <div class="col-xs-6 col-md-4">.col-xs-6 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-6 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-6 .col-md-4</div>
</div>

Element 2:
<div class="row">
  <div class="col-xs-6 col-md-4">.col-xs-6 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-6 .col-md-4</div>
  <div class="col-xs-6 col-md-4">.col-xs-6 .col-md-4</div>
</div>

But we can not have everything at once, right?

Killing, Alexander [alex], 17 Mar 2017: @Matthias "I assume cell 4 is placed under cell 3 because it is not very high and 3+4 are not higher than cell 2 (other than shown on graphic), right?". No, I think the picture illustrates the floating behaviour quite well. The height of 2 should not matter. What matters is that the heigt of 3 is smaller than the height of 4.

Kunkel, Matthias [mkunkel], MAR 20, 2017: Thanks for the explanation, Alex, even if it is not really comprehensible for me. But anyway... More important is to finally decide the name of the feature. I strongly recommend "Multi-column layout" or "Column layout". This feature relies on the technical concept of a grid and the existing grid implementation by Bootstrap. But grid is not a good name for labeling this feature in the UI.

JourFixe, ILIAS [jourfixe], March 27, 2017: We would like to have a behaviour like shown on the green example above (flex grid). Alexander will try to implement this and comes back to the JF in case he failes. According to the decision of the PM the feature shall be called "Column Layout" / "Spaltenlayout".

Killing, Alexander [alex], 19 Apr 2017: I failed to implement the flex grid approach. Mainly because I was not able to get nested column layouts working properly (the linked css above fails to provide this). So my current patch falls back to the bootstrap standard behaviour, which supports nesting.

Amstutz, Timon [amstutz], 19. April 2017: I am currently working at a related task of making the cards in the user gallery all the same height without using js. I think I found a working solution using flex. However, my issue is less complex, since I always have an amount of cards in row that is smaller than the max number of cards a row can hold. If you have a specific DOM snippet to look at that causes trouble, I would be happy to go over it. Maybe we can still do something. However, maybe not.

JourFixe, ILIAS [jourfixe], April 24, 2017: Alexander gave a short update about the current implementation of the flex layout. We will give a last chance to this implementation. If it does not allow nesting in a satisfying way, we go back to the pure Bootstrap implementation. According to Bootstrap web page, Bootstrap 4 (still alpha) will support flex boxes.

Hesse, Joel [Joel_Hesse], 19.06.2017: works great. Thank you all.

Hesse, Joel [Joel_Hesse] UPDATE (07.11.2017): We need the flex-grid behaviour like in the green example above.

Kiegel, Colin [kiegel] 2017-11-15: The flex-grid behaviour is essential to construct responsive layouts with cells of different height. I consider "not having this" a bug, especially since flex-grid behaviour is supported by all current browsers.

JourFixe, ILIAS [jourfixe], 20 NOV 2017: The Jour Fixe decisions made in March and April are still effective. The implementation is based on the current behaviour of Bootstrap 3. The scenario shown above in red is not considered as a bug but as the expected behaviour of Bootstrap (3). We are open to discuss this behaviour again when having switched to Bootstrap 4 where flexible grids are handled different. But this is not possible before 5.4 at the earliest.

8 Implementation

Test Cases

Test cases completed at 2017-02-28 by Tödt, Alexandra [atoedt]

• 18378: Grid einfügen

Approval

Approved at 19.06.2017 by Hesse, Joel [Joel_Hesse].

9 Outdated Documents