See http://buytaert.net/spark-update-unified-in-place-editing for more background/video walkthrough (http://www.youtube.com/watch?v=evBpwxWPzPk)

I didn't want to embed that here, because it means only like 100 people could update the issue summary. :)

Problem/Motivation

With the introduction of the "Edit" model we have three competing models for getting to "Edit" something from the front-end, two was already much, three is definitely too much. With the edit inline model we promote the idea of "click near" the place you want to edit something, staying in context.

  • Move more tasks to "in context": All administrative tasks should move closer to the context, overlay was a initial attempt but by bringing controls closer to the content we eliminate more and more the "context loss" that you get as you move into an administrative context (e.g. adding a menu item), you get no preview and with that lose connection with the thing you are editing/creating.
  • Streamline similair patterns: There are contextual gears to edit content, local tabs to edit content, and “Edit mode” to edit content. These patterns all kind of do the same, lets choose one model so the user has a consistent understand where things are.
  • Easy tasks, require deep administrative navigation: Seemingly simple tasks can often result in “pogo-sticking” around in the admin backend trying to locate where to change a given setting.
  • Advanced settings slow users down: Drupal forms tend to be long and full of advanced/confusing options, which can overwhelm users trying to complete simple tasks. We can choose to display only a subset of this configuration.
  • Mobile discover ability : Its very hard to make contextual links, mobile friendly - because in the end you would like to toggle them, since they could obfuscate the screen

Proposed resolution

You can view the prototype for the suggested changes at https://projects.invisionapp.com/share/U2A4IAGX.

Notes on the prototype:
- Hold down the shift ket to see where links are
- Keep in mind that the prototype is just images with hot zones, there’s no actual html so none of the text is editable etc.
- Not everything is linked so you may have to back out of a dead end using your back button.
- If you change something your next click will usually clear out the change you just made. It’s a limitation of this type of prototype.
- The block weight buttons (up-down arrows) can be demoed on the blog block only.
- This is a “Northstar” prototype which means it includes features we would build given unlimited time and resources. We will follow up with an MVP (minimally viable product) design.
- Features included here that will probably *not* be in the MVP include: edit site logo, edit site name, edit main menu, edit user menu (blocked on the blockification of these blocks :) ), preview block edits before publishing, add to a view, place blocks and lock regions (blocked on scotch), automatic modal form validation, and probably a few others.

Remaining tasks

Edit module integration

Contextual links

Simpler form architecture

Simpler overlay display (if we are even going to use overlay)

Block form usability

Block in-place editing

Block conversions, so placement, editing, contextual links work on page items

Menu form usability

There are many others probably not opened yet. Add as found/opened.

User interface changes

See prototype.

CommentFileSizeAuthor
#85 Spark-project-node-promote-form-elements.jpg38.73 KBLars Bo Jensen
#75 unified-edit-prototype-demo-75.patch60.61 KBGábor Hojtsy
#68 unified-edit-prototype-demo-68.patch40.79 KBGábor Hojtsy
#67 Screen Shot 2013-02-07 at 11.34.26.png85.03 KBWim Leers
#67 Screen Shot 2013-02-07 at 11.34.32.png75.2 KBWim Leers
#65 Edit-image-to-multi-value.png193.77 KByoroy
#65 Edit-image.png248.47 KByoroy
#65 edit-footer-blocks.png13.16 KByoroy
#65 Edit-pencil-icons-z-index.png83.98 KByoroy
#63 unified-edit-prototype-demo-63-do-not-test.patch31.75 KBjessebeach
#45 unified-edit-prototype-demo-45.patch56.93 KBjessebeach
#45 interdiff_40-45.txt6.47 KBjessebeach
#40 unified-edit-prototype-demo-40.patch51.8 KBGábor Hojtsy
#39 unified-edit-prototype-demo-39.patch28.97 KBGábor Hojtsy
#37 unified-edit-prototype-demo-37.patch27.93 KBGábor Hojtsy
#34 unified-edit-prototype-demo-34.patch30.75 KBGábor Hojtsy
#34 EditMenu-1.png50.32 KBGábor Hojtsy
#34 AddMenuItem-1.png38.6 KBGábor Hojtsy
#30 unified-edit-prototype-demo-30.patch29.71 KBGábor Hojtsy
#29 unified-edit-prototype-demo-29.patch29.49 KBGábor Hojtsy
#29 EditingBlock.png76.11 KBGábor Hojtsy
#29 AddMenuItem.png72.95 KBGábor Hojtsy
#21 the-top-edit-bar.png232.72 KBBojhan
#21 horizontal-orientation-does-not-scale.png103.7 KBBojhan
#21 edit-as-vertical-menu.png158.88 KBBojhan
#21 move-buttons.png81.35 KBBojhan
#21 blocks-publish.png162.98 KBBojhan
#21 modal-adding-menu-item.png153.55 KBBojhan
#8 AddMenuLinkSimpler.png71.09 KBGábor Hojtsy
#8 AddMenuLink.png98.84 KBGábor Hojtsy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Issue summary: View changes

Updated issue summary.

webchick’s picture

Issue tags: +Usability

Oops. Sorry, I created this in a hurry. :)

webchick’s picture

Title: Unify editing approaches in Drupal » [meta] Unify editing approaches in Drupal

One more.

webchick’s picture

Issue summary: View changes

Updated issue summary.

webchick’s picture

Thanks to some truly epic acrobatics by Dries, http://buytaert.net/spark-update-unified-in-place-editing was posted *just* in time for UX office hours today, so I was able to present it to the UX team (Kevin unfortunately couldn't make it).

Initial feedback from the UX team (specifically Bojhan) was along the lines of:

1) What happens to local tasks (tabs)? Will some but not all get moved to contextual links? Will we remove them altogether? If so, what happens on the back-end forms? e.g. how would I get to editing fields from editing a content type?

2) While this "toggle on editing mode" pattern seems to make a lot of sense for touch devices, it tends to make less sense for desktops. One nice thing about contextual links is they show up right on the thing you're trying to edit on hover. Obviously, mobile devices can't do hover, but that's not a good reason to degrade the desktop experience.

3) The "reduced form" pattern makes good sense on something like the blocks / menus forms where most of it is cruft that you don't set in 90% of cases. But there are a lot of other cases ("panels" "polls", "slideshows") where either everything on that form is important to someone, or there's no real clear way to distinguish between the two. It'd be helpful to have a few more examples of this pattern, specifically from contrib.

4) "Show more options" is a lot like collapsed fieldsets, and from testing we know that people always click those to see what's in there.

5) Not sure if the "Edit mode" toggle is discoverable enough (at least on a desktop).

6) The arrows are a weird way of moving blocks up and down (esp. since you also move blocks left/right/diagonal)… it wasn't clear what those were for.

Bojhan's going to attempt to post a longer/more detailed review later this week.

Bojhan’s picture

Yup, I will try to do a full review., a few short additions.

2) We can do both, allow on the desktop for hover to trigger the "edit" button. But also have a switch, if you want to see all the "edit" buttons, and have it consistent with the mobile experience.

3/4) Should we split this conversation off to http://drupal.org/node/1880168 ?

5) I wonder how this tested, I had to point a lot of people to where the "Edit mode" toggle was. The new model of using the pen on the far right, is already a lot better - if its not mixed in with main menu, I think that will solve a lot.

6) That definitely wasn't clear, I thought it would be a way to see more contextual actions.

effulgentsia’s picture

Related to #3.1, what if I'm on a node page (like node/1), and want to edit something that's not currently visible (e.g., an optional field that is currently empty or a non-displayed field like the date on which I want the node to become published (assuming I'm using a workflow module that supports that): how would I do that?

tkoleary’s picture

@webchick @bojhan

Apologies again for missing the office hours today. Here's some answers to the above points:

"1) What happens to local tasks..."

I think the answer to this is that all the local task tabs on site pages get moved into the contextual links and the ones on admin pages remain.

"2) While this "toggle on editing mode" pattern seems to make a lot of sense for touch devices..."

Kind of the same thing that came up in toolbar. Yes we can have hover on desktops, but IMO it should be secondary and engineering it should not impede engineering the touch model. You only have to walk into any Best buy to see that the new normal is a full size touch screen with a keyboard. The mouse will soon be as obsolete as the rotary phone.

"3) The "reduced form" pattern makes good sense on something like the blocks / menus forms where most of it is cruft that you don't set in 90% of cases. But there are a lot of other cases ("panels" "polls", "slideshows") ..."

Sure, this is a complicated area, and we have already pretty much determined that it might be impossible to have a programmatic solution for it. That leaves us (and module devs) to do the categorization on a form-by-form basis. However, the fact that everything on a form might be important to someone does not equate to "everything on a form is of equal importance". Progressive disclosure requires that we make smart test-data-driven decisions about the hierarchy of information and present the user first with only the essential tools 80% of users would need need to complete a task, providing more detailed options on request as they need them.

This is no less true in a complex UI like views, in fact it's even more important for complicated interaction patterns because there is more room for confusion.

"4) "Show more options" is a lot like collapsed fieldsets..."

I've heard that. That did not happen in the tests that we did, if it did, though that would be a clue to me that something critical to the task the user was asked to do was missing from the top of the form.

"5) Not sure if the "Edit mode" toggle is discoverable..."

Users found it easily on iPad. We haven't tested on desktop yet.

"6) The arrows are a weird way of moving blocks up and down..."

That has not been tested yet. If it tests poorly we may need to alter the affordances.

@effulgentsia

The link to full node edit is the "configure" link in the bar below the toolbar on the right. That my not be discoverable, or clear enough. It is a new addition that has not been tested yet.

hass’s picture

Usability wise and personally I can say it took me an unacceptable long time (5-10min) to find the Edit button when I tried the Aloha editor for the very first time (desktop) some months ago. My first idea was that something is not configured correctly and that this is the reason why I'm not able to enable the edit mode. I expected an double click on the content would enable editing. The way - how Aloha works on the Aloha website.

This Editor button is placed in a position that nobody expects. Without having the video intros seen it's a clear usability fail to me.

hass’s picture

Issue summary: View changes

cleaned it up, less about contextual links, more about inline editing pluses

Gábor Hojtsy’s picture

FileSize
98.84 KB
71.09 KB

There are many many details to these designs and I'd like to call attention to some fundamentals:

1. This design brings together (unifies) several different interactions. The "edit" module interaction of true in-place field editing, where if you click on a pencil, it actually edits right there. The title and body are implemented on the design. If there is extra information needed (such as when adding a link or inserting an image), a popup will be displayed, but the editing itself is in-place. When the edits are saved, the page is not reloaded. This conveniently ignores the fact that the edit might have effect on other things on the page, such as if you edit he node title and it shows on the sidebar in a view, that will not reflect the change until you reload the page. This is done to ease editing, especially to make many successive edits easy.

2. Many things on the page are not nodes/entities with fields, so those are not in-place editable. Eg. if the page is a view, the title comes from the view and may even be dynamic based on a token / argument. There is no in-place editing for this case. I'm not sure this is very intuitive to the user, especially that we give the same entry-pencil to start editing. For a views originated page title, contextual editing option buttons and then a modal would show up instead of actual in-place editing right away.

3. The designed model is appealing for various ways: it is much cleaner than the overlay because it does not want to support tabs, or adding stuff to shortcuts, it moves the title in the modal and gets rid of the close "attachment" at the top in favor of cancel buttons on forms. It also moves buttons to the right, which is a minor detail we should not delve into here, but it allows the form expansion link to be more visible. As-is in #1880168: Introduce top-level sections for all forms that link is very obscure.

Compare current menu link addition (tabs, shortcut support, close button, form field sizes, etc):
AddMenuLink.png

To proposed design:
AddMenuLinkSimpler.png

4. There are also many simplifications in the form itself, the layout of elements is much more compact (custom form layouts like that are not common in core so far). It also hides all form elements descriptions and provides an "action link" to click to access one of the lesser used elements (to add a menu item description for example in this one). The form elements are bigger too, the are close to the size of the buttons, which is not like current forms in Drupal. Some of these are possibly sweeping changes but mostly one-by-one on forms.

5. The behaviour of the modals is not 100% clear yet. Although #1880168: Introduce top-level sections for all forms uses the overlay straight, that means easier to implement form flows, validation handling, AJAX form elements, etc. However, it also means the underlying page will reload when the overlay is done, to reflect the changes made. This is *technically* more correct if the action had wider effects (see point 1) but is not in line with in-place editing expectations set up in (1) and is harder to make quick edits. If we'd attempt to implement a full form handler system in modals, that would AFAIK take considerable client power to essentially implement form flow, validation feedback, etc. Also, if we don't do a full form reload, we need partial page rendering, which is an eventual goal of both WSCCI and blocks and layouts but they are not close there yet. We'd need to implement block rendering in the context needed for example (given the path, roles, etc. all of the conditions that might vary the block).

6. For form simplicity, the design does not make it clear if the form expands to show all elements or goes to a more complete form in the admin area if the link is clicked on the bottom. Going out of the page would invalidate all in-progress unsaved edits (although that already happens if we use the overlay), showing the form elements inline would make the popup look pretty much as now with the top of the form simplified only. We have been discussing using separate forms or trying to augment existing forms to serve both "simple" and "complex" needs. We did not believe having separate forms for different needs would work and that it would be easy to generate a simpler form with the elements only needed for the simple form, so we came up with the augmentation solution (see #1880168: Introduce top-level sections for all forms). It also keeps crucial validation-required elements in the form even if they are not immediately displayed. I have also observed people clicking on all "additional elements" links in user tests (for multilingual), so don't necessarily agree with @tkoleary that we can say it is negligible.

This is the kind of huge discussions where one wishes we could be in the same room discussing it, because there are so many angles and things to figure out where quick decisions would be key to progress fast enough. The timing does not fit with that very well.

Gábor Hojtsy’s picture

BTW discussed most of the above with @Bojhan and @frega on #drupal-usability in IRC.

Bojhan’s picture

Just a quick note, on these comments;

3) Keep in mind these are nice ideas, but will need more research if its actually possible. Because I dont fancy the idea of introducing 3 types of modal/overlay styles, one inline modal, one normal modal, one overlay. It is only much cleaner because it plain out removes loads of stuff, the question is when the 80% usecase requires more forms/tabs how it handles it then.

4) Again, nice ideas but will need more research. Because we can't have custom form styles for each setting, that goes against the idea of modular design and will create a mess in contrib land where everyone styles their "small" form differently.

I share your concern that the timeline does not accomodate the bread of research this change requires. The concerns in 5) are even more worrisome, as it sounds like quite an engineering effort. With the still unclear usability gains, beyond a small few - I think we should clearly examine the added value of this effort

hass’s picture

I like the inline editing, but I wonder how this works with Workbench Moderation modules. What I'm writing is not the published version... it may be a draft or needs review first. What is the visual plan about this?

tkoleary’s picture

@hass

Interesting. I agree that the former position of the edit tab was confusing which is why we set it apart from the tabs. We did not see that much difficulty finding edit mode in the testing we have done since then. Have you tried the new prototype? Do you find it more intuitive?

Also, on your comment about Aloha, I felt exactly the same way when we began working on how this should work for touch devices and our first designs went in just that direction. What we quickly found though, is that disentangling the experience of "I want to edit this thing" from "I want to browse my site" becomes very complicated both from a usability and implementation perspective. The task is amplified greatly when you consider that this has to work for any kind of site that can be built on Drupal. That's why we moved to the "edit mode" solution.

tkoleary’s picture

@hass

Re: "wonder how this works with Workbench Moderation modules."

That's a complicated problem we have only scratched the surface of thus far. When editing fields in the node the module can display other types of submits like "save draft for review" etc. The issue becomes much more complex when we consider other blocks on the page and the layout. Currently plugin blocks can have instances with unique titles and visibility settings, which would allow them to be placed only on the unpublished node/s that are in the revision queue, however, they can't yet have unique content. I think that is the key blocker to completing the user story "I want to have unpublished pages in a workflow that contain draft content, layout and blocks"

tkoleary’s picture

@Bojhan

As usual Gabor has gone into considerable detail and clarified many of the issues that I kind of hand waved :). On your points though I think there's some confusion about what we actually envision. What we are hoping for is not multiple solutions for modals/overlay but one unified solution. The way forward to implementing this is by evolving the current overlay into our unified modal.

What the design in the prototype does not yet reflect is that the entire form will still be present in the modal and it will be the same form that the user sees in admin pages (enhancements to the forms in the designs in all cases should be assumed to be implemented in both places). The difference is that the user will be contextually presented with only the 80% use case fields needed to complete the task and the others will be collapsed in fieldsets. This simplifies implementation greatly because essentially the only difference between this and overlay is presentation. Of course it also requires that we make the forms more usable but we really need to do that anyway.

Just to clarify, in the design above where it currently says "edit main menu" it should say "more options" with an arrow indicating a collapsed fieldset which would open to reveal weight, parent, etc.

Does this cover all of your questions?

tkoleary’s picture

@Gabor "on all "additional elements" links in user tests (for multilingual), so don't necessarily agree with @tkoleary that we can say it is negligible."

No, your'e right, it's not negligible but I think the effect can be alleviated by carefully considering if the top level fields cover the 80% use case and if the collapsed set label is carefully written to both a) explicitly state that the enclosed fields are not required and b) describe the contents so that the user is more likely to make a decision without expanding the set.

In this case the label might read:

"Optional link settings".

Alternately we could just summarize them but that might not scale well. In this case that could (with some nomenclature simplification) give us something like:

"Optional fields: (Disable, Expand, Set parent, Set weight):

Which is really not too bad.

webchick’s picture

webchick’s picture

Issue summary: View changes

Update list of issues

Gábor Hojtsy’s picture

Issue summary: View changes

Add block issues.

Gábor Hojtsy’s picture

Issue summary: View changes

Add menu items issue

Gábor Hojtsy’s picture

Issue summary: View changes

Added more blocks related things.

dasjo’s picture

just saw the video and wanted to give some feedback.

i like the idea of unifying the edit experience. as stated, not every action (creating, editing non-node-content, editing non-visibile content, ...) will be possible in-place, so a clear path to supporting both ways is needed from my perspective.

visually, i found the big amount of icons quite disturbing, but i understand that when using touch you want to display them all. i'd like to propose an idea of alternatively allowing for the touch "press" interaction on an editable area to reveal the options. this especially ties the interaction more to the content and allows the (capable, in terms of touch-enabled) user to skip clicking the edit link in the toolbar above.

also, i found it disturbing to see the content being moved a little down when enabling edit mode from the toolbar. this might be necessary to show relevant information, but well, for in-place editing i'd love to see a consistent ui without things being moved around, if possible :)

you might also want to account for cases, where multiple, configurable elements overlap in a manner, such that contextual links (in your proposal the static icons) aren't reachable because of overlap. this happens to me often, when for example a panel contains a views contains a node etc...

finally i wanted to share some links to inline editing in the plone cms. they have had in-place editing for quite some time now. since plone 3.3+ they have made it optional. one motivation seems to have been

what you really want is a quick option to go to a full edit-mode. Editing a single field is a much less common operation than we were expecting

http://plone.org/documentation/manual/plone-4-user-manual/managing-conte...
http://plone.org/products/plone/roadmap/238

Wim Leers’s picture

#8.5:

[…] uses the overlay straight, that means easier to implement form flows, validation handling, AJAX form elements, etc.

Either I'm missing or something, or this is wrong. If you use the Edit module to edit e.g. tags with the "taxonomy_term_autocomplete" Field API widget, then you also get a fully AJAXified form, that works completely, without any special stuff happening; it's just using Drupal's long-existing AJAXified form API.

However, it also means the underlying page will reload when the overlay is done, to reflect the changes made […]

Only if something *new* would appear on the page or it would appear in a previously non-existing region, then this would be a problem AFAICT?

#17:

also, i found it disturbing to see the content being moved a little down when enabling edit mode from the toolbar. this might be necessary to show relevant information, but well, for in-place editing i'd love to see a consistent ui without things being moved around, if possible :)

Is this in the demo video or in Drupal 8? Enabling Edit mode in Drupal 8 should not anything even a pixel around, we went through great pains to ensure that is the case. It's definitely not moving anything around for me in Drupal 8.

RE: Plone: their implementation was borked — see http://bergie.iki.fi/blog/inline-editing-done-right/.

dasjo’s picture

at #18: i was referring to the whole site being moved down in the video, see http://www.youtube.com/watch?feature=player_detailpage&v=evBpwxWPzPk#t=141s

dasjo’s picture

Re Plone: i still find that quote to be appropriate

what you really want is a quick option to go to a full edit-mode. Editing a single field is a much less common operation than we were expecting

but i guess this needs further testing to figure how users get their tasks done most effectively

Bojhan’s picture

Thanks Kevin, Webchick & Gabor for this effort.

Looks like I am the first one to give this a more in-depth review (we need more!). I was quite excited to see the groundwork for this, I felt like the the earlier ideas were not really there yet in terms of interaction. This is a rather quick review, since it seems like I need to get this out before a meeting on this topic. I've started my review at the top of the page :)

1) In the previous designs I understood, why we needed this - in the current design its not clear to me. The "add block" in the front-end I was previously denied, because its too hard to implement. Is it a possibility now? I really like that we moved to "one edit button on the right" to rule em all, the whole intertwining with the navigation links was too much.

2) For contextual links we tried all kind of orientations, and we ended with the vertical one simply because it scales better and is easier to scan, opposed to horizontal which has different kind of widths (which has some impact on ability to easily hit things) and alignment. I am tempted to think, that this horizontal idea is nice - on the surface, but if you dive deeper into what it means it will end up biting us.

Me and Kevin explored the horizontal idea, a little on IRC - and he suggested that the "Edit" button on for example a block that exposes a view, goes straight to editing the View - and then on that modal you have a tab, to go to "Edit block". This sounds still do-able, but we have contextual links that often expose 4/5 links - we now have to move that into either deeper levels on the modal, or merge forms together. Both which sound like hairy undertakings, and not ideal for larger websites.

Just an idea;

Not necessarily trying to hold to the vertical idea, but it just scales much better. I do agree for the "WYSIWYG Edit" of WimLeers you would want a horizontal bar - but we still can. Since its part of the WYSIWYG interaction, it will be a natural shift and accommodation of the WYSIWYG.

Another thing, and I think we already reached some agreement; on the desktop you totally want to just hover a block, and be able to click the pen. The pen on the top right in the toolbar, then exposes all - so on your mobile phone you can just trigger that. That way its both fast on the desktop, and consistent/usable across platforms.

3) Can we just go with the "Move" action, instead of also having those up/down buttons. I think that outside of Brochure websites, the act of moving a block up and down will not be done too often - at least not by content creators. So we probably don't have to duplicate the functionality - its common, but not 80% common.

4) The idea looks really nice. I think we might want to consider if its really MVP though, and if not remove it from this proposal. Because this is what makes/breaks on larger sites in the "Introduce Edit module" issue, we did not tackle the workflow problem and frankly the problem remains and I haven't seen anyone actively working on it. So I am not confident, we get preview + workflow figured out in a few weeks.

5) The idea of showing people a small form, and getting them right back to the thing they are editing - is exactly why we introduced the Overlay. It seems that is what you want to do here, but just show a smaller overlay/modal (so you lose less context) and hide some of the functionality (simplifying the activity). I am fond of the first idea, I am extremely worried about the second and would consider it a won't fix, not because the idea is bad but because the implications are huge and we have little time and idea how to tackle it properly.

As contrib add functionality to Drupal core, it often ends up throughout forms, as custom sites get made they often have different end-goals for particularly things like menu's. For example "add link" in a deep hierarchy would have to expose the structure or you couldn't make sense of where its added - whereas in a Brochure like website, as shown in the prototype you don't need that. I am worried we are assuming how easy this process will be, and we do not have good way to tackle it - #1880168: Introduce top-level sections for all forms for example, implements custom block and makes the wrong assumption that for editing a custom block, the 80% case does not include editing the body - while from my point of view it clearly does.

Others should chime in on this one, but I don't think this fits the modular nature, and audience of Drupal. We cannot expect them to customize all of these experiences. "Show all" is nice, but users always click that when a form is as small as this - so I don't even know if the gain, is much more than an initial one, and largely aesthetic.

Conclusion
I think the main thing we should do, is come to an MVP - because for feature complete phase, we shouldn't really be discussing north start designs. Looking forward to continuing this process.

webchick’s picture

Status: Active » Needs review

Thanks for the review! Generally agreed on most of that feedback (the second toolbar at the top is challenging, horizontal orientation of contextual links is challenging, up/down + move doesn't really make sense, etc.) Also, marking needs review to hopefully get some more reviewers, even though this is "concept" and not a patch yet.

Responding to a couple of things, though...

Block drafts: #1871772: Convert custom blocks to content entities might actually get us somewhat the way there. It effectively turns custom blocks into "almost" nodes (content entities) with revisions, fields, etc. Though as xjm pointed out in IRC, some aspects of nodes (ex: previews, "published" status) are still node-specific, though others such as revisions are available to all content entities. It's definitely not part of the MVP though, agreed, but the general idea that if people get draft mode articles, they're going to expect it for other things they perceive as "content" I think makes it something worth pondering about for later implementation to make sure we're consistent (it's a release-blocker, so we're not currently prioritizing it until after feature freeze).

I don't really understand the strong negative reaction to showing the reduced form, and perhaps it stems from misperception of implementation details. So let me get into that a bit.

IF this were implemented in such a way that every module had to define and expose two forms: one for "simplified" mode and one for "full" mode, with duplicate validate/submit functions, etc. then I agree this would be a total disaster, and no one would ever do it. However, that's not the plan.

The plan is to make both of these forms exactly the same form, identify the "80% fields" with a Form API property, and then use client-side code to show/hide the extra fields that don't have that property when the simplified version is rendered. This way, if you're a contrib module, and you decide to insert a "search thesaurus" button right after the path lookup on the menu screen, you'd do that exactly once, and it would work consistently on both the front-end and back-end form without any extra work. You just have to make sure that your field is in the same group as the other fields marked "80%" but that's no different than making forms now.

It's true that we do need to evaluate forms on a case-per-case basis on what's the "80%" for them (and in some cases such as the "site information" form, the answer can/will vary depending on what you're doing), however identifying those fields on each form we want to expose via contextual links is only going to help clean up/split up the back-end forms and make them more coherent and approachable. So it's win/win, and it's also work that we can do up until RC1 (or maybe code freeze if you want to be very conservative), since it's simply re-formatting what's already there.

One thing I am a little worried about is the inconsistent behaviour of "I clicked that thing and now I can edit it immediately" (e.g. node fields, possibly also custom blocks once #1871772: Convert custom blocks to content entities makes it in) and "I clicked that thing and now I see a list of things I could do." However, I think that's relatively learnable after awhile; we can find out w/ testing.

I also don't understand the strong opinions around the fact that people can/do expand things to see what all is under them. Well, yes. :) It is not the job of Drupal's user interface to stifle the innate curiosity of human kind. :D The key factor is that as a user you will do that exploration once (or maybe a few times), but then once you've learned what's under there, you leave the section collapsed from then on because don't need to worry about it again. And from then on, every task you re-complete is much faster than before because it's without all the extra visual noise. I really think showing less on forms is a critical UX component of this design: it's taking "contextuality" all the way to the form level, helping users to better-target their actions more specifically without being overwhelmed. (As you know, you can just watch the eyeball scanner in any UX video to see how much of a problem this "too many options" situation is currently.)

Bojhan’s picture

@webchick Gábor did explain it to me earlier today, so the implementation is not a surprise. I am not necessarily against it, I just think it needs a lot more investigation before we all shout "yay!", because beyond the technical implementation I see little scenarios on how this impacts the UX. Sure contribs can interject and people can form_alter there way into making this more sensible for their usecase. But I don't want Drupal to be a system, where we just hide everything behind buttons - to make it appear cleaner and then upon clicking a river of stuff comes down. Solving the problem, would be to apply more visual hierarchy so it isn't like a river of fields/checkboxes with that drastically reducing the eyeballing around + adding progressive disclosure like proposed here.

I don't really get the whole front-end/back-end distinction, when you click edit - you get the back-end in a overlay/modal. If your agenda is to remove the overlay through this issue, please say so. If not, to me the most logical way is when you click edit you get an overlay/modal (arguably smaller, without the darkening) but you do land in the back-end form. That way we are not creating two entry points/view points, and we educate the user as to where something is, and you always get to that thing no matter where you enter from.

webchick’s picture

No, my agenda is when I want to add a menu link, I want to add a menu link in the simplest way possible. I don't want to add a menu link, configure its parents, specify a weight, etc. Fine to show me all of that stuff when I'm in an administrative context (I'm setting up my menu, let me customize it carefully), but when I'm browsing the site and want to make a quick tweak to something, I want that tweak to be just that: quick. :)

tkoleary’s picture

@Bojhan For my part I think I've been pretty open that I think our ultimate goal in this issue should be a synthesis of overlay and all other modals. The proliferation of different approaches, implementations and styles in contrib right now is a mess that we need to make an effort to clean up for D8.

Gábor Hojtsy’s picture

On publication status: live/draft, etc. The most challanging thing there is that when you create a menu block for example, you create menu items, reorganize exiting menu items, you might rename the menu, etc. So the extent of the change is way beyond the block itself, it spans several things in the menu. So while we could get much closer to draft/live blocks for custom blocks, for more complex blocks where the underlying data is at different parts of the system, I don't think so... So that said, it is not really part of our MVP for blocks for now.

On smaller forms, #1880168: Introduce top-level sections for all forms does consider it part of the 80% to show the block body for custom forms, I demonstrated that with a screenshot there, so I think there is som misunderstanding there on Bojhan's part. Also that is currently implemented with two markers in the form, and elements within those markers are considered part of the 20% and not shown initially. It is not per element because it can be any kind of widget or even an expanding set of elements with process callbacks. Nobody commented on the technical solutions yet, and it can surely be done better technically as well.

As for getting rid of overlay or not, technically overlay seems to be the best tool we can implement this with for various reasons at the moment, however that is one of the open questions on whether we should use the new modals (no iframe, more JS) or the overlay (iframe, easier theme control, natural browsing history, etc).

tkoleary’s picture

@Bojhan Point by point here are my thoughts on your review. Mostly in line with webchick and Gabor.

  • Re: the page title at top left "multiple articles on the page"
  • This design assumes the page library so for a landing page (multiple nodes) you would see that landing page's name, not the name of one node.
  • Re: the top bar and adding blocks near a region.
  • This is a real issue. My inclination is to put a dropdown arrow next to the edit toggle to contain: the full node edit link, a page (or layout) edit link and a "place blocks" link. That would solve the vertical space issue you bring up but may also be less discoverable. I will prototype and have Dharmesh test it. On placing blocks near the region, one possible solution would be to put "add another block to this region" in the block contextual links. This avoids the unappealing thought of adding a pencil icon to every region which would be messy.
  • Re: Horizontal orientation.
  • Exploring Lewis Nyman's device controls idea for this.
  • Re: Up-down move buttons.
  • I am re-designing that whole interaction.
  • Re: Publish blocks.
  • We are kicking that discussion down the road.
  • Re: Optional fields summary.
  • I believe Gabor addressed this cogently.
Gábor Hojtsy’s picture

Posted a simplified overlay proof of concept at #1889150: Simplify overlay look, *only use for contextual operations*.

Gábor Hojtsy’s picture

Issue summary: View changes

Updated issue summary.

Gábor Hojtsy’s picture

Issue summary: View changes

Add overlay issue

Gábor Hojtsy’s picture

Here is a merged patch from the latest ones on #1889150: Simplify overlay look, *only use for contextual operations*, #1880168: Introduce top-level sections for all forms and #663946: Merge "List links" page into "Edit menu" page. Using this the overlay should only open on contextual links, all links in the overlay would lead out of the overlay and the block and menu item addition forms would appear simplified (with less used items hidden). Also, the menu editing and item reodering pages would appear as one. That is the combined effect of the 3 patches. (They did apply to my environment after each other with little fuzz in one place).

Editing a block:
EditingBlock.png

Adding a menu item:
AddMenuItem.png

Please DO NOT REVIEW this patch, review the individual patches in the listed issues. This patch is merely rolled for demonstrational purposes.

Gábor Hojtsy’s picture

Updated unified patch based on changes in underlying patches.

Status: Needs review » Needs work
Issue tags: -Usability, -Spark

The last submitted patch, unified-edit-prototype-demo-30.patch, failed testing.

andypost’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +Usability, +Spark

The last submitted patch, unified-edit-prototype-demo-30.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Remove blocks name discussion.

Gábor Hojtsy’s picture

Bojhan’s picture

Can we already push on with all the parts that we did agree on? It seems like the simplify contextual administration screens is something that has already been split of, all the other improvements we discussed 2 weeks ago - can go into core nowish

Gábor Hojtsy’s picture

@Bojhan: yeah #1893740: Remove repeated "Block" UI text from block editing, fix title landed. #663946: Merge "List links" page into "Edit menu" page is almost as good as it can get now. We need to move the action links as per your proposal I guess and we need to agree on the code solution to the problem. The other two are highly debated. :) Do you mean other things that we agreed on but we don't have issues or we do have issues but not focusing enough?

Gábor Hojtsy’s picture

Rerolled compound patch based on #1880168: Introduce top-level sections for all forms needing a reroll (given #1893740: Remove repeated "Block" UI text from block editing, fix title got committed, that is obviously not included in the patch anymore). No other changes whatsoever.

eigentor’s picture

One thing that would be a great benefit even without all the inline editing stuff is simplifying important forms (like editing menu links).
Identifying the 80% tasks and hide the rest in a "More options" "Advanced options" or whatever solves a lot of problems.
Even if some stuff should be mistakenly but inside the collapsible and turns out to be mor commonly needed, it is still in the form and can be discovered. Taking the risk of getting some of those wrong is vastly outweighed by the chance of simplifying the forms and thus probably helping 80% of the users.

There is lots of places this can be applied. As it makes sense even without inline editing maybe we should try to collect the forms that could be simplified like this, so it can be worked on seperately.

Gábor Hojtsy’s picture

Rerolling with the latest patches from issues (with a minor adjustment to make the add link action show up):

- #1889150: Simplify overlay look, *only use for contextual operations*
- #1880168: Introduce top-level sections for all forms
- #663946: Merge "List links" page into "Edit menu" page

It works almost the same as posted in #34, but the menu edit page has an "add link" action between the list and the menu details, like this (backend screenshot):

Gábor Hojtsy’s picture

This compound patch also includes #1898020: Proof of concept for unified edit pencils although that one is still a bit buggy and only for demonstration purposes.

jessebeach’s picture

I put together a demo of the patch in #40.

http://edit.qemistry.us/

user: tester
password: tester

aspilicious’s picture

The prototype totaly confuses me, so it's hard to review it.

- Sometimes when I click the pencil it works, sometimes it shows the menu for a sec.
- The overlay screens are way to narrow on high resolutions desktop devices resulting in lots of toolbars.
- With this approach I can't explain to my clients when they are inline editing or when they are editing in the backend. Because it all looks the same. Why provide a button to edit the entire node if you can do the same on field level? When I want to edit the full node I would like to see a full overview of my content and fields, not a small window with all the fields pushed into it.

Don't get me wrong. I agree with the original concerns that we should have a unified editing approach but this prototype doesn't improve the situation in my eyes YET. ;)

Couple of suggestions:
- When editing entire nodes go to a backend page (no overlay's or modals)
- When editing fields, make sure the modals make more use of the available screensize. Body fields can use a lot more space on my computer. Would eliminate some of the scrollbars.
- Try to eliminate the toggle in the toolbar somehow. I always wonder in what kinda edit mode I'm in.
- What ever we choose we should try to come with a solution where the scrolling of the entire page isn't so disturbing. I think that scrollbars inside the modals make more sense. I'm not sure that is possible with the current overlay.
- Not really a suggestion but we should think about a way to make a distinction between editing an entire node and editing a field. I'm trying to think of a solution but I can't find any at the moment...

eigentor’s picture

@jessebeach thanks for the demo
So great using a smparthone and actually being able to edit stuff in Drupal :)
Testing that raises a question (that may have been mentioned in this issue somewhere before).

If the edit mode is something that is introduced as a very basic thing that every user of Drupal should learn:
It would make sense to completely hide Contextual links then.
It is confusing in the demo that there are pencil icons for contextual links, and even more pencil icons (that behave differently) appear when you toggle the edit mode.

Pencil icons should appear only when edit mode is on. And, of course, they should all behave the same. The old contextual links that just lead to the regular edit form for things are still a nice thing, probably we do not want to throw them away. If they are meant to be kept alongside the "true" in-place-editing, they must look different. So in that case I'd be in favor of keeping the gear icon.
It is not very probable to impossible to make everything editable in-place (like if it is a teaser and you would have to edit the node to change it).
For blocks, though, it might work.

Gábor Hojtsy’s picture

@aspilicious: interesting observations. I've reproduced the same bugs with the pencils (flicker, etc), those are temporary. As for the more fundamental questions:

1. We need some way to go to full edit mode for the node. That should indeed open the backend (not in modal/overlay) IMHO, but it would equally be disconcerting that some contextual links open in a modal, while the edit would not. We need a way to go to edit the full node for adding not-yet present fields, edit non-visible data, etc. This used to be on the design as "Quick edit" and "Edit" separated, where quick edit was the current edit mode.

2. As for eliminating the edit option in the toolbar, we added it especially so hovering the site around your mouse would not be a jarring experience of big pencils popping up all the time. As more of the things on the page are content entities (think menu items, custom blocks, nodes, etc), they'll have field displays which are directly editable and block wrappers which have contextual edit options. Even more potential pencils than what we have now. The edit option in the toolbar brings you into this mode where you are not just browsing your site but editing. I personally would hate keeping a personal account on the site for looking at it and an admin account for administering. It is also fundamental for touch, because there is no "hover" on touch.

@eigentor:

I agree the contextual links should be governed by the edit mode fully, no hover show-up like it does now. It is very inconsistent. I also agree the different behaviours for the menu pencils and the real in-place edit pencils is confusing. The triggering goal for this issue from the start however is to bring these two under the same umbrella. So there are things you cannot edit in-place (eg. how many comments are displayed in a recent comments block), but we can provide quick avenues for you. I personally agree the use of the same pencil icon is confusing and brought this up before. Hope some user testing will help us figure out what actual users perceive of this.

jessebeach’s picture

This patch attempts to respond to tkoleary's requests to modify the code for UX testing. Here are his comments:

  1. Viewing node "this is an aaaarticle" edit toggle is not in toolbar. Shouldn't this work on all nodes?
  2. On "home" hover is enabled on pencils (and there is a quick flash of blue outlines) for teasers (not bocks) but clicking them doesn't do anything
  3. Pencil dropdown on blocks also sits above overlay when it loads
  4. Pencils z-index puts them above overlay
  5. Pencils for fields other than the one being edited sit above field being edited when it is in focus.
  6. Edit toggled on should not show outlines on fields or blocks (only on hover)
  7. For the purposes of this test display:none the local task tabs
  8. Overlay bg png is too dark (this is a design change from core but I think it will help the test.) New png attached.
  9. In the pencil dropdown a:hover should be color:#fff

The one thing I was not able to do is fix the z-indexing issues. I just can't seem to get the correct layering given the current structure. We may need to revisit how elements are layered if the approach proves felicitous.

@eigentor and @aspilicious, I fixed the flickering contextual menus. There was an issue with setTimeout and a little loop that caused the menus to dismiss as soon as they were opened.

I'll update the demo site after I post this patch.

Gábor Hojtsy’s picture

@jessebeach: please post patch updates in the underlying issues. This META issue is meant to **aggregate** the patches merely for easier testing - not to work on them. The list of issues with actual patches:

- #1889150: Simplify overlay look, *only use for contextual operations*
- #1880168: Introduce top-level sections for all forms
- #663946: Merge "List links" page into "Edit menu" page
- #1874664: Introduce toolbar level "Edit" mode that shows all contextual links (used to be #1898020: Proof of concept for unified edit pencils)

dcmistry’s picture

Results from Usability Testing

Goal: To uncover usability issues with unified editing for Spark

URL: edit.qemistry.us
Username: tester
Password: tester

Methodology:

  • 6 participants responsible for editing/creating/maintaining content on websites were tested
  • Four of the participants were internal Acquia employees; all with beginner/intermediate level Drupal knowledge. All these sessions were conducted in person in Burlington, MA
  • Two of the participants were external employees with no prior knowledge of Drupal. One participant data was discarded as the participant did not understand the tasks. These were unmoderated studies done through usertesting.com

Tasks

Part 1

Task 1: Edit the body of the main article on a different tab

Part 2

Task 2: Edit the title of the secondary menu
Task 3: Reorder the menu items in the secondary menu
Task 4: Add another menu item to the secondary menu

Part 3

Task 5: Add another menu item to the main menu and place between the first and second items

Note: In order to eliminate bias, order effect was used during the study. Half of the participants conducted the tasks in the order: Part 1, Part 2, Part 3. Whereas other half conducted the tasks in the order: Part 2, Part 1, Part 3.

Executive Summary:

All the participants had a positive response to edit functionality of the prototype. They thought it works well and is an extension of current Drupal but has some holes. With those changes addressed (listed below), they did not foresee any problems with using this prototype as a part of our daily lives.

  • “Edit seems easier” (P1)
  • “It’s quicker” (P2)
  • “Similarity in icons helped despite the different edit interaction patterns for main page and the block. My expectation was that it isn’t going to be the same” (P1)

Although editing is great and inline is wonderful, participants bigger concern was how would this interact in terms of revisions and workflows. This is extremely crucial for the content authoring experience.

Also, the unified editing helps the new/beginner Drupal users to get started, however legacy Drupal issues around terminology (path, different menus, what is a block?) obstructs them from taking it to the next level.

Top Issues

Inconsistent edit interactions

  • “Edit” mode is switched ON by default on the homepage. But not on the other pages. Although it did not take more than a few seconds for the users to understand that they have to click “Edit” icon on the toolbar, they complained about the inconsistent treatment (P2)
  • Edit is ON by default on the homepage. But when a user doesn’t select any field on the homepage, it takes the user OUT of edit mode. Also, when a user hovers on a field on the homepage, the pencil symbol of edit appear again. This creates difficulty in building a pattern map in their minds on how and when edit is activated.
  • Participants want the design to inform them all the times that if they are in EDIT mode or not. “It doesn’t scream that it’s edit mode. It should be clear.” (P3)
  • Editing an article on the homepage happens in a full node overlay. Which is very different from the usual per field edit model.
    https://www.evernote.com/shard/s134/sh/5cf4d42c-dd08-4e2f-b21d-e1b0721b9...

I can edit one menu inline but not other. Why?

Participants were surprised to see that they cannot edit the main menu inline but they can for the secondary menu. Since you can’t edit the main menu directly, participants had mild struggle and had to resort to trial and error to find the right menu under the toolbar and make changes. This problem was exaggerated with Drupal and non-Drupal participants who are not very technical when it comes to site building on Drupal.

  • “How can I add menu item [through the pencil] to one and not other? I almost gave up! That’s weird.” (P3)
  • “Oh! there is no pencil here, so it’s going to be a little difficult!” (P5)

https://www.evernote.com/shard/s134/sh/2ef7e8ff-8000-46d9-bd8f-ea823e651...


Very slow page load times

All participants suffered through severe slow loading of pages on the prototype


Jesse confirmed that this is not a Drupal issue

Drupal Issues

  • Beginner level Drupal users weren’t sure how to generate a path while creating a menu item (through the secondary navigation, in this case). Participants who did know this also complained about the disconnect between creating a menu item and inserting a path.
  • “You have to walk in with very specific information [to create a menu item]” (P3)
  • New Drupal users do not understand what is a block (P5)

Other Notes

  • One participant had concerns that editing on per field basis would hamper productivity (and also because you can’t see the vertical tabs) and it’s unclear how it would work with respect to revisions. [Need more research on this concern]
  • While editing a field, one participant wanted the “Save” to be at the bottom of the field instead at the top because he was used to that. (P3)

Next Steps

  • To make changes to the prototype based on the feedback
  • Address concerns about revisions and workflows and re-test again with new and existing Drupal users

Screenshots of the prototype

Homepage (with EDIT on)
https://www.evernote.com/shard/s134/sh/fc3b4086-3591-4071-96e1-8b66f28c1...

Editing a block
https://www.evernote.com/shard/s134/sh/7dc7656c-f104-45c6-adcc-a996387f8...

Editing a piece of content
https://www.evernote.com/shard/s134/sh/a656dbe3-e068-4f35-b45f-bbbd048bd...
https://www.evernote.com/shard/s134/sh/998c147a-26ea-4031-b1ec-405ab7b51...

jessebeach’s picture

Slow loading is probably due to my shared hosting service, not Drupal. I notice slow response times in ssh as well.

tkoleary’s picture

@dcmistry

Beginner level Drupal users weren’t sure how to generate a path while creating a menu item (through the secondary navigation, in this case). Participants who did know this also complained about the disconnect between creating a menu item and inserting a path.
“You have to walk in with very specific information [to create a menu item]” (P3)

Good to see these concerns corroborated again validating the need for attention to the path issue.

dcmistry’s picture

@tkoleary

Yep! I remember this from the very first studies that I did on Drupal. Looking forward to seeing this issue getting resolved.

webchick’s picture

Thanks, Dharmesh!

Hm. So my read of #47 is we didn't run into any problems with simplified forms, nor the way the overlay is being used. We apparently didn't even run into interaction problems with the pencil icons doing different things, which I actually find surprising.

Sounds like we need to:
a) Get rid of the behaviour of edit mode being toggled on on the home page by default (was that just to help testing? I can't imagine we'd do that in real life)
b) Some further tweaks to styling to make it really clear when you are/are not in edit mode.
c) Get rid of edit on hover and make contextual links hinge off of Edit mode? Is that how to read "Also, when a user hovers on a field on the homepage, the pencil symbol of edit appear again. This creates difficulty in building a pattern map in their minds on how and when edit is activated."?
d) Ditch overlay on the full edit mode, and make it only happen on simplified forms? Or? I'm not quite sure how to handle "Editing an article on the homepage happens in a full node overlay. Which is very different from the usual per field edit model." You obviously have to be able to get to this mode somehow.

