Category Archives: Thoughts

Google could’ve owned social

Google Wave is considered one of Google’s big failures today. It was bloated, had a crowded UI, suffered from feature creep, and, while it was online, it was pretty useless, since nobody was on it and it was hard to get invited.

And yet, if Google gave it a proper overhaul — drastically simplified, removed the UI oddities, and properly split Wave’s different aspects into several pages, it could have been the next communication platform. It’s open-source, decentralized, and includes enough features to meet a number of communication needs.

Messages (E-mail+Chat)

Did you know that the Google Wave founder left Google for Facebook? A little while later, Facebook Messages, a blend of chat and e-mail, appeared. It did essentially the same thing as Google Wave, except all the complexity was taken out and focus was put on one thing — simple person-to-person communication. And it was a huge success.

Due to its decentralized nature, Google Wave could have made “messages” universal. Messages would sooner or later become a communication standard, outplacing e-mail and making closed communication platforms like Facebook Messages or Apple’s iMessage irrelevant, since it’s just superior technology to e-mail. And for those still clinging to their e-mail accounts, messages could be sent as e-mails and vice versa.

Comments

One of the most important features of Wave was the “embedded wave” — a wave websites could bundle as their comment field or a feedback box. Imagine having a decentralized, open-source alternative to Disqus, Livefyre, etc. that you don’t even have to create a special account for. Even better — you get replies to the comments you’ve made anywhere on the internet under your account right on your Wave client, hopefully fit and snugly within its own special section instead of intermingled with your serious messages.

Google+ base

If Google+ was decentralized, it would rock so much more than it currently does. And an easy way to decentralize it would be to simply take Google Wave and tweak it a little. You’d no longer have to choose between having a closed, restrictive social network with your friends and your grandma on it (Facebook, Google+) and an open, decentralized network with few people and little activity (Diaspora).

Contacts

Since you’d have all your communication tied to one place and one wave account (whatever wave provider you chose to go with), you’d only need to manage a single set of contacts. That would make sharing/privacy settings so much simpler. Not only that — if done correctly, it would open other services to these settings. So, for example, you could tell Ubuntu One that you’d like to share your files only with people from your “Work” circle even though Google would actually host your contacts.

Online freedom

Now that we’d have a single decentralized communication and contact system, the rest follows. The user would be in control of his data on the net. He wouldn’t be forced to use his real name, he wouldn’t be tied to a single host, he wouldn’t be coaxed into having a public profile, and he could have as many accounts as he’d like.

How does this help Google?

It helps the open web. Frankly, right now, Google could care less who hosts the communication platform. It’s not making any money on Google+ — it doesn’t even have advertising on it yet. All it’s doing is trying to divert people from Facebook, which is becoming the new way people discover things, the new place where people spend time, and is eating at Google’s business. And Google is still the biggest online advertising provider, so it’s likely that a number of wave hosts would put Google’s ads on their sites to make money.

Why we shouldn’t make a LibreOffice for iOS

The Document Foundation is currently planning to port LibreOffice to two mobile operating systems: Android and iOS.

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.

…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.

Simple customization

Over the past several years, there have been a lot of discussions around the OpenOffice.org/LibreOffice user interface, and most of them seem to lead to “Give us all the various UI options: toolbars, ribbons, sidebars, etc.”. It’s nice to have a flexible core and it’s always good to be able to change the UI if you don’t like it, but when a UI tries to give the user as many options as possible, it tends to end up a mess.

Options in LibreOffice (here you see less than half of the categories)

Options in AbiWord

