U4-10934 - Spike: Infinite editing

Created by Jacob Midtgaard-Olesen 05 Feb 2018, 10:34:10 Updated by Sebastiaan Janssen 13 Feb 2018, 08:41:52

Subtask of: U4-10747

1 Attachments

Download infinte-editing-media-picker.mp4


Mads Rasmussen 09 Feb 2018, 12:00:48

I have made a proof of concept of how I think the infinite editing workflow could be solved. The main thought behind the change is when infinite editing is fully implemented “everything will be an editor”. All pickers (content picker, media picker etc) and editors (content, media, doc types, templates etc) will be built with the same concepts in mind (layout, components, etc).

The proof of concept shows how a media picker will work with infinite editing (see attached video). To add a media item you click the “add”-icon to open up the media picker. Inside the picker, all media items have been added the option to edit the media item (design is WIP). When clicking the edit button we open up the media editor where you can easily update the media item.

Branch: I have made a separate branch for infinite editing so it is easier to see the changes. Sorry for the many file changes. I went down the route of renaming a CSS class which was used a lot □□ https://github.com/umbraco/Umbraco-CMS/compare/temp-v8-UI...temp-v8-UI-infinite-editing

Today all editors are made with routes as the way to get ids and other states from params (“create”, “subviews" etc). All of this will still be the same and navigating the back office from the tree will work exactly the same as today.

On top of this, we will add a layer which is close to how the overlays component/dialogService works today. We will have a global "editor service" which will provide helpers to easily open and close new editors/pickers in “infinite mode”. The service will also be responsible for keeping track of all open editors/pickers. The service should include helpers to open all supported editors easily and the most common pickers (content picker, media picker etc.) The service will communicate with events to a global “umb-editor” component added to the dom root.

For this to be able to work we will have to make sure all supported editors have an “infinite mode”. When in “infinite mode” the editors need to get their data from the component instead of the route params. They will also need a “close”-button and to extend the save/submit/done with an easy way to “save and close”. We will also need to make sure these editors open new editors in “infinite mode” or disable “broken” functionality (links etc. which changes the route).

Currently all “regular editors" are made with the correct editor components so they will look the “right way” but all pickers/dialogs need to get an update to the markup/logic to use the same components as the “regular editors”.

What we need to figure out is: Is this the right approach to solving infinite editing?

Known challenges which aren’t solved in this proof of concept:

  • The tree - The tree takes up a lot of space and you don’t need the tree when the focus is on a picker/editor opened in “infinite mode". When infinite editing is open how should we handle the tree?
  • Many pickers layered on top of each other. This one is a bit complicated to explain in text but here we go. A picker only takes up a little bit of the screen where a regular editor will take up as much space as possible. When we start combining many pickers opened after each other with full-width editors there are some challenges on the best way to allocate the available space.
  • Collapsed editors. When many editors are open we should start collapsing the first editors so we only show the editor title. This will give us some extra space for newly opened editors.
  • Discard changes: If you refresh the browser all editors opened in infinite mode will be lost as we currently have no way to get back to that state. We will need a solution to either prevent refresh without confirmation when the infinite mode is open or a way to restore the current infinite state.
  • Animation. To ease up the infinite flow we should look into how we can add some smoother transitions when opening and closing new pickers/editors

Sebastiaan Janssen 13 Feb 2018, 08:41:48

I'm moving this to fixed as investigation is done and we can build on that later. Objective of the spike reached I'd say.

Priority: Normal

Type: Task

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version:

Sprint: Sprint 78

Story Points: 5

Cycle: 8