Problem/Motivation

The overall goal is to make more site edit/build functionality available directly on the frontend of your site (“turning Drupal outside in”). A current example of this is the "Edit" button (toggle) top right in the toolbar:

This button in itself has usability issues but new developments like #2724819: Create experimental module for place block on any page feature are adding their own seperate links to the toolbar. Which obviously does not scale well:

We need to find a way to scale this pattern so that besides content editing we can also expose interactions for "add new", "rearrange" and others. The general idea could be to have a global View/Edit/Build toggle for example which could show a sidebar with applicable tools.

Proposed resolution

gifImage links to attached video

Trigger an "edit mode" in which links are disabled but all blocks are tap/clickable. Taps/clicks trigger an off-canvas configuration tray which separates content and configuration tasks into two tabs (the above prototype shows the toggle and off-canvas tray integrated with the experimental "place block" module).

Remaining tasks

- List potential interactions to expose
- Rank them: what are the 80% use cases, which are more on the side of 20%?
- Define an initial scope
- What are existing contrib solutions in this space?
- Explore designs options
- Prototype, test, iterate
- Decide on the preferred design
- Write up a spec
- Write the patch (in a followup issue?)

User interface changes

See child issues.

Comments

yoroy created an issue. See original summary.

yoroy’s picture

Title: Design for triggering an edit/build mode from the toolbar » Design for triggering an view/edit/build modes from the toolbar

The title might need some work, naming things is hard :)

yoroy’s picture

Title: Design for triggering an view/edit/build modes from the toolbar » Design for triggering view/edit/build modes from the toolbar
yoroy’s picture

Issue tags: +Usability
webchick’s picture

Over in #2724819-102: Create experimental module for place block on any page feature, @tkoleary proposed a toggle like so:

Editing disables build; build disables Edit

(pretend "place blocks" == "Build" or similar)

This way we could re-use the existing Quick Edit paradigm but not overwhelm people with thousands of blue boxes at once. It would also help with some of the interaction patterns we observed in UX testing; for example clicking on the "friendly pencil" leading you to the Views UI. (Horror!) Contextual links icons could be Pencils in "Edit" mode and only let you edit content, vs. switch to Gears in "Build" mode and expose "Configure foo" and "Place block"-style options.

Bojhan’s picture

My primary concern with this approach is that its not scalable. At one point we will end up with like Menu's, Blocks, Views, Edit, etc and people will spend lot of time "knowing which modus" to go into. We can go for the 2nd menu, but clicking something on the right to get something on the right probally doesn't work either.

Is there a way to have a "edit all the things" mode? Like injecting the "empty" regions into the current page?

yoroy’s picture

Would be good to at least note in hear that @tkoleary is working on prototypes for this… Demos in Hangouts only don't count ;-)

tkoleary’s picture

FileSize
17.65 MB

@yoroy

Good point. :)

I have attached a video of the interaction prototype. For those not attending UX meetings, we have now iterated on this two or three times.

This is the prototype that the team at Cheppers will be testing. Comments here will be noted for the next iteration which will happen after user testing.

It shows the following features:

  1. The "edit" button which we already know is not discoverable, is mover to position #1 (top left).
  2. User is moved to where "edit" was (should be a different issue but makes for a more sensible prototype)
  3. "Edit" triggers a mode with it's own toolbar in which links are not clickable, and clicking blocks triggers the off canvas configuration tray
  4. The mode is clearly explained with a message.
  5. The off canvas tray is where the "build vs edit" split happens, re-worded here as "content" and "configuration" tabs
  6. "content" is understood not in the technical sense but in the user sense of "Text printed on the page that I can change"
  7. The "Configuration" tab shows a subset of configuration options in the full form (the "tray display" of forms would need an API so developers and site builders could configure which fields are shown). Configuration will also require sub tabs for different forms eg. Block configuration, and menu configuration.
  8. After focus a second click on rendered text triggers quick-edit, but text is also editable in the field in the tray (This opens up the exciting possibility of being able to switch to source view while editing a node without losing the rendered preview).
  9. Because some blocks may not be clickable (eg. z-indexed below something by the theme), clicking where there is no block triggers the block dropdown where the user can choose the block to edit (thanks to bcwald for this observation). This dropdown is also always available as an alternate form of navigation around the page.
  10. It is not shown in this prototype but our assumption is that hovering a block in the list that is scrolled away would scroll the page to that block as well as highlighting it.