As I see it, the best option is to develop an interface in which customization is intuitive and simple. A good example of this is the Windows Phone tiles UI. (Despite all my antipathy towards Microsoft, I do have to acknowledge that their “Metro” UI is brilliant.) A user can add tiles (shortcuts, similar to icons) from various areas of the phone (applications, contacts, websites, …), adding tiles is simple (just push a button), tiles are aligned to a grid, they look neat, uniform, are easy to organize and browse through, and, overall, working with the home screen is a very fluid and coherent experience. Compare that with Android’s UI, which sloppily combines icons and gadgets, which you can only add to your home screen through a special home screen customization dialog. Android gadgets come in various shapes and sizes and varying levels of integration with the software. You can flip through some gadgets, scroll through others, some you can input text into, and some are just read-only. It can be pretty messy, and customizing it is a pain.

I want the LibreOffice UI to be as seamless and simple as the WP Tiles UI is. I want a single way of organizing commands (currently, commands in menus, toolbars, and “customization” dialog are all categorized differently). I want a single place that houses all commands (the menu bar seems ideal for that). I also want simple customization — being able to drag and drop commands from menus onto the toolbar, or from the “ellipsis menu” (below) onto the toolbar or vice versa.

That doesn’t mean that we can’t have ribbons or sidebars or toolbars to house commands, just that we shouldn’t overwhelm the user with options or weigh down the suite with a ton of optional half-baked UI choices. Let’s shoot for quality, simplicity, and intuitiveness, and leave the alternatives for extensions.

————————————

Note: I’d really like a Lotus Symphony-like sidebar as another option for housing commands, either built-in or as a featured extension. I’m not sure, though, how exactly to organize it so that it works the same way as the context bar and fizz (where you can add and remove commands to your liking), but doesn’t look messy or disorganized. If I come up with something, I’ll post a mock-up. (Feel free to take the Citrus UI svg and mock something up too…)

It’s all about UX

Microsoft announced the new Windows 8 interface yesterday and, although it’s not without its flaws, it seems to be simpler, more intuitive, and easier to use than any of the current touch-based and perhaps even mouse-based interfaces right now, except maybe Chrome OS. It’s gotten me a bit worried, because now interfaces for Linux-based operating systems will have to catch up again (and I doubt that the newly-created GNOME Shell and Unity interfaces will want to reform so soon). On the other hand, if I know the open-source community, I’m sure someone will cook up a copy of the new Windows UI soon enough. It won’t be as good as the original and applications might not fit in as well (although the new Windows 8 applications should apparently be based on HTML and JavaScript), but it’ll be fine for normal use.

That bothers me, though. When it comes to open-source projects, user experience is rarely a priority if it’s considered at all. Most developers usually copy the leading competitor or provide an exhausting amount of options that lets the user fine-tune the interface instead of actually trying to come up with the best interface for the user.

That’s too bad because the user experience is the most important part of software. It’s the reason why the iPad was such a success while Microsoft’s Tablet PCs weren’t. It’s the reason why people generally prefer Photoshop to GIMP, or even MS Office over LibreOffice.

So what’s the point of this post? Basically, I’d just like open-source projects to really focus on usability — to stop before adding another feature and ponder how to best incorporate it, to do more user testing and to listen to user input, to be focused and organized and provide a list of topics currently “on the table”.

With LibreOffice, it seems like a mixed bag. On the one hand, the design team is very friendly and open to any suggestion. On the other hand, it seems to function quite separately from the developer group, and thus it’s never clear whether ideas brought up on the design list will ever make it into LibreOffice and things that aren’t very user friendly, like more Options categories or the confusing Title Page dialog. To be fair, though, LibreOffice is a new project and its design team is just kicking off, so… we’ll see how LibO fares in the long run. UX in open-source projects is still in its infancy, and the landscape is about to get a whole lot more interesting.

Suite Utopia, or What ODF Needs to Change the Game

If you use ODF, you’re in the minority. If you use Linux, you’re in an even bigger minority. So if you’re like me and happen to be in these minorities, then you should know how hard it is to avoid Microsoft’s proprietary formats and fonts and you’ve likely also gotten complaints about your documents (whether it be that the recipient can’t open them or they just don’t render correcly in Office).

So what should we do about this?

ODF in the browser

A big step towards bringing ODF to the masses is putting an ODF viewer on every computer. Even though LibreOffice is free, most people won’t download a whole office suite just to open that one file that you sent them. They probably won’t even want to download a small viewer or an ODF converter, because they don’t feel safe installing unknown software, installation takes time, and, let’s face it, it’s just more crapware installed on the computer.

And so it’d be great if Chromium and Firefox (and other browsers) could open ODF files. It’d be preferable if it was built-in, but as this suggestion was rejected on the Chromium bug reporter (since ODF is much less common than PDF), the feature could be developed as an extension. I’m not sure if anyone is still actively working on it, though there was some discussion on both the TDF and the ODF mailing lists.

Fonts everywhere

Another step towards liberation from MS technology is liberation from the proprietary fonts they utilize (namely Times New Roman, Arial, and Courier). There are font banks that help us with that: Google Web Fonts, the League of Movable Type, and the Open Font Library. Now all that remains to be done is to integrate these with office suites. For example, a person who receives a document with a font he/she doesn’t have installed should be automatically asked to install that font by the office suite (if it can be found on one of these font banks).

ODF everywhere

But let’s not stop there. Let’s make it easy for any software developer to implement ODF support in his software. That’s just what WebODF, ODFKit, and Calligra Suite (to a level) do.

WebODF is a JavaScript library that allows you to add ODF support to your website, but also to desktop and mobile software. It paves the way for an open-source online office suite. There’s a pretty good video about it up on YouTube.

ODFKit is what came before WebODF was conceived. It was developed by the same person, Jos van den Oever, but it isn’t a JavaScript library and doesn’t use HTML and CSS to display documents. Rather, just like WebKit, it’s a layout engine for rendering ODF documents.

Calligra Suite is an office suite, just like LibreOffice. But unlike LibreOffice, Calligra Suite has a much more modular core and therefore it should be much easier to branch and move to other platforms. There’s a good post about it on Inge Wallin’s blog.

Nautilus nostalgia

I must’ve seen this mock-up before, but I forgot about it. If I remembered, that might have saved me the trouble of mocking up Tap from scratch. (Now that I look back at Tap again, I agree that my mock-up was unnecessarily complex and unwieldy.)

This mockup comes from a group of Gnome enthusiasts: Garrett LeSage, Allan Day,  Hylke Bons, Máirín Duffy, Lapo Calamandrei, Andy Fitzsimon, and others. The blog post that this mockup comes from discusses the possible evolution of Nautilus (which has been transformed into today’s much heavier Nautilus 3).

There’s one particular UI element that I really like about it, though, and, sadly, it hasn’t been implemented in Nautilus 3: the Actions bar. This bar would “show relevant actions for the selected item”.

While that’s not necessarily revolutionary (this functionality being hidden under a right-click menu for years), having this functionality up front could potentially lead application developers to integrate better with this toolbar, which could make the experience of moving between file browser and application more fluent (as I talked about in a previous post).

Why there’s a need to reinvent the file browser

While web browsers have evolved amazingly rapidly over the last few years, thanks in no small part to Firefox and Chrome, file browsers have evolved at an extremely sluggish pace. Sure, over the years we’ve had some innovations like improved search and file previews, but for the average user, file managers are still woeful at their one function: managing files. That’s why people’s desktops are so crowded, why their Downloads folders are teeming with files, and why people are increasingly moving to specific file managers, like iTunes and iPhoto (or their FOSS equivalents).

But specific file managers still don’t cut it, at least not yet. They don’t exist for every file type there is, they show files only from specific folders, they don’t integrate with other applications (e.g. if you wanted to browse your Shotwell collection with Chrome), and, most importantly, they don’t allow you to associate files of different type.

My Tap proposal started out as an evolution of the LibO welcome screen into a specific file manager for LibreOffice files, much like the Google Docs file manager leads to all of the Google Docs modules. This manager would benefit from deep integration with LibreOffice and would make it easier to integrate LibO with online and mobile services, which usually lack a generic file manager. I realized, though, that this is not an optimal solution, as a LibO-specific file manager would single out every other document/presentation/image/… editor. Because this manager duplicates most of the functionality of a generic file manager, it makes more sense to just improve the generic file managers.

