Show HN: Poor man's Google Docs | Hacker News Reader

Show HN: Poor man's Google Docs

github.com

136 pointsmarco190 comments

Looks pretty good.

For an even-poorer-man's google docs, I like to keep this bookmarked:

    data:text/html, <html contenteditable>

If you navigate to that string in your browser it gives you a blank, editable page. No saving or any fancy features, but it is pretty convenient to be able to quickly spin up a scratch pad sometimes.

Clever, but why? Notepad.exe, TextEdit.app, Gedit, nano are all already there - and do save if you want to after. TextEdit will even just let you quit and come back without saving and the draft is there. Leave the browser sometimes man!

How dare you forget my favorite text editor in your list.

Which is?

Cat, Awk, Grep, and unix pipes

ed.

Butterflies.

https://xkcd.com/378/ For those confused

vim

Emacs. In TECO.

Visual Studio

Neovim

copy con

Zile

acme

The nicest thing with using a shortcut like the one above is that all formatting is preserved, tables especially, but also other html elements with styling (mostly). This is very handy in a lot of contexts.

Also, a quick way to get a scratch pad in Emacs is to switch to a non-existent buffer. C-x b foo RET and type away in a buffer called foo.

this reminds me of something I made once that was basically exactly this, but included a button you could click that would run, more or less

    window.location = "data:text/html," + document.documentElement.outerHTML

functioning as a kind of lame save button

Very cool tip, although I use notepad++ for this because even if I shut everything down it saves any new tabs I opened as temp files without me giving it a second thought.

Whatever you do, don't fat-finger ctrl-w or similar. :(

> Whatever you do, don't fat-finger ctrl-w or similar. :(

You could add a onbeforeunload handler to prevent that. You'll immediately recognize it from every other annoying web page that adds uses.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/WindowEvent...

Also, Ctrl-Shift-T will usually bring back the tab you just closed with its state intact. Some JS-heavy pages don't restore cleanly, though.

GP bookmarklet isn't restored under Chrome

In this case, it won't bring back your html editable. :(

I use this Chrome extension and it has been awesome. text area + edit + save whenever you open a new tab.

It doesn't take away from this, but because of the title: Google Docs started much like this, but eventually they gave up on plain HTML and changed to the current model which still uses the DOM but is "complicated"(tm) HTML.

I can't find the link at the moment, but I think it's interesting because despite it being the simple solution, they eventually realized it was holding back adoption amongst business users.

Edit: Found the article: "Babe Ruth and Feature Lists" [0] where former Google PDM Ken Norton writes:

>We were relying on the browser’s rich text surface, which used HTML as the underlying data format and caused browser compatibility nightmares. You’d bold a word and then be unable to un-bold it. Bulleted lists couldn’t be edited or deleted without screwing up the whole page or turning everything into a bullet. Centering a line would often center-align the entire document. Formatting bugs had been an annoyance for Googlers, but they were fatal for groups of students who needed to print a term paper to a teacher’s exacting specifications.

0 - https://library.gv.com/babe-ruth-and-feature-lists-1818bb8c6...

Thanks a lot!

This project is mainly targeted at presenting (read-only) documents, which includes displaying and printing invoices etc. I admit, the project description could have made this clearer.

Basic editing is possible, which is why it's a poor man's Google Docs. Styling is possible as well, if you don't try to bold/unbold randomly, etc.

So for presenting read-only documents, this has zero of the problems that Google Docs had and the project can safely continue to use the DOM and "contenteditable".

I've had the same experience. In order to have a great cross-platform weird processor, you've got to do it yourself.

Here's a great technical explanation of the problem: https://medium.engineering/why-contenteditable-is-terrible-1...

Thanks, great read!

Please see my comment on the parent to your post for a response.

No JavaScript? Nice. Don't see too many functional pages without it. I don't know that I would call it a poor man's Google Docs due to the lack of equivalent features but good work nonetheless.

  > No JavaScript?

And even these keyboard shortcuts work, at least in Chrome:

Ctrl B: bold

Ctrl I: italic

Ctrl U: underline

They do not work in Firefox (and probably other browsers), unfortunately, but you can still edit the DOM in the inspector there.

My favorite is this chrome extension : https://chrome.google.com/webstore/detail/new-tab-notes-alph...

Another one (bottom-left menu for options): https://chrome.google.com/webstore/detail/papier/hhjeaokafpl...