tkoleary’s picture

FileSize
26.76 MB

Uploaded newer version of video/prototype

Bojhan’s picture

This approach could use some more thought, I discussed this with Gabor and we kept running into more challenges.

Can we discuss the following parts:

  • How do we deal with "placing blocks"? Is this triggered by pressing Edit?
  • How do we deal with the "mobile" pattern where you cant hover to see which parts are editable? The dropdown could work, but how does it scale to sometimes 30/40+ items (I mean I have never seen a site with just 8 blocks on the homepage).
  • What does the "Page/my-article" allow you to do? Can't this just be "Go back to site/view" - imagine long URL's.
  • The save/cancel/exit functionality seems to be all differently placed and not in-line with core. While this is possible its not required for this interaction to work can we keep it out for the time being?
  • Edit, Manage, Shortcuts are all different. How do we deal with the fact that "Manage" might be open - does it close when you click "Edit"? Especially relevant with the horizontal toolbar as that would disrupt your sidebar
  • The point of the "Edit" toggle was to show where all the contextual links are - to make it more discoverable that is high value, now removed. I don't think that the dropdown is a good substitute, because you remove it from "near the object" which was the whole point, as block names often aren't very descriptive.

I disagree with the premise that we should remove all contextual links from the front-end. While I understand you like "Edit" to claim this space, conceptually this is only needed if you expose functionality that can't be caught using contextual links (e.g. placing blocks). The primary benefit of contextual links is that you can move through your website and quickly jump to relevant configuration. The proposal is to reserve that "jump" to only when your in "Edit mode" that seems artificial and not necessary. Contextual links are not in the way, they might be less discoverable - but testing so far has not proven this (we know the top right edit button doesn't work, that is not transferable to all contextual links).

It looks to move this issue and #2729413: Open "Configure Blocks" contextual links in a Modal with a simplified (quick edit) form forward there are a few major things we need to hash out:

  1. What is considered "advanced" and how do we deal with this?
  2. How all encompassing should the new "edit mode" be as an experimental module?

To be frank figuring all of this out, and dealing with the toolbar, contextual links and implementation with various modules - sounds very difficult in 5 weeks. We can probably do a limited version of #2729413: Open "Configure Blocks" contextual links in a Modal with a simplified (quick edit) form possibly even without the whole edit reinvention and just a new contextual link (like that patch does).

Can we please consider the scope and timelines? This should have a meta issue.

tkoleary’s picture

How do we deal with "placing blocks"? Is this triggered by pressing Edit?

Yes.

How do we deal with the "mobile" pattern where you cant hover to see which parts are editable? The dropdown could work, but how does it scale to sometimes 30/40+ items (I mean I have never seen a site with just 8 blocks on the homepage).

It is not necessary to hover. On touch devices, tap will focus on the item tapped. Since links are disabled there is no issue of accidentally tapping a link, and since everything is now a block, everything will be tappable.

What does the "Page/my-article" allow you to do? Can't this just be "Go back to site/view" - imagine long URL's.

We could but I think it's important to orient the user so that they understand what they are editing.

The save/cancel/exit functionality seems to be all differently placed and not in-line with core. While this is possible its not required for this interaction to work can we keep it out for the time being?

Yes. I think it's important, but It can be a follow-up issue.

Edit, Manage, Shortcuts are all different. How do we deal with the fact that "Manage" might be open - does it close when you click "Edit"? Especially relevant with the horizontal toolbar as that would disrupt your sidebar

