I suppose What You See Is What You Get has its place, but as an OCD addled programmer, I have a problem with WYSIWYG as a one size fits all solution. Whether it's invisible white space, or invisible formatting tags, it's been my experience that forcing people to work with invisible things they cannot directly control … inevitably backfires. A lot.
So is the UI slick? Yes, but it suffers from the same problem that almost all other current editors have: I have to save and switch contexts in order to see my results. What a productivity drain.
I know many web developers (including myself) who eschew fancy IDEs in favor of developing in the browser itself: using Firebug or equivalent to ‘live preview’ changes as they are being typed into the window. No save, no refresh, rather immediate results.
The Glimpse thing is pretty damn cool. That said: It would be nice if there was an argument for complete separation of content, structure, and effects that wasn’t 15 years old. (The linked article of Nelson’s is from 1997.) We’ve all had a lot more experience dealing with that kind of integration; editing markup inline with content was a relatively new thing in 1997 (yes, I realize there are prior examples), but we’ve all been doing it for over a decade at this point.
It might be true that for certain domains (writing textbooks?) a more rigorous separation might be valuable, but I’m not certain there would be much value in forcibly splitting apart the content and markup of a website, especially when the content is frequently a tiny fraction of the overall number of bytes involved.
Hey Jeff,
I completely buy how important this approach is. Have you checked out Bret Victor’s awesome video on visualizing code? https://vimeo.com/36579366. It totally blew me away.
We obsess over how to teach young kids to code. Stuff like this rocks…
Keller
www.Romotive.com
I was just about to share that same video, KellerRinaudo. Good post, Jeff. And I agree with KellerRinaudo, check out that video. It’s really inspiring stuff.
I’d been thinking recently about how people often say that HTML vs. CSS is a way to separate content from layout. However, that actually seems like a bad place to try to make that division, because there are a bunch of layout-related things that live in the HTML part. For example, you might have to edit your HTML to add a new class to a div so that you can style that class in the CSS, or reorder the divs in the HTML so that one will ‘float’ to the correct place.
So, actually, this 3-layer model seems to map fairly well to the reality of how things are separated in most blogging/CMS tools:
The line between “structure” and “polish” is blurred about the same amount between HTML and CSS as it is in the conceptual definitions of those levels that you give above.
I really liked the Glimpse screencast and wonder how it could work with or handle more complex rendering stacks. Particularly in web development like a LAMP stack.
That said I’ve created a quick AutoHotKey script to play with with this idea. Basically same thought of holding down a key >> preview in a web browser >> let go of key >> back to editing. I hope my hacked together partial-solution helps someone else out there 
Code: https://github.com/AnthonyRL/Glimpser
Screencast: http://screencast.com/t/KqDskktPKqqa
Valletta (http://itunes.apple.com/us/app/valletta-markdown-editor/id504794951?mt=12) is an app that demonstrates another interesting approach – it’s a markdown editor that renders a live preview for everything except for the line under the cursor which is displayed as raw markdown.
It seems to me that the anchoring of higher levels becomes possible with proper version control. So the answer is in the operating system.
I was at Bell Labs in the 90s and we had it there in the Sablime source control system.
I don’t understand how we’ve sat through decades of OS development and version control is still something only used by programmers (and not even all of them).
You can have something similar to Valetta for LaTeX with Emacs + AUCTeX (Preview-LaTeX part of AUCTeX). You can have live preview (in a separate window) with Emacs + Whizzytex (the problem here is invalid input during writing). You can go from preview to source with source specials enabled.
Jeff, have you looked at XPages from IBM? There you have that split between data (stored in Domino databases, relational databases or other sources), business logic/functionality (using Xpages/SSJS) and finally polish (using CSS).
I am not an expert on Xpages, I just started developing with it, but there are plenty of resources and blogs about it where you can find out more. http://www.xpages.info is a good start.
I filmed a Xpages jumpstart session at the IBM conference Lotusphere that show Xpages development, about 2-3 minutes into the video there is a slide that explains the architecture. Take a look at http://youtu.be/0ViUTfAzoTo if you like.
Nice idea, Anthony!
I too would recommend watching Bret Victor’s video.
There’s actually a forth option: hide markup and use visual means (font face, color etc.) to highlight text structure (WYSIWYM). WYSIWYG is not of much help anyway if your content is to be rendered in several formats (i.e. HTML and PDF). If you limit styles to the most essential ones then Markdown or any other markup could be used behind the scenes.
I recently began exploring this approach at http://www.textseditor.com and would appreciate feedback.
Can you ever truly separate markup and content? What if you want emphasize a word in your content? You would need some sort of syntax to highlight the word. What if your content required a table, that it only made sense when contained in columns and rows?
This exists for CMS applications as well. The theory is that you only store “content” in the database, and “style” in the presentation. For basic content that works, but falls apart with real world usage.
I used in a generated and annotated documentation project XML and XSL, outputting HTML.
The generated HTML had a CSS stylesheet and used JavaScript for some interactions.
It seems to me pretty close to the 3 layers split.
I had no tool, though, to easily switch from generated markup to content view.
But the XML contained >90% content. Of course, the XSL can be quite complex, especially when mixing the HTML markup inside.
The gliimpse project seems promising. Someone might create a MarkDown version for stackoverflow Editting text still rules, but a lot of work can be done to make it better.
I think if the last 50 years have taught us anything, there is no utopia. And I’m far more afraid of the problems with keeping content synchronized with it’s separated mark-up than I am of having light mark-up mixed into the content. The Ted Nelsons of the world make us think … truly a good thing. The Tim Berners-Lees of the world give us working systems that often don’t live up to the high expectations of the theorists, but they’re availably today.
Personally, I’m scared of people that try to persuade you to strictly follow one or the other.
Actually, not all things should evolve at the same rate.
Also a good developer not always have to see invisible things to control them, when coding or typing, he knows what will be the output.
And there is fourth interface or option, but it is used commonly in drawing/CAD/painting applications.