Otherwise, participants ran into either pre-existing, known UX issues (#1123662: Participants did not know how to get the path while creating a menu link, #1869476: Convert global menus (primary links, secondary links) into blocks, #1760558: Rename 'Blocks' (Twig already uses the term 'block')) or things we already knew we needed to address (#1678002: Edit should provide a usable entity-level toolbar for saving fields, #1898946: [Meta] Simplify and reconcile the behaviors of edit-submit actions in node/edit and edit (edit-in-place)).

Is that a proper interpretation?

Bojhan’s picture

@webchick I am also surprised that we didn't run into many issues, which probably means we should add more weight to the issues dcmistry elevated and/or run a more elaborate study (hopefully after some iteration).

A) Honestly, it reads like a bug - I can't imagine we do that either.
B) This is a serious issue, one would think all of the blue lines that are otherwise not present would signal that you are in "Edit mode". I also wonder if this is because people did not explicitly click edit due to A), wondering what dcmistry further explanation of this is.
C) I think the difficulty we have is that we have an "Edit mode" which triggers a variety of Edits some contextual links other entity inline edits, and in the future configuration inline edits (site name). As proposed before I suggest we all standardise this, so "Edit mode" doesn't toggle inline edit mode for a few things, but rather exposes contextual links for everything. That way, there is one way to toggle the edit mode on the thing/object, through contextual links.
D) I feel like this study has not rendered useful results on the simplified forms, unless dcmistry has results around this he hasn't shared yet. But all we know atm, is that people where confused to get the simplified mode on full node edit (which they shouldn't get anyway?) and that although we have simplified forms, we present them with confusing forms (e.g. path).

I think the primary take aways are that 1) reaffirms our existing concerns around workflow, 2) some items being inline editable and others not, 3) a global edit mode toggle as currently implemented causes confusing because its not noticed/not clear when one exits/contextual links conflict.

Gábor Hojtsy’s picture

I think the global edit mode can be made much more clear if we avoid the hover behaviour (accessing pencils without being in edit mode). The full node edit feature is an interesting question, because that definitely should not be opened in the simplified overlay but if that opens another page, then we have **three** different behaviours for pencils: (a) direct edit (b) contextual menu with items opening modals (c) contextual menu with an item opening a separate page. This maybe be over-reacting the differences in the behaviour. IMHO we should adjust and test again.

Test results on people not knowing what a block is and why some menus can be edited but others don't reaffirms my earlier push to have #1869476: Convert global menus (primary links, secondary links) into blocks and friends resolved for site name, slogan etc. That would make almost everything a block on the page, so you'll probably discover that blocks are containers or sections for parts of the page.

Bojhan’s picture

@Gabor I dont think I follow you at all, and again dont follow why we are discussing three things in one issue. I dont think we should have C) at all, and I dont think we should build for A) which will basically lead to dozens of pencils instead of only the ones for primary objects. Can you imagine a page, with many fields? It will be a mayhem of pencils. I think removing hover behaviour, and with that basically contextual links (or will we have two models here?) - will significantly decrease the UX on the desktop.

Wim Leers’s picture

Gábor: Bojhan is referring to his proposal where we would no longer have per-field pencil icons, but only per-entity. You'd then be able to click the pencil icon and choose either "Quick edit" or "Full edit". Choosing "Quick edit" would cause the blue outlines around fields to show up, i.e. each field would be in-place editable. Together with Kevin's entity-level toolbar (and save/discard) action, that would help us migrate from per-field to per-entity saving.

It soles your points a, b and c, by having everything work like b.

Gábor Hojtsy’s picture

@Wim/@Bojhan: yeah, right, sorry, the design at http://drupal.org/node/1874664#comment-6993582 works a little differently. However, that does not even attempt to give the user ANY way to go to full edit for a node as far as I see, so yeah it does not solve (C), but not sure it intends to not have any solution for that in fact.

Wim Leers’s picture

#56: that's an omission on Bojhan's side in that prototyped screenshot AFAIK, because Bojhan and I discussed this last Saturday and I'm 95% certain that he said both "Quick edit" and "Full edit" would be actions provided by the contextual links for the user to choose from.

Bojhan’s picture

@Gabor It can just give the "Full edit" link? Its just missing from that design, doesn't mean it cant be there.

Gábor Hojtsy’s picture

@Bojhan: right, so we are back at some contextual links opening an the in-place editing blue borders, some opening a modal and some reloading the page with a whole new admin page instead. Three very different behaviours depending on how the link behaves, which was my point above.

Bojhan’s picture

@Gabor I think "Quick edit" should always do inline edit, so there is no confusion there. When it comes two the two different modals (the small one, and the overlay one) I am not convinced, we should do that simplified model at all. Just because of what you mentioned, in some cases we will need an overlay in some cases we can use a modal - it will appear completely random to the user, even if we trow out the overlay and go to a full page.

Wim Leers’s picture

#59: hm, that's a good point. The problem Bojhan tried to solve by having "Quick edit" also be a "contextual link action", is to solve another "different behavior problem": in our original designs, clicking the pencil icon on fields would *immediately* start editing, whereas other contextual link actions all triggered the overlay.
Bojhan's proposal solves the "jungle of pencil icons" problem and the aforementioned different behaviors. But I don't think we can ever have all the different possible actions on an entity behave in the same way; if we'd want to do that, then we cannot have unified in-place editing.

Or what am I missing? :)

Gábor Hojtsy’s picture

jessebeach’s picture

This is reroll of #45 given recent commits to 8.x that reduce the load of the megapatch. This patch combines the following for simpler application and testing:

#1889150-10: Simplify overlay look, *only use for contextual operations*
#1880168-29: Introduce top-level sections for all forms
#1874664-56: Introduce toolbar level "Edit" mode that shows all contextual links

jessebeach’s picture

Issue summary: View changes

Add more issues.

dcmistry’s picture

Sorry for odd reasons, I did not get notifications about responses to the thread

Here are my comments

@webchick

A) We apparently didn't even run into interaction problems with the pencil icons doing different things, which I actually find surprising.

Yes, I found it surprising too. But they are Drupal users and they understand that the main content is different from the block.

B) Get rid of the behaviour of edit mode being toggled on on the home page by default (was that just to help testing? I can't imagine we'd do that in real life)

I will have Kevin reply to that. I thought it was a prototype issue. IMO, it should be NOT ON by default.

C) Some further tweaks to styling to make it really clear when you are/are not in edit mode.

+100. It should be absolutely clear when you are in EDIT mode and when you are NOT

D) Get rid of edit on hover and make contextual links hinge off of Edit mode? Is that how to read "Also, when a user hovers on a field on the homepage, the pencil symbol of edit appear again. This creates difficulty in building a pattern map in their minds on how and when edit is activated."?

I think this more of a problem, because it wasn’t clear if they are in EDIT mode or not. Does that make sense?

E) Ditch overlay on the full edit mode, and make it only happen on simplified forms? Or? I'm not quite sure how to handle "Editing an article on the homepage happens in a full node overlay. Which is very different from the usual per field edit model." You obviously have to be able to get to this mode somehow.

This was a problem because of the inconsistency. “Quick Edit” and “Full Edit” could be worth exploring. “Full Edit” can take you to the node page. The capability of editing on per field (through “Quick Edit”) and a node together (through “Full Edit”) will help immensely the new and power users.

@bojhan

I feel like this study has not rendered useful results on the simplified forms

What kind of information are you looking for?

yoroy’s picture

1. There are hardly any direct navigation options anymore. Everything except the home and user button in the toolbar requires at least two clicks. Click Menu to see menu options, then choose one. Click Shortcuts to see shortcuts, then choose one. Click Edit, then edit. The default of showing the Shortcuts takes away most of these concerns but

---

2. 'Edit shortcuts' link is on its own new line, doubling height of shortcuts bar. Seems like a small CSS issue.

---

3. Action: clicking 'Edit' in the toolbar

Confusing first impression: when I click 'Edit', the icon changes to a crossed-out pencil and many edit icons show up around my content. Can I edit or can I not? I can either way so what's happening here?

---

4. Task: Edit a block in the overlay.

A. This takes me into an overlay. Pencil edit icons are on a higher z-index, overlapping the form in the overlay:

B. 'Advanced settings'… :-( (I think there is another issue already open for this?)

C. Cancel is on the left, Save on the right. Bah, this favors Cancelling over Saving. Does not instill trust but suggests I'm likely making a mistake. I may well be overly sensitive to this, but I hate it when Drupal does that, protect me against myself. I came to edit, let me save my edits.

D. Overall, I find the introduction of these kinds of tweaks on top of the big UX change of edit-in-place a distraction and they do not support the case in point. I'd rather see these things discussed in follow-ups.

---

5. Task: Edit a node's image from the homepage teaser listing

A. I click 'Remove' button. Get error: "An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (32 MB) that this server supports." I click outside the edit box, error message goes away. Edit the image again, click Remove again, get a white screen at URL "http://d8:8888/edit/form/node/1/field_image/und/teaser", and an output like this:

[{"command":"editFieldFormSaved","data":"\u003Cdiv class=\u0022field field-name-field-image field-type-image field-label-hidden\u0022 data-edit-id=\u0022node\/1\/field_image\/und\/teaser\u0022\u003E\u003Cdiv class=\u0022field-items\u0022\u003E\u003Cdiv class=\u0022field-item even\u0022 rel=\u0022og:image rdfs:seeAlso\u0022 resource=\u0022http:\/\/d8:8888\/sites\/default\/files\/styles\/medium\/public\/field\/image\/DSC_0511.jpg\u0022\u003E\u003Ca href=\u0022\/node\/1\u0022\u003E\u003Cimg class=\u0022image-style-medium\u0022 typeof=\u0022foaf:Image\u0022 src=\u0022http:\/\/d8:8888\/sites\/default\/files\/styles\/medium\/public\/field\/image\/DSC_0511.jpg\u0022 width=\u0022220\u0022 height=\u0022170\u0022 alt=\u0022A meeting of like minded spirits\u0022 \/\u003E\u003C\/a\u003E\u003C\/div\u003E\u003C\/div\u003E\u003C\/div\u003E"},{"command":"settings","settings":{"basePath":"\/","scriptPath":"","pathPrefix":"","currentPath":"edit\/form\/node\/1\/field_image\/und\/teaser","overlay":{"paths":{"admin":"node\/*\/edit\nnode\/*\/delete\nnode\/*\/revisions\nnode\/*\/revisions\/*\/revert\nnode\/*\/revisions\/*\/delete\nnode\/*\/translations\nnode\/*\/translations\/*\nnode\/add\nnode\/add\/*\noverlay\/dismiss-message\nuser\/*\/shortcuts\nadmin\nadmin\/*\nbatch\ntaxonomy\/term\/*\/edit\ntaxonomy\/term\/*\/delete\ntaxonomy\/term\/*\/translations\ntaxonomy\/term\/*\/translations\/*\nuser\/*\/cancel\nuser\/*\/edit\nuser\/*\/edit\/*\nuser\/*\/translations\nuser\/*\/translations\/*","non_admin":"admin\/structure\/block\/demo\/*\nadmin\/reports\/status\/php"},"pathPrefixes":[],"ajaxCallback":"overlay-ajax"}},"merge":true}]

B. I click the linked URL of the image, get a pop-up with a bigger version of the image. Nice.

C. I change the image alt text. Click outside the edit-overlay, get alert message 'You have unsaved changes' Save on the right again, 'Discard changes' on the left. Hit 'Save'. Alert box and edit box go away. I can't tell if the alt text change was saved. Firebug inspection tells me it was indeed saved.

D. Since I can't delete because of the error above, I can't upload a new image either. At this stage, edit in place for an image field is broken.

E. Lets change the image field for the article content type to accept multiple values (3).

Returning to the default homepage and edit-in-place the teaser image gives a very sparse edit-popup:

To verify if this is because of changing to multi-value on an existing node, I created a new article with two image and I get the same result.

---

6. Task: Edit the title

Clicking the pencil shows the standard 'edit', 'delete' contextual links. Disappointing experience. I assume because the title is (still) not a field (yet) and thus another issue…

---

7. I notice the submitted by and publishing date info is not editable in place.

---

8. Task: edit the body text

A. Works. It's getting a bit weird that the edit-box is only half the width of how the original is shown, forcing scrollbars where they are not there in the original. Lets work on getting those gawd-awful text format explanations out of sight. They are the ugliest bits of UI on many an edit form. But anyway…

B. Heh, I added line breaks in the content beyond what the teaser shows (I'm still working from the homepage teaser listing), so my edits are not reflected. Viewing the full node I see changes were saved, so all good I guess.

C. Creating a custom teaser (change summary). Works. Nice.

---

9. Task: edit the tags

Works as expected, good.

---

10. Task: lets edit-in-place a comment I made

I can't.

---

11. Task: Edit the Contact / Powered by Drupal blocks

Icons are close to each other, issues with overlaps and too-cramped spacing around the contextual links

---

12. Notes on visual styling and overall UX

A. Too much blue borders and boxy-ness for my liking.

B. But thinking about that a bit more, I'm thinking thisf boxy-ness, when compared to the overlay paradigm, doesn't really shrink the relative (cognitive?) distance between the object and the editing of the object. The editing of an object still happens in a box that contains a 'copy' of the object instead of the object itself.

Put bluntly, just because the rest of the page doesn't get the darkened overlay treatment doesn't mean we're really editing in place. In that sense, one can wonder how much closer this really brings us to in-place editing. The biggest win is in getting the individual edit-pencil icons. The actual UI for making the edit happen is still quite removed from the actual object.

Is this where we look into making all of these per-field edits look and feel more overlay style?

Gábor Hojtsy’s picture

@yoroy: thanks for your great review! First of all if you tested the patch above, that is not the very latest we have. We did not post yesterday's summary patch. The easiest way to test that is to go to http://simplytest.me/project/spark/8.x-1.x and fire up a site there. I'll update the compound patch shortly too for posterity.

1. The navigation menu tray is persistent. So if you open the admin menu, it will be there later too. You can keep your most used item open all the time. This is related to how the new toolbar is set up, not changed at all in this patch set.

2. The edit shortcuts CSS issue I have not seen, but it would be great as a toolbar module issue.

3. You can edit either way, right. The edit toggle merely highlights the things you can edit, so you don't need to discover (at least in the latest version). And it is supposed to be the primary means to make it work on mobile where hover cannot work. I agree the cross-out is confusing, this was brought up before. No better suggestions yet. (It is currently meant to designate what is going to happen if you click it not what mode it is in right now).

4A. The pencils overlapping should be fixed in our latest patches.
4B. The "advanced settings" issue is #1880168: Introduce top-level sections for all forms (yes, the simplification issue introduces advanced settings).
4C. This is already solved in the latest patch by removing the Cancel button and going back to the close button on the overlay instead. The primary action is on the left as in normal Drupal.
4D. We backed out of most of the invasive overlay changes in #1889150: Simplify overlay look, *only use for contextual operations*, what we left is the title inside the overlay, no shortcuts or breadcrumbs and no tabs on the overlay. Also sized smaller than the full size overlay used to be.

5. All of the points here refer to the *existing* edit module in core. I personally agree with all of your remarks on the first annotated image. The proliferation of blue bordered boxes is a bit excessive (original box staying in the background and then two boxes for editing). It would be great to bring over these reports to the edit module queue, if there are no existing issues for them. Nothing is changed in this regard in the patch it is already in core.

6-7-8-9-10. Not sure about the edit module roadmap for these. Probably existing edit module issues are in the queue for most if not all of these.

11. The too cramped issue was found by Wim as well, it pre-exists the patch and already in Drupal core. We need to submit / find an issue for it or take on solving it in #1874664: Introduce toolbar level "Edit" mode that shows all contextual links.

12. Well, a key point that these boxes get you closer to real in-place editing is they don't load you the whole form in a popup but instead you only get to edit the specific field. Once CKEditor lands in core, it will plug in and the body editing will not actually be a small popup, but will be actually in-place editing the text. #1890502: WYSIWYG: Add CKEditor module to core. This issue is in fact making the overlay less intrusive, not to make the in-place editing popups more intrusive / overlay-like :)

Hope this helps, and compound patch coming soon with updates. Please test with http://simplytest.me/project/spark/8.x-1.x in the meantime.

Wim Leers’s picture

3. I agree that the current "Edit mode" toggle is confusing. It needs to be improved. However, note that at #1874664-64: Introduce toolbar level "Edit" mode that shows all contextual links and later, we're no longer using the "Edit" button/tab in the toolbar to toggle "Edit mode". There it now means "Show all contextual gear/pencil icons", as Gábor already pointed out. Nevertheless, the way that button works definitely needs to be improved.

5. I completely agree Edit needs to become better. The redundant info only exists because of a core change, because the second field label mention wasn't there before (it should be stripped automatically). The general ugliness: post-feature freeze clean-up :) For the per-field "Save" and "Close/cancel" buttons, see #1678002: Edit should provide a usable entity-level toolbar for saving fields.
5.A. This definitely used to work; it seems like somewhere along in Drupal 8 development, the JavaScript that makes that "Remove" button work was removed (i.e. no longer #attached), which causes this breakage.
5.C. Edit's own modal dialog: will go away, see #1872296: Edit should use core-provided Dialog (instead of its own).
5.D. Caused by the bug described in A.
5.E. There seems to be something wrong with your Drupal installation, because that grey "Image" bar is in fact a collapsible fieldset, but in your case the triangle is missing. If you click it to expand, then you'll see what a horrible UI this also is. We'll either need to improve the default UI (in the full node edit form, the behavior is also terrible: if you upload another image, the fieldset will automatically collapse again — WTF!?) or make Edit smarter at presenting only the relevant parts of the form.

Gábor Hojtsy’s picture

New roll of the compound patch This patch combines the following for simpler application and testing:

#1889150-37: Simplify overlay look, *only use for contextual operations*
#1880168-30: Introduce top-level sections for all forms
#1874664-70: Introduce toolbar level "Edit" mode that shows all contextual links

The easiest way to try this out keeps being using http://simplytest.me/project/spark/8.x-1.x and just firing up a site there. That also includes other changes: the edit toggle moved to the right in toolbar, etc. but is largely a good altogether experience of these proposed changes.

Gábor Hojtsy’s picture

@yoroy and here is more guidance for the goal of this patch: Drupal 7 has the overlay and contextual links. Contextual links are best friends with overlay because they allow you to go to do a contextual operation, close down the overlay, and bam you are right back where you were. No side-navigation on a tab on the admin UI. You get to change your stuff and then get the page reloaded as it changed. So it is as close as you can get to an "in-place" administration experience in Drupal 7 core.

What we are arguing here is that the overlay is also overused as a generic admin browser when the context sensitivity does not matter. Also Drupal 8 got much closer to actual in-place editing (eg. with ckeditor hopefully soon to be committed, it will get actual in-place editing for textfields without this ugly box popup). The in-place edit module already in core does more targeted single-field edits in small popups.

So we got back to contextual operations for other things that would theoretically work a similar way. You cannot really click on anything to edit the "number of items displayed in the recent comments block" or "add a menu item here", or "reorder menu items in this menu" so as true in-place editing as is with entity fields is not possible. However we can get the experience closer and unify the interactions. See http://drupal.org/files/pencils-1874664-64.gif for the current experience (or try the patch or try via simplytest.me).

So the goal we set out in this issue (via its sub-issues) is to make actual context sensitive operations simpler by brining them under one umbrealla with in-place editing, de-clutter the dialog/modal/overlay for editing for contextual operations and unify all operations in contextual links (no local tasks priviledge for the primary content). This results in one unified way to initiate operations on things, removes admin related pieces from the normal page view and hopefully simplifies quick operations. That is the thinking behind the issue and the scope we are looking for reviews. :) Let me know if you have any questions, I'm happy to answer.

Status: Needs review » Needs work

The last submitted patch, unified-edit-prototype-demo-68.patch, failed testing.

eigentor’s picture

Concerning button placement: If you don't know the study, I find the reading very worthwile: http://www.lukew.com/ff/entry.asp?571

I mean it mainly concerning seperating buttons and placing one on the left and one on the right. In the study they also had cancel on the left. Note that this performed poorly in their study.

Takeways for me from that were:
1. Having different colors for save and cancel may slow people down, but helps them not to click the wrong button. Check, I think our current save button is blue, cancel is not.
2. It is not really worthwile experimenting with fancy button placement. The vertical axis is the main axis of orientation and moving buttons away from it causes confusion. This also applies to position them in the middle.
3. Keep the "Save" button on the left, aka more prominent position. If you presume that people want to keep their edits, this is the primary action. Cancel is secondary. I think Yoroy also mentioned that. Putting Cancel in primary would presume people would normally not want to keep their edits.

So: I do not like the seperated buttons, and this is an attempt to back that up with real-world empirical data.

aspilicious’s picture

Tested the new version and it looks better :).
I still don't understand the edit button on the right corner.

When you click it you see all the available editable spots.
When you don't click it you only see it when hovering.
But no matter what you choose you always can edit the content.

So personally for me this button is kinda useless. The quick edit vs edit is already a huge improvement to me. And the change from a gear to a pencil is understandable too.

Wim Leers’s picture

#72: It's necessary for touch devices, where one cannot hover. It's also useful on non-touch devices in that it can show you all the things that are editable in one overview.

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
60.61 KB

New roll of the compound patch This patch combines the following for simpler application and testing:

#1889150-37: Simplify overlay look, *only use for contextual operations* (same as before)
#1880168-30: Introduce top-level sections for all forms (same as before)
#1874664-78: Introduce toolbar level "Edit" mode that shows all contextual links (this got some good updates)

The easiest way to try this out keeps being using http://simplytest.me/project/spark/8.x-1.x and just firing up a site there. That also includes other changes: the edit toggle moved to the right in toolbar, etc. but is largely a good altogether experience of these proposed changes.

For code reviews, the individual patches should be reviewed. #1874664-78: Introduce toolbar level "Edit" mode that shows all contextual links is actually getting to a place where it can be reviewed for code as well. It is not merely a prototype.

Status: Needs review » Needs work

The last submitted patch, unified-edit-prototype-demo-75.patch, failed testing.

seantwalsh’s picture

Regarding the global "Edit" link:
It seems odd that when I toggle the upper right-hand "Edit" link that it does not persist when I change to a different node. My initial reaction was that this should either be always on when I select it or off when I don't. Also, when in the "Preview page layout" the global "Edit" link does not display even when on, but the hover edit works.

Wim Leers’s picture

#77: are you saying that as you browse around your site (i.e. go to different URLs), you expect the "Edit" toggle to remain enabled?

corbacho’s picture

Good work here. Since the last time I tried Spark I see a lot of improvement! =)
Observations:

1. I found the interface "restless" with pencil icons and labels like "Body", "tags", popping up all the time, specially frustrating when I'm not in Edit mode.

2. Although I appreciate the predictions of tkloeary "The mouse will soon be as obsolete as the rotary phone.", I agree with webchick that we should look into the present and fix the desktop behaviour. I propose one of these 2 solutions

* Mouse hovering displays the context menu (life drupal 7)
* Clicking the menu displays the menu but moving the mouse out of the menu doesn't close it. (If mouse-in doesn't open the menu, why mouse-out is taken into account ? )

3. I found myself a little confused about when Edit toggle is on or off ? . (A strike over the pencil icon is not *that* intuitive, although you get used to it quite fast. Where have you see that pattern before? Maybe in a "Mute" symbol? The mute symbol is displayed when you are *already* in Mute status, it does not represent a button to *go* Mute. See the youtube volume icon http://www.youtube.com/watch?v=mzgjiPBCsss )

4. I would expect when turning off the main EDIT toggle that also affects to the "Quick edit" (so both become disabled). I feel permanently in some "Edit" mode.. I would like a way to switch off everything that is about editing in the interface.. so I can move the mouse freely in the screen without stuff popping up

5. I found the main Edit button easy to find.. but it could be thought that it's for editing the toolbar. Could it have some other shape or color that makes more evident that is not about the Toolbar ?

As you see my observations are small details. I was surprised with the nice interface and user-friendly modals/toolbars, etc. Everything well thought and fast! Good work

Wim Leers’s picture

#77: now implemented over at #1874664-85: Introduce toolbar level "Edit" mode that shows all contextual links :)

#79: Which did you test? The unified patch at #75?

1. There's nothing new here versus Drupal 7? :) Just a new icon!
2. A) mouse hovering works identically as before AFAIK, B) that's a bug that also exists in Drupal 7, it's not an artefact of our prototype — it's only noticeable now because nobody ever used contextual links before I guess :P — fixed at #1910008: When launching the overlay, a contextual menu remains visible when it should become hidden.
3. Also fixed at #1874664-85: Introduce toolbar level "Edit" mode that shows all contextual links!
4. Well, you can "Quick edit" without ever enabling "Edit mode". "Edit mode" is now different from before, it's no longer what you need to enable to enable any in-place editing at all; it's now effectively a "Show all contextual actions available toggle".
5. Also fixed at #1874664-85: Introduce toolbar level "Edit" mode that shows all contextual links — I think.