In edit mode you are editing a specific page and the ability to navigate away is potentially destructive. In the current design you need to leave edit mode to use the admin menu tray. The current uasbility tests should uncover whether this works for users.

The point of the "Edit" toggle was to show where all the contextual links are - to make it more discoverable that is high value, now removed. I don't think that the dropdown is a good substitute, because you remove it from "near the object" which was the whole point, as block names often aren't very descriptive.

The point of the edit toggle in this prototype is indeed slightly different from the point of edit toggle as it exists in now. Because tapping *immediately* exposes configuration options it is no longer necessary to provide options in a dropdown, and because *everything* is tappable there is no longer a discovery problem (unless the block is z-indexed below other things and un-tappable, which is the reason for having the dropdown).

I disagree with the premise that we should remove all contextual links from the front-end...

We don't need to remove them. They can still be available when the user is not in the edit mode.

To be frank figuring all of this out, and dealing with the toolbar, contextual links and implementation with various modules - sounds very difficult in 5 weeks. We can probably do a limited version of #2729413: Open "Configure Blocks" contextual links in a Modal with a simplified (quick edit) form possibly even without the whole edit reinvention and just a new contextual link (like that patch does).

I don't think we need to be so conservative. There are primarily four tasks to get the basic implementation (blocks) in:

#2753919: Move the "edit" link in the toolbar so that it's more discoverable This should be very simple.

#2753941: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode Which should not re-invent wheels but simply extend toolbar, replicating the left vertical tray on the right.

#2753937: Move simplified "configure blocks" form into the off-canvas tray which leverages form building work already done by @tedbow in #2729413: Open "Configure Blocks" contextual links in a Modal with a simplified (quick edit) form

#2753933: Re-style the "region placeholders" so they are not ugly. which already has design and CSS form the patch I wrote that was de-scoped from #2724819: Create experimental module for place block on any page feature

We are not removing contextual links, we are not designing for every possible use of the tray, we are not doing anything new with "save, cancel." The dropdown with list of blocks feels like it should be a follow-up enhancement, as is the tabbed structure of the open tray.

tkoleary’s picture

SKAUGHT’s picture

#11 - How do we deal with the "mobile" pattern where you cant hover to see which parts are editable?
stop thinking hover. elements can not be hidden from the beginning. Users forget what things do and how/why they need to. Then forget what they are doing..

IMO: combining Edit and Place Block should not happen. they are separate tasks. and do require different modules to be enabled! Also, down the road we will have more such addition task buttons.
--> perhaps a dropbutton for these tasks should be introduced and keep right.. (ie: like Foundation menus.. off-canvus for mobile.)

SKAUGHT’s picture

Bojhan’s picture

Thanks for the response.

I think its acceptable to remove the capability to visually see what parts are "editable". It would be removal of a feature, but I do expect just tapping will indeed be sufficient. It might be a bit "confusing" combined with the "place blocks" interaction, that does add this "click here" type visual style. But likely something you can figure out in a updated design.

Not being able to navigate away and "collapsing" the admin menu in Edit mode seems reasonable. I am a little concerned about the "back" functionality - which now has two purposes. Knowing what page you are on, and going back. This breaks with the current "back to site pattern", which only has one purpose. We can dual purpose it, but prefer to then have another item on this revamped toolbar that just gives the current location. Usability wise knowing very quickly how to go back is important.

Could you add contextual links to your prototype in non edit mode to make clear we aren't removing them?

If core moved a lot faster, I would happily not be so conservative. These two issues are relatively isolated. The challenges I see are mostly, that toolbar/quickedit/contextual link changes have been notoriously hard :)

tkoleary’s picture

@skaught

stop thinking hover. elements can not be hidden from the beginning. Users forget what things do and how/why they need to. Then forget what they are doing..

In most cases I agree, but I think this is different. Users understand that tactile interfaces where everything is touchable, which is what we are talking about. Putting little lines around everything is both unattractive and an impediment to users seeing the site they are working on "as the user sees it."

It is true that initial discovery needs some aid to the user, but the design has that:

image

IMO: combining Edit and Place Block should not happen. they are separate tasks. and do require different modules to be enabled!

Yes, but which module the functionality comes from should be transparent to the user, and the idea here is not to combine them, but only for them to both leverage the same tray for in-place configuration.

tkoleary’s picture

"back to site pattern", which only has one purpose. We can dual purpose it, but prefer to then have another item on this revamped toolbar that just gives the current location. Usability wise knowing very quickly how to go back is important.

This is a good point, perhaps the edit mode back toggle should be disambiguated from "back to site." There are other common patterns we could use like collapse upward (double up karat like in chrome inspector), or simply close "x" icon.

Could you add contextual links to your prototype in non edit mode to make clear we aren't removing them?

Yes

If core moved a lot faster, I would happily not be so conservative. These two issues are relatively isolated. The challenges I see are mostly, that toolbar/quickedit/contextual link changes have been notoriously hard :)

As regards toolbar this is true, because of the need to know backbone and then internalize the application structure of toolbar as architected by @jessebeach. I think there may be only person who could quickly tackle this, @nod? :)

SKAUGHT’s picture

@tkoleary
thanks for the visual. I see the 'tray' idea now. It is essentially a variation of drop buttons. nice.

backbone:
As a developer I appreciate using/trying other tools. Perhaps it may be more practical to rework back to a drupal.behaviour so that a wider range of 'usual' drupal dev's would be more comfy working with it. *would help speed up the rate of things.

Wim Leers’s picture

It is not necessary to hover. On touch devices, tap will focus on the item tapped. Since links are disabled there is no issue of accidentally tapping a link, and since everything is now a block, everything will be tappable.

This does not work. It means the first tap is focus, the second tap is "start editing". This is super confusing, and not a single site out there (at least that I know of) uses that pattern on touch devices.

How do we deal with the "mobile" pattern where you cant hover to see which parts are editable?

Exactly!

I am a little concerned about the "back" functionality - which now has two purposes. Knowing what page you are on, and going back. This breaks with the current "back to site pattern", which only has one purpose. We can dual purpose it, but prefer to then have another item on this revamped toolbar that just gives the current location. Usability wise knowing very quickly how to go back is important.

+1

It is true that initial discovery needs some aid to the user, but the design has that:

It says Click on any block — but how does a user even know what is a block?

I think there may be only person who could quickly tackle this, @nod? :)

I've worked a lot on that with @jessebeach, so I could do it too, but I have different priorities right now (REST + theme component library).

tkoleary’s picture

@Wim Leers

It says Click on any block — but how does a user even know what is a block?

Good point. We can change to "click on anything", what a "block" is is irrelevant.

This does not work. It means the first tap is focus, the second tap is "start editing". This is super confusing, and not a single site out there (at least that I know of) uses that pattern on touch devices.

I believe it will work, but we should certainly test it to make sure.

How do we deal with the "mobile" pattern where you cant hover to see which parts are editable?

You don't need to see outlines, you can see what's on your page which is what you want to edit. But again we need to test.

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
ipwa’s picture

I also disagree with the premise that we should remove all contextual links from the front-end but I think the work being done here is amazing, good job. I felt really inspired watching the video demo, a lot of great ideas. The possibility of having this in Drupal 8 is so very exciting.

tkoleary’s picture

@ipwa

I also disagree with the premise that we should remove all contextual links from the front-end

I have suggested that the links could still be present when not in "edit" mode. I think that's something we need to explore further.

but I think the work being done here is amazing, good job. I felt really inspired watching the video demo, a lot of great ideas. The possibility of having this in Drupal 8 is so very exciting.

Thanks!

webchick’s picture

Issue tags: +Outside-in
webchick’s picture

Bojhan’s picture

