User Experience/Grand Concept
Contents
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 shift that will have the greatest impact in the future. Pure text documents - by definition static - have evolved to something dynamic. There is no correspondence in classical documents for this new type.
The future is marked by 2 substantial developments:
Greater Net Interactivity
- more people write in blogs, wikis and forums than they use documents (by a margin of probably more than 10:1; tendency increasing)
- the ability to export directly to these formats is urgently needed (MediaWiki extension is the right thing, but needs much improvement)
- ability to synchronize local documents with remote/net-based documents is needed (e.g. for Wikis: beyond export, importing back is also needed, 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
The current spreadsheet model is rather a very old one. It has evolved by combining some elements of true spreadsheets with various formatting options. Unfortunately, it does not accomplish any of these 2 different jobs very good.
Canvas/ Grid – Editor
Most casual spreadsheet users will use the spreadsheet only as a big canvas/grid that allows them to easily highlight/format the data. They don't really need a spreadsheet model. What they need is to construct visually beautiful tables.
This is a feature I begin to use more and more often. (I am a spreadsheet power user, but, due to serious limitations of existing spreadsheets I have begun shifting the spreadsheet operations to other programs - see next section for further details.)
This advanced canvas should offer the following options:
- great flexibility
- advanced formatting options:
- e.g. highlight headers, different colours for alternating rows and highlight active row (issue 78181)
- easily fitting content to printing pages
- see also Mac's iWorks/Numbers
Multidimensional Spreadsheets
A different approach is covered by multidimensional spreadsheets. Multidimensional spreadsheets have been developed in the late '80s - early '90s. They offer great advantages in high end settings and represent truly relational data structures.
A multidimensional spreadsheet defines relations between the various variables/dimensions.
- every column represents a dimension/variable
- one defines relations between variables on a global level
- see also the Analytica website
- Advantages
- more structured
- easy to develop and maintain
- easy to extend and scale
- greatly reduce error rate
- a formula is introduced only once and applies to the whole data-set
- when extending one dimension (e.g. adding a new month-column), the formulas apply automatically to this new data-set; no need to manually set them
- easier to select which columns/variables to view
Solutions
What is really needed is to split these 2 concepts apart and really implement the 2 spreadsheet models independently and simultaneously. OOo should have both a powerful Table Canvas-editor, as well as a Multidemensional spreadsheet.
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
Code Changes
- 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?
- extensible architecture
- very good install wizard to pick up which additional modules to install
- completely asynchronous install process
Users might download the full package. But some will download only what is needed.
Extensible Architecture
OOo should be able to download any missing modules and install those components. The download should be asyncronous:
- only the missing files/components shall be downloaded, NOT the complete package
- this concept is used extensively in other domains: e.g. R will automatically detect and install any missing libraries/extensions when installing one particular extension that depends on those missing ones
Asynchronous Install Process
- users shall be able to work while OOo downloads/installs missing components
- OOo shall not need to restart, or, IF restarting, shall keep track of its previous state (similarly to latest Mozilla after an installation)
Install Wizard
If only some components have been installed, the user might be unaware of the full possibilities and features that OOo offers. Therefore, the OOo wizard has to be extended specifically to make informed guesses of what the user needs and to offer clear explanations about available modules and the utility of those modules.
GUI / Framework
The existing GUI is a relict from the beginning of GUI development. The GUI is very static, often not adapted to the use of a particular user, making it quite impractical in everyday life. Again, one can learn many new concepts from web technologies.
Many menus and buttons make the GUI complex and poorly usable. Dialogs are ugly, too, and contain mostly wasted space.
Some modern concepts will be discussed on a separate GUI page.
