Revision as of 11:05, 12 January 2008

THE GRAND VISION

A Radical New Approach to Content Creation and Management

Intro

I have a vision, but unfortunately, like any radical vision, it implies major changes in many different areas.

The increasing prevalence of Internet and Net technologies imply a major shift in content creation. Unfortunately, current “classical” content formats do not keep pace with these new developments.

These older formats were designed for printing on paper, not to view and edit on the net. They were appropriate for the last 500 years, but they miss the point in the 21st century. When we talk, we are dynamic. Sometimes we argue with ourselves, alone, in a monologue, but most often people dialogue with each other. The visuals are important, too. Yet, these old documents do not have any dynamic content, because, obviously, the paper cannot support something that is dynamic.

But paper is relentlessly supplanted with online content, be it wikis, blogs or forums or any other eDocument type. Completely new document formats are emerging: just consider YouTube and its tremendous success. The future will be a rich one and a very dynamic one.

I will begin this discussion with some specific points about the existing OOo modules and, in the end, list some requirements needed to meet these future goals. Unfortunately, because the future is so dynamic, the single most important requirement, implies refactoring OOo in a way that will allow easily improving/adapting/developing/EXTENDING OOo. A slim, modularized OOo will allow this. A monolith will be a block in future development.

Writer

The greatest shift in content creation takes place in the classical text-documents. It is this that will have the greatest impact in the future. Pure text - by definition static - has evolved to something dynamic. There is no correspondence in the classical documents for this new type.

Greater Net Interactivity

• more people write in blogs, wikis and forums than they write documents (by a margin of probably more than 10:1; tendency increasing)
• ability to export directly to these formats (MediaWiki extension is the right thing, but needs much improvement)
• ability to synchronize local documents with remote / net based documents (e.g. Wikis; not just export, but import back, as a wiki might have been changed by someone else)

Dynamic Content

• the new technologies make the old document formats look like carvings from the stone age
• one of the major drawbacks of these old formats is the very limited dynamic functionality
• the net technologies (like js/java) are much more dynamic, and new ones (like the Lively Kernel) will become even more so in the future
• audio/video-capabilities in OOo and ODF are virtually non-existent
  • there are more viewers on YouTube daily than probably downloads of all ODF-compatible programs in one month
  • some videoclips on YouTube have more than 10,000,000 views; tendency increasing

These net technologies open avenues for content development that exceed our imagination. The world is in a revolution, and rather in a big one. In 1-2 years we will see document types that we haven't even thought about today. I am rather sure about this development. Of course, you can't print a video on paper, but this misses the point. The world has become wired, and documents will evolve to fill this gap.

The problem with the current OOo design is its monolithic structure. It has to become more flexible. New modules need to be integrated more readily, and, more importantly, it has to become easier to develop new modules. Documents will evolve fast, so you need a slim modularized architecture to keep pace with the development.

Should OOo include audio/video-editing capabilities?

My point was always to reuse existing software, especially when free and very good alternatives exist. It is likely that there won't be enough resources to do it from scratch anyway. However, both ODF and OOo have to prepare to integrate such features in the shortest time possible. YouTube doesn't wait. Please also take into consideration, that future document types might evolve to something very different we envisaged today. OOo (and ODF) must be able to adapt fast. Only those who adapt fast will survive. Take the scissors now, not later. Later might be too late.

Impress

Interactivity

Current presentations are often so static. This becomes more cumbersome with online-presentations (see next section). Net technologies offer so many lessons and advantages, that I am still amazed how little the classic presentations have evolved. I already mentioned the Lively Kernel and posted some feature requests on IssueZilla, but this is more than some disparate issues. This is really about a global challenge in the perception of presentations.

Audio/Video

Beginning with 2006, more and more online presentations popped up on the net that use both audio and video streams. In the beginning (before 2004), most online presentations consisted of images exported from MS Powerpoint accompanied by some transcript. In late 2007, the presentations shifted to really dynamic audio/video-content using fully the new net-technologies, similarly to the evolution of YouTube. This development will likely increase in the future and mostly supplant existing presentations (the classic presentation won't completely disappear, but it is cheaper to watch the presentation from home, than buy a plane ticket, fly 8-12 hours around and then fly back with a monster jet-lag).

Impress has to adapt quickly to this new situation. It is not as widely used as MS Powerpoint (less so than even Writer and Calc), and tremendous changes are pending. Even more likely, both Impress and Powerpoint will be the great losers.

Calc

Multidimensional Spreadsheets

Canvas/ Grid – Editor

OOo Modules

The first step in addressing all previous concerns is to split the monolithic OOo into separately downloadable modules.

Intro

By far the most used modules in OOo are Writer and Calc. This will always be the same. All other modules are less often used and – more importantly – are used in very specific niches. The numbers speak for themselves. Before debating some further concepts, I would like to address these niches:

1. Impress

• mostly used in academia and in the management/marketing departments of businesses
• rarely used outside these settings
• bias towards MS PowerPoint: although I exclusively use Writer and Calc at home (and >95% at work), I still mainly use MS Powerpoint for presentations. Therefore, the ~5% usage statistics for Impress has the potential to increase, especially in particular settings (but strong new features are needed to supersede MS Powerpoint)

2. Base

• probably used in very specific situations
• likely used preferentially by power users
• do not know any friends actively using it, nor do I use it myself (neither Base, nor Access, I might be biased therefore)
• good alternatives are available (MySQL, Postgre, phpMyAdmin for DB management)

3. Draw

• good alternatives are available (Inkscape, Gimp, others)
• used by a minority (but this could be improved, if more versatile)
• needs further development / more features

4. Math

• used by a minority
• because of its tight integration with Writer and possibly the small overhead (just guessing), could remain in the base package

Why should OOo be split?

Simply put, the monolith is too big. I will try to compare the OOo story with the Mozilla/Firefox story (please remember, I am a staunch supporter of Seamonkey, not of Firefox!). There are also differences, as Firefox added substantial improvements over IE, but still one of the main reasons of its success was its small size. It was a wise decision to split up the monolith and develop a slim and powerful component.

What should be done?

Split OOo into a base module (Writer + Calc + possibly Math) and separate modules for Base, Impress and Draw.

What are the requirements?

1. extensible architecture
2. very good install wizard to pick up which additional modules to install
3. completely asynchronous install process

Users might download the full package. But some will download only what is needed.