Help get this topic noticed by sharing it on Twitter, Facebook, or email.
I’m frustrated

We need a Google Docs format for serious publishing

The older Google Document format included support for HTML/CSS editing. Not only was this feature useful for sorting out bugs with the earlier version of the Document editor but it enabled users to create cohesive styles in the same manner that we do with websites.

Use Case:
I had always toyed with docs but never really considered using it for work/business until I needed a resume to go job hunting. I didn't have MS office installed at the time and didn't feel like installing it so I thought I'd give Docs a shot.

After some googling I discovered that I could save a lot of time by searching for public templates. When I received the document it was close but missing the personal touch I knew I would need to get the job. I tried using just the GUI tools but found them clunky and ineffective.

After searching through the menus I discovered the HTML/CSS editing feature and sighed with a breath of relief. I have tried (unsuccessfully) over the years to bend the styling tools of traditional desktop publishing platforms (Office, OoO, LibreOffice, Indesign) to work the way I wanted but the inability to easily view/set the borderline between styles has always been a pain.

The combination of HTML tags and CSS classes address all of my gripes with traditional platforms in a manner that is familiar. Plus, if I ever feel the need to share/publish a document template I can feel comfortable that the format is ubiquitous enough to be useful to others. Due to my past experience with using HTML/CSS to design webpages, the barrier of entry to jump right in to do some advanced editing was nil.

I know the easy (canned) answer for this type of thing is, "just use google sites" but I'm not looking for a tool to write website content; I'm looking for a tool that can marry the simplicity of docs on the surface with the power of HTML publishing under the covers.

I'm not suggesting that Google change the current Document format, I understand that the format is geared to be light, clean, and fast. What I'm suggesting is, resurrect the old format as a new document type that puts power/versatility over performance.

It seems ironic. Because of this first favorable experience with Docs I have moved on to incorporate Google Spreadsheets into my daily workflow. I have spent the past two months leveraging Google Apps Scripting to build an online documentation and auto-reporting system; when I finally came back to use the Document editor, I discovered that it has been transformed back into a toy.

Please don't take my harsh tone as anger. Take as frustration that unique/powerful/useful tool that I had adopted will soon me made unavailable.

Here's what Google Documents used to be capable of:

http://knol.google.com/k/google-docs-...#

Plus, I'm not the only one:

https://groups.google.com/a/googlepro...

https://groups.google.com/a/googlepro...

http://webapps.stackexchange.com/ques...
6 people like
this idea
+1
Reply
  • EMPLOYEE
    I’m sympathetic.
    1
    I can't answer your (excellent) question, but I can give you a little bit of background.

    > The older Google Document format included support for HTML/CSS editing.

    Multi-user collaboration was problematic when using HTML/CSS. Different browsers have different ideas about how to render the same content. Pixel-level differences in browser layout resulted in line wrap on the same document being different for different people. This resulted in a cascade of ever-increasing divergence on long documents. Relying on the browser to perform any form of layout turned out to be not possible.

    The switch to the new format pushed all layout to the server-side. Each word is now absolutely positioned on the page. Reintroduction of raw code editing would have to address the server's internal model of the document rather than the browser's model.

    [Source: the keynote Google gave at SVG Open 2011. http://www.svgopen.org/2011/registrat...]

    Personally, I too greatly miss the raw editing capability; I keep a couple of legacy documents around specifically to preserve my own access to this ability. I can't comment on whether restoration of this feature is planned or not.
    • OK, that makes it easier to visualize the issues involved in developing a browser based text editor. Using a SVG editor in place of HTML elements is a pretty novel solution. That also explains the recent addition of Google Draw.

      I get that "Reintroduction of raw code editing would have to address the server's internal model of the document rather than the browser's model" is the equivalent to emulating the HTML/CSS layout specification in SVG (very bad). The development effort would be like creating another Chrome Browser that runs purely on SVG (not so bad but very costly). I completely understand why that's a non-option.

      I don't disagree that the current incarnation of the Document format should remain the flagship product. Using docs for internal documents is still a simple/preferred solution. The inconsistencies between browsers and sheer amount of outdated browsers in the wild won't end anytime soon so It's understandable that the flagship product should be consistent across all platforms.

      Conversely, what I'm suggesting is an alternate format (ie. epub/html). One that serves a relative but alternate purpose the same way that the Table doctype doesn't serve the same purpose Spreadsheet. For the sake of simplicity I'll call it Hypertext.

      To keep in line with what web publishers would expect, strip the UI editing capabilities down to the bare minimum (ie. what you'd expect from a wiki/blog) but allow more advanced editing capabilities by digging into the code. Force the users of the Hypertext doctype into the same workflow that they're used to using already in other design contexts. That will break the expectation that the Hypertext format should follow the same progress roadmap as the Document format (and cut down on development cost overall).

      To address the browser inconsistency issue post a notification, "The current browser is not supported and may display inconsistent results when opened in other browsers". Kind of like how the current, "Your browser's current zoom setting is not fully supported" notification works. Anybody who has ever touched HTML knows that some browsers just don't play well and should be avoided altogether.

      A simple link to a page explaining why the inconsistencies exist will keep the noobs quiet. Let them know that the editor will work if they upgrade their browser. The key is not to code around the inconsistencies (once again, cutting down on development cost) but to enable users to make a better choice.

      Push the project into beta until the browsers reach parity on the current CSS specification (if that'll ever happen). The format isn't a flagship product so it doesn't have to be designed to please everybody.

      What it all boils down to is:

      - How far off is the rendering model between browsers?
      - Can the tool be made available across all of the current generation browsers?
      - Are the current generation of browsers good enough to make this work without endless kludging?
      - Is Google willing to devote the development resources to a product that may not be 100% functional across all browsers any time in the near future?

      I fully understand that the, "I want it the old way" complaining isn't very constructive. That's why I wanted to make an attempt at a lateral approach. Plus there's opportunity to break new ground if it could be used to write ePub docs.

      I'm honestly impressed with the changeover to SVG; the look-and-feel is so consistent that I would have never known if you hadn't told me. I get that resource constraints and/or technical inconsistencies can make certain development efforts volatile.

      Thank you for your time.
    • The inconsistencies between browsers is a big pain for me (a year later after this post). I'm a teacher. I'll create a test, at home, using Chrome on my Mac. Then, I'll go to print that test at school, using Chrome on my PC. I'll have to spend some time changing the length of my lines to write on and mess with the page breaks.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned kidding, amused, unsure, silly

  • I’m thankful
    thank you both for raising the subject. It's a bit frustrating not being able to edit my strikethrough or paragraph styles the way I like them to be.

    hopefully in the near future you guys will be able to address this and give us back our power.

    thanks.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned