As someone who is currently writing a WYSIWYG editor for the web (http://ghosted.it (currently in alpha, only compatible with chrome/FF)) I find this really interesting. I have found that if you want to produce good code, then people do need to have some concept of how the basics of the format works (e.g. CSS floats), but they shouldn’t need to know the actual syntax.
Personally I don’t see any need to go to a full code view (in theory, with a good enough editor). WYSIWYG controls are more than capable of handling basic headers and if you need/want to use TeX for complex formulas then this should be available in the area it is needed. Custom CSS values should be editable from within a visual interface, and rendered in real-time.
Cross-browser (almost), usable WYSIWYG editing is not impossible, it is just very difficult and time consuming to implement (and I certainly don’t have enough time to do it). The problem with offering a code view, is that this means that the WYSIWYG editor has to be able to handle arbitrary code, and not only be able to render it, but provide intuitive editing controls for it (ever tried pasting a complex layout into TinyMCE’s code view and then trying to edit it in WYSIWYG mode? Hidden elements galore. Even with a good understanding of HTML and TinyMCE’s behaviour I can’t work that one out).
IMO it is better for WYSIWYG editors to constrain themselves to what they can do (and producing good code for basic headers/lists/columns they certainly could).
That was awesome! But in this and many other videos (including Bret Victor’s) I see another interesting trend - we’re finally about to step over some kind of threshold in processing power where we can truly SEE what we are doing WHILE we are doing it. I’d say that these approaches don’t replace WYSIWYG - they are the next generation of WYSIWYG! Made possible by the vast amount of unused processing power we’re starting to get in our computers. I’m excited to find out what else people will come up with the insanely powerful multi-core CPU’s of today and tomorrow!
Comes tThis article, and most of the comments, all miss an essential point. The presentation is the content.
This white elephant of content and presentation, model and view, etc. is something thats plagued our user interface design for ages. That is why doing proper localization is so difficult, why text editors are so primitive, and why trying to separate out html and the “content” almost always results in some ungodly mixing of levels.
I dont have the answers, but as a thought experiment I offer the following question: commonly we see the content feeding into the presentation layer, but what if we reversed that and instead visualized the presentation details feeding into the content? CSS comes to mind, of course, as do some of the less formal markup languages, where the way something is rendered as resolved as a function of the markup symbol, rather than the layout adding content.
Neither of those techniques are ideal. Someone much cleverer than I will, soon I hope, come up with a contextual rendering system, probably tied to a good natural language parser.
For web stuff I use the side-by-side approach, with LiveJS, works great.
Pitch from their website: “Just include Live.js and it will monitor the current page including local CSS and Javascript by sending consecutive HEAD requests to the server. Changes to CSS will be applied dynamically and HTML or Javascript changes will reload the page.”
Separating the layers vs. inline markup seems like MVC Frameworks vs. PHP. One is more Theoretically Good; and one is friendlier to a much wider audience. At least in part because there’s nearly zero bootstrapping: “highlight and click one of these (font face/bold/color/etc.) buttons” in the word processor is good enough to get started; a fancy Styles library that lets you re-face/bold/color/etc. your document by editing the style set is an Advanced Feature that may be introduced/discovered later. If Styles were the only way to do it, that whole model needs to be learned before it produces useful knowledge.
I used to work on a project, where I had 3 layers like you said, namely XML, XSL-T and CSS. Unfortunately XSL-T isn’t very good for the exact purpose it is created for, because it’s a functional language that is supposed to walk through data - even lacking at that. It has no iterations, variables, reliable complex conditional statements or even cross-platform mathematical tools. It was interesting to use it, but in the end it was such a mess to work with it, that the next time I wanted to present data from XML on HTML+CSS I just ended up making a code to code compiler for it in Python…
Context is often forgotten when people think about these things. If you assume a context if plain web content (without floating elements and such), then this approach is great.
If you are thinking about writing a book, then structure is more important so that everything can be presented in a consistent style and the content is removed from the formatting. Here I think somthing like DocBook, XML-XSLT, etc. are good given you use a good editor for them.
For code, Bret’s approach is excellent as it also encourages better programming (smaller chunks of code with single responsibility etc.)
For more visual stuff like a modern website that may load content dynamically and bits need to be designed individually to show/hide this content you need a different approach. Here I think the only solution I have seen work is getting youself two monitors and use live preview editors like editing a page in FireBug.
Hence there is no “right” answer. A simple WYSIWUG editor for stuff like comments is “just-right” for its content but totally awkward for writing a book. Vice versa DocBook or XML/XSLT is overkill for writing comments in a blog. And neither are good enough for designing a dynamic webapp.
Quite nice as an idea. However, I don’t think it approaches solving the content->structure->effect problem. I think Nelson’s idea is the correct-yet-unachievable statement by which we should just strive to get as asymptotically close to as possible.
The problem is that Nelson’s approach, while correct and provides for a living document that scales with the technology, required the work to be done three times. You can ask me to do the work once, even twice, but three times?
A good example is something that I do on a daily basis: Kuali Rice (kuali.org) presentation. To do it “The Kuali way”, I have to create a Java object, a JSP presentation layer, and a data dictionary. Same problem as above: I’m doing the same work three times. In practice, I don’t do the data dictionary and simplistically do the JSP (i.e. just enough to make the customer happy).
The correct approach isn’t WYSIWIG, it’s to present “good enough” structure and effect layers to start with, let content creation occur, and then alter the structure and effect layers as part of the editing process. Perhaps I should just shut up and create that system…
Didn’t Word perfect do this back in the day? It was WYSIWYG, but you could toggle the visibility of mark up at the touch of a button. Delete one tag and the other tag would be removed.
Actually they still put markups with the plain text but the markups represent an idea rather than a style. So we end up with :
First Layer : Text + markups expressing the role and meaning of the content
Second Layer : Correlation between the markups and the style