[WP][UX] separate the backend and the frontend, like WordPress

[jenlampton]

3 - separate completely the backend and the frontend of the website, like wordpress, grav and other CMS do: so you must login in a completely separate page where there are just user, password, a "forgot password link" and maybe a "new user registration link" and there is not the frontend website theme 4 - I think in the backend there should be a direct link to the frontend website opening the link in a new window and the Shortcut drupal module to provide some menu quick links (and the home links in the backend can disappear) 5 - in the content I'm editing there should be a link in a new window to the page rendered in the frontend and maybe a "split view" mode like SilverStripe or ProcessWire CMS do for example (this view mode can do a preview of a page I'm editing)

This issue was spun off from a comment by @fivepoints79 in https://github.com/backdrop/backdrop-issues/issues/495#issuecomment-461456258

[jenlampton]

This is an interesting idea. It certainly works for WordPress!

I've also seen a lot of high-end/enterprise sites where they want to split the back end editing interface of a Drupal site into a completely separate "more secure" location, than having it attached to their front-end publically-viewable site.

I personally like the way it is now, but maybe that's just because it's familiar to me :) Adding the more-feedback label so we can see how others feel about it.

My gut says that reworking our administration to be "back-end" and "front-end" is going to break a lof of things, and may be better left to 2.x, so adding milestone. If it becomes a priority we can re-evaluate and see if we can do it in a backwards-compatible way.

[fivepoints79]

This is an interesting idea. It certainly works for WordPress!

I've also seen a lot of high-end/enterprise sites where they want to split the back end editing interface of a Drupal site into a completely separate "more secure" location, than having it attached to their front-end publically-viewable site.

I personally like the way it is now, but maybe that's just because it's familiar to me :) Adding the more-feedback label so we can see how others feel about it.

I like both, but I have this idea just because some content writers in the past have pointed out to me that maybe they were more comfortable with a separate backend interface.

My gut says that reworking our administration to be "back-end" and "front-end" is going to break a lof of things, and may be better left to 2.x, so adding milestone. If it becomes a priority we can re-evaluate and see if we can do it in a backwards-compatible way.

ok, thanks. anyway these points are just some ideas but I don't know if they can be applied to backdrop CMS.

[oadaeh]

I'm just here to be a contrarian. :)

3 - separate completely the backend and the frontend of the website, like wordpress, grav and other CMS do: so you must login in a completely separate page where there are just user, password, a "forgot password link" and maybe a "new user registration link" and there is not the frontend website theme

When I first encountered that on WordPress, I was confused by it and thought it was a bizarre idea to separate site configuration/administration into two separate areas that looked different from each other and both required logging into. I think if Backdrop goes down this path, there should be very clear indicators in the UI of what is happening.

4 - I think in the backend there should be a direct link to the frontend website opening the link in a new window and the Shortcut drupal module to provide some menu quick links (and the home links in the backend can disappear)

I think relying on the Shortcut module for that is not a good idea. That is always one of the first modules I disable, when I create a new D7 site (which hasn't happened in quite a while).

[fivepoints79]

I'm just here to be a contrarian. :)

no problem: thank you for your feedback and suggestions : )

3 - separate completely the backend and the frontend of the website, like wordpress, grav and other CMS do: so you must login in a completely separate page where there are just user, password, a "forgot password link" and maybe a "new user registration link" and there is not the frontend website theme

When I first encountered that on WordPress, I was confused by it and thought it was a bizarre idea to separate site configuration/administration into two separate areas that looked different from each other and both required logging into. I think if Backdrop goes down this path, there should be very clear indicators in the UI of what is happening.

ok, so maybe the separation between frontend and backend is not so intuitive for the majority. maybe is not good for all people.

4 - I think in the backend there should be a direct link to the frontend website opening the link in a new window and the Shortcut drupal module to provide some menu quick links (and the home links in the backend can disappear)

I think relying on the Shortcut module for that is not a good idea. That is always one of the first modules I disable, when I create a new D7 site (which hasn't happened in quite a while).

about the shortcut module, I meant to use it for custom "rapid links", just in case one feels the need, but I know that not everyone appreciates it.

thanks

[cellear]

As I mentioned in today's Design call (https://youtu.be/aTrEV1RamQ0?t=785) I think we should pay attention to the success and popularity of dedicated administrative backends among our fellow CMSes. Notably, of course, Wordpress does it. I attribute it to Wordpress's founder Matt Mullenweg's origin as a content editor -- as project leader, he has carefully guarded the interest of content creators. So, since the giant Wordpress community thinks its a good idea, we should pay attention.

I'd also point out that we tend to have much more complicated information architectures, that are less generally amenable to a WYSIWYG treatment than Wordpress's comparatively simple posts and pages are.

As a further datapoint, all of the commercial CMS systems I've worked with over the past few years -- Adobe Experience Manager, Sitecore, Tridion, Episerver -- have dedicated administrative back-ends.

[olafgrabienski]

Interesting topic! Personally, I like the way how Backdrop works because it's possible to work as a content editor using both, the backend or the frontend. For example, if you edit a post using an Edit link on the post in the frontend (or using a contextual Edit link in a View, always in the frontend), after editing you're redirected to the frontend page. If you're editing the same post from a backend admin content page, you're redirected to the backend page. Both ways work fine and are consistent.

IIRC, WordPress is less consistent: If you edit a post coming from the frontend (which is possible), you edit it in the backend but after that you're not redirected to the frontend. Instead, to see the result of your edit, you have to open the frontend page by clicking a link which opens in a new tab. If you then edit the post again (and again), the same is happening again (and again), resulting in many open tabs.

That's how I remember it from a year ago, or two. I'm not sure if it's still the case, because I don't work often with WordPress, and in my impression the WordPress UI has changed a lot over time. I think they try to keep a strong focus on usability for content editors and blog owners, but my impression is that not all solutions seem to work equally good. My conclusion: If we take WordPress as an example or as inspiration, it's important to describe quite detailed how it's actually working.

[stpaultim]

I'm so used to Drupal/Backdrop CMS that I'm having a hard time imagining this. Will try to explore a Wordpress site sometime soon to experience this and better evaluate the pros and cons. It's not clear to me what the benefit is.

[fivepoints79]

IIRC, WordPress is less consistent

yes, I also think is less consistent.

If you then edit the post again (and again), the same is happening again (and again), resulting in many open tabs.

yes, I think it's better to use maximun two tabs.

so, my conclusion in relation also to the feedback received is that it is probably better not to separate the backend and the frontend. I then mentioned SilverStripe and ProcessWire because IMHO, I think they, like Backdrop, also have a very good way of displaying the preview of the content being edited (I think it's better in SilverStripe than in ProcessWire because ProcessWire to me seems a little more confusing about how it handles the preview links) and could probably be taken as a starting point for new ideas. SilverStripe in particular also has a preview mode for desktops, smartphones and tablets (for smartphones and tablets you can also change orientation). so for me maybe we can consider only the point 5:

5 - in the content I'm editing there should be a link in a new window to the page rendered in the frontend and maybe a "split view" mode like SilverStripe or ProcessWire CMS do for example (this view mode can do a preview of a page I'm editing)

[olafgrabienski]

in the content I'm editing there should be a link in a new window to the page rendered in the frontend and maybe a "split view" mode like SilverStripe or ProcessWire CMS do for example (this view mode can do a preview of a page I'm editing)

