Posted
by
timothy
on Sunday March 25, 2012 @08:32AM
from the be-sure-to-preview-your-comment-below dept.

New submitter lulalala writes "Writing documents using markup languages isn't always easy. Take Wikipedia, for example: one often needs time to relocate the current focus when they switch between previewing and editing mode. Now with Gliimpse, one can watch the markup code gradually turn into the rendered result. The demonstration on Youtube simply looks amazing, and shows that the software supports many markup languages, including LaTex Mathematics."

The readme file states that you need Apache Ant to run the demo. That's not true,java -cp gliimpse.jar:lib/bliki-core-3.0.16.jar:lib/bliki-pdf-3.0.16.jar:lib/colt.jar:lib/pdfbox-app-1.4.0.jar:lib/PDFRenderer.jar:lib/swingx-1.0.jar fr.aviz.codeglimpse.uistdemos.HTMLEditorDemowill work, too.

How is that "better" than a browser open you can Alt-Tab to and refresh in two keystrokes? Cognitively it looks like a mess, and I don't see the benefits, even after RTFA and WTFV. I do HTML and CSS for a living and have tried just about every IDE and tool combination that's been available since HTML was born, and (IMHO) nothing beats a code aware text editor and the latest browsers to preview the rendered markup. There just isn't much loss in productivity when you're using keyboard shortcuts to bounce back

How is that "better" than a browser open you can Alt-Tab to and refresh in two keystrokes? Cognitively it looks like a mess, and I don't see the benefits, even after RTFA and WTFV. I do HTML and CSS for a living and have tried just about every IDE and tool combination that's been available since HTML was born, and (IMHO) nothing beats a code aware text editor and the latest browsers to preview the rendered markup. There just isn't much loss in productivity when you're using keyboard shortcuts to bounce back and forth from code to render in less than 3 seconds. Load times? Well, in development those should be almost nil because you should be working from a local dev server on your network. I just don't see the gain from this application's approach, especially when you add in the bane of every WYSIWYG markup editor the ever moving standards support game. The browsers are always ahead of the WYSIWYG editors as far as new standards support.

My thoughts exactly (kinda) when it comes to html editing. People can do fine (and actually do) by simply alt-tabbing+F5.

