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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
In my experience the old Google Docs worked better for (college) group work. The new one still doesn't have proper heading numbering, table editing sucks, and styling is severely limited compared to using CSS. It's also too slow/heavy for editing large documents. It seems like a case of NIH syndrome, poor product management and googlers overestimating their abilities, which has resulted in a big bloated mess that still hasn't achieved feature parity with the old one (in the places where it matters) despite years of development.
In my opinion they should not have tried to imitate MS Word, but build a new kind of collaborative word processor on the strengths of HTML/CSS/JS. Now they have just a bloated slow MS Works style crippled word processor that doesn't really work for anything demanding.
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".
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.
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.
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.
97 comments
[ 3.9 ms ] story [ 102 ms ] threadFor an even-poorer-man's google docs, I like to keep this bookmarked:
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.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...
Ctrl B: bold
Ctrl I: italic
Ctrl U: underline
But isn't it skeumorphic to have pages based off of real paper sizes?
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.
What, then, would skeumorphic paper be?
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
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.
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.
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.
Except that it does resemble a plain A4 loose sheet of paper -skeuomorphically! :)
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.
Now matter how you look at it, it's not a feature that applications have to bother with reinventing.
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.
Printing is the responsibility of the platform, not the application.
Something something Zawinski's Law.
https://developer.mozilla.org/en-US/docs/Web/API/Window/prin...
Why ContentEditable Is Terrible, Or: How the Medium Editor Works (2014) (medium.com) https://news.ycombinator.com/item?id=11487667
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.
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...
In my opinion they should not have tried to imitate MS Word, but build a new kind of collaborative word processor on the strengths of HTML/CSS/JS. Now they have just a bloated slow MS Works style crippled word processor that doesn't really work for anything demanding.
Please see my comment on the parent to your post for a response.
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".
Is that a bug, or is it not intended to work that way?
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
Does this do that?
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.
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.
http://operational-transformation.github.io/what-is-ot.html