The latest design in the [meta] issue does not fully reflect the discussion here.

  1. We discussed that merging the back to site button, and location is confusing. Links ideally should say where they go to, not the current page they are on.
  2. The pattern for tapping into "editing" is still quite unusual. We did not verify this in testing. Can we reconsider this approach? Wim is clearly adamant and there are other patterns like long-press, or just exposing it when pressing.
  3. The help text needs a little bit of work. I hope we are not gonna list all the blocks you cant configure :) menu's, views, any special block etc.

Other than that this looks really good!

tkoleary’s picture

@bojhan

Thanks!

We discussed that merging the back to site button, and location is confusing. Links ideally should say where they go to, not the current page they are on.

The "required for commit" task is just to have it say "Editing page", adding the page name is a follow-up issue. If users who test the patch don't have a problem understanding the scope of what is editable in this mode we can remove the follow-up.

The pattern for tapping into "editing" is still quite unusual. We did not verify this in testing. Can we reconsider this approach? Wim is clearly adamant and there are other patterns like long-press, or just exposing it when pressing.

This issue did not arise either in my initial hallway testing or the Cheppers test. Having said that we should test on mobile when there is a patch.

The help text needs a little bit of work. I hope we are not gonna list all the blocks you cant configure :) menu's, views, any special block etc.

Can you take a stab at writing a version of it?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

webchick’s picture

Title: Design for triggering view/edit/build modes from the toolbar » Refine/finalize designs for triggering view/edit/build modes from the toolbar

Re-purposing slightly.

xjm’s picture

Title: Refine/finalize designs for triggering view/edit/build modes from the toolbar » Finalize the behavior for triggering view/edit/build modes from the toolbar (and fix the "disappearing toolbar")
Issue summary: View changes
FileSize
5.1 KB
17.01 KB
27.78 KB

When I toggle the "Manage" or "Shortcuts" buttons on the toolbar, their relevant elements are exposed and hidden. I can also just switch to another button by clicking on it.

Manage menu on

Manage menu off

When I toggle Edit mode, the whole toolbar disappears. I cannot toggle directly into a different section; instead I have to figure out how to turn off editing mode to get my toolbar back.

I thought this was a major bug when testing the patch. Apparently it is by design? I'd encourage us to reconsider whether we can just make it behave like other toolbar buttons, because it seems really broken (and was bad user experience at least for this user) for the top-level toolbar I rely on to vanish.

tkoleary’s picture

@xjm

When I toggle Edit mode, the whole toolbar disappears. I cannot toggle directly into a different section; instead I have to figure out how to turn off editing mode to get my toolbar back.

If you look closely at the gif at the top of this issue you can see the feature that solves this, the pencil changes to a left arrow. That was de-scoped for the MVP, but it is still a should have. As for the bar being empty, it is only empty if there is no "in place" module that utilizes it. If you have block place enabled the block place link shows up in the white area, as will other triggers that utilize this mode.

Having the admin menu disabled in this mode is by design since we don't want people navigating away from a page they have changed.

xjm’s picture

Having the admin menu disabled in this mode is by design since we don't want people navigating away from a page they have changed.

You can navigate away from the page anyway by clicking on links on it. Taking away the toolbar seems like an unnecessary punishment of the user. Wouldn't it be better to instead warn the user before they navigate away with unsaved changes?

xjm’s picture

tkoleary’s picture

@xjm

You can navigate away from the page anyway by clicking on links on it. Taking away the toolbar seems like an unnecessary punishment of the user. Wouldn't it be better to instead warn the user before they navigate away with unsaved changes?

This is a very good question question that goes to the long-view of the outside in editing mode. While it is true that in the current patch it feels rather empty at the moment and not having the toolbar takes the experienced Drupal user out of their comfort zone that will not be the case for long.

Very soon we will want to integrate the block place module with outside in, this adds another tab to the edit mode toolbar. Once we do that we need to take into account feedback on the block place designs that necessitates a select for all blocks on the page since some blocks may be put "behind" other page elements by the theme (for example an auto-play video block z-indexed under banner text). Since it covers the whole page, that select would need to be in the edit mode toolbar as well.

