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

Consider removing the trailing inserter in favor of a clickable area #3078

Closed
jasmussen opened this issue Oct 20, 2017 · 10 comments · Fixed by #3623
Closed

Consider removing the trailing inserter in favor of a clickable area #3078

jasmussen opened this issue Oct 20, 2017 · 10 comments · Fixed by #3623
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... General Interface Parts of the UI which don't fall neatly under other labels.

Comments

@jasmussen
Copy link
Contributor

Right now we have a trailing inserter that lets you insert content at the end. There are also hover buttons to the right of this. This is working reasonably well, but it is also a design that was created before we had a slash command, and before we had the "insert between" shortcut. As it stands, this gives us 4 ways to insert content — from the toolbar, in between, using the slash command, and at the end.

In most content editors, clicking below all the content simply sets focus there, which lets you either insert new content, or start typing. Perhaps with recent advances in insertion by other means, we can retire this interface?

It could look like this:

mini redesign

Just click at the end of the post — the white area below — and you'd be in a paragraph where you could type, or use the slash command. There would be no placeholder text like we've tried in the past, doesn't even have to be a special cursor.

We'd probably want to combine this feature with a change to how the inserter works when focus is in an empty paragraph. That is, it should work like the slash command inserter does, and replace the empty text block.

Thoughts?

@jasmussen jasmussen added the General Interface Parts of the UI which don't fall neatly under other labels. label Oct 20, 2017
@gziolo
Copy link
Member

gziolo commented Oct 20, 2017

Just saying that it would make the following UI issue non-actionable:
screen shot 2017-10-19 at 11 38 01

I wanted to fix it, but now I'll wait until we decide what to do next with the very bottom inserter :)

@jasmussen
Copy link
Contributor Author

jasmussen commented Oct 23, 2017

Here's how Medium does it:

click below

☝️ that's an image at the end. There is no linebreak until the white area is clicked. It's a "fake" textarea.

@folletto
Copy link
Contributor

This seems a solid idea.
Very solid.

I keep thinking that the "on editor canvas" (+) buttons add clutter and remove focus from the (+) Add button in the top toolbar.

If we have a reliable method to add on the toolbar and a single fast method with the cursor (and typing) I think it's more than enough.

@paaljoachim
Copy link
Contributor

That looks very interesting!

I think we should have a predefined outline around an area we can call the canvas or document. This area one can click into this area and just begin writing. It should be easy to just write and adjust the writing with easily available text options.

I made this issue: #3539 which is somewhat similar.

@afercia
Copy link
Contributor

afercia commented Nov 20, 2017

Of course this should be done in an accessible way. What the "clickable area" would be in terms of semantic HTML? How that would be announced by assistive technologies? How that would work when using only the keyboard?

Worth reminding any UI control should be properly labeled, whether it's a textarea, an input field, an editable block, a button, etc. Ideally, labels should be visible. If there's a strong design need to hide the labels, a possible trade-off would be hiding them visually with screen-reader-text or similar CSS technique.

@jasmussen
Copy link
Contributor Author

So, we had this merged in, and then reverted again due to some keyboard troubles, and suggestions to resurface the trailing inserter. Here are mockups for addressing the latter.

1, you hover near the end:

trailing inserter 01 hover near end

2, you click that spot, and get a textarea to type in, and a clickable inserter on the left.

trailing inserter 02 click near end

3, if you start typing, it's business as usual:

trailing inserter 03a started typing

3b, Otherwise, you can click the inserter on the left, which is also mostly business as usual

trailing inserter 03b inserter clicked

The big difference is that the trailing inserter is not visible until you've put focus in the trailing placeholder.

Thoughts?

@folletto
Copy link
Contributor

folletto commented Dec 7, 2017

reverted again due to some keyboard troubles

May I ask a short tl;dr summary of what were the issues that made us to revert? Just to understand and give more grounded feedback.


That said, this direction seems a good one to explore: simple, reusing all our elements. :)

@jasmussen
Copy link
Contributor Author

jasmussen commented Dec 7, 2017

May I ask a short tl;dr summary of what were the issues that made us to revert? Just to understand and give more grounded feedback.

The details start here, but the summary is:

  • I'd made the hit area for the placeholder bigger, making the container jumpy when clicking
  • A good argument was put forth for why the trailing inserter plus might still be viable, even if in a less emphasized way
  • Arrowkey navigation from the title to the first placeholder broke
  • Clicking this empty area, then clicking away, created an empty placeholder block, which should probably be snipped if you didn't type anything

@youknowriad
Copy link
Contributor

Closing as this is now a thing.

@paaljoachim
Copy link
Contributor

Nice! The above approach seems to create a much better text writing flow.
I look forward to trying it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
6 participants