The technology behind the new Google Docs editor(googledocs.blogspot.com)
googledocs.blogspot.com
The technology behind the new Google Docs editor
http://googledocs.blogspot.com/2010/05/whats-different-about-new-google-docs.html
39 comments
An editor like this would be great for teaching programming. I've been thinking about something like this since Zed's new Python book came out. Having taught several complete beginners, the greatest friction in first learning to program doesn't come from bad pedagogy, but at step 0: getting the environment set up. A web-based coding and learning environment, complete with syntax highlighting and whitespace management, would be wonderful.
Have you looked at Mozilla Bespin? https://bespin.mozillalabs.com/
The replacement of the built in html editor is what all the wysiwyg's need to get so that code generation stays consistent across browsers. Think they will open source at least that portion?
Possibly, but Google Docs doesn't write in HTML anymore. Advanced positioning and stuff like tab stops don't translate easily into CSS, so even if they _did_ open source the editor, the final HTML will look different than what it did in the editor.
Example: create a document with two lines of tab-stopped text with varying lengths, and then export to HTML.
Example: create a document with two lines of tab-stopped text with varying lengths, and then export to HTML.
I hope for the same. The Bespin project by Mozilla is also interesting in this space, they've built a text engine based on canvas. They target code editing but at least they're solving a (very important) part of the same problem.
I have been seriously considering going the Bespin/canvas way myself. I wrote http://bulletxt.zetabee.com/demo using a bunch of textarea tags but having seen how well Bespin works, I think it would be much better to code it on canvas. It would work much better across all the different browsers.
One important thing to consider before going down that route -- the font metrics in the Canvas API are extremely impoverished, so it will be very difficult to do much more than a simple text editor. In particular, there's no support for constraints, wrapping, etc. You can only ask for the width of a given string. This is particularly nasty if you want to do, e.g., asian languages that are hard to segment. The browser desperately needs real font metrics, segmentation, etc.
You're right. Though I could do what Google is doing. They're not doing direct font-on-Canvas, which would be pretty cool actually. They're creating/editing divs/spans on the fly. I already do that with textareas but the problem is textareas work differently on different browsers where different events get fired for similar actions. So technically, I'm doing almost the same thing they're doing at a basic level (pressing enter in middle of a sentence creates a new textarea below the current one and move the text after the cursor into the new textarea).
What I was wondering if I should do or not is create my own cursor management. The benefit of that will be better control over copy-paste, drag-drop etc. I am trying to build an undo system for Bulletxt and in some browsers, you can just drag-drop text in the same text-area without firing any keypress/up/down events. Then I have to hook on to the onupdated/onchanged events which may not offer enough granularity if you make multiple drag-drop actions. Additionally if you drag text from one textarea and drop it into the other, I can't always tell what the source was in all the browsers. Writing my own layout-engine would definitely solve that issue. Plus undo would be very easy because every mouse-click/keyboard would be an event that can be undone.
What I was wondering if I should do or not is create my own cursor management. The benefit of that will be better control over copy-paste, drag-drop etc. I am trying to build an undo system for Bulletxt and in some browsers, you can just drag-drop text in the same text-area without firing any keypress/up/down events. Then I have to hook on to the onupdated/onchanged events which may not offer enough granularity if you make multiple drag-drop actions. Additionally if you drag text from one textarea and drop it into the other, I can't always tell what the source was in all the browsers. Writing my own layout-engine would definitely solve that issue. Plus undo would be very easy because every mouse-click/keyboard would be an event that can be undone.
This is really impressive. Although, I didn't know about contenteditable until a few weeks ago so I thought all of the rich text editors were doing this until then. Is the main thing that rich text editors like TinyMCE give you the toolbar buttons and making inconsistencies in browsers go away?
The browser handles pretty much everything inside the editor including the handlebars for resizing images and tables. Editors like TinyMCE and CKEditor are still very impressive, I've made my own RTE once and it's one giant PITA to get everything to work nicely, especially across browsers.
Would anyone who has experience working with operational transformation care to comment on it? It's mentioned in the OP as the basis for real-time collaborative editing and seems pretty important (and interesting!) for this type of app.
As always, wikipedia is a good start:
http://en.wikipedia.org/wiki/Operational_transformation
http://en.wikipedia.org/wiki/Operational_transformation
That link is (a) obvious to the point of tautology; (b) included in the OP; (c) irrelevant to my question, which was addressed to any HNers who have personally worked with this material.
Suppose if two people starts changing the same sentence at the same time, and there is latency of say 1 minute - then after 1 minute the result will be a jumbled up sentence?
Was this based on Etherpad? The Etherpad editor is setup similarly (with it being a whole bunch of <div>'s instead of a normal text field).
Tab stops and other basic features are impossible to support if you’re using the browser’s HTML layout engine for your text.
Can't you just place the document you're editing inside a DIV and use left and right margins for tabstops and change them with javascript? Or am I completely missing something?
Can't you just place the document you're editing inside a DIV and use left and right margins for tabstops and change them with javascript? Or am I completely missing something?
I really enjoy the collaborative editing functionality, I wish there were native apps with the same thing. Or at least that their collaboration approach was closer to the google one than the "handle version sent by e-mail" variant.
There are native apps which do the same thing - Microsoft OneNote 2007 and 2010 can do it on Windows, SubEthaEdit on Mac OS X, and a small ecosystem of variously working offerings on Linux, from Emacs and Screen based scripts to libobby based editors.
Word 2010 is doing it with a different approach - multiple people can open a shared document, and it will tell you who is working, but it waits for you to save before your edits are shared with the others, and waits for you to request updating with other people's edits before changing your document around with them.
http://blogs.msdn.com/microsoft_office_word/archive/2009/09/...
Word 2010 is doing it with a different approach - multiple people can open a shared document, and it will tell you who is working, but it waits for you to save before your edits are shared with the others, and waits for you to request updating with other people's edits before changing your document around with them.
http://blogs.msdn.com/microsoft_office_word/archive/2009/09/...
Really? I'd like to see browser based applications to continue to be advanced. Users are in the browser all day. Browsers are getting closer and closer to the metal on most devices and I think that is a good thing for the software industry and consumers in the long run.
There are such projects, the most famous one probably being SubEthaEdit for the Mac, but clones exist for most platforms. Obby is a multiplatform editor using Operational Transform, for example: http://gobby.0x539.de/
I don't get it. The explanation is confusing to me, on the one side they say they don't rely on the browser as they used to : and the browser takes care of letting the user edit that text and yet they talk about the new GDocs entirely in JavaScript. JavaScript runs on the browser.
Can someone explain how the new GDocs is different technically speaking ?
Can someone explain how the new GDocs is different technically speaking ?
They old way they used javascript, but they browser code, not their javascript, handled how the document actually looks on the screen.
The new way their javascript handles everything, including how the document actually looks on the screen.
The new way their javascript handles everything, including how the document actually looks on the screen.
That's really annoying - I've been working on a similar thing on and off for about two years but never had the time to commit to it properly ... oh well, I guess I can just check the google code and see where I could've improved.
That is really slick. Too bad that old documents can't be automatically converted (wait for that feature, sure it is coming).
Is this technology derived from their acquisition of EtherPad? Or is this from Google Wave? Or both?
This version of Docs uses operational transformations, the idea for which almost certainly came from Wave. However, the actual code in Wave is written using GWT (Java compiled to JS), whereas Docs is written in JS straight.
This still doesn't seem to be an option for Google Apps for your Domain users.
Truth is Google Docs is utterly broken and unusable.
Google Beta corp is fond of releasing promising but half-arsed products, indefinitely & conveniently labeled Beta, and they seldom demonstrate any urgency to fix and improve them.
Google Beta corp is fond of releasing promising but half-arsed products, indefinitely & conveniently labeled Beta, and they seldom demonstrate any urgency to fix and improve them.
Maybe these are coming from etherpad brains.