"package is invalid"

It's possible to generate PDF client side. You might consider adding that feature.

"Print to PDF" isn't clientside enough for you?

As far as I know Chrome is the only browser that offers that as built in feature.

Every browser in Linux and OSX does it, and doesn't Windows 10 ship with a built-in PDF printer too?

Those are built into the operating system, not the browser.

My point is that not everyone has those features out of the box. Sure, you can install more software, but it's not a reason to not have a feature like that in this word processor.

Well by that logic, I sure hope my word processor has a calculator and an mp3 player and shit it better have an app store too.

Printing is the responsibility of the platform, not the application.

> Well by that logic, I sure hope my word processor has a calculator and an mp3 player and shit it better have an app store too.

Something something Zawinski's Law.

Yes, Windows 10 has this now, just as Ubuntu with its "Print to File". But Windows 7 and 8 don't have this feature.

You can either install third party PDF printers for them (there's literally dozens), or use the builtin XPS printer and a converter.

Now matter how you look at it, it's not a feature that applications have to bother with reinventing.

Yes, I really wish Firefox added this feature! As far as I know, they even have this in the Android version of Firefox.

Anyway, if your operating system comes with a PDF printer or if you installed one manually, you can use the normal printing feature that every browser has.

What are you on that Firefox doesn't have a built-in print-to PDF? On GNU/Linux, I've got a "Print to File" printer that lets me select between PDF and Postscript, even though I don't have cups-pdf installed.

Thanks! That "Print to File" is provided by the operating system, not Firefox. I'm on Windows 7, where the operating system doesn't provide this. Yet Chrome provides it itself.

It's a CUPS feature on macOS and Linux, not a Firefox feature.

I used to use it as a CUPS feature, but as I said: I don't have cups-pdf installed, and indeed, I don't have CUPS installed at all. Perhaps it is being provided by some system library (perhaps libcups), but not by CUPS itself.

Actually, it's a "gtkprint" feature. You don't have to install anything separately. But still something built-in into the operating system.

Firefox has the option to save to PDF (on macOS at least). http://imgur.com/a/pKOPU

Thanks! Might this be provided by the operating system as well (instead of Firefox)?

Safari on mac offers it (like everything does on mac -- it's built in)

I just checked and Edge has it. Pretty sure every browser has it.

No, I want a dedicated button and not mess with CTRL+P :)

button.onclick = function() { window.print() }

https://developer.mozilla.org/en-US/docs/Web/API/Window/prin...

>No skeuomorphic paper

But isn't it skeumorphic to have pages based off of real paper sizes?

Yes, more or less!

It's quite hilarious to see how a certain class of developers think (or portray) that something is skeuomorphic, and therefore, undesirable, when in fact there is nothing (zilch!) in software that is not stemmed on skeumorphic thinking.

Starting from Object Oriented Programming to visual design, everything in software is a skeuomorphic inspiration of what we have experienced offline before.

For example: The web scroll is a direct skeuomorphic rip-off of physical scrolls from back in the day! In fact between paginated page-flips of modern physical books and scrollbooks or yesteryears, scrolling is probably the older of the two technologies. Then we have paper-like pages in MS Word or Google Docs with page-breaks in them!

The mobile dial-pad is a cute skeuomorphic rip-off of physical buttoned dial-pads on phones. iWatch/digital watches still do good with clock needles the way physical ones always did. Button, shadow, gradients, flat buttons, round buttons, corner elements, form design and pretty much everything in "good design" are all grounded on, in principle, skeuomorphism.

Hell, we even copied the scrolling momentum!

It's a fact: any ego-strut or marketing-speak from anybody in software that says some "design" is original and not skeuomorphic is simply selling bullshit.

Thanks for this short excursus, but "not skeuomorphic" has never been marketing speak here.

Instead, it has been added only to disassociate from a HTML/CSS imitation of paper (the material) by itself, which quite a few people have been expecting, given the (improvable) title of this project.

> Instead, it has been added only to disassociate from a HTML/CSS imitation of paper (the material) by itself

Assuming that digital screens cannot truly be produced using cellulose and starch (the material) the dissociation and difference in the nature of medium is understood. And then the "software part" has absolutely no role to play in that dissociation.

You can't evade the fact that it is just marketing-speak at every level. I am pretty sure that the dev community likes to believe otherwise, and hence the downvotes, but that's just lame groupthink anyway.

FWIW, I understood it as "we didn't use a background 'texture' that visually resembles a piece of looseleaf paper", and I rather welcomed that particular visual design choice.

That's exactly what it was meant to express. Thanks!

https://delight-im.github.io/HTML-Sheets-of-Paper/

Except that it does resemble a plain A4 loose sheet of paper -skeuomorphically! :)