Moving on from there as we start to get into questions of block context in outside-in design feedback has also surfaced the fact that we will need a way to "contextualize" the page by "impersonating" a certain role or set of roles. Since this type of impersonation applies to the whole page also it could not be in the off-canvas tray (which by definition is focused on editing selected sub-sections of the page and not contextualizing the whole page) and would IMO also belong in the edit mode toolbar.

What about layout? Blocks and layouts initiative seems to be moving in the direction of a kind of "Panels IPE for core" if that comes about should the trigger for editing layouts in place exist in yet another toolbar (as it does now) or simply be another tab in the edit mode toolbar?

Finally we have quick-edit itself. It seems obvious to me that, ultimately, the experience we are looking for should be one in which clicking into edit mode also presents a toggle to quick edit the node itself, thus unifying all of the "in-place-editing" things in one mode. That toggle would naturally also live in the edit mode toolbar.

Now at that point it's not simply that we have an edit mode toolbar with a bunch of links and an administrative menu with a bunch of links and that's too much stuff on the page for the user to grok, it's that the types of items in each are of two fundamentally different classes. The administrative menu is just that, a menu, it contains links that bring you to other places. The edit mode toolbar on the other hand is not a menu, it is an application toolbar in the true sense of the word. Every button it might contain should perform an action that changes some aspect of the display of the page you are on and if it contains things that are links that bring you elsewhere that can only introduce confusion and ambiguity.

I could be wrong, but we can also look to how users actually interact with this and if not having the menu is a real obstacle or not.

webchick’s picture

Issue tags: +sprint
pwolanin’s picture

I'm having serious front-end caching problems with the code in HEAD. Every time I enter or exit edit mode I have to force reload the browser.

I think we need to add a query string and a page load when you enter the edit mode to avoid Drupal and browser caching issues.

xjm’s picture

SKAUGHT’s picture

mlhess’s picture

Issue tags: +MWDS2016

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tedbow’s picture

Status: Active » Fixed

This issue was about the prototyping iteration which was done before we committed the Settings Tray module. Closing

xjm’s picture

Status: Fixed » Active

Okay, but if that's the case, then we need a new issue, because other issues/feedback threads were closed in favor of this the disappearing toolbar thing is still a WTF. So reopening.

xjm’s picture

Also, as far as I can tell, we still do not have a solution for "configure this one thing here" versus "configure this thing that OH CRAP YOU JUST CHANGED THE WHOLE SITE", which was a must-have from the original issue for a lot of reasons.

tedbow’s picture

@xjm I create an issue for this. #2877088: When in Edit mode Inform the user when they are configuring something that changes more than the current page
It may be could be added the message when the user enters edit mode. But can be discussed further on that issue.

tedbow’s picture

RE #46

Okay, but if that's the case, then we need a new issue, because other issues/feedback threads were closed in favor of this the disappearing toolbar thing is still a WTF. So reopening.

I am not sure remove the items in the toolbar as you outlined in #34 is really a WTF.

I believe when #2773601: Display "You are now in edit mode" prompt when user enters edit mode is in the user will know they are in a different mode and how to get out.
There was also no mention as far as I know that this ever came up in user testing.
Also in the 10 months in has been in core as an experimental module it has also never come up.

Right now this issue is Must Have for Settings Tray module to become stable.
As far as I can tell there are 2 remaining issues

  1. #2877088: When in Edit mode Inform the user when they are configuring something that changes more than the current page
  2. Toolbar UX described in #34

Since #2877088 has it's own issue and #34 has not been reported as an issue by testing or usage I would like to create new issue(not a must have) for #34 and close this issue.

Does that seem ok?

Bojhan’s picture

Status: Active » Fixed

Yes, three issues are filed and those are the primary things still left to do/discuss.

Bojhan’s picture

Status: Fixed » Active

Oops, sorry #34 still needs an issue.

tedbow’s picture

Status: Active » Fixed

Ok. I have created #2889747: Determine if elements should be removed from the toolbar during edit mode. for #34.

Closing as all issues are have been broken out into sub-issues

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.