14

This markup:

first<strong>second</strong>

gets rendered as

firstsecond

and now consider the task of inserting character in between first and second words. User should be able (predictably) to chose where to insert the character: after t in "first" or before s in "second" so inside that <strong> span.

Ideally it should be two caret positions (marked by |):

first|<strong>|second</strong>

But this clearly has UX implications, e.g. both caret positions share the same place on rendering canvas/surface:

first|second

so user will see caret "stuck" while LEFT/RIGHT navigation.

I have solved this in my blocknote.net by inventing "directional caret", when caret arrives to that position from the right it caret stops here:

first<strong>|second</strong>

and if caret arrives from the left it stops here:

first|<strong>second</strong>

This works OK so far but the main problem is in visual feedback - after some time when you see caret blinking at that position you cannot determine where next character (say, 'X') typed will go, it could be

firstX<strong>second</strong> or
first<strong>Xsecond</strong>

Any idea of how to modify caret rendering to show its "real" position? In Sciter I've added "trail" to the caret:

caret with the trail

but something tells me that it can be made better, so asking.

In fact there other "unusual" caret positions that I am handling in next version, for example position in between <ul> and <ol> here:

<ul>
  <li>ul item</li>
</ul>
<ol>
  <li>ol item</li>
</ol>

it is required to allow text (e.g. <p>) insertion between these two lists. Ideally chosen caret rendering should support such cases too.

4
  • 3
    This is something that's an annoyance in nearly all word processing apps. I think your 'directional' solution is fine as it will help those that know, but those that don't have likely already figured out their own workarounds to deal with this. I don't think you need to go out of your way to provide feedback.
    – DA01
    Jan 21, 2015 at 5:23
  • A bold and normal caret?
    – paparazzo
    Jan 21, 2015 at 15:56
  • @Blam this is not only about bold or italic, consider abc<a href>def</a> for example.
    – c-smile
    Jan 21, 2015 at 17:02
  • A left caret and a right caret? I like what you have now.
    – paparazzo
    Jan 21, 2015 at 17:17

3 Answers 3

6

Regarding the caret design, see what Raskin described in Humane Interface. Use arrows as an indicator to show where the text will be added. You can do something similar to show where text gets added.

Cursor design from Humane Interface

1
  • Page 134 / section 5-5 in my copy (third printing, 2001)
    – duozmo
    Sep 2 at 19:29
1

I don't know you need to over think this. Namely because this is a problem that exists today for most any user of MS Word or nearly any word processor. Most of us have come up with our own workarounds already.

Your 'directional caret' solution is clever, and I like it. And it's pretty slick. Not everyone will find it, or know about it, but I don't know that it's that big of a deal.

In addition, anyone that knows HTML will just jump out of WYSIWYG mode and put their cursor exactly where they want it.

But if you're determined to provide some sort of feedback, one suggestion that I've seen in some WYSIWYG editors is to provide some context as to where in the DOM you are below the editing window.

So in your first example, coming from the left, it may look like this:


    ---------------------------------
    | first|second                  |
    |                               |
    |                               |
    ---------------------------------
    <p>

and from the right:


    ---------------------------------
    | first|second                  |
    |                               |
    |                               |
    ---------------------------------
    <p><b>

UPDATE:

Based on your comment, if showing any HTML is just out of the question (something I'd argue against, but I digress) you could still show the 'state' the cursor is in via some form of identifier (thanks to Jcl's idea):


    ---------------------------------
    | first|second                  |
    |                               |
    |                               |
    ---------------------------------

and from the right:


    ---------------------------------
    | first|second                  |
    |                               |
    |                               |
    ---------------------------------
    [bold]

This would be a much more complex solution to implement, however, as you'd have to decide what becomes an indicator vs. not. Jcl points out that you could simply activate the applicable toolbar icon. This is perhaps the best option for standard text formatting. But your second example of 'first list vs. second list' is, alas, not easily solvable without exposing some level of HTML/DOM structure to the user (as visually, it's irrelevant to them--it will just look like one list).

I'd still encourage the HTML breadcrumbs. It will help people learn over time. Alas nearly every site I've managed that relied on content authors having full access to a WYSIWYG editor ultimate led to really horrific markup--especially after a half dozen cycles of edits.

14
  • Thanks. The goal is to make an editor "for the rest of us". And not exactly for HTML, markdown serialization for example is there too. As others. So breadcrumb/path visualization is the least thing I want to do - it is far from editing "focal point" and too tech-y I would say. So I am still looking for metaphors that can help "internet writers" to create content without diving into HTML/CSS depths.
    – c-smile
    Jan 21, 2015 at 6:02
  • The way Word (or many other editors) solve the "is the next character bold or not" question is just having the toolbar button pressed or not. This of course, won't help if you don't have a toolbar, but having a WYSIWYG editor without a toolbar is not very common.
    – Jcl
    Jan 21, 2015 at 7:43
  • @c-smile the catch is, it is HTML. And if the ultimate goal is to create HTML, I'd argue a little insight into that isn't a bad thing. Think back to the days of Wordstar, for example. If HTML is too techy for this audience, I'd argue a WYSIWYG editor is the wrong tool for them to begin with. It will only lead to bad HTML which will frustrate both them as authors and the readers. I'd look into more structured content input and formatting at that point.
    – DA01
    Jan 21, 2015 at 8:09
  • The irony is that the best way to use a WYSIWYG HTML editor is to first understand HTML. I've seen some crazy markup created by non-HTML people trying to use a unstructured WYSIWYG HTML editor.
    – DA01
    Jan 21, 2015 at 8:11
  • 1
    @Jcl toolbar or something like it will be there but it cannot indicate state reliably. Consider this: <b>aaa</b><b class="foo">bbb</b>. That's extreme of course but ideally should be supported.
    – c-smile
    Jan 21, 2015 at 17:07
0

enter image description here

To answer this question I have done an test in WYSIWYG (Dream weaver) and I split the design and code section to see what happen there ,I think in all circumstances it goes to second place that you mention I mean at s location not at t . even when i delete the strong section in code it goes to next line and also in design mode it show a little space, so i think it predictable and it goes to second place, hope i could help you. enter image description here

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.