No, that's just good design. The use-case seems to be for printed documents.

I guess my confusion is just: are we saying that white rectangles with the dimensions of paper are not skeumorphisms of paper?

What, then, would skeumorphic paper be?

Sorry for the confusion!

This was actually only added to underline that there's nothing like [1] in this project. Will improve the README.

[1] https://www.google.de/search?q=paper+texture&tbm=isch

This comment implies that skeuomorphism and good design are mutually exclusive.

Excuse me, sir, can I introduce you to our lord and saviour Jony Ive?

So you think Apple's design are away from skeuomorphism? In case you do, you're very wrong and probably don't understand what skeuomorphism is.

Good design? No, it's just marketing-speak.

Good design is one where a user doesn't lose focus from the task they had on their mind -- be it in physical realm or software. In fact for this reason alone there is no well-designed software in the world, anywhere, that doesn't rely on skeuomorphism at its core.

I believe Google Docs is actually the poor man's Google Docs.

my wife calls Google Docs poor man's Microsoft Word.

I'm a big fan of Papier for chrome. It doesn't save to your Google account so my notes on my home computer are different than my work computer, which is just how I like it: https://chrome.google.com/webstore/detail/papier/hhjeaokafpl...

Might be nice to add "outline: none;" to .page

What browser are you using? Did you test this? I can't see any difference. Please note that a drop shadow has been added deliberately here.

Safari on OS X has a blue glow around the input field when focused.

As does Chrome 52 on Windows 10

Thanks, will investigate!

What happens if multiple people load the same page and type simultaneously? I'm on a phone and can't test that for myself, but the simultaneous access/editing is what Google Docs truly valuable.

Does this do that?

Good point!

It doesn't do this yet, because the focus here has been on perfect representation of pages via CSS.

But using socket.io or something like this, it shouldn't be thard hard.

It's not as easy as you think. You will also need to learn something called Operational Transformation to avoid merge conflicts.

http://operational-transformation.github.io/what-is-ot.html

I suspect it is harder than you think. Have a go, and let us know how you get on. I'd love to see a simple, light-weight, elegant alternative to Google Docs.

Thanks, I didn't mean it's trivial, but it's not a hard technical problem (anymore) to do that on the web.

Not sure if I'll be working on this, though, because there are so many (commercial) services providing this already. Sure, you might think that Google Docs could be more lightweight and elegant, but for many people it's working fine and that 10% improvement on Google Docs is definitely too much work for a tiny open-source project.

I was talking about basic functionality, just as you were in your first comment. The title of this contribution didn't talk about a poor man's Google Docs by chance.

This contributes nothing more than <div contenteditable> and to present this a document editor is counter-productive to users searching for something reliable. The link below shows the many shortcommings of just calling the contenteditable browser API as an emulator. For example, Google Docs does not use contenteditable at all -- for the many reasons outlined below. Building a real doc editor that functions as a widget in blogs and forums sites requires a lot more support -- of the open source alternatives, Medium is one of the best.

Why ContentEditable Is Terrible, Or: How the Medium Editor Works (2014) (medium.com) https://news.ycombinator.com/item?id=11487667

It does!

You might not have looked at this closely enough, but "contenteditable" is really only one line that has been added to make the demo more useful.

The real thing this is about is the CSS. There are ~250 lines that produce the correct page sizes, margins and paged content and ensure that prints are as expected.

Adding content to the first "page" doesn't cause the content below it to re-flow onto the second page.

Is that a bug, or is it not intended to work that way?

Thanks!

This does only affect the "in-browser" view. In the print view, everything is correct.

Yet, you're right in that this just isn't acceptable. The "preview" mode in the browser should work exactly like the print mode here.

This is a known issue and had already been tracked here: https://github.com/delight-im/HTML-Sheets-of-Paper/issues/2

When i viewed the print preview it seemed broken too - the content in the first on-screen page (which was too long) became two pages, and then in the print preview it forced a new page before the next block of content.

Pretty cool - thanks!

Reply on news.ycombinator.com