U4-11042 - Back office front-end rebuild

Created by Pete Duncanson 02 Mar 2018, 15:59:48 Updated by Andy Thompson 04 Jun 2018, 23:00:52

Relates to: U4-11047

Parent for: U4-5576

Parent for: U4-11041

Parent for: U4-11044

Parent for: U4-11045

Parent for: U4-11046

Parent for: U4-11047

Parent for: U4-11048

Parent for: U4-11049

Parent for: U4-11050

Parent for: U4-11051

Parent for: U4-11060

Parent for: U4-11067

Parent for: CON-1509

Parent for: U4-11069

Parent for: U4-11074

Parent for: U4-11395

This issue is a thread about the possible reasons for wanting to do a back office rebuild, what it might look like, what we'd want it to do and how we might go about doing it. Consider it a wish list for now but ultimately what gets created needs to be pragmatic in the sense that we have to deliver something that helps many rather than something super technical no one can use or is so big it can't be finished (we've done that before).

More initial thoughts are on the blog post here: https://offroadcode.com/journal/dev-talk/thoughts-on-rebuilding-the-umbraco-cms-back-office/

Lets try to NOT have this become a framework battle just yet, please focus on what we want it to become, if we want it at all and how we might go about it. Other cases could be spun up under this if needed.


Jason Prothero 02 Mar 2018, 18:01:01

Pete, love the post and I think this is a good time to start the conversation.

I'm going to jot down some initial thoughts while I still have them:

  • While I agree its too early to talk frameworks, I think it would be useful to identify other CMSs that are using frameworks that may be a potential fit and see how it worked out for them. Just a thought, and there's obviously work there to discover this information and research the results. However, it may give us some great ideas.

  • I agree that the effort is big and risky. Since we're spending the time, could we at least consider features or perhaps a slight reorganization to give some value to clients? Maybe we create a list of our clients biggest pain points or complaints and see if we can address some of them?

  • I really love the approach of simplicity for people who want to extend Umbraco. Make people new to the system feel powerful.

  • Is the back-office API generic enough to simply build a new SPA on top of it? Or are there a lot of areas/services/APIs that know that Angular is being used and simply does it a certain way? Seems like we should address this first.

Jon Humphrey 02 Mar 2018, 23:35:36

Much obliged @peteduncanson, I'm with @Prothero on this, brilliant write up at the right time!

A few points from me as well, and while I know there will be great gnashing of teeth for this, there's a lot we could do to make the developer's experience better, namely:

  • Granular permissions control in the doctypes eg. tabs assignable to roles/members/users would be amazing!
  • Easier segregation of the doctypes/compositions/etc for logical layout and classification - i.e. no more Site Options content nodes on the root!
  • If we need to create a custom dashboard or tree, add a UI that handles this for us, then we know we're doing it right!
  • Finally, for now, +1 on the API clarification - and for the client led PITA list!

Thanks! J

Pete Duncanson 04 Mar 2018, 14:19:22

I've spent a little time this weekend creating cases for some of the performance tweets we've found. See all the linked cases to this one.

Some we have done, some we are wanting to do and others are still up for grabs. This is all stuff that will make whats already there right now faster, smaller and better to work with for everyone so all good stuff to be doing now. I've got some more on my list but they are more client dependant and some others that need some more digging.

Having pondered the feedback from my blog post I think this is screaming out for a session at Code Garden (now roughly 7 weeks away) to get some brains in a room with post-its and start documenting a plan and needs/wants/wishes so we having something concrete to work towards and make choices about.

Not sure an Open Space is right for it though but at a push that would do, danger is we discus it plenty before then at the bar (aka the "back channels" or "bar channels") and no one writes anything down and we are all a bit spent come Open Space day. Open to suggestions/ideas.

Anthony 05 Mar 2018, 07:11:05

I personally think the backoffice is great, and just needs iterations. Unless of course someone comes up with a great new UX. The current codebase is good, and can be nudged to a new direction. The codebase for the backoffice will get increasingly easier to modify/improve as the APIs get more mature.

Keep in mind that no matter what is discussed, HQ has said that they are concentrating dev time on getting the .net side all the way to .net core, and that’s realistically going to take the better part of 2 years. Add to that the ideas/features that might get thrown into the mix (eg. tours).

Ronald Barendse 06 Mar 2018, 23:03:41

@Dang And first getting the server-side to .NET Core would also bring other opportunities, like better integration with client-side frameworks using [JavaScriptServices|https://github.com/aspnet/JavaScriptServices] or (by then) even [Blazor|https://github.com/aspnet/Blazor]...

Package authoring and installation could also benefit from this, because some packages now have to provide an Umbraco (for actions like adding document types) ''and'' a NuGet package (for adding IntelliSense or other library dependencies). The Umbraco actions can be done the way [Chauffeur|https://github.com/aaronpowell/Chauffeur] does this, so packages would only need a NuGet version that could be installed from the back-end or Visual Studio ([Orchard|https://orchardproject.net/] uses this type of [packaging|https://gallery.orchardproject.net/] and already has a [.NET Core v1 beta|https://github.com/OrchardCMS/OrchardCore]).

Back to the back office front-end: having some system for resolving JavaScript dependencies/versions would also make writing packages a lot easier. Fetching client libraries using npm and [importing|https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import] them would be ideal. This brings me back to integration using JavaScriptServices, so .NET Core support should come first. And if Umbraco packages would have to be rewritten for the new front-end framework, the installation options should also be updated to allow for these improvements anyway...

Dirk 02 Jun 2018, 17:52:26

@peteduncanson, @jon@randomprecision.co.uk Great thoughts and conclusions. I am currently think about combining users and members and addressing the different functionality just by roles or groups (what ever you prefer to call it). I had just my first insight into ASP.Net Identity. At the moment I have the impression it would be possible to leverage Identity and its role capabilities to distinguish frontend vs. back office usage of currently logged in user/member. This separation always occurred un-logical to me and I still realise this when I explain the concept to none-Umbracians (umbbles? like muggles :-D).

Jason Prothero 04 Jun 2018, 15:31:16

@dseefeld The separation of members and users is actually a benefit to many of my more security conscience clients. I personally think its a feature that is a good thing.

Andy Thompson 04 Jun 2018, 23:00:52

Would it be a start in the .NET Core direction to take the smaller assemblies and convert them to .NET Standard? It could be done slowly and incrementally by using facade classes and some redirection so existing code doesn't have to be relinked (yet). Converting the assemblies would be a great opportunity to also clean the code. Plus, if it doesn't seem to be working it's less to roll back.

Staying compatible with the current targetted .NET Framework 4.5 would require using .NET Standard 1.1, but once there the .NET Standard version can be incremented.

When .NET Core begins to be used the other assemblies would already be on their way to being compatible.

Priority: Normal

Type: Bug

State: Submitted


Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version:


Story Points: