Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Editorial comments/notes #17949

Closed
ellatrix opened this issue Oct 15, 2019 · 12 comments
Closed

Feature: Editorial comments/notes #17949

ellatrix opened this issue Oct 15, 2019 · 12 comments
Labels
[Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@ellatrix
Copy link
Member

I had started work on comments (or notes if you like) on text or blocks inside the editor. I soon realised that this might require some design input. One big influence is, of course, Google Docs. I like the way the comments are always visible, but we might not have the space for that with the sidebar (inspector). Alternatively, the list of comments could be displayed in a list in the sidebar, and kind of move next to the marked text when it is clicked on (the comment or the text). The downside of this is that the comment list wouldn’t be always visible.

@ellatrix ellatrix added [Type] Enhancement A suggestion for improvement. Needs Design Needs design efforts. labels Oct 15, 2019
@karmatosed
Copy link
Member

This is really exciting! There might be some previous explorations to use from the Comment API work: #3026.

Topbar and in sidebar: #3026 (comment)

41223822-273fdace-6d6b-11e8-81d2-d57c3199f517

41223816-23933be6-6d6b-11e8-9375-b1d90ee720a7

41223826-29242250-6d6b-11e8-83f6-4ddb96c60637

Outside: #3026 (comment)

54441071-3daf0180-473c-11e9-8780-4a6017625d94

54441043-2b34c800-473c-11e9-919d-056b5058af08

Kudos to @hedgefield and @uxkai for explorations.

@ryanwelcher ryanwelcher pinned this issue Oct 18, 2019
@ryanwelcher ryanwelcher unpinned this issue Oct 18, 2019
@mapk
Copy link
Contributor

mapk commented Dec 27, 2019

Here's an idea spurred from the concepts above. I'm making use of the sidebar because we have it. I'm also suggesting we use "Comment" as a mode in the new mode selector for Edit and Select. It might fit nicely there.

Selecting the "Comment" mode swaps out the sidebar with comments and shows all the highlighted comment areas on the page.

Clicking through each highlighted part shows new comments in the sidebar.

Link to prototype

comment 2019-12-26 20_42_29

@mapk mapk added Needs Design Feedback Needs general design feedback. and removed Needs Design Needs design efforts. labels Dec 27, 2019
@karmatosed
Copy link
Member

karmatosed commented Jan 6, 2020

I would like to bring us back to a few points to decide on before we go through with any design here. Just as a bit of consideration as there are some assumptions in the prototype (which are fine if we agree):

  • Is the new place to interact with anything that is a different interaction going to be the mode drop down?
  • Is commenting a mode?
  • Is adding a 3rd use to the sidebar a good route forward?

Now, I have a few thoughts relating to this myself. I personally don't see commenting as a mode so would argue against putting it in same buckets as the others. You can edit and comment for example. I don't see a precedent for mixed modes yet (we might be establishing one).

If I think of the use case of commenting for example in Google docs, I do so 'on the fly' and I don't have to switch modes to do that. This is why I think some earlier explorations around this might be good to follow.

https://user-images.githubusercontent.com/253067/66833422-bd5fb180-ef53-11e9-878e-17c4887b047b.png

I think though bringing back to my first points, we need to have some clear IA on the modes and rules around that before jumping into this being the design direction.

One consideration is I think without indicating it's the 3rd sidebar and just laying it over, that's quite a jarring experience. Of course, if commenting is to be a separate mode that might be acceptable, but what if I am in that mode and have sidebar turned off or on a smaller screen?

@jasmussen
Copy link
Contributor

jasmussen commented Jan 6, 2020

Great thread, great ticket, great feature. I'm so excited someone is working on this. My instinct for this is also that a sidebar is a good place for this.

The old editor, "Editorially", was so lovely in this respect. I don't have good screenshots, all I could find was this:

78edaa1682dc2e381bd24ee7ffb0f791_3

But in this one, it looks like commenting was indeed a "mode" that was invoked by activating the sidebar. I don't necessarily think it needs to be a mode in the block editor (and modes should definitely not be invoked by simply opening a sidebar), but it could be a mode invoked by selecting a tool from the dropdown, as suggested. This is equivalent to Figma where clicking the comment bubble changes into a mode where a single click adds a comment.

I will say, though, that if we do make it a tool/mode, like Figma, we should sleep on this idea for a while, think about it long and hard, and only do it if we feel it's SUPER right. We definitely don't want the tools dropdown to become a kitchen-sink :)

@mapk
Copy link
Contributor

mapk commented Jan 6, 2020

I personally don't see commenting as a mode so would argue against putting it in same buckets as the others.

If the term "mode" is difficult, which I totally understand, we call these "tools" in the actual popover in Gutenberg. In which case, the Comment tool would be active when selected. I imagine it's similar to how Figma does it.

Screen Shot 2020-01-06 at 11 29 37 AM

Figma's sidebar also switches over to a commenting system.

Screen Shot 2020-01-06 at 11 40 17 AM

My concepts are just thoughts being shared. I totally dig how Google Docs does it and would choose that first, but based on the original issue, I was under the impression that wasn't going to work so well for us here.

@karmatosed karmatosed added Needs Design Needs design efforts. and removed Needs Design Feedback Needs general design feedback. labels Jan 6, 2020
@karmatosed
Copy link
Member

Just swapping out labels to encourage those iterations.

@jasmussen
Copy link
Contributor

If the term "mode" is difficult, which I totally understand, we call these "tools" in the actual popover in Gutenberg. In which case, the Comment tool would be active when selected. I imagine it's similar to how Figma does it.

To be clear, I'm cautiously agreeing with you that the Figma tool/mode combination might just be right here! The only reason I'm cautious is to suggest, and to echo Tammie, that this is something worth sketching/figma-prototyping out in somewhat high detail so that we can build up the confidence I feel should be necessary to add the tool!

@hedgefield
Copy link

Great to see some action on this concept again. I've been short on time for more explorations, so thanks a bunch @mapk for jumping in with a new prototype. The modes dropdown feels like a natural place to put the commenting sidebar toggle that I had in my old mockups, it didn't exist back then or I would have probably come to the same conclusion :)

That said, I agree with the point that leaving a comment should be a no-brainer anytime anywhere action. But I don't think these have to be mutually exclusive.

I think the act of commenting can be integrated into the writing and editing mode easily. It could appear when you highlight a sentence or a block, open a popover to type into and that's it. This is similar to what Notion does in the screenshot that Tammie posted above.

Taking action on comments then could use a dedicated sidebar that shows all the comments and replies in their entirety and you can go through and respond. This also wouldn't have to exclude editing, as to edit text you don't really need the sidebar. This means you can comment and continue working without the burden of a separate mode, and only summon all comments when necessary. And I'd vote for making that possible from every comment indicator in the document, instead of explictly having to go to a mode dropdown.

I hope this makes sense to anybody outside of my head too! I've made a quick sketch to support the idea visually. Thoughts?


@mapk
Copy link
Contributor

mapk commented Jan 8, 2020

Hey @hedgefield! Glad to see you coming back to this. 😄

But I don't think these have to be mutually exclusive.

I agree here! The combination that you presented works quite well together.

This also wouldn't have to exclude editing, as to edit text you don't really need the sidebar. This means you can comment and continue working without the burden of a separate mode, and only summon all comments when necessary.

Good points! 👍 I didn't dig into that experience in detail quite yet, so I'm stoked that you did. Allowing a way to just add a comment from the "Edit" mode feels intuitive and bringing some sort of way to do that close to the content is the way to go.

@karmatosed
Copy link
Member

This is great @hedgefield, good to see more exploring around this. I wonder what other than a sidebar could be used? I know there were some explorations right back in phase one we went through that I think took it interestingly out of there.

@paaljoachim
Copy link
Contributor

paaljoachim commented Mar 17, 2020

What I found interesting in Gutenberg 7.7 was the placement of the Block Patterns in the sidebar. Even though they later will be added to the Block Inserter screen. The concept of turning on something that shows up in the sidebar was very interesting.

Screen Shot 2020-03-17 at 23 17 46

Advantage
It does not add any icons to the top toolbar.
It is a little more hidden away. Does not create visual clutter.
Uses the sidebar to create notes.
It can become the new user interface area to add special features.

@karmatosed karmatosed added the [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later label Apr 6, 2020
@karmatosed karmatosed added this to the Future milestone Apr 6, 2020
@karmatosed karmatosed added Needs Decision Needs a decision to be actionable or relevant and removed Needs Design Needs design efforts. Needs Decision Needs a decision to be actionable or relevant labels Apr 6, 2020
@Soean Soean mentioned this issue May 4, 2020
@mtias
Copy link
Member

mtias commented Sep 29, 2024

Closing as this is superseded by #59445.

@mtias mtias closed this as not planned Won't fix, can't repro, duplicate, stale Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

7 participants