Tobias, On Thursday, March 7, 2013 3:30:27 AM UTC+8, Tobias Beer wrote:
> Thanks Vincent, > > 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 -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