How?

Well, it’d be nice if there were some APIs that file managers could use to communicate with applications (I’m not a developer, correct me if I’m describing it incorrectly). The goal would be to get application commands into the file manager. For LibreOffice, these commands could include document conversion and exporting (e.g. *.doc -> *.odt), printing (you could print several files), editing document properties (metadata, security and internet options), wizards, merging and comparing several documents, creating a master file from several documents, etc.

Another welcome improvement would be leaving management of system files to “technical”/advanced/classic file managers and concentrating on managing non-system files, i.e. the files that the average user tends to come in contact with.

Various managers have been dancing around the idea of getting rid of the folder hierarchy. Personally, I find Google Docs’s solution to be the most powerful, yet incredibly simple: collections. Collections are basically tags that can have a hierarchy (i.e. you can have a single file in several collections, and collections can contain subcollections). There are many reasons to prefer collections over folders, and you may see these use cases already implemented in some specific file managers. For example, in photo managers like iPhoto or Shotwell, you can categorize photos by the people in the photo, by date, by event, and by any other custom category. In music managers, like iTunes or Banshee, you can include a single song in as many playlists as you’d like.

In a generic file manager, there is an advantage in sorting files by filetype (like Google Docs does or like many media players do). Sorting by filetype allows generic file managers to have the same kind of filetype specialization as specific file managers do. For example, there could be two kinds of collections: generic for all filetypes (akin to folders) and filetype-specific. Thus, you could use playlists with the “Music” and “Videos” sections of your generic file browser, photo albums with the “Photos” section, libraries with the Documents section, etc. The interface wouldn’t bloat up with collections too easily, as filetype-specific collections could only show up when viewing the appropriate file type.

Lastly, all file browsers could profit from built-in (or just closely integrated) file preview capabilities, à la Apple’s QuickLook and its open-source equivalent Gloobus. The improvements range from being able to use your file browser as a basic media player to just not having to launch and close an application every time you want to look at a file.

Why We Can Do Better than the Ribbon

There’s a bunch of people who like the Ribbon. And there’s a bunch of people who don’t like it and either keep using Office 2003 (or earlier), use alternatives like OOo and LibO, or crankily use one of the ribboned versions of Office.

I actually think the change from Office 2003 to Office 2007 was a positive one. Here’s why:

  • The organization finally makes some sense, and a user can now easily find his favorite commands.
  • It is the one central place to find everything.
  • It brings more functionality.
  • It has some big buttons that are easy to hit with a mouse cursor.
  • It looks good.

None of these things really require a Ribbon. This can all be accomplished with our classic menus and toolbars.

Here is where the Ribbon fails:

  • It’s not very scalable.
  • It’s horizontal, so it’s unintuitive to scroll through and move through.
  • It takes up a lot of valuable screen estate (vertical space is more valuable than horizontal; sidebars would have been better).
  • It’s browsed by icons, not by text.
  • For acceptable scalability, each icon has to have several sizes.
  • There’s an ambiguous “Home” category and “Quick Access” toolbar, which include various commonly used commands.

I’m convinced we can find a better UI than the Ribbon. I don’t think maintaining several different UIs for LibO is a good idea (that’ll just bloat LibO and take up development time) and I don’t think adopting the Ribbon is a good idea either, even if MS’s Ribbon patent gets rejected.

It seems that OOo is going to have both the Ribbon and the old interface (which I think is a horrible idea), and I’m hoping LibO will go another way.

I’d like to hear some comments on this from the LibO leaders: Does LibO plan to work on their own UI if OOo gets the Ribbon?

I’m also looking forward to some UI proposals from others: some people on the mailing list said that they were already working on them. There’s a good chance that the future LibO UI will beat anything MS has. :)