…how penguins might rule the world… Part 1

You know those videos Microsoft Labs make, where they try to “envision the future” by basically putting an animated screen on everything, from credit cards to newspapers to all the walls in your house… (btw, am I the only one who thinks this is a dystopian future rather than a utopian one?)

I’m also going to try to envision a future, or rather, say what I’d like to see happen in the future of open-source productivity suites.

Web technologies

The web is a big opportunity for open-source software. Now that we’ve managed to force Microsoft into adhering to web standards, there’s finally a platform that works everywhere — mobile phones, desktops, laptops, tablets, and perhaps soon even televisions. And the platform’s power increases exponentially, at a much faster rate than that of other platforms.

At first, I thought the ideal thing would be to have a good office suite suited for the web, like WebODF, that anyone could share. It could become a nice complement to open-source file storage services (à la Google Docs) or perhaps social networks (à la Microsoft’s Facebook Docs). Then I was inspired by Sozi and impress.js and I was thinking: why don’t we base our standard formats not on ODF but on web technologies.

Maybe I’m being naive — I really don’t know that much about code, and I’m sure there are a thousand advanced features in ODF that would be hard to implement in web technologies. For the average user, though, all the features are there. And the features missing tend to appeal to only a nitch market, which will continue to be supported — this is open-source software after all. But the suites suited for the average consumer, a person that just need to type something up, align a few things, apply some styles, could easily use web technologies for their default format. And the files could be viewed inside a browser, with no add-ons or extensions to show them.

Our files would be compatible with every operating system capable of running a modern browser. What’s more — they’d be rendered almost identically in all modern browsers (given that every program that supports ODF renders it differently right now, this would be a huge step up). No more complaints from others about not being able to open ODF files or broken DOC files.

Having browsers support the file format is good because there’s no need for installation of anything. If you find yourself on a public computer, chances are that it won’t allow you to install (or even download) programs and that it won’t have anything that you could view ODF files in. But it’s very likely it will have a browser, and with non-admin Chrome Frame, you’ll be able to view your file even on an older IE version. Also, it’s much more comfortable to be able to view a file inside the browser than download it and open it in another application, especially the molasses-slow LibreOffice (if you open PDF files with Chrome, you know what I mean).

So what I’m basically saying is that I want a web-based alternative to ODF. SVG is already miles better than ODP. SVG could potentially even replace ODP, as seen in Sozi, except I think impress.js provides much smaller and smoother files. ODT, though, needs something to replace it, something that recognizes pages and page breaks and is suited for print rather than for a screen. The other ODF formats are secondary and I don’t think they can be easily replaced by web-based formats.

What’s also needed are the open-source editors. I’ve had some problems with Inkscape and I still sorely miss Macromedia Fireworks (I haven’t used Adobe Fireworks and don’t know what they’ve done to it) and Creature House Expression, but still, it’s the best SVG editor out there. Although you could use Inkscape with Sozi to produce presentations, it’s not a very comfortable way to do things — there’s definitely a need for an editor there. And the most important thing — the word processor.


4 thoughts on “…how penguins might rule the world… Part 1

  1. HTML seems like it’s already completely adequate.


    You mention support for page breaks and similar. That really is the biggest problem with HTML-as-editor. But the only thing we really need is a [pages] element which wraps content into a restricted size. Heck – we don’t even need that. We have a page-break syntax printing, so we just need some javascript to put it into little divs.

    We’re not going to make a pixel-perfect editor in HTML for a while; fonts may be transferable over the internet now, but rendering is completely out of the browser’s control. But if you’re just printing text and not some magazine-style page, that’s more than enough.


    Also, this new interface isn’t playing well with Chrome. The Email, Name, Website sections below are overlapped with foreign text (EMAIL_ADDRESS, NAME_FULL and UNKNOWN_TYPE respectively) and it’s kinda’ ugly.

    1. The next step, then, is to ensure the same markup appears the same way in every browser on all platforms, carve out some rendering standards.

      How does LibreOffice make sure ODF files are rendered the same way across platforms? Does it do all rendering itself, using no OS technologies whatsoever?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s