The Mega apps

Around 2000 I worked on Java Web apps using Eclipse, an open source IDE, which was also extendable with all kinds of tools. Since it was an IDE some made tools for drawing code with UML (connecting named boxes with attributes). But it was also the playground for tools less related to coding. It became a kind of OS running on an OS.

Less niche, was perhaps Netscape Communicator. It was a web browser, an email client, a webpage builder, a calendar … all in one. And also quite extendible again with plugins. The idea still lives on in the Mozilla Seamonkey-project.

A remnant of this is perhaps Microsoft Outlook. An e-mail client with integrated calendar app. An approach mimicked by Evolution on Linux.

I was reminded by all this because Mozilla wants to focus on integrating AI in their flagship product Firefox. A lot of people respond negatively to that idea. The common theme: a browser should be fast. And probably they remember the time that browsers were suites, like Netscape communicator… big apps that became slow to start with a plethora of plugins. I guess that most users have just a small selection of plugins installed these days, as browsers do just enough to satisfy their needs.

But let’s explore the contrary idea: there are definitely advantages to having mega apps. It potentially allows you to create apps that have features that deeply hook into each other. Combining e-mail and calendaring allows you to receive an e-mail with a date, parse it, and create a new calendar item from that e-mail. But macOS users will tell you that this can also work quite well even across apps. But why not have a great video editor accessible in your presentation suite. Or at least a great photo editor? I definitely would like to see browsers being able to at least do some image manipulation before upload. There are plenty of work flows that could benefit from a deep integration of tools, not restricted to the copy/paste/insert interactions.

But how to prevent bulkiness? Perhaps we should be building OSes more. An API layer that allows cooperation between different apps that tie into the OS. The definition of an OS here being stretched. Maybe it is more of a desktop environment.

An offline translation function is nice, but it should not be an extension to just a browser. What if a OS plugin exists which detects texts (web documents and others) and allows for rapid on the fly offline translations anywhere? Or, when having a call and deciding on the next meeting, you want to quickly share ability, share not your entire calendar but just your availability (yeah within companies it typically seems to work to plan a meeting, but across… Heck, your machines should have come up with solutions. And all this functionality should not be restricted to just your office suite in use within your company.

On lower level many things are shared. The open dialogue, the print dialogue, much of it is standardised. But what should the next layer be like, to truly support our day to day life mediated by machines. Dynamically linked libraries? Or near monopolistic OSes that set the standards? Perhaps collaboratively crafted open source, but still a single platform? Or should we have APIs that would allow users to mix and match tools that collaborate without ever having been tested to work in unison? Not as code. But as bricks of Lego. Maybe apps may come with new other bricks.

We are converging to a world of apps where things become more isolated. Because we know how things behave in isolation. And it solves our problem of bulkiness. But to properly support our work, we also need to keep in mind how these apps can work together, as integrated collaboration. Perhaps even assisted by some AI.