How do we resolve the classic tension between WYSIWYG and markup . Alas, one can't explain that properly in blogger, but if you follow this link, you'll see what I mean.
Framemaker may be the most enjoyable document editor I've used. Markdown-like notations on the one hand (too limited, no semantics) and full HTML/CSS (too rich/complicated, few standards for semantics) on the other hand are two ends of something better in the middle. I'm not sure Makado is in the middle. It's kind of at the crossroads of a number of disparate systems.
"Moreover, all these principles apply beyond text editing."
This is really interesting to me, given the correspondence to many kinds of domain-specific editors.
A few questions:
1. Do you see full-custom editing of HTML/CSS as important to an Ampleforth document? (Are they called Ampleforth documents or is Ampleforth more a capability within an HTML document?)
2. Will the WYSIWYG editor necessarily be less capable than the markup? i.e. given enough time to fully develop a WYSIWYG editor should it be every bit as capable as editing the markup?
3. Do you see the markup taking on more semantics as with Framemaker? Would those extensions only be represented as live Newspeak objects? Could there be a reason for a new kind of markup element being implemented in Newspeak but not 1:1 with a Newspeak object?
I agree about Madoko. Of course, I'd like LaTeX, but it doesn't really extend to live elements (though I suppose one could try an extension). So in a sense Madoko would be a good target markup, but it adds a complex dependency.
As for applying these principles beyond text, think about extending documents from 2D to 3D. I won't go to deep on this just now, but think of Croquet (both the original 20 years ago, and the current croquet.io) or other XR systems.
Answers, FWIW:
1. Yes, full editing of HTML in Ampleforth documents is important. Of course, in a perfect world, we wouldn't use HTML, but rather a custom markup that was a sort of duel to Newspeak. It would in fact, be the language used for string interpolation in Newspeak string literals (but I digress). In any case, that is not an ocean I want to boil. 2. I want to enrich the WYSIWYG side so that using the markup is rarely needed, and I think that's plausible. However, I think that the possibilities in the markup are ultimately greater than in a GUI, no matter how elaborate. 3. Good question. I'd like to say no, but the temptation is always there. As for the 2nd question, I'd hope not.
I'm really enjoying the live-editing demo, Gilad, and I look forward to watching the YouTube videos when I can, to understand more of how it's built! The demo page has the feel of an interactive session in Squeak Smalltalk, but as a natural-feeling extension of a web browser. So neat.
I didn't know about Madoko before. Neat! I would think it can be a good intermediate representation for a site like the one discussed in this article--i.e. that the projects may combine very well, if everyone is interested. In general, markdown languages have taken over. They're everywhere and with good reason. Madoko seems to be an especially good one.
Back to the demo, I must say that flipping back and forth between markup and the rendered version is powerful. With a WYSIWYG editor, you can't really tell for sure what you've written. There are forever little artifacts that aren't what you meant at all, and they can be hard to fix without being able to flip to the markup view. There are a few tools that work like this, and I'm surprised it's not more common. Wordperfect is an example. If you use Markdown in certain editors such as IntelliJ, it'll work like that. You can edit either side, I believe. Most tools just support one or the other. Google Docs can be infuriating if it gets the wrong idea about what you're trying to do. There are many things such as indentation that are invisible in the rendered text but are important to understand as you edit things going forward.
Markdown is better than WYSIWYG for extension. You can produce and consume markdown in other tools, because it is parseable text of its own. It therefore has many applications outside of producing an entire standalone document. Ticket systems and any form of registry would be examples; you often want a "description" field, and it's usually better if the user can supply a little bit of formatting.
Markup is also good for internal extension. It lets you add new elements to it, and it potentially allows the end user to write their own macro tower.
LaTeX is beautiful in many ways, and also shows some ways that can be better. The biggest limiting factor on my mind is that the way the macros work means you cannot parse text into a syntax tree without knowing the macro definitions. Smalltalk started out that way, where each symbol would eat as much of the following text as it wants to, and implement its own sub-language, but it didn't last long. I can't speak for the gang's reasoning, but there's certainly a value in being able to parse a program even if you don't know what all the words mean. The ability to do so is a necessary property if you want people to look at part of a program, and understand part of a program, without having to understand all of the program.
The above is also a pragmatic issue, in that you can't really process LaTeX as an input. Since you have to delve into the macro definitions to know what the text really means, you essentially can do nothing with it except (a) render it, or (b) guess. As such, LaTeX is both beautiful in many ways, and yet poignantly limited outside of its sphere of dominance.
I'll (finally) stop there. Thank you so much for sharing.
Nice to hear from you! You make excellent points and I pretty much agree with them. I've never fallen for the temptation of macros, despite their vast powers, because they inherently introduce a stratification of static vs. dynamic, and I don't believe it's worth the price.
My goal is to make Ampleforth my go-to editor for everything. I think it's within reach. It should provide a combination word-processor, note taker, presentation manager, text editor, computational notebook, IDE and eventually GUI builder. It will take a while, but the great thing is that I can free myself from the ever decaying products of Apple, Google etc.
The old HoTMetaL HTML editor does something similar for tags, resembling in a way Morphic halos, a means for editing details from the WYSIWYG view. https://images.app.goo.gl/HkpZXRxNW9FXomfC6
Framemaker may be the most enjoyable document editor I've used. Markdown-like notations on the one hand (too limited, no semantics) and full HTML/CSS (too rich/complicated, few standards for semantics) on the other hand are two ends of something better in the middle. I'm not sure Makado is in the middle. It's kind of at the crossroads of a number of disparate systems.
ReplyDelete"Moreover, all these principles apply beyond text editing."
This is really interesting to me, given the correspondence to many kinds of domain-specific editors.
A few questions:
1. Do you see full-custom editing of HTML/CSS as important to an Ampleforth document? (Are they called Ampleforth documents or is Ampleforth more a capability within an HTML document?)
2. Will the WYSIWYG editor necessarily be less capable than the markup? i.e. given enough time to fully develop a WYSIWYG editor should it be every bit as capable as editing the markup?
3. Do you see the markup taking on more semantics as with Framemaker? Would those extensions only be represented as live Newspeak objects? Could there be a reason for a new kind of markup element being implemented in Newspeak but not 1:1 with a Newspeak object?
ReplyDeleteI agree about Madoko. Of course, I'd like LaTeX, but it doesn't really extend to live elements (though I suppose one could try an extension). So in a sense Madoko would be a good target markup, but it adds a complex dependency.
As for applying these principles beyond text, think about extending documents from 2D to 3D. I won't go to deep on this just now, but think of Croquet (both the original 20 years ago, and the current croquet.io) or other XR systems.
Answers, FWIW:
1. Yes, full editing of HTML in Ampleforth documents is important. Of course, in a perfect world, we wouldn't use HTML, but rather a custom markup that was a sort of duel to Newspeak. It would in fact, be the language used for string interpolation in Newspeak string literals (but I digress). In any case, that is not an ocean I want to boil.
2. I want to enrich the WYSIWYG side so that using the markup is rarely needed, and I think that's plausible. However, I think that the possibilities in the markup are ultimately greater than in a GUI, no matter how elaborate.
3. Good question. I'd like to say no, but the temptation is always there. As for the 2nd question, I'd hope not.
I'm really enjoying the live-editing demo, Gilad, and I look forward to watching the YouTube videos when I can, to understand more of how it's built! The demo page has the feel of an interactive session in Squeak Smalltalk, but as a natural-feeling extension of a web browser. So neat.
ReplyDeleteI didn't know about Madoko before. Neat! I would think it can be a good intermediate representation for a site like the one discussed in this article--i.e. that the projects may combine very well, if everyone is interested. In general, markdown languages have taken over. They're everywhere and with good reason. Madoko seems to be an especially good one.
Back to the demo, I must say that flipping back and forth between markup and the rendered version is powerful. With a WYSIWYG editor, you can't really tell for sure what you've written. There are forever little artifacts that aren't what you meant at all, and they can be hard to fix without being able to flip to the markup view. There are a few tools that work like this, and I'm surprised it's not more common. Wordperfect is an example. If you use Markdown in certain editors such as IntelliJ, it'll work like that. You can edit either side, I believe. Most tools just support one or the other. Google Docs can be infuriating if it gets the wrong idea about what you're trying to do. There are many things such as indentation that are invisible in the rendered text but are important to understand as you edit things going forward.
Markdown is better than WYSIWYG for extension. You can produce and consume markdown in other tools, because it is parseable text of its own. It therefore has many applications outside of producing an entire standalone document. Ticket systems and any form of registry would be examples; you often want a "description" field, and it's usually better if the user can supply a little bit of formatting.
Markup is also good for internal extension. It lets you add new elements to it, and it potentially allows the end user to write their own macro tower.
LaTeX is beautiful in many ways, and also shows some ways that can be better. The biggest limiting factor on my mind is that the way the macros work means you cannot parse text into a syntax tree without knowing the macro definitions. Smalltalk started out that way, where each symbol would eat as much of the following text as it wants to, and implement its own sub-language, but it didn't last long. I can't speak for the gang's reasoning, but there's certainly a value in being able to parse a program even if you don't know what all the words mean. The ability to do so is a necessary property if you want people to look at part of a program, and understand part of a program, without having to understand all of the program.
The above is also a pragmatic issue, in that you can't really process LaTeX as an input. Since you have to delve into the macro definitions to know what the text really means, you essentially can do nothing with it except (a) render it, or (b) guess. As such, LaTeX is both beautiful in many ways, and yet poignantly limited outside of its sphere of dominance.
I'll (finally) stop there. Thank you so much for sharing.
Hi Lex,
ReplyDeleteNice to hear from you! You make excellent points and I pretty much agree with them. I've never fallen for the temptation of macros, despite their vast powers, because they inherently introduce a stratification of static vs. dynamic, and I don't believe it's worth the price.
My goal is to make Ampleforth my go-to editor for everything. I think it's within reach. It should provide a combination word-processor, note taker, presentation manager, text editor, computational notebook, IDE and eventually GUI builder. It will take a while, but the great thing is that I can free myself from the ever decaying products of Apple, Google etc.
Moar prior art: "Reveal Codes", WordPerfect
ReplyDeleteInteresting, thanks!
ReplyDeleteThe old HoTMetaL HTML editor does something similar for tags, resembling in a way Morphic halos, a means for editing details from the WYSIWYG view.
ReplyDeletehttps://images.app.goo.gl/HkpZXRxNW9FXomfC6