Layout Manager

[srenault-meeds]

Rationale

Using Meeds Software, it is not possible for the admin to edit any site, any navigation and thus any page.
Yet, this becomes frustrating as we need to sometimes manage navigation or page layout to test a journey or to hilight a page.

1. Functional Requirements

Top User Stories

First, we will inheritate the Layout Management Addon from the eXo team so Meeds will have starting now this addon in the product.
This means that any hub will be able to:

• manage sites
• manage navigation
• manage nodes
• manage pages

And, thus, with same UX / Functional specifications as it was identified before. Nothing is meant to be updated, excepted the layout manager.

Indeed, the layout manager will be fully revamped for a modern UX:

Precision: only admin will remain able to manage layout

1. I add a page
2. I choose the blank template
3. A tab opens to allow me to manage the layout of the page
4. By default, a section of 12 columns / 12 rows is provided

5. I can rearrange cells at my convenience

6. I can add section above, below and of course moving any section is possible

selection of section type is needed (fixed or dynamic)

7. I can edit the section to manage: display (rows, columns if fixed and columns only if dynamic)

8. I can add an app in a cell, thanks to a revamped app registry

9. For each app, I can edit it: margins, height + advanced options (sticky, mobile view, dynamic app)

Permissions for apps are equal to permissions of the page

Additionally, the first version of this Layout Manager will provide options to access and save templates

1. Add the ability to choose a template when creating a page:*

• Empty Template (Grid)
• Empty Template (Columns)
• Section and News Templates will be delivered by eXo as the News add-on is not available on Meeds Package
  

2. Add the ability for admin to set a layout as a template

• When adding / editing a page, I can decide to set is as template
• Once requested, I have to identify characteristics: name, description, preview
• Once confirmed, the template will be added in the template dropdown (after default templates, sorted alphabetically)
  For now, it will not be possible to edit, delete the template, neither add permissions

Impacts

Gamification

NA

Notifications

NA

Analytics

NA

Unified Search

NA

2. Technical Requirements

Expected Volume & Performance

Since this feature is exclusively used by administrators, the used data by this new layout editor shouldn't affect a lot the stored data size.
The page loading shouldn't be affected by this change since it should be affect the page edition only.

Security

Only Site administrators should be able to access to page and site editor.

Upgradability

This data model should be preserved and only minor changes which doesn't require an Upgrade Plugin should be applied.

Existing Features

All other features should remain as is without being affected by the new page editor.

Feature Flags

No Feature flag is needed

Other Non Functional Requirements

In the context of current feature, it would be a opportinity to delete the usage of gtmpl and WebUI in pages. In fact, there are 3 drawbacks currently while using the current technology:

• Bad UX: Loading two different pages at the same time display the same page at both Browser tabs
• Performances: first Loading of pages are very slow (gtmpl files compilation)
• Bad Developer Experience & Learning Curve & Maintainability: the WebUI is a custom framework which isn't documented, thus which offers a Bad Developer Experience

But this still isn't a main concern for this feature for now. It's important to consider that the page loading should be stateless and we have at least to delete the statefull mode of pages loading to enhance the UX (Point 1).

3. Software Architecture

Security

The usage of UserAcl service, Site and page permissions should remain as is. Thus, no need to change the current security model for pages Read & Write.

Access

The site and page content has to be loaded without WebUI in order to apply the new strategy of Stateless Mode, same as done for Site Navigation. This may be done by two ways:

• Load the Content through a REST API call
• Load the Content directly when accessing the page by with a different engine which uses:
  • Gtmpl: this will ease the migration but will reduce the maintainability and productivity on the product
  • Html & JSP: this will require an extra effort for migration which is quite difficult but it will improve the first page loading after startup and this will improve and ease the maintainability of the product.
    At this stage, no study was made yet, thus we will keep the first choice for now, in order to bring the feature to end users ASAP. After this, a dedicated technical study can start, when the WebUI isn't used anymore in all product(s), which will make the transition and migration easier (instead of an Hybrid system between WebUI and no WebUI).

Services & processing

Each page modeling/design should begin a draft page which will store periodically the changes made by the user and locks the page edition to inform other users that the same page edition is in progress. This lock should be kept active at most 10 minutes. When the UI is displayed, the lock time is updated each time the user makes a modification or each 2 minutes to make sure that the lock stay hold by the user. The lock shouldn't be a hard lock, and another user (with same privileges) should be able to force it if needed.
Once the page is saved, the draft (TEMPORARY) page should be deleted.

[srenault-meeds]

@margondicco to check please

[boubaker]

@margondicco to check please

ok, I will wait for Go-func to submit for a Go-tech (@rdenarie in case you want to read the first tech spec version)

[margondicco]

Hello Go fonc Good job !

[srenault-meeds]

Thanks!
@boubaker your turn :)

[boubaker]

Ready for tech review by DAO Members (eXo : @rdenarie )