Here's a Drupal module which could be ported to work as Backdrop contrib module or used as inspiration for Backdrop core:

Responsive Theme Preview, https://www.drupal.org/project/responsive_preview

[fivepoints79]

Here's a Drupal module which could be ported to work as Backdrop contrib module or used as inspiration for Backdrop core:

Responsive Theme Preview, https://www.drupal.org/project/responsive_preview

I did not know this awesome module existed! thanks.

[matthewv789]

Personally, I'm more concerned with my admin site being at a different hostname from the front-end site, which I prefer to export as static HTML. :)

I do like some aspects of the idea of totally separating things:

1. Can remove a lot of cruft from front-end themes if there are never any admin links or needed support for admin functionality (ie js libraries, styles). I want full control over my front-end HTML and what JS/CSS loads, and I want it to be lean and clean; mixing admin functionality into the front end makes this difficult.
2. To the extent that code you are working on affects only the front end, errors shouldn't affect the admin interface.
3. Even more (this would be a whole new step) would be to go beyond just the themes, but to specify modules, or code within modules, to be either front-end or admin so that it only loads in the appropriate situation. This could speed up performance of both sides of the site and isolate bugs as well.

[indigoxela]

Usually I don't have strong opinions about UX proposals made here. This time I have!

One of the reasons, I always liked Drupal and like Backdrop is, that everything can get edited in place. The reason I never really used Wordpress is exactly that - this crazy clicking forward and back from/to frontend and backend never made sense to me. So let's not change something, that's better by design to something else, just because other CMS (not only WP) are doing it that way.

I'm convinced, Drupal and Backdrop have the better solution regarding this. Please, let's not introduce the same frontend/backend madness.

[Graham-72]

Personally I find the Wordpress arrangement confusing, particularly when a custom 'theme' is added which may add a lot of functionality but has very 'techie' UI. I recently helped a client by reworking her new Wordpress site to use BackdropCMS instead because she couldn't cope with the UI provided for handling bookings for her holiday cottages. No doubt this is largely the fault of the theme designer, not Wordpress. But I prefer the seemless approach we can provide by giving clients customised access to the admin features they need within one admin environment.

But how can we become as easy as Squarespace (for example) for users adding page content? Do we attach enough importance to our WYSIWYG interface? Just asking!

[alanmels]

Please don't to this to Backdrop! We have plenty of customers who have been attached to their Drupal 7 websites, accustomed to Drupal way's of doing things including through its familiar interface, and whom we'd like to bring to Backdrop. I believe who want this are just seeking a visual differentiation between backend and the frontend, and templating differently editor and regular user pages differently would satisfy such users.

[klonos]

We're doing some work related to this in #4410

[ghost]

FTR, I'm against this.

Backdrop exists (in part) to be familiar to D7 users, and D7 users are definitely used to having no seperation of backend/frontend. Some might call it a feature. It's one of the major differences between Wordpress and Backdrop/Drupal and I think that's good. If we copied everything Wordpress did, at best we'd become a direct compeditor of Wordpress and at worse we'd simply become Wordpress.

I agree with @jenlampton that if this were to happen, it'd be a breaking change and therefore couldn't get in until 2.x. However, if we find a way to make it possible to do in 1.x, I'd suggest making it a contrib module instead.

[yorkshire-pudding]

I'm against this. I helped an organisation with something on their Joomla site and didn't like the split system approach. I think for content editors to be able to view an article/event/page, see its wrong and go to edit it straight from the page is a great feature of drupal/backdrop.

Also, Backdrop lends itself to light applications where end users may be creating particular content types as part of the whole site experience. As an example, take the resource_timeslots module: each reservation of a timeslot for a resource is an entity that is created in the node create form, but this would probably be exposed to end users to reserve their timeslot.

[domaingood]

I'm against this too.But We can make better admin theme like wordpress. but separate the backend. I think dont need that.

[jenlampton]

It sounds like we have a lot of people who feel strongly that we should leave things as they are. I'm going to add the label "contrib candidate" since I think a contrib solution might still be a reasonable approach for those who would like to see a front/back separation, but I will close this issue for core.

Thank you everyone who weighed in!