Inline Editing and TWted

[Tobias Beer]

Hi Vincent, this relates to the following discussion from the TiddlyWikiGroup:

https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/n7LTYB7toXs

Answers in the next post...

Thursday, 7. March 2013 08:25:10 UTC+1 by Vincent Yeh:

 

Tobias, 

 

Locally, I can now edit things. Quite a lot of functionality you've put in there, looking at all the options.

What I do like...

• being able to click and edit stuff right at the spot
  
• being able to trigger formatting using __, // and ''
• although you must know that you need to close it the very same way you openened it which also holds true for TiddlyWiki markup, yet from WYSIWYG I would expect otherwise

Please forgive me for the length of the following list, but I must say that I find the current editing / preview in many respects quite un-intuitive. 

 

I am very glad to receive constructive comments, especially when they are long. That means you had spent a lot of time trying and writing, and that tells me you think it could be useful. I am very thankful for that.

Many of your comments are from the editor's point of view instead of the coder's. They are showing me good directions. I like them! I understand many of them are confusing, some of them confused me, too. It's still primitive and under development, many of them will be fixed along the way.

 

So here are the things that I find confusing...

• there are so many modes and they are switching somewhat arbitrarily back and forth
  
• by default, there is the view-mode of the element
  
• then, when I click on the edit button for something editable, there (sometimes) is a plain text input 
  
• above it (sometimes immediately) a preview panel appears
  
• (sometimes) also a (browser?) dropdown may appear below the text input showing the last edit
  
• then the simple input disappears when I use arrow keys and the preview panel turns into an even bigger preview
  
• however, sometimes, both the input and the preview panel are displayed together, yet entering happens only in the preview panel, which I find rather confusing
  
• the preview is translucent, which can help understanding what happens, but watching the actual wikitext below has a somwhat debug'ish feel to it
• the preview editor being a lot bigger than the item itself and not at exactly the same spot as the element being edited makes things jump around quite a bit, not to mention my focus ...it all feels very fiddly
  
• in edit mode, the popup preview sometimes overlays the editor, so I can't get to or see what I am entering
  
• other times, if I toggle up and down keys, the mode toggles between preview editor and text input ...however, inputing text switches back to the preview editor... that's a whole lot of jumpiness whereas I never quite know whether I edit or view something and where exactly
  
• using up and down arrows may make the editor jump quite farther than I'd expect, leaving out some text between
• after I hit enter on an element, the input box may be displayed again... why? ...I'd believe hitting enter means done
• there is no more double clicking to edit the tiddler ...and I really did want to
• then, markup magically (but partially) appears (like @@) using left and right keys in the editor (very confusing) and I can't (or worse, really shouldn't try to) edit anything, because if I (accidentally) put something between @@ and dare hit enter, then it all gets scrambled
  
• (un)indenting lists is very difficult; it took quite a while before I kind of figured it out (somewhat) ...but I was never sure, If I had it right
  
• copy and paste is quite difficult as you may actually input stuff at the wrong spot (or end) and thus eliminate some crucial markup
• underneath it all still is the old dom element rendered as before, but (almost) empty ...current list bullets are still there
  
• when I try to get at the start of a line, I often find myself jumping to the previous element, same at the end for jumping to the next element
  
• on some edits the whole tiddler refreshes, so the spot I edited now is back to view mode and getting back to where I was involves another round of fiddling
  
• then the preview also (sometimes) displays nested lists (even though I can see them already)... however editing obviously has focus only on one item, so it jumps back (if it actually does)... so, the multiline preview / editing really just clutters the view
  
• selecting (the right text) or any text sometimes works, sometimes it doesn't and you need to click some more (at the right spot, if you find it using the mouse)
• actually, selecting text using ctrl+shift+arrow happens in the input underneath the popup ...so you kind of see what you select... kind of

I guess, for an inline-edit mode, my personal suggestion would be more along one of these methods...

a) (ctrl-)clicking an editable item, a simple text input / textarea would appear (by default) below the thing that I want to edit and editing the text immediately wikifies the edits at the corresponding dom element being edited. Once, I click save, saving the new wiki text should be somewhat a snap, as I have already entered wiki format.

This is what I was heading. As I was trying I found some of the elements are easy to be refreshed, while others not, especially those with "sub-elements of the same type" (like sub-lists in a list or sub-blockquotes in a blockquote). So the current solution is to wikify the text in a preview panel and leave the original element untouched until changes accepted. I am still working in this direction and hopefully a good solution will come out soon.

 

