It’s probably the best style gallery that’s out there to date. If only it weren’t so limited…

Go check it out.

Would anyone be interested in taking on this role?

There’s no pay, although if a designer wanted some monetary compensation, we could start a Kickstarter project.

So here’s my attempt at making styles simpler. It’s a series of mockups for the tablet, but it would work the same way on the desktop.

The style list is drastically slimmed down. Only the first member of ordered groups of styles (like Headings) is shown until that member is used in the document — e.g. once you use “Heading 1″, the list will also show “Heading 2″, and once you use “Heading 2″, the list will also show “Heading 3″, etc. The list is also shorter because paragraph and character styles have separate drop-down menus.

Adding styles and editing them is done right within the menu — there’s a toolbar up at the top. Pushing edit shows all the included styles:

Within the style editing dialog, there’s a “Pin” button and a text box for a textual icon. When pinned, this icon ends up in the style bar, a toolbar for pinned styles that floats above a selection. It makes getting to commonly-used styles easy, easier than to Bold or Italic with a mouse, because a mouse has to cover less distance to reach these style buttons:

Looking forward to feedback. :~)

I really hope that an open-source alternative that seeks to define a single message standard arises soon — something like Google’s Wave, only less complex and with a better UI.

Anyone in the FLOSS community interested in reviving the project?

You might have noticed that my tablet UI proposal is missing rulers. That’s because I wanted to make rulers contextual: if a user inserts a tab or taps within the empty space where a tab is, a tab handle and a horizontal ruler should appear, allowing the user to adjust the tab width. Or if the user inserts a floating object (image, table, shape, …), rulers should appear. Or if the user selects a page, he should be able to adjust the margins.

I also thought that maybe there could be a single “ruler mode”, where the user is able to adjust all the lengths and widths within the page (margins, column widths, indents, tabs). I’m wondering: should this mode be triggered by selecting the page? Then the user could get to this mode much faster.

Possible page selection modes

 or 

With the ruler shown, the user would able to edit the units it uses. With an object selected, the user would also have the ability to type in the object’s distance from the margins. Here’s a mockup of what it could look like for a selected tab:

What do you think?

More on the official page.

Being an advocate for open-source software, for privacy and free speech and against monopoly and lock-in, I’m not too thrilled with the planned iOS version. An operating system is only as good as it’s software, and as long as Apple has developers treating it as the premiere platform to develop for (along with Android), it will maintain a sizeable userbase, much like Windows has managed to do.

That’s too bad, though, as Apple’s turning out to be a lot more monopolistic than Microsoft. It strictly filters its app selection and allows users to install apps only from its own marketplace. Its App Store policy prohibits (L)GPL-licensed software. It actively fights against jailbreaking, in case users doesn’t want to play by Apple’s rules. If one wants anonymity, he has to jailbreak the device in order to use Tor. It attacks the rest of the industry with (mostly bogus) hardware and software patents. Its iBooks textbook platform locks students into Apple’s proprietary software, especially as all paid textbooks made with Apple’s iBooks Author can only be sold through the iBookstore. Apple was also a backer of SOPA/PIPA and refuses to support WebM for HTML5 video on iOS, rather backing its proprietary counterpart H.264. The list goes on and on.

So how about instead of targeting iOS as a second platform for LibreOffice, what about WebOS? Or Plasma Active? Or Tizen? These platforms need LibreOffice way more than iOS. Let’s stop fueling Apple and target the platforms that should succeed, platforms giving you some freedom, platforms that don’t tie you to a filtered list of applications, platforms that allow (L)GPL licenses, platforms that you can trust because you can read the source code.

Incidentally, Karen Sandler, GNOME’s Executive Director, gave an excellent speech on the importance of free software on devices. Go check it out.

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.

So I’m asking you for help — if you know how to get this done, please say something. If you have any comments, suggestions, or can further refinement to the Overflow menu whiteboard, your help is very much appreciated. Developers wanting to work on this and willing to initiate a rich discussion on the developer list would be great, too.