Within 1 minute, you can have a simplytest.me instance up & running with that patch I referenced so often — instructions are at #1874664-85: Introduce toolbar level "Edit" mode that shows all contextual links :)

Lars Bo Jensen’s picture

Just tested at http://simplytest.me/project/spark/8.x-1.x on a desktop computer.

I look forward to see what CKEditor in core will bring to this. For now, I agree with yoroy's fundamental criticism in #65 12.B. The quick edit is cool, but still isn't "inline". I would like to exit quick edit mode on save. But if I wanted to edit more, that's no good. Actually I don't want to have to activate any mode, when I have the rights to edit. I would like to just click in the field (title included!) and edit. The wysiwyg, save and cancel buttons should turn up by changes and then just leave me in peace when I'm done.

Maybe that's stupid, maybe it's science fiction. I haven't concidered any technical issues, as I'm pretty much just a sitebuilder and writer. I think, I would like it.

Apart from small weaknesses, the project improves a lot ot things: I don't miss the tabs above content. They disturb the look of the page. More granulated context links is a good way to go. Inline editing as such also is.

Adding the save options Save and keep published / unpublish is a good idea.It supports and attracts attention to an important aspect of the content workflow.

I do miss the vertical tabs at the bottom of full node edit forms, the menu, comment and so on settings. I find the vertical accordion-like pushing plain annoying.

I find the project extremely interesting, as it addresses the fundamental workflow of editors. It could indeed be simpler and more intuitive, and Spark is taking it there. Thank you all for doing this!

Wim Leers’s picture

#81: Thanks for the feedback! :)

I'm particularly interested in a few parts of your feedback:
1) "not directly/inline enough": this is true on the *front* page, where you're editing a teaser. Because it is a teaser, we *must* load the full object, because it's logically impossible to edit the teaser, since that is an automatically trimmed version of the original. Please try Spark 8.x-1.x again, but this time go to node/2 (i.e. the full node view) and do in-place editing of the body field there. Now you will see that it is truly inline, "true WYSIWYG" :)

It'll be like this:

CKEditor through Editor.module both on regular form and for true WYSIWYG.png

2) no toggling of any edit mode: do you mean that clicking the pencil icon and then clicking "Quick edit" is too much? You want to be able to click on anything to start editing it right away? Theoretically, that would be possible (for textual fields), but it'd have far-reaching UX consequences. The simplest example possible: how would you then want to select text? :)

3)

I do miss the vertical tabs at the bottom of full node edit forms, the menu, comment and so on settings.

The rule is simple: if it's visible, we'll make it in-place editable. Otherwise, it wouldn't really be "in-place" editing, right, since the thing you want to edit isn't really already in place? :)

4)

I find the vertical accordion-like pushing plain annoying.

What does this refer to? Can you clarify?

corbacho’s picture

Sorry @Wim, I tested just Spark 8.x-1.x
1. There's nothing new here versus Drupal 7? :) Just a new icon!
True, I know, I know.. but it feels now more intrusive. Before was displayed was a "subtle" icon, no dashed borders (until you put the mouse over the icon) and only for blocks.
2. D'oh, it's true
well.. the rest of points were addressed

Oh man, such a useless feedback I provided. Sorry about that

PS. Just now simplytest.me is failing to build with that patch. I found the new patch http://drupal.org/files/pencils-1874664-91.patch althought it's not an unified patch, I can confirm that everything I said in #79 it's already addressed =) Good work

Wim Leers’s picture

#83: No, your feedback was very useful, and very much appreciated; it's just that we were already moving forward on feedback provided in that specific issue. Please keep the feedback coming! :)
I just updated Spark 8.x-1.x to include the very latest work of #1874664: Introduce toolbar level "Edit" mode that shows all contextual links, so that others who want to review it will truly get the very latest, even though there's no huge functional changes, the many subtle improvements should make for a better UX.

Lars Bo Jensen’s picture

Well, thank you for reading and commenting :-)

1) Editing at node/2 is indeed different, but I had been there and still meant what I wrote. You guys are making a great improvement to the very basics of Drupal UX, I want to state that. Because you brought it so far, I want to have what I consider the rest - total elimination of any obstacles between display and edit (for text fields). So that you can just click in there and edit (cf. 2) ). I haven't fully considered the consequences, but among other there could be quite many editable fields on e.g. a landing page or some views or panel page, causing performance issues and maybe a horrible UX. Probably you have to do "one at a time". The solution is quite flexible already, and saves both time and clicks.

(There is a funny bug (that doesn't change the intent of the module, though): When I have "stopped quick edit", the body text field is still writable. Without save button or any other parts of the editor interface.)

2) Clicking twice truly isn't much. I just still have the feeling, this is only half way where we want to go. I don't quite understand, what you mean by selecting text. I can select text (including formatting and inserted images) either way: in edit mode or not / from the CKEditor form or from the displayed node. You probably have a good point, but I didn't get it...

3) and 4) I didn't mean to critisize the inline editing, but the changed look of the node form. I have attached an image showing the new look. With "annoying pushing" I refer to the fact that scrolling to the bottom of the page (node edit form) and clicking one or two of the tabs here ("Menu settings" and so on) pushes the ones beneath it downwards so that I have to scroll (several times) to see the rest and/or the save button.

Drupal 8 node form

seantwalsh’s picture

That's correct. I am thinking that from a content manager perspective, I would want to know what is editable on each page I visit without having to toggle this everytime. It feels somewhat cumbersome to have to keep enabling it.

Wim Leers’s picture

#85: 3/4: that's unrelated to the work done here or the Edit module, actually :) That was done as the first step to the improved, two-column content creation page. I agree the current state is not good.

#86: You can just hover around and wherever a pencil icon shows up, you can edit that. Or maybe that's not what you mean?

Gábor Hojtsy’s picture

@Lars Bo Jensen: as for having initiating actions for in-place editing (edit toggle in toolbar and quick edit button in contextual menu) vs just clicking or double clicking to edit, we want to integrate in-place editing with workflows for example, where you save changes not necessarily for immediate publication but as draft (if you want). That requires exposing which fields belong to the same content piece that you are editing, which is in part what lead us to have a quick editing toggle per node in contextual links for the node, so we let you know in the process which fields belong in the same node.

Lars Bo Jensen’s picture

#87 3/4: oh yes, that's true. Sorry. Still glad we agree, though :-)

@Gábor Hojtsy: excellents points regarding workflows! Thanks for explaining some of the background.

jhodgdon’s picture

I tried out the (wow!!!) test site at http://simplytest.me/project/spark/8.x-1.x today. Overall, my impression was: It's great!

I had a few "disconnects", and since I don't think I want to read through 89 comments right now, don't probably plan to get involved with developing on this project, and I didn't see them in the issue summary at the top, I'll post them here:

a) When I went to my user account page, there was still a regular "Edit" tab there, instead of the contextual Edit pencil icon thing. It seemed like the user account page should have contextual editing just like the content pages, with quick edit for my profile fields, account name, and other visible stuff, and full edit to get to password etc.?

b) I used the contextual icon to add a menu link. There was a black "Advanced Settings" heading but nothing in it. It seems like if there is not going to be anything there, it shouldn't be visible at all?

c) On the Search block, the pencil contextual menu gave me the option "Delete block". This was scary -- would that mean I am deleting it completely from the system or just removing it from where it is displayed? I tried it, and it does seem like it deleted it completely. How about adding an option for "Disable block", which would (temporarily) move it to the "Disabled" section of the blocks page, without losing any configuration you might have done?

d) After several operations (Delete Block, Edit Menu) from contextual links, when I clicked Save, it put up a short-lived dialog box with a "something has been done" type of message, and the body of the page I happened to be on. This was very confusing. I think it would be better if the overlay completely closed and the message appeared on the actual page, so I would have time to read it.

e) The Taxonomy term page still has traditional View/Edit/Delete tabs. Should be all contextual?

Grayside’s picture

Inline Editing Feedback

    It's weird to me that the contextual drop down has a link that changes state, and that I have to go back into a dropdown to get out of it.

    Once editing a particular field, I was confused that I couldn't click on a different field to edit something else.

    Cancel editing current field, then leave editing mode. Seems like I should be able to do that with one click at any time, or if it's two clicks, it's to confirm I'm discarding any changes.

I guess what I am seeing is some confusion when I go in with "exploration" as a goal, as opposed to a clear sense of discrete edits I want to perform.

Not sure what I'd make of it if I came in to a very raw draft, started with a small change, and then launched into more of a topical refactoring. I can imagine mild frustration at the routine of saving progress in Body Field, then switching to Full Edit.

tkoleary’s picture

@ jhodgdon

b) I used the contextual icon to add a menu link. There was a black "Advanced Settings" heading but nothing in it. It seems like if there is not going to be anything there, it shouldn't be visible at all?

Right, pretty sure that's a known bug, also it is proposed we change that to just collapse existing fieldsets with descriptions as prototyped here: http://invis.io/FVB89STC (turn on edit and check the recent content block).

c) On the Search block, the pencil contextual menu gave me the option "Delete block". This was scary -- would that mean I am deleting it completely from the system or just removing it from where it is displayed? I tried it, and it does seem like it deleted it completely. How about adding an option for "Disable block", which would (temporarily) move it to the "Disabled" section of the blocks page, without losing any configuration you might have done?

I agree. Good idea

d) After several operations (Delete Block, Edit Menu) from contextual links, when I clicked Save, it put up a short-lived dialog box with a "something has been done" type of message, and the body of the page I happened to be on. This was very confusing. I think it would be better if the overlay completely closed and the message appeared on the actual page, so I would have time to read it.

That is a known bug.

e) The Taxonomy term page still has traditional View/Edit/Delete tabs. Should be all contextual?

This is still under discussion at http://drupal.org/node/1874664

jhodgdon’s picture

Regarding Taxonomy: if the goal of this meta-issue is "unify editing approaches in Drupal", then, since Taxonomy is an entity and can have fields just like Node, User, etc., then IMO all entities (including Taxonomy and User) should look/behave the same for editing. Just doing it on Node and some Blocks will lead to fragmentation of contrib modules as well. If there is one best approach, then it should apply to everything. And if it's not a good approach, it shouldn't be used for anything.

tkoleary’s picture

@ jhodgdon

I agree. That was our initial recommendation. David pointed out though, that then non-admin users would lose local task tabs! THis was definitely a regression so we are now have both and we are working out the kinks of that in the issue I referred to.

jhodgdon’s picture

If you need both for Taxonomy, then you need both for everything. All I'm saying is: make Taxonomy, User, Node, Block, and any other entity/area/whatever a;; work the same. I don't see why you would need local task tabs for taxonomy if you don't need them for nodes, and I don't see why you should have quick edit and all the other things on the pencil icon for nodes if you don't also have them on taxonomy. And there were none on the test site I looked for for nodes...

Also, artificial distinctions between "admin" and "non-admin" users do not make sense when any role can have a constellation of permissions, and any user can have several roles. If someone has permission to edit a taxonomy term, they should be able to get to the editing either by quick edit or a full edit, and if that means they need both the contextual pencil icon menu (which -- does that even work without JS by the way?) and tabs, then they are needed for everything.

effulgentsia’s picture

I don't see why you should have quick edit and all the other things on the pencil icon for nodes if you don't also have them on taxonomy

I agree with this in principle, but just want to point out that it's existing HEAD behavior that only nodes, blocks, menus, and views currently have contextual links. I like the idea of users, taxonomy terms, comments, etc. having them, but I don't see an issue link in the issue summary pointing to an issue where this is to be done.

Also, artificial distinctions between "admin" and "non-admin" users do not make sense when any role can have a constellation of permissions

Agreed. I think in this context, "admin" is shorthand for someone with "access contextual links" permission, and "non-admin" is shorthand for someone without "access contextual links" permission. I need to update #1915730: Decide what to do about important contextual links when that module is disabled or restricted with a new patch, but the conclusion I'm reaching there is that important entity operations (Edit and whatever else is decided as an important operation) should appear as contextual links on the entity's primary page for users who have access to contextual links, and as tabs for users who do not. For anyone interested in this aspect of the problem space, please follow / comment on that issue.

does that even work without JS by the way?

Yes, in Drupal 8, contextual links appear as regular, visible links in bulleted lists when JS is disabled.

sun’s picture

Issue tags: -Usability

+1,000 to @jhodgdon's #95, on all points. I think that's what I tried to say in my past reviews, but I failed to find the right words/terminology. Thanks for nailing it, @jhodgdon!

Especially on the "admin" vs. "non-admin" part — we have user roles with fine-grained permissions, not "admins" vs. "users". Whether a user has access to contextual links is completely irrelevant there, IMHO.

effulgentsia’s picture

I agree with this in principle, but just want to point out that it's existing HEAD behavior that only nodes, blocks, menus, and views currently have contextual links.

Thinking more about this... D7 and D8 HEAD implement contextual links for just these. However, HEAD is consistent in providing an Edit tab for all editable entities. So, maybe what #95 is saying is that if we move the Edit tab to an Edit contextual link and if Quick Edit is only available via a contextual link, then we'll need to implement contextual links for all entities. But that raises a question: do we want contextual links for users, comments, taxonomy terms also appearing when these entities are displayed inline in other content (which is what the original intent of contextual links was)? That would mean, a node page with 50 comments would show lots of contextual links (one for each comment, one for each place the author of the comment is listed, one for each taxonomy term on the node, etc.): would that overwhelm the administrator?

effulgentsia’s picture

Issue tags: +Usability

I don't think #97 intended to remove the Usability tag, so restoring it.

effulgentsia’s picture

That would mean, a node page with 50 comments would show lots of contextual links (one for each comment, one for each place the author of the comment is listed, one for each taxonomy term on the node, etc.)

Sorry for the noise. Actually, this might not be so bad, because we only display contextual links when an entity is displayed as an entity, not just as a link. So in this case, the comments would get contextual links, but the tag and author links wouldn't, unless the site builder configured these to display as entities and not just links.

sun’s picture

Not quite right — Each comment outputs the 'compact' view mode of the user account of the comment author in the meantime, which means that contextual links for the comment author would appear there.

Also note that comments do not get contextual links right now, because when we originally tried that, it caused a major (as in really major) slowdown of the node view page rendering when there are some more comments. Usability ideas aside, we cannot ignore performance.

tkoleary’s picture

@sun

Usability ideas aside, we cannot ignore performance.

The performance hit would only result from an arbitrarily global application of the rule, which I don't think anyone is suggesting. There is no usability benefit to showing contextual links on every comment so we just don't do that.

Wim Leers’s picture

#101: RE: performance. Contextual links is breaking the render cache already. I'll fix that at #914382: Contextual links incompatible with render cache. The current plan is to use the same approach as Edit module's metadata retrieval: an AJAX callback that receives a JSON response. It's very well possible though that due to the number of comments, like you already indicated, that may come with its own set of performance problems, but they wouldn't impact the node view page rendering performance.
Would that address your performance concerns in this issue?

Wim Leers’s picture

Issue summary: View changes

Updated issue summary.

webchick’s picture

Issue summary: View changes

x

Gábor Hojtsy’s picture

Issue summary: View changes

Add a few more recently opened issues

Wim Leers’s picture

Status: Needs work » Active
Issue tags: +sprint, +in-place editing

Status update

So, by now contextual links' performance impact (i.e. it breaking the render cache) has been fixed at #914382: Contextual links incompatible with render cache as promised.

At #1966704: In-place editing for taxonomy terms and custom blocks we added in-place editing for custom blocks and taxonomy terms. We also had comments working (see e.g. the screencast I posted in the first issue comment there), but decided to postpone that due to likely UX problems, which was a discussion that we didn't want to have there: we wanted to ensure that in-place editing worked at all on non-node entities.

Sadly, it was still necessary to have per-entity type hook implementations to enable in-place editing on each entity type, because it's impossible to set attributes on all entities. We're fixing that at #1972514: Impossible to set attributes for all entities.

To move this issue forward again

but the conclusion I'm reaching there is that important entity operations (Edit and whatever else is decided as an important operation) should appear as contextual links on the entity's primary page for users who have access to contextual links, and as tabs for users who do not.

That would break the render cache as well. Unless you'd use CSS and/or JS to hide the local task tabs whenever contextual links are available.

If you need both for Taxonomy, then you need both for everything. All I'm saying is: make Taxonomy, User, Node, Block, and any other entity/area/whatever a;; work the same.

Absolutely! :) That's what we've been working on in the last two issues mentioned above.

Also note that comments do not get contextual links right now, because when we originally tried that, it caused a major (as in really major) slowdown of the node view page rendering when there are some more comments. Usability ideas aside, we cannot ignore performance.

This is hopefully no longer true. The question is: are we sure we want this? Because only then it makes sense to profile this.

Conclusion

It looks like we're all kind of on the same page. We all want consistency. Nobody wants more complex permissions.

To me, it looks like the questions that need to be answered definitively are (and I apologize for not having re-read the entire issue, hence I might have missed something):

Major: Is there still a valid use case for local task tabs?
It seems the answer is "yes".
Major: Is it sensible to have both local task tabs and contextual links at the same time on the same entity?
It seems the answer is "yes", even though it's unfortunate to have two ways to achieve the same endpoints.
Minor: Should contextual links be present for every entity?
It seems the answer is "yes, if possible from performance POV", but then a new problem poses itself: how do we display contextual links on display:inline rendered entities, like the comment author? There's not enough room for them to be usable?
catch’s picture

I was going to open an issue to look at putting contextual links back on comments - that's a lot of access checks to do in the ajax callback so it could still be poor for performance on that side, but it would be an important step towards making comments render-cacheable. The current comment links are per-user and contextual links no longer would be, so we need to look at refactoring those either way.

Wim Leers’s picture

#105: Interesting! So you're saying that getting rid of the typical "reply/delete" comment links in favor of contextual links would actually improve performance, right? :)

Note that ideally we could leverage (session|local)Storage to cache the rendered results on the client side. I'm already doing that for Edit module in this 8.x contrib module: http://drupal.org/project/edit_metadata_cache. See this (very short) issue on why that can't live in core: #1872264: Minimize metadata HTTP requests triggered by Edit's JS — basically: "the most crazy dynamic access mechanisms might be at play, e.g. only allow X between 13:00 and 13:05 on Tuesdays". If we'd have better predictability here, then we could do client-side caching, and avoid a lot of hits to the server.

Gábor Hojtsy’s picture

Ha, interesting, indeed it sounds like if we remove the operations links from comments, the comment rendered can be cached more widely, lowering cache footprint and making it faster to retrieve a rendered comment.

Wim Leers’s picture

A consequence of that would be though that only browsers with JS enabled would be able to comment. I don't think that's necessarily a problem though? What's the current policy around this?

effulgentsia’s picture

I think that would actually be a problem. So far in HEAD, contextual links are only used to provide quicker access to things you could also do without them, so them requiring JS isn't an accessibility concern. However, making it so that you can't edit, delete, or reply to a comment without JS would, I think, be an accessibility problem. Please correct me if I'm wrong, but AFAIK, despite most blind users currently using screen readers without turning off JS, there are still both blind and sighted users who do turn it off, and some governments and organizations continue to require that all website tasks be possible for those users to perform.

Wim Leers’s picture

#109: they can still consume the content, just not create content. It might be reasonable to require JS? Also, non-sighted users are more likely to have JS enabled: http://wimleers.com/talk-drupal-speaks/#/6/5. If governments require no JS to work… that's a different story of course.

catch’s picture

Reply doesn't really feel like a contextual link to me, have never seen reply done that way in other interfaces. If that doesn't require contextual module/js the rest isn't so bad. For caching it means per role but not per user.

Although we have comment permalinks they're shown in the comment listing so there's nowhere to put tabs. It'd be possible to have an own comments view with operations links as a fallback though so that doesn't feel insurmountable.

effulgentsia’s picture

#111 (leaving Reply as a non-contextual link, plus having a "My Comments" View to allow people without JS or "access contextual links" or "administer comments" permission to still be able to edit their comments) would address my #109 concern.

effulgentsia’s picture

Though let's consider the use case of drupal.org. For when we move d.o. to D8, will we give "access contextual links" permission to all authenticated users? If not, then does that mean editing an issue comment will require going to a "My Comments" View, rather than being able to do it with the handy "edit" link we have now? Not that we should make Drupal software decisions based solely on the needs of drupal.org, but I think it provides a good model for lots of other sites where comments are a major component of the site.

LewisNyman’s picture

hm, I didn't think we were suggesting exposing contextual links to front end users as an interaction pattern? This has a bad UI implication based on a performance improvement.

Bojhan’s picture

@Lewis Could you clarify what you mean? We have been exposing it to site builders, and we do indeed wish to show it to content creators as much as possible too. Its not really something we want to show to end-users (people who post comments).

LewisNyman’s picture

That's what I meant, we shouldn't expose this to "people who post comments". It sounded like that's being suggested as well, is that right?

catch’s picture

There's other ways to handle the comment links for performance other than converting them to contextual links - it'd mean similar js-replacement based on comment author + current user + permissions.

For example, we could move 'delete' and 'unpublish' to contextual links and leave edit/reply where they are, then open a separate issue for the caching issue with edit.

jcisio’s picture

#117 I think it is contrib's job. Drupal core should not care about which links are cacheable and which are not, for each website configuration etc. Contrib should be able to override easily core behavior.

catch’s picture

@jcisio: there's an open issue to add render caching for entities, since comment entities are part of the node render output it's not possible to cache nodes without also being able to cache comments, which means fixing this in core.

jcisio’s picture

I followed that issue. Is it possible to cache comment per role/user only (i.e. use drupal_render_cid_parts(DRUPAL_CACHE_PER_ROLE) + array($user->uid == $comment->uid)) ? Yes, I know it is dirty and broken, but it is usable and let's have more complex logic in contrib. Ìf core is simple and solves 95% problems, and contrib is capable of solving the other 5% then it's good.

It is as simple as filter caching system. If a module comes with complex permission system, it marks an input format as non-cacheable or invalidates the cache when necessary.

catch’s picture

@jcisio: it's possible to cache comments per user yes, but doing that for one link that can very easily be shown/hidden client-side is extremely wasteful.

jcisio’s picture

By #120 I didn't mean per user, but per ($user->uid == $comment->uid) and roles, i.e. so that it works with "popular" permissions.

catch’s picture

Ah OK gotcha! Yes that's a lot better for comments.

We'd still be caching per-user for the full node page, but if comment_node_view() is handling this it could change the cache granularity itself or disable it altogether for that.

jcisio’s picture

Wim Leers’s picture

Category: feature » task
Status: Active » Closed (fixed)
Issue tags: -sprint

Originally, this was a feature request. By now, most of those features have gone in. This was just the meta issue. So I guess this should've been a task all along. Updated.


While it #105–#124 is a very interesting discussion about how to deal with actions for comments in specific, AFAICT, the conclusion I posted in #104 still holds true. The fact that nobody challenged it, seems to confirm that. This issue is about a general approach, not the one off case.

Hence I'm marking this issue as fixed.

I propose that you open a new issue, catch, to continue this discussion for comments in specific, just like you said in #105.

Wim Leers’s picture

Issue summary: View changes

Update for issue duplicate change.