b) pseudo-edit the dom element directly by inserting text, character-by-character ...yet only providing for the most basic markup, like bold, italic and underline... not the whole fancy-schmancy. If at all, in this mode, any changing of dom structure, like (un)indenting lists should happen instantly... no clicking enter to save and see ...using tab and shift-tab for lists or headings. Anyhow, in live-preview-mode, I would never show any wiki markup in the input. The input could really be 1 character wide directly in the location where you expect the result and just be 'where you type'... while being immediataly rendered.

In both cases a) or b), the original dom element(s) being edited would be hidden and you would rather edit an initially 1:1 copy... modifiying it directly with your edits. Clicking enter would 'commit' the changes and replace the original element with the new stuff while saving the tiddler if applicable.

Whether a) or b) are possible or only some parts of it, I would not know. However, I would not mix both. Either I edit using plain wikitext at the size of an element -- or I edit WYSIWYGishly in-place with the most minimalistic input element... the rest remains 'as is', no additional popup or panels.

My opinion is they are possible, at least a good part of them. It's not yet, but will be.

 

All in all, editing to me is the mode where I want to do nothing but use the keyboard. Really, moving the mouse to the right spot should always be a means of last resort. The best editing environment to me is something like WriteRoom or FocusWriter... totally distraction free... why would I need or want to learn about editor features that I hardly ever need to use?

 That's a good direction to think about. Thanks.

 

I guess I more and more find myself a passionate markup proponent. If anything, I would suggest a watered down preview in edit mode whereas the text is only partially wikified for the given context in a preview pane that never distracts me from writing stuff.

Kind regards, Tobias.

Thanks a lot for the comments and suggestions. They really gave me good directions and inspirations.

Best regards,

Vincent 

[Tobias Beer]

Hi Vincent...

This is what I was heading. As I was trying I found some of the elements are easy to be refreshed, while others not, especially those with "sub-elements of the same type" (like sub-lists in a list or sub-blockquotes in a blockquote). So the current solution is to wikify the text in a preview panel and leave the original element untouched until changes accepted. I am still working in this direction and hopefully a good solution will come out soon.

Can you give some more details on what exact approach(es) you tried for refreshing the existing dom and some details on the kind of problems you were facing?

Headings seems (somewhat) straight forward to me, as all you need to do is increase the level, e.g.

Assuming we know it's a heading and someone used either of tab (to increase) or shift-tab (to decrease)...

level = parseInt( $h_old[0].nodeName.substr(1) ); 

if(ev.shiftKey) level = level > 1 ? level -- : 1; //previous level

else level ++; //next level via tab

$h_new = $('<h' + level + '/>').hide().insertAfter( $h_old );
$h_old.children().appendTo( $h_new );
//TODO reset the input focus / rerender it appropriately
$h_old.remove();
$h_new.show();

Trying to imagine this, as you can see from the TODO comment above, I could think that your editor might lose focus of where you were last editing. Would that be one of the problems you were facing? But then how is that different from a <b> in a <span>? Seems the same trouble of finding the right spot for rendering the input element focus. Also, if the actual input would be inside the heading, then it would have moved with it over to the new heading... and returning focus to it might be all that is needed, if even.

Lists would probably go down a slightly different route. You would need to inspect for...

1. the outer ul / ol
2. any preceding li
   
3. any following li

And provide means to...

1. give the user a simple way to decide on an (allowed) list type of the current item
• although items that the level should always be of the same type
  
• mixing types in the same indentation makes little sense (to me), e.g...
  
1. a
2. b
• x
1. c
• y
• the above are entirely new lists of their own type, obviously
2. let the user indent / outdent using tab and shift+tab
• this must consider the type of the preceding element
• outdenting should be restricted to one level highter than the previous
• TiddlyWiki can't handle anything else either
• although I would argue that this rather is a bug (/ missing feature) [1]
• the following li may need to be rerendered into the right list
• altough as a first guess, it should remain as it was
• unless we had a means to select and move multiple lines at once
• which seems a very complex issue that I would avoid
3. add a new list item!

So from my perspective it really boils down to starting with one individual feature and getting it right and then move to the next... not try and achieve all at once.

I am very glad to receive constructive comments, especially when they are long. That means you had spent a lot of time trying and writing, and that tells me you think it could be useful. I am very thankful for that.

I'm really glad you take it that way... I tend to criticise much an that can have a discouraging if not annoying effect... neither of which being intented.

My opinion is they (a and b) are possible, at least a good part of them. It's not yet, but will be.

When developing stuff, it's good to tocus on a desired core functionality and doing so with one (prioritized) feature at a time. Right now, I would say that TWted tries both of a) and b) and I find that to be a problem. So, do you have plans to...

• A) focus on Wiki Format (=a) and entirely take b) out of the focus
• B) focus on WYSIWYG (=b) and entirely take a) out of the focus
• C) make the mode switchabe, but not in the fiddly 'live' way that it currently is, but rather as a global setting
  

I guess focussing on B) is what you seem to be been after mostly ...at least, that probably involved the most effort.

Beyond of what I have seen so far, a formatting toolbar (not unlike the one in newer versions of MS Office) above or below the editor might be helpful in either case, e.g. which gives you some of the usual rtf editing buttons... but obviously handle them differently in a) or b)... so you can click on the desired format, instead of having to know that you can press '' and things start to get bold... but that's probably a feature for version 10, not version 1.

https://ssl.gstatic.com/editor/editortoolbar.png

Either way, there probably are some edits that need sanitation, for example while semantically I can do this in html...

1. level 1
1. level 1.1.1
2. level 2

... I really can't do this in TiddlyWiki as...

# level 1

### level 1.1.1

# level 2

...will not work. So some 'sanitation' may always be needed to eventually save consistent wikitext that doesn't get swallowed.

Many of your comments are from the editor's point of view instead of the coder's. They are showing me good directions. I like them!

I think it's crucial for ALL software to have the user perspective be the #1 priority and spokesperson, not what is technically possible and how. Of course there always are constraints, but all of them  eventually have implications on the user perspective, e.g....

• if a system was too expensive, it's not a business problem
• its the user not bying it
• if the server or client would take 10 seconds to commit an edit, then it's not that the machine is to slow and the required hardware too expensive
• it's the user not using the software because it is unresponsive
• if its hard to use the software its not necessarily a lack of or poor quality of its documentaiton
• its the user (rightfully) refusing to learn stuff that is hard to use 

Always look from the user perspective first. Now, I start to sound like someone in TRON and I hated that movie, hail the users ;-)

I understand many of them are confusing, some of them confused me, too. It's still primitive and under development, many of them will be fixed along the way.

I think what you have accomplished neither is primitive, nor broken... it just is, and as such rather complex and feature rich ;-) ...although there is such a thing as 'featuritis'. So, from my mindset, the eventual piece of art - and I am positive that it will see the light of day - is when you get to discard all the distracting bits and reduce the thing to the very productivity-enhancing essence... like some artist and a handful of strokes expressing so much that you cannot but stand in awe ot the creation...

https://www.youtube.com/watch?v=JFSB3-SzgoQ

Just to complete the picture, there also is the other end of the scale, some form of 'simplicitis', e.g. when things are reduced (for whatever constraints) to a barely usable feature set, like the mail apps that ship with windows 8 or good old ms paint that far outlived its deserved half-life. But then again it's the user saying: 'Why on earth would I use a software that comes with such a reduced feature set while easily accessible and far more productive alternatives have been available for decades?

Cheers, Tobias.

[1] Test this in a tiddler...

# 1

### 111

* a

*** b

# 2

* b

[Yakov]

Hi Tobias,

actually, there's already a thread for TWtid/TWted/TWcalc [1] (I've even mentioned in the WYSIWYG discussion), why create another one? Sure, if you propose some code parts, that's more dev stuff, but when discussion is splitted bewteen several threads, it becomes harder to follow and understand.

Best regards,

Yakov.

[1] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/0FT6iBneYOk

четверг, 7 марта 2013 г., 13:52:59 UTC+4 пользователь Tobias Beer написал:

[Tobias Beer]

Hi Yakov,

Actually, there's already a thread for TWtid/TWted/TWcalc [1] (I've even mentioned in the WYSIWYG discussion), why create another one? Sure, if you propose some code parts, that's more dev stuff, but when discussion is splitted bewteen several threads, it becomes harder to follow and understand.

