Idea: highlight editor when user clicks on live preview

markdown-it-review

(Alexander) #1

Ok I’ve done this like ten times now. I’m mostly done with writing a post, and I’m reading through the preview just to the right of the editor. I rambled a lot so I’m scrolling through it over there with my mouse. I’m following along with my mouse a litle bit, moving it out of the way of the next paragraph or whatever. Oh then I see a typo, so I double-click on the word, it’s selected, then start typing it correctly, and nothing happens. What? So I click again, the word unselects, so I double-click again, the word selects again, so I start typing again and what is going on, my keyboard doesn’t work or something? Oh wait the editor is on the left and I am looking at the preview on the right. Then I feel like an idiot for a minute for trying to type into static text.

How about if the editor highlights itself or blinks or something if you click on the preview, to remind you that the editing happens over there, not where you’re reading?

It would be real fancy if it could point out where in the editor the spot you’re trying to click on actually is.


I just noticed that scrolling through the editor makes the preview scroll to try to keep up with what you’re looking at in the editor. However, it doesn’t work the other way around. Making that work in the other direction might also help experts like me.


Compose preview box is too distracting
(Sam Saffron) #2

@balpha implemented something like this as a stack exchange plugin, but its very very complicated to say the least.


(probus) #3

I’ve been guilty of this many times as well…

I like the highlighting idea. There is already a blue highlight around the left panel, how about flashing it when the user clicks the right panel. Perhaps the preview panel could also be restyled differently to help prevent this?


(Jeff Atwood) #4

The easy thing to do is move focus back to the left (editor) box when you click on the right (preview) box and begin typing. We should definitely do that @neil.

At least that way typing wouldn’t be lost, though who knows what the insert point would be…


(lid) #5

There is actually a simple CSS modification that can help the user understand that the preview box is not editable.
by simply changing the cursor to the default cursor.

Option1 (css only)

#reply-control .contents #wmd-preview {
cursor: default
}

Option 2 (javascript)
with javascript we can have a bit more creativity, this will change the cursor to not-allowed cursor and only when the user mouse is down. The change will be very brief a split of a second. Enough for the user to see it.

You can try in console while the composer is open
edit: we can also add focus back to input (like @codinghorror suggested). In chrome it will trigger an outline fade in. and the caret will be in the last position prior to the lost of focus.

$("#wmd-preview").mouseup(function (){
$(this).css("cursor","auto");
if ( Discourse.Utilities.selectedText() == "" )  $("#wmd-input").focus(); //set focus on the input element if there  is no selected text by the user
});

$("#wmd-preview").mousedown(function (){
$(this).css("cursor","not-allowed");

});


Option 3 my least favorite (CSS)
change cursor to not-allowed and background gray out to indicate that the box is not editable. using css :hover
problem with this, that this cursor at least on windows is too dramatic. and make the user feel like something is wrong
and it is too much like get out of this box as soon as you can kind of message.

#reply-control .contents #wmd-preview : hover {
cursor: not-allowed
background: #F7F7F7
}

this is how it will look with this css


(Sam Saffron) #6

I really dislike big :no_entry_sign: its off putting. Also I sometimes select and copy stuff from the preview pane.

Would prefer we defer on a fix here and wait till we have a sane preview-sync going.


(lid) #7

@sam So option number 1 for you.
You can still copy in all three scenarios


(Jeff Atwood) #8

Agree cursor default seems harmless.


(Alexander) #9

The last time I did this, I feared that I had been typing in the editor, and unintentionally deleting stuff I had meant to keep, because I still hadn’t found where my cursor is.


(Nukeador) #10

This topic makes me wonder, why do we need two panels by default?

Why we can’t write directly in a rich editor instead of the text mode? Wordpress for example allows this (Visual/Text) modes.


(Jeff Atwood) #11

Because of this:

http://blog.codinghorror.com/invisible-formatting-tags-are-evil/

Watch the animated GIF.


(Jeff Atwood) #12

Anyway, the basic preview sync @sam talked about (and @velesin worked hard with us to make happen) is in.

That means @lid’s excellent option #1 now seems really safe here, so I am putting it in.

#reply-control .contents #wmd-preview {
cursor: default
}

(Jeff Atwood) #13