Killing the office suite



All timestamps are based on your local time of:

Posted by: stak
Tags: mozilla
Posted on: 2014-11-15 11:44:20

Have you ever had the experience of trying to write a document in MS Word (or Open/LibreOffice) and it keeps "correcting" your formatting to something you don't want? The last time I experienced that was about a year ago, and that was when I decided "screw it, I'll just write this in HTML instead". That was a good decision.

Pretty much anything you might want to use a word processor for, you can do in HTML - and oftentimes it's simpler. Sure, there's a bit of a learning curve if you don't know HTML, but that's true for anything. Now anytime I need to create "a document" (a letter, random notes or signs to print, etc.) I always do it in HTML rather than LibreOffice, and I'm the happier for it. I keep all my data in git repositories, and so it's a bonus that these documents are now in a plaintext format rather than a binary blob.

I realized that this is probably part of a trend - a lot of people I know nowadays to "powerpoint" presentations using web technologies such as reveal.js. I haven't seen many people comment on using web tech to do word processing, but I know I do it. The only big "office suite" thing left is the spreadsheet. It would be awesome if somebody wrote a drop-in JS spreadsheet library that you could include into a HTML page and instantly turn a table element into a spreadsheet.

I'm reminded of this old blog post by Joel Spolsky: How Trello is different. He talks about most of the people who use Excel really just use it because it provides a table format for entering things, rather than it's computational ability. HTML already provides that, but whenever I've tried doing that I find the markup/content ratio too high, so it always seemed like a pain. It would be nice to have a WSYIWYG tool that let you build a table (or spreadsheet) and import/export it as raw HTML that you can publish, print, share, etc.

As an addendum, that blog post by Joel also introduced me to the concept of unshipped code as "inventory", which is one of the reasons I really hate finding old bugs sitting around in Bugzilla with perfectly good patches that never landed!

Posted by Stephan Sokolow at 2014-11-15 15:27:22
What you say definitely makes sense.

My primary way to write is either Markdown or, in creative writing cases where even Markdown is too code-ish for me to stay in a literary mindstate, a simplified pseudo-WYSIWYG like LyX's "WYSIWYM" which is still semantic, but represents things like emphasis visually.

I haven't needed to produce a presentation in the last few years, so I'm not sure what technology I'll prefer, but I suspect I'll be using something like reveal.js next time, both because it gives me that HTML/CSS/JS content/presentation/behaviour separation and because it's easy to take the HTML and do scripted processing/transformation on it.

As for spreadsheet use, I'm not sure whether I line up with your impressions. I have three main uses for LibreOffice Calc:

1. I definitely use it as you suspect: paired with a TSV-to-HTML Python script as an alternative to writing HTML table markup by hand.

(Though I do rely heavily on various keyboard-driven "do what I mean" behaviours like the semantics for copy-pasting from a single row/cell to a range of rows/cells, so reproducing just the GUI on top of an HTML table exporter isn't as simple as it initially appears.)

2. I also use it, coupled with autocomplete and copy/paste, as a way to prepare more or less unstructured data for import into a relational database.

(I can't find a single open-source SQLite-compatible GUI which can be efficiently controlled by the keyboard and understands foreign keys, so it's less painful to just use Calc's autocomplete and copy-paste in concert with a CSV/TSV import script which does validation and deduplication to shove tabular data into normalized relations.)

One of these days, hell will freeze over and I'll find time to write some kind toolbox for rapidly prototyping high-efficiency batch-entry UIs on top of an SQL dialect abstraction layer like the one in SQLAlchemy.

3. While I'm a programmer (and, thus, not "most people"), I do sometimes use LibreOffice Calc's computational ability. When the best UI really IS a grid of cells and the "code" is a directed graph of of functions, nothing compares with a spreadsheet. (Otherwise, I'll probably use IPython Notebook.)

Calc is definitely heavier than necessary for that, though. Another "rainy day" project: Some kind of PyQt application which ties "eval() each cell" behaviour to a tabular widget and uses the Python AST module to figure out which cells depend on which other ones for refresh purposes. (Or possibly in-browser when Skulpt gets far enough along to implement the AST module.)

(And, if I need a linear solver, I'm going to use GLPK's MathProg language or implement something higher-level using its Python bindings. A spreadsheet is, at best, an ugly, awkward way to define a linear program.)
[ Reply to this ]
Posted by xza at 2014-11-15 23:19:09
I write in RST because it supports tables and all the fancy stuff - yet is an easy, straightforward pure text format.
Its a lot easier than HTML too (but mainly its a lot faster to write).

There's plenty of RST converters to anything and it seems much more suited than Markdown or pure HTML for many people. It just doesn't get the same press. A lot of people are using it however.
[ Reply to this ]
Posted by Stephan Sokolow at 2014-11-16 10:36:46
I really should get used to RST and, as a heavy Python programmer, I feel the pressure but, given how much impetus I already have to stick to other forms of markup, I never seem to get around to it.

- My Python docs are done using ePyDoc in ePyText-mode because ePyText is familiar and Sphinx is for writing manuals, not API docs. (A real API documentation tool can be configured to recurse through a package hierarchy, gathering ALL TODOs and printing warnings for code that's been left undocumented.)

(On a related note, I really need to make another attempt at detangling the code Sphinx uses to generate the index for its Javascript-based search system so I can write a Ruby index generator and migrate my blog from WordPress to GitHub Pages without having to use Google Site Search to maintain feature parity.)

- My favourite PIM tool is TiddlyWiki 2.x (and soon TW5 will be my favourite RAD platform for data-organization apps), which has its own markup.

- GitHub Pages and Issue Trackers don't support RST, which reduces the impetus to use the RST support in the README and Wiki.

- The bare RST supported by Pandoc is a rather wimpy dialect and I haven't figured out how to script Sphinx so I can get an asciidoc-like "Use a default template to render a single file without creating a whole new project" script.

- If I want a lightweight markup instead for writing a big book, LyX is WYSIWYM for LaTeX and asciidoc maps 1-to-1 to DocBook XML.

(And asciidoc also has a nice default template which makes it very appealing for quickly banging out a file with O'Reilly-esque markup including admonition icons)
[ Reply to this ]
Posted by Stephan Sokolow at 2014-11-16 10:39:04
Ugh. Clipboard got confused and pasted the wrong link.

admonition icons
[ Reply to this ]
Posted by Simon at 2014-11-16 03:04:41
I use MS Office at work, as a matter of corporate standards for "official" documents (in particular, for a few complex spreadsheet templates).

But aside from that, I mostly stick to text formats... plain text, evolving into markdown or asciidoc if I find myself needing a nicely formatted version. Writing stuff in HTML directly... definitely not. The mental cost of working with tags is just too high, especially for tables where you're a minimum of four levels deep before you even start adding content.
[ Reply to this ]
Posted by André Jaenisch at 2014-11-17 12:18:27
Do you know Ethercalc yet?

For quick notes and documentation, Markdown is super easy. There's a project on GitHub for converting it to HTML et al. called MultiMarkdown
Speaking of LyX above: Forget it. Their LaTeX output is too ugly :)
[ Reply to this ]

[ Add a new comment ]

 
 
(c) Kartikaya Gupta, 2004-2024. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!