Not so sure about that. Personally, I'm not a fan of endless threads... or perhaps "the one thread to fit them all". I like having focused discussions. TWtid/TWted/TWcalc's complexity suggests that its far too much for one discussion thread... it's an entire application set. On Github you'd possibly use the wiki and bug tracking to manage it all.

A good discussion for me would is what in other systems corresponds to a comment thread on a single question, bug or feature request. If all that ended up in a single thread, that's where I tend to lose track.

Cheers, Tobias.

[Yakov]

четверг, 7 марта 2013 г., 16:51:50 UTC+4 пользователь Tobias Beer написал:

I see. I'd note though, that the discussion I mentioned is rather new (the old >200 posts was switched to another one) and also that because of active development by Vincent, there always were tons of ideas, bug reports and discussion in the thread, so there's no chance to use a separate discussion for each one. And the latest builds (1.5.1 and 1.5.0) are quite buggy.. I haven't finished the testing yet. Now I'm not even sure where to report the feedback when I do finish.

Best regards,

Yakov.

 

Cheers, Tobias.

[Tobias Beer]

Hi Yakov,

Now I'm not even sure where to report the feedback when I do finish.

I'm pretty positive that Vincent will find you(r feedback)  ;-)

From my perspective, if you do a whole lot of testing and report on a lot of findings... I think it's sound to open a thread... unless Vincent has opened one called 'Please test my new version and report here.' ...if that exists, then I may indeed have missed it / would have better posted there.

Multiple threads may be difficult for Vincent to keep track of, but maybe not. Perhaps, they rather help to stay focused rather than wade through a large number of possibly long, possibly only marginally related replies.

Cheers, Tobias.

[Vincent Yeh]

Hi Tobias,

On Thursday, March 7, 2013 5:52:59 PM UTC+8, Tobias Beer wrote:

Hi Vincent...

This is what I was heading. As I was trying I found some of the elements are easy to be refreshed, while others not, especially those with "sub-elements of the same type" (like sub-lists in a list or sub-blockquotes in a blockquote). So the current solution is to wikify the text in a preview panel and leave the original element untouched until changes accepted. I am still working in this direction and hopefully a good solution will come out soon.

Can you give some more details on what exact approach(es) you tried for refreshing the existing dom and some details on the kind of problems you were facing?

Headings are already done in the current release so I do not worry about them. What's not yet is when the user changed the level of a list item. Your suggestions below, and Yakov's some time ago, are very useful and saved me quite some time. Thanks!

The refreshing problems I am facing are more technical than logical and most of them I do have ideas how to fix or get around. I just don't have time to get them done yet. I don't like to get you bored with technical problems, only if you like to know:

• Determine the right part of innerHTML to refresh a list item.
• The current way I am trying to refresh the original element is to pull out the innerHTML (using jQuery method .html()) from the previewer and put it to the original DOM element (also using .html()). It works fine for elements with no levels or sub-elements. For a list item I see additional bullets (<UL>) or numbers (<OL>) in addition to the original bullet or number.
• How to fix: need to find the level of item and pull out only the correct part.
• Missing sub-lists when refreshing the original list item
• Currently TWted handles edits the list item itself without doing anything to its sub-lists. With 1.5.0 when you click on a list item with sub-lists attached to it, you see an editbox containing only one line of text (that defines the list item itself), and a previewer showing just the list item (without its sub-lists). When I refresh the original DOM element using .html(), the element gets refreshed for sure, but its sub-lists are gone because the previewer does not have them.
• How to fix: detach the sub-lists from the original element and re-attach back after refreshed.
• Well, let's skip the boring technical problems...

Yakov I suggest you to leave pre-1.5.1 along at this moment, for the pre-release I put out was mainly to quickly show an idea of W-G-ish behavior, it will not be the default behavior in the released 1.5.1.

Actually I have been focusing on (A) instead of (B). I didn't think W-G is possible with wiki style text before, so I started all these with this "micro editing" (or partial editing as Yakov suggested) in mind. I didn't even think of a previewer until Yakov suggested it. That pre-release of 1.5.1 was really a quick idea that popped into my mind when I was fixing a bug recently. The bug was that I accidentally hid the editbox so I only saw the previewer and the original element without the editbox. But I found I was still able to type and the previewer was still updating, that gave me a feeling of W-G-ish behavior. So I thought that might give some one a hint how to do W-G thing with wiki text and decided to post a quick demo. I guess it was too quick. :-)

 

Beyond of what I have seen so far, a formatting toolbar (not unlike the one in newer versions of MS Office) above or below the editor might be helpful in either case, e.g. which gives you some of the usual rtf editing buttons... but obviously handle them differently in a) or b)... so you can click on the desired format, instead of having to know that you can press '' and things start to get bold... but that's probably a feature for version 10, not version 1.

https://ssl.gstatic.com/editor/editortoolbar.png

This I would like to try collaborating with QuickEditPlugin, as suggested by wolfgang a while ago. It will probably start in v2.0... or maybe 10.0...

 

Either way, there probably are some edits that need sanitation, for example while semantically I can do this in html...

1. level 1
1. level 1.1.1
2. level 2

... I really can't do this in TiddlyWiki as...

# level 1

### level 1.1.1

# level 2

...will not work. So some 'sanitation' may always be needed to eventually save consistent wikitext that doesn't get swallowed.

Many of your comments are from the editor's point of view instead of the coder's. They are showing me good directions. I like them!

I think it's crucial for ALL software to have the user perspective be the #1 priority and spokesperson, not what is technically possible and how. Of course there always are constraints, but all of them  eventually have implications on the user perspective, e.g....

• if a system was too expensive, it's not a business problem
• its the user not bying it
• if the server or client would take 10 seconds to commit an edit, then it's not that the machine is to slow and the required hardware too expensive
• it's the user not using the software because it is unresponsive
• if its hard to use the software its not necessarily a lack of or poor quality of its documentaiton
• its the user (rightfully) refusing to learn stuff that is hard to use 

Always look from the user perspective first. Now, I start to sound like someone in TRON and I hated that movie, hail the users ;-)

Very well said! I do agree with you on these.

 

I understand many of them are confusing, some of them confused me, too. It's still primitive and under development, many of them will be fixed along the way.

I think what you have accomplished neither is primitive, nor broken... it just is, and as such rather complex and feature rich ;-) ...although there is such a thing as 'featuritis'. So, from my mindset, the eventual piece of art - and I am positive that it will see the light of day - is when you get to discard all the distracting bits and reduce the thing to the very productivity-enhancing essence... like some artist and a handful of strokes expressing so much that you cannot but stand in awe ot the creation...

https://www.youtube.com/watch?v=JFSB3-SzgoQ

Just to complete the picture, there also is the other end of the scale, some form of 'simplicitis', e.g. when things are reduced (for whatever constraints) to a barely usable feature set, like the mail apps that ship with windows 8 or good old ms paint that far outlived its deserved half-life. But then again it's the user saying: 'Why on earth would I use a software that comes with such a reduced feature set while easily accessible and far more productive alternatives have been available for decades?

I should keep these in mind. Thanks. :-)

I like to see a programmer with a sense of an artist. Best regards,

Vincent

[Tobias Beer]

Hi Yakov,

By the way, today I stumbled over Checkvist [1]. Despite the funny name, it is entirely awesome in how it manages edits... some of which I will definetely (try to) implement in listr which I have neglected for quite some time (hello complexity) but which will come in a really slick version hopefully not to far into the future.

Cheers, Tobias.

[1] http://checkvist.com

[2] http://listr.tiddlyspace.com

[Yakov]

Hi Tobias,

well in terms of TW that's a set of separate cool features which I'd expect to see in different plugins.

List hierarchy changing by tab/shift-tab is nice, but limited to non-touch screens (as well as the other hotkeys). Slider treeview is a feature which is rather natural for TW (NestedSlidersPlugin), but navigation through arrows is rather not. (This arrows navigation is what I want for managing news in TW: if RSS import is established, I'd like to quickly navigate though the list of news via arrows, preview them on the right, delete via del button and add tags on the fly, like Opera does). The "to do" functions ("space" to strike out, "aa" for other styling) is a thing for another plugin.. (I use auto-aggregated lists and tagging for to do lists, although I want more functionality for those and are going to use ForEachTiddlerPlugin when I finish some improvments)

суббота, 9 марта 2013 г., 1:36:55 UTC+4 пользователь Tobias Beer написал:

[Yakov]

I like your approach. Would be useful if listr lists items filtered with a certain filter. Is there a thread for the plugin discussion?

[2] http://listr.tiddlyspace.com