I do disagree, however, in that it cognitively looks like a mess or that there are no benefits. The algorithms explored in this research *could* be integrated into professional editing tools that spit out html (or any markup for that matter). If all I need to do is press one key to toggle back and forth from preview to editing in a single window, that on itself is efficient (subject to the editing person's predilection) than alt-tabbing+F5 with two windows.

Beyond html, this would certainly help with wikitext or latex. Call me crazy, but I would prefer a single toggle key to preview my wikitext on demand (and certainly with latex, which even with tools like LyX, previewing always take more than a few keystrokes.)

Beyond the actual need for something like this (which people can legitimate question), the algorithms and idea behind this are impressive.

Replying to my own post - why don't markup editors (and word processors for that matter) provide a single toggle key shortcut to switch back and forth from editing and previewing? That would be a far better approach than what is suggested with Gliimpse (get rid of the animation), and than alt-tabbing+F5.

The point is also that you can connect effect and cause of parts of the site. This is not easy by just a preview.

This is also what Bret Victor talked about in Inventing on Principle [vimeo.com]: To be effectively creative and productive, there must be an immediate connection between what you do and the consequences.That principle is broken when you have to go over, and reload. (anything longer than 500ms is broken).

Having just watched the video, it looks like the reason it's better (as alluded to in the summary) is eye focus. When you tab to a different browser you have to then find your place in a potentially large document. Ditto when you tab back. With this thing, if you keep your eye on where you are in one view and follow the animation you end up looking in the right place in the other view.

I find this a genuine problem, and as a solution this looks positively awesome.

I still prefer a method where I can view both the code and the formatted document simultaneously. As for finding the place I need I use Opera Dragonfly which highlights the place in the document that I have selected in the code or finds and selects the part of the code that I have picked in the document.

As a professional code monkey I assure you that no one uses alt-tab-f5 any more.

You edit the code in FireBug and see the change in the upper window. In fact using FireBug is even quicker than the thing demoed here, because the change is instant. No pressing a special key to see anything. You see things change as you type.

How is that "better" than a browser open you can Alt-Tab to and refresh in two keystrokes?

It's not. It's just a pretty animation designed to make people think it's better because it looks fancy. This should appeal to people who buy "hologram wristbands" to promote health and wellness. Or people who consider Dreamweaver experience a "skill."

Cognitively it looks like a mess, and I don't see the benefits, even after RTFA and WTFV.

It reminds me of the shell game. You make a change and then see if your eyes can follow the element while it slides around. Most real world HTML files are going to be long enough that you won't fit all the code on one page, so the element you're trying to find

First of all, this isn't targeted to professionales (from you comment, I guess you do this for a living, or at least, at a very high level).Secondly, it allows users to quickly relate pieces of markup with the resulting view itself. It makes navigation and relating both views easier for less-professional users.

I recently added LiveReload to my coding process (guard-livereload [github.com], LiveReload for Chrome [google.com]), and it eliminates the second keystroke:-p It also has the added benefit of keeping any element styles you applied in the DOM inspector while reloading CSS or JS (which is kind of nifty).

Just use a gui editor. You highlight the text and mark it as bold, it shows s bold, no need to mess about with smoothly transitioning between seeing the markup and seeing the presentation. This sort of problem was solved, better, back in the 20th century.

I really love how a single image and a paragraph turns into a 2MB html file and 10 pages of markup.

Seriously though.
When a gui editor can create easily read code that loads faster than something I can do in the same amount of time with notepad, I'll think about switching, and so will the other 400,000 people on slashdot who do this type of work.

Until then, STFU about gui html editors and let the professionals talk.

When a gui editor can create easily read code that loads faster than something I can do in the same amount of time with notepad

Notepad? Seriously? I mean, I can understand not wanting to use a GUI editor since they all suck, but you're only hurting yourself if you insist on using the second most primitive tool available. (Why not go the whole hog and use EDLIN?)

There are a whole load of things in between that provide conveniences like indentation, tag/attribute completion, on-the-fly validation, etc while

I was using notepad as an example, especially since I know for a fact that I can code a simple web page design by hand in notepad faster than the office's contracted "web designer" with her wysiwyg tools. (we tested it one day after I got irritated and let my mouth get away from me)
I actually prefer to use Vim for editing. (with a ton of customization, and a few wrapper scripts)

If I am working on a web design, I have a large set of tricks that I use to get the best features of GUI editors without the issues.

For example,

I add a javascript autorefresh on a 10 second timer to the header of the page
ssh into the dev server and open the page in all of the browsers that I need to be compatible with. ........(I have a 3rd monitor set aside just for this, and if I have more than a few browsers, I'll open some on my laptop as well)
I also use a script that tests the page for validation errors every minute and changes the background color of my terminal window to let me know I broke something.

Interleaf [wikipedia.org] had that in 1984, on Sun workstations. The markup was in a column alongside the text, and lined up with it. The markup display didn't show the text, just the formatting commands.

Interleaf had a technology that was way ahead of its time. Because of that, they had a terrible business model - Interleaf's main product was a set of four Sun workstations and a laser printer, branded with the Interleaf name. The software alone was thousands of dollars per workstation. They couldn't sell many copie

Man, I miss Interleaf. 20 years after I first used it, there's still no layout tool that manages to do what it did. It's even more aggravating watching Word add pointless features release after release while failing to get right what Interleaf got right two decades ago.

I started to post this in reply to "what's the point"... Or maybe in reply to "I don't think so"... But... The answer is somewhere between the two comments, I think.

This tool would be amazingly useful somewhere in between the "casual" cases where WYSISYG is most prevalent and needed (for those that either don't know the markup, or for whatever reason don't care enough to bother learning it) and those that are masters of the markup. For those that are in the process of learning the code, in other words.

Wikipedia addressed the problem by making a JavaScript GUI editor to hide the markup. IMHO the problem with that approach is that it solves the wrong problem. The problem isn't that the markup is to difficult (although learning more then the basics is), it's that people just don't care to put any effort into understanding it and would rather complain that it's 'to hard'. The solution shouldn't focus on teaching people markup. It should either remove the markup and only allow a GUI, making the encoding inaccessible like document editors do, or use the effort required to understand markup as a barrier to entry.

The demo presents this as the only system you're going to want, which is very trollish, frankly, but I can't really fault them for being enthusiastic about their idea, especially when they've implemented an actual version of it.

Typically, editing usage will fall into the two use cases of writing brand new markup, or editing existing markup.

This looks like it will be far more effective for editing existing markup, and that a live preview will be more effective for writing new material. And you'd clearly want

It is actually quite hard to follow where each part of the text takes its new place in the transition. You can focus on one point ok but seeing the whole text is tough. If I would be using that, I think I would spend a lot of time flicking back and forth between the two views.

That being said, the code behind that gizmo must be quite sophisticated. It's pretty cool accomplishment.

I spent the last half hour or so using the demo provided. It's a bit disorienting at first, but after a few minutes it's very useful at keeping you focused on what you're working on. There is no delay or loss of focus going between editing and the rendered page. I let my kids try it and they suddenly understood quite a few things about nesting and wrapping text with tags that they've been struggling with after just a few minutes of watching their text change as it was rendered. It also worked with CSS so they could see how the same HTML looked totally different with some tweaks to the CSS page.

The demo doesn't let you save anything, but it's still fun to play with. Can't wait until this comes to main stream. All that searching and re-orienting with side by side windows seems so archaic by comparison now. It's like moving to scripting languages where suddenly you're working with live code instead of a compile cycle.

I look forward to this being integrated into browsers or other editors in the future. Keep up the good work guys.

I could see glimpse coming in handy in situations when I'm dealing with someone else's code, and it's a really neat concept. Even if it's faster to ALT+TAB and F5, I like that they're thinking outside the box, I could see myself using both methods and being happy with that.