Slashdot Mirror
Animating From Markup Code To Rendered Result
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."
Unfortunately, apart from a demo in .jar format, I don't see a download link.
The biggest F#$@#!!#@ tease - where is that damn DOWNLOAD button?!?
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.
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.
Wow that's amazing!
Now I don't have to press F5 to reload the page when making changes. (Ok, alt-tab first)
What will I do with all the spare time this frees up? Life will never be the same again!!!!!!!!!11one1!!!
Oh hold on a second(hooho), it's quicker to alt-tab then press F5 than wait for the stupid transition.
Yay for frivolous transitions without productive benefit!
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.
Didn't Word Perfect used to have an edit window for the markup at the bottom of the screen, while the top of the screen displayed the formatted text?
I've always thought that was a good idea compared to tools like Eclipse which flip between rendered and raw views (display both on the same tab, people!), but it's definitely not a new idea.
I do not fail; I succeed at finding out what does not work.
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.
For those who have just discovered that they will be using a markup often enough to run into the limitations of WYSIWYG editing, but are just entering the world of the markup code underlying it. An obvious example already mentioned is Wikipedia (or any other wiki). Another great place would be for students just learning Latex.
This method, aside from must looking pretty, does a good job of letting you easily see what parts of the code translate into what parts of the screen.
here's your non-slashdotted link, editors, is that really so hard?
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.
Thank you - right front center .... "doh"
From the demo video:
but then:
<td colspan="2" color=#999999> <center>
Seamless transition from 2012 to 1997! Great Human-Computer Interaction experience.
Can't find shit. Is it really so hard to mention it on your fucking web page? Or at least in the goddamn download? After all, it is the single most interesting thing about a software project.
Some days ago this was discussed here. The video, even if very long,is incredible interesting
http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html
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.HTMLEditorDemo
will work, too.
...and all I saw in the demo was marked-up text.
As a marketing convention, this equivalence of HTML and code is almost as pretentious as Wordpress' notion of equating code with "poetry."
The Bitfighter level editor has had a similar feature for... well, for a long time. Holding tab gives a live preview. Though, admittedly, without any transition animation...
For all the "I don't get it comments", the issue is that people don't understand or like markup languages. This helps people literally see the connection between the markup and the result. This problem was studied and documented extensively by Wikipedia:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study#What_I_see_Vs._What_I_get
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.
tomorrow who's gonna fuss
Where would the animation transition to if you were changing a line in your CSS?
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 the display to show you all your errors and such. This is simply another (very clever, and probably very useful in many cases) application of the idea that the IDE should aggregate information from continuous integration directly in the editing pane, or as close to it as possible.
The larger problem, I think, is that these systems are billed as being for large, complex documents, but that's precisely the case where they fall apart. As an example, I've got a few LaTeX document that is a clunky system of:
-- source managed on git
-- build scripts written with waf
-- a multi-file structure using the subfiles package
-- some latex is literate haskell that is preprocessed through lhs2tex (which looks pretty, but is surprisingly unreadable compared to naïvely typeset haskell, and I'll probably tear it out at some point)
-- some latex is generated by Perl scripts
-- some graphics are generated by Perl scripts
-- tons of macro definitions for common words and symbols
-- indices based on the macros
As soon as you introduce a few layers of indirection, all these sorts of systems completely choke, so the best I've managed is to have all the scripts run in Jenkins so at least I hear it reading out the bugs a few minutes after I commit. I'll also put in visible markers indicating where files begin and end, but that's the LaTeX equivalent of sprinkling print statements throughout my code...
Interleaf 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 copies, since you needed a $10,000 workstation to run it.
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.
We tried something similar to this a while back, it made people feel sick trying to follow the focus with their eyes. I see they haven't improved on it enough to stop that (watch it in full screen, several times in a row).
It's a nice toy, but won't work on extended periods of work, or indeed on complex documents.
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.
Tools-> Web Developer-> Tilt (ctrl-shift-m)
Has anyone any experience with this new feature?
Maybe I'm blind (morning coffee here) but what's the license for this new tool?
I think this would be nice to have as an option. I think it might depend on the document whether or not you'd want to use it. There are some things where you'd rather work WYSIWYG. Then there are some things where you prefer to stay with code. Sometimes split screen is better. Sometimes it's not adequate. Having one more tool in the bag sounds good. This probably takes some horsepower. If your boss says you can't get the bigger monitor because you don't need side-by-side, then tell him you need more horsepower to animate the documents.
In Emacs/psgml, M-x sgml-hide-tags RET (and show-tags, bound to the key of your choice) pretty much does, this, bar the typographics.
Does this for LilyPond on Windows, Linux and MacOS
http://frescobaldi.org/
Wikitext gui editors suck. Badly.
It would be really really helpful to see my wikitext parsed and displayed as I type. pressing Preview is irritating and time consuming.
As it is, I am in the middle of converting a 300+ intranet site that is full of images and markup to Confluence wiki. I really really would like to see my changes resolved in real time, if for no other reason than to spot my code stuffups early.
One little stuffup in wikitext can wreck the rest of the page..
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.
Actually I just wanted to see what it would be like to post on the internet.