Re: [tw] Will or will we not have WYSIWYG in Tiddly v5

[Jeremy Ruston]

Hi Rocker

I scrapped the WYSIWYG explorations I did back in the first beta of TW5 in 2010 for a number of reasons:

* Marrying WYSIWYG with wikitext is a hard problem to solve, and I felt that my efforts were better spent elsewhere (see how long Wikimedia have spent getting their new visual editor ready)

* Perhaps because of the rise of Markdown there seems to be a groundswell of opinion that WYSIWYG isn't the nirvana it first appeared, and the advantages of explicit markup are more widely appreciated.

I'd be interested to understand the usecase you have in mind,

Best wishes

Jeremy

On Fri, Mar 1, 2013 at 9:20 AM, rocker909 <equite...@gmail.com> wrote:

A couple years ago the tiddlywiki people were working on a fully wysiwyg tiddlywiki 5. But I saw today from the demo page that there's no wysiwyg at all. Very disappointed. Anyone know why it's been scrapped?

--
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 tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Yakov]

пятница, 1 марта 2013 г., 18:00:07 UTC+4 пользователь Jeremy Ruston написал:

Hi Rocker

I scrapped the WYSIWYG explorations I did back in the first beta of TW5 in 2010 for a number of reasons:

* Marrying WYSIWYG with wikitext is a hard problem to solve, and I felt that my efforts were better spent elsewhere (see how long Wikimedia have spent getting their new visual editor ready)

I guess that's the most important point for now.

 

I'd be interested to understand the usecase you have in mind,

I'd say that writing scientific texts with (math) formulae would be much easier with WYSIWYG, not because it's better to use WYSIWYG for formulae themselves, but because it's easier to edit TeX when you see the context. Like I pointed some time ago [1], what I'd expect of W-G in TW is the possibility to edit simple stuff like lists via W-G and and have "wikiboxes" for everything else: wikibox is a part of W-G area clicking/moving the cursor by keyboard arrows to which opens its plain wikitext. This approach is extendable: first one can implement W-G for lists and headers and such simple things, then for tables, for some simple macros, then for more complicateds stuff including manual sorting of lists/table rows, W-G for formulae (actually, that's not needed, only preview would be useful), for transclusion etc.

Not exactly W-G but rather an idea of "partial editing" is now developed in TWtid and Co [2] which is a very useful stuff.

[1] https://groups.google.com/forum/?fromgroups=#!searchin/tiddlywiki/A$20really$20simple$20WYSIWYG$20concept/tiddlywiki/EbF4J7yraZU/EJT8UTovd1cJ

[2] https://groups.google.com/forum/?fromgroups=#!searchin/tiddlywiki/twtid/tiddlywiki/0FT6iBneYOk/VPIxUbQOiF4J

[Adam Sneller]

HI Jeremy,

I'd like to 2nd this. Like Yakov, I am also interested in using TiddlyWiki for scientific notetaking. I think this make a terrific Log Book and Journal.

In the past, I have really enjoyed using LyX for writing LaTeX. Instead of taking a straight WYSIWYG approach, LyX takes a WYSIWYM (what-you-see-is-what-you-mean) approach. In other words, don't clutter the editor with formatting but still give the user a preview of the rendered LaTeX.

I think something like this that perhaps renders the Markdown code as you type (or highlights the syntax) would be helpful.

A couple of other approaches that look promising:

1. There is really cool jQuery plugin called writemaths. This creates a LaTeX preview that hovers above as you write your equations. jQuery plugin. Here is the link to github: https://github.com/christianp/writemaths
2. SciNotepad take an approach similar to LyX. Looks promising... but I think they are using ASCII math instead of LaTeX.
3. Confluence has a terrific WYSIWYG environment. Like Basecamp, this allows the user to insert blocks of content, or widgets (a todo list, a text block an image). You can then drag and drop each block to reorder it on the page(pretty cool).
   

Anyway, I love working with TW and I would love to see its development continue to evolve!

[PMario]

On 1 Mrz., 23:16, Adam Sneller <adam%earth2adam....@gtempaccount.com>
wrote:

> In the past, I have really enjoyed using LyX for writing LaTeX. Instead of
> taking a straight WYSIWYG approach, LyX takes a WYSIWYM
> (what-you-see-is-what-you-mean) approach. In other words, don't clutter the
> editor with formatting but still give the user a preview of the rendered
> LaTeX.

This may be of interest: http://math-template.tiddlyspace.com/

> I think something like this that perhaps renders the Markdown code as you
> type (or highlights the syntax) would be helpful.

this may be of interest for realtime syntax highlighting.
http://youtu.be/J5tq5xv0FHU?t=5m2s
here is the full list of supported types: http://codemirror.net/doc/modes.html

The new codemirror library also supports mixed font sizes:
http://codemirror.net/demo/variableheight.html

have fun!
mario

[PMario]

I forgot this one: http://codemirror.net/mode/tiddlywiki/index.html
-m

[Adam Sneller]

Thanks Mario—these look promising!

[DaveG]

Yes, and it interesting the path that markdown editors are moving...
WysiwyM in fact - with an emphasis on have a rendering available - rather than editing the rendered version-- and highlight as a typing assist.

Examples would be markdown composer, byword and marked.

U
I also use LyX a lot and I like the way this separation helps me write - it is easier to focus on words -- and leave the formatting till later. And with LaTeX the formatting is always uniform and that is such a time saver compared to Word. At first this separation seemed like it could be a loss, but it really a gain.
So I think more people will come to this understanding too.

Best regards,

Dave

[Vincent Yeh]

I might have figured a way (by accident actually) to mimic the WYSIWYG behavior. Although still in the primitive stage, you can try it here https://dl.dropbox.com/u/23745840/pre_release-1.5.1%2B0.7.8.html.

The idea actually came from a careless bug that I recently created, and it seems to work!

Comments and suggestions are highly welcome!

Vincent

[Tobias Beer]

Hi Vincent...

You example does not work for me at all, neither in Chrome, nor Firefox, nor IE. Is that one of these Dropbox issues?

What I see is this CE jumping around all over the place but...

* not where the mouse is

* it's also not clickable

Personally, I woud prefer to not even have this CE thingy at all but rather just CLICK or perhaps ALT+CLICK on anything in order to edit it. The thing is, if this is your wiki, then you know what to do, no need for a clue.

Cheers, Tobias.

[Vincent Yeh]

Tobias,

I agree with you that those flying buttons are annoying. Actually I have planned to remove them in the near future. Now they are there for debugging purposes.

I don't know why it doesn't work over the internet, it doesn't work for me either. It works on my local copy, though. Did you try save it locally?

Vincent

[Tobias Beer]

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. 

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.

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.

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?

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.

[Vincent Yeh]

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.

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...

I have posted a reply over at the TiddlyWikiDev group...

https://groups.google.com/d/msg/tiddlywikidev/vNQi6i9lj-k/hWRi2o2QjUAJ

Cheers, Tobias.