StarOffice / OpenOffice.org “Q” Product Concept

This document provides a +comprehensive, high-level overview of concepts for features in the +next release of StarOffice / OpenOffice.org (SO/OOo) currently in the +planning phase.

The specification for such a large +project covers many areas and many details. Consequently, it will +not provide a complete list of all the details, but occasionally will +include some details to aid in clarifying the discussion. Many more +details have already been and will soon be submitted as feature +issues in IssueZilla, completing the picture.

In compiling this document, we've +gathered feedback from users, developers and existing or potential +customers: in direct communication at trade shows like Linux World, +during events like the OpenOffice.org Conference, using surveys, and +last but not least in discussions on the OpenOffice.org mailing +lists. We then put together ideas to respond to these requirements, +prioritized them, and finally assembled it all into the Product +Concept. +

During the prioritization for this +release, we had to strike a balance between the importance of each +requirement and the goal of an 18-month cycle for releases. We've +learned from discussion, particularly with enterprise customers, that +this is their expected “heartbeat” for major releases of +an office productivity suite.

The structure of this document +provides different levels of detail about the concept:

Before beginning, let me introduce +one convention used throughout this document. Code name “Geordi” +stands for SO/OOo 1.1, and “Q” for the next major release +after 1.1.

And one final note, you'll find the +document chapters tagged with different author names reflecting that +many people contributed to this document. We all would be happy to +get your feedback. So if you want to tell us something we could have +done better, we may have forgotten or just want to ask a question, +please refer in your comments to the section on which you are +commenting. This will help us identify the person who can best +respond to your feedback.

+2 Executive Summary

“Q” will be the next +major release of StarOffice / OpenOffice.org (SO/OOo). Listed below +are the concepts to address the key requirements of our existing and +potential customers. These CTQs (Critical to Quality) are all +centered around the main theme: migration to “Q”.

+3 Concept Overview

This section explains the +prioritization and provides a general overview about all concept +areas. More details are given in section 4, Concept Details.

The priorities used in this concept +have been set according to the general guidelines of priorities from +different bug tracking systems, including IssueZilla. Although the +latter doesn't +specifically exclude feature issues from having priority 1, a P1 +issue normally means that an area is broken and cannot be worked +with. Typically P1 is reserved for bugs only. That's why the scale +for requirement priorities ranks from P2 (highest) to P5 (lowest). We +assigned them in the following way.

+3.1 Key Drivers (P2)

The overarching motto and strategy +for this release is to lower the barrier for customers to migrate to +StarOffice/OpenOffice.org (SO/OOo). Our concept addresses this at +various levels, in different areas of the product. The following +areas describe the key drivers for “Q” - the areas that +we hear about most in our customer research. These are the areas with +highest priority and also often the highest effort in development +engineering. +

+3.1.1 Microsoft Office Interoperability

Interoperability between Microsoft +Office and SO/OOo is generally influenced by three factors. The +first factor is the quality of the filter component, that is, the +quality of the component that translates the content and structure of +a Microsoft Office document into the content and structure of a +SO/OOo document. The second factor is the compatibility of the +feature set of the application in Microsoft Office versus the +corresponding SO/OOo application. The third factor is the behavior +or interpretation of features that exist in both applications. Even +if another application and SO/OOo both support a certain feature, +there might be differences in the way the feature is actually +applied, so that documents in fact might look different although they +have exactly the same values stored for the feature within their text +engines. +

One (already resolved) example of +this is the upper paragraph margin that exists in Microsoft Word and +SO/OOo Writer. The latter, +like many DTP and professional word processing applications, ignores +this value for the first paragraph of a page. Microsoft Word does +not. The result of this is that the documents look different, +although exactly the same values are stored in both text engines.

+3.1.2 Usability

“Q” will change its +overall appearance in order to improve the usability for the majority +of non-SO/OOo customers. These changes affect the menu structure, the +toolbar User Interface, the terminology, and finally the overall +window layout. +

In general, usability is about task +conformance, familiarity, predictability, flexibility, robustness, +customizability, and learnability. Several minor usability +improvements support the usability of SO/OOo in aspects of these +usability qualities. All new features will be evaluated against these +qualities by the Sun StarOffice User Experience Team.

Task conformance pushes us to +reconsider the necessary steps for an action and reduce the number of +mouse clicks in “Q” as much as possible. Predictability +demands that we strive for a consistent user interface. We will +provide a conceptual model that is predictable and consistent for all +SO/OOo applications instead of conforming with the majority of +competing applications. On the other hand, predictability calls for +conformance with styleguides for the target platforms.

+3.1.3 Performance

SO/OOo will improve its performance +in four areas that are especially important to customers. The two +most visible areas of improvement will be decreasing the Startup Time +and Document Open/Save Time. The third area of improvement will be +Responsiveness in rendering more complex drawing objects as they, for +example, occur in presentations. The fourth area is in the +Scalability of large scale multi-user deployments like on Citrix, +Tarantella, and SunRay servers. +

The performance improvements in the +first three areas were identified as being mostly of an architectural +nature. Significant improvement in any of these areas can be +achieved through either refactoring the current architecture, or +replacing architecture. The fourth area of scalability issues +originates in a number of areas that can be addressed individually.

+3.1.4 Programmability

Programmability describes the +possibility of usinge SO/OOo or parts of it in custom solutions +programmatically. The underlying technology for SO/OOo +programmability is the SO/OOo component model UNO (Universal Network +Objects) and the SO/OOo API . “Q” will make it easier +on many levels to create solutions utilizing UNO and SO/OOo's API. +This will be achieved through improved language bindings, IDE +integration, easier deployment of add-on components into a SO/OOo +installation, and a new scripting framework that allows use of other +languages in addition to BASIC for scripting purposes.

+3.1.5 Integration into Gnome Desktop and Microsoft Windows

The overall requirement is to provide +an easy to use desktop with an appealing and modern Look and Feel +that is consistent throughout all applications.

To achieve a better system +integration, "Q" will make increased use of information and +infrastructure that is provided with the Gnome desktop instead of +creating platform independent solutions. +

+3.2 General Improvements (P3)

The next areas are still mandatory +requirements. They fall under general improvements, that help +facilitate a successful deployment of SO/OOo.

+3.2.1 Stability and Quality

“Q” improves stability +and quality by addressing the response to SO/OOo crashes with +unsaved documents, which can result in lost data. Currently, SO/OOo +performs an emergency backup of those documents only. Upon next +startup, a Document Recovery dialog then offers to restore those +documents to a previously known good state.

The probability of data loss due to a +crash will be reduced by augmenting the current emergency backup with +regular backup copies of documents. The Document Recovery dialog +will be improved by providing more guidance and feedback while +restoring documents. An Error Report tool, available in the “Geordi” +release, should provide data to help identify and eliminate crash +causes.

+3.2.2 Administration and Deployment

With regard to deployment, "Geordi" +offers a platform independent installation process, which can not +easily be managed by any kind of management software. Instead of +adding additional management capabilities in this area, SO/OOo "Q" +changes the installation process. The platform independent +installation is replaced by the support for standard, platform +dependent installation routines - so called native installers - and +their native installation packages. These are the Solaris Package +(pkg) installation, the Linux RPM package manager (RPM) installation, +and the Microsoft Installer (MSI) installation.

The advantage of this approach is to +leverage already existing deployment technology based on those native +formats. With "Q", administrators will be able to install +"Q" with their existing tooling.

+3.2.3 Modern Look & Feel

Users are asking for various look and +feel improvements, which fit mainly into three categories.

For SO/OOo "Q" we will +address these areas by improving the look & feel and adjusting it +to the expectations of the majority of non-SO/OOo users while +balancing it with the expectations of current SO/OOo users.

+3.2.4 Integration (Plugins, 3rd party applications)

The first two options are already +widely used in SO/OOo. Adding support for more 3rd party applications +simply means providing the necessary conversion routines and will not +be discussed here in detail.

External communication means are +usually tailored for every single use case. Examples for this kind of +integration are external e-mail clients. +

This concept document concentrates on +the first approach. The latter one is addressed by UNO bridges like +the ones we have (or will develop) for OLE Automation, .NET or SOAP.

+3.3 Upcoming Opportunities (P4 and P5)

The final part of the concept +contains optional enhancements in the area of upcoming opportunities +that we can foresee today.

+3.3.1 Asian and CTL languages

Internationalization (I18N) describes +the ability and availability of a product for international markets. +This means that the product has to comply with 3 important issues:

StarSuite 6.0 and "Geordi" +support IME that enables the input of East-Asian scripting like +Chinese, Korean and Japanese. Furthermore "Geordi" pays +tribute to the most needed features for text processing in Asia, like +vertical text layout, Ruby support, specific font effects and other. +While "Geordi" covers features and needs for CJK markets, +it takes only the first steps towards a specialized offer to the CTL +(complex text layout) markets (Arabic, Hebrew, Thai, Hindi etc.). “Q” +will complete the CJK (Chinese, Japanese, Korean) feature set and +complete CTL features started with "Geordi":

With “Geordi”, SO/OOo +demonstrates it's suitability for the CTL markets (e.g. Arabic and +Hebrew regions)

+3.3.2 Digital Signatures

Security for office document content +can be divided into two features, digital signatures and encryption. +

Digital signatures themselves are a +relatively new topic for office applications. The requirement to +protect data from being modified has existed for many years , +however. In the past, it has been addressed by features that +protected documents from being edited within the office application. +With digital signatures, these features will be enhanced to offer +secure protection of document content, inside SO/OOo, and outside of +it.

+3.3.3 Compelling upgrade features (e.g. multi media, OCR, DB)

Encryption is a feature that has been +supported by office applications for a long time. Enhancement in +this area mainly affected the encryption algorithm themselves, to +make them more secure. However, since there was no standardized way +in which encryption algorithms are applied to documents, processing +such documents outside an office application was complex. By +supporting new XML encryption standards, and due to SO/OOo's XML file +format, this will become much easier.

Although the requirements cover many +improvements and new features for SO/OOo, this section is reserved +for features that make the upgrade particularly compelling for +existing SO/OOo customers. Since we don't know of any specific +customer requirements that fit exclusively into this section, it's +content will be determined later.Web Services

Web Services become more and more +important as they easily can be used to establish B2B communication +in a platform independent way. There are lots of Web Services +available that offer a broad range of functionality, for example +Google offers a Web Service for searching the Internet.

It would be valuable, if SO/OOo could +act as a Web Services client, meaning that it could access and use +arbitrary Web Services.

Additionally it could be interesting +to offer SO/OOo's functionality as Web Services. An example for such +a Web Service is a document transformation service, which would be +based on SO/OOo's document import and export.

+3.3.4 Intelligent Document Tags +

SO/OOo will support an interface for +intelligent and extensible document tags. This interface will allow +third party vendors to offer additional information/services on the +basis of textual analysis. This is a win-win situation. SO/OOo gets a +feature without the effort of reinventing the wheel. For third party +vendors it creates a business opportunity around SO/OOo.

Initially, all words/phrases which +are recognized as keywords will be underlined. The user is able to +open context menus for these marked words and to choose additional +actions.

Example: A vendor offers a component +with different dictionaries (technical, juristic, medicinal). The +SO/OOo document will be scanned for entries in these dictionaries. +For marked words the context menu contains the names of the +dictionaries where the word has been found. The user chooses a +dictionary and the component displays the complete entry.

Example: The supporting component is +based on a customer list. If the name of a customer is present in a +SO/OOo document it will be underlined. The context menu may offer +actions like “address”, “send email”, “show +business volumes”, “show last order” et cetera. The +chosen information will be displayed or another program like an email +client will be started. +

+3.3.5 Collaboration

+4 Concept Details

+4.1 Key Drivers

+4.1.1 Improving Microsoft Office Interoperability

In the past, interoperability between +Microsoft Office and SO/OOo was improved by completing the import and +export filters. In "Geordi" interoperability between +Microsoft Office and SO/OOo was improved by also adding features to +SO/OOo and by changing SO/OOo's behavior and interpretation of single +features. +

For “Q”, interoperability +will be improved in a very large scale by continuing to add features +to SO/OOo. Changes in the filters are of course still required to +support the new features or changed behavior.

The movement of effort from the +filter development into the application development is in fact a very +natural process. At a certain stage, interoperability of a certain +feature cannot be improved by the filter any longer, because it +already converts all data that is supported from one application to +the other. At this point, if the feature still behaves differently, +the SO/OOo application itself may be enhanced.

4.1.1.1 SO/OOo Writer

For SO/OOo Writer, there are four +main areas in which interoperability with Microsoft Office will be +improved: tables, drawing objects, numberings/bullets and spacing. +The improvements in these main areas will be completed by many other +small enhancements in other areas that also raise interoperability +issues.

The most important improvement will +be the support of automatic page breaks within cells. Currently, this +can cause significant differences in layout of the same document +between a non-SO/OOo application and SO/OOo Writer if the document +contains tables that do not fit on a single page. Two other important +improvements will be the support of tables within tables and of +tables where text flows around them. Table interoperability will be +completed by a border model that provides better interoperability +with other applications, including Microsoft Word. Interoperability +improvements mentioned above are considered to be a much higher +priority than those that can be achieved by introducing a different +table model.

A second very important area where +interoperability will be improved is in SO/OOo drawing objects. The +most important improvement will be supporting other applications' +drawing objects within page headers and footers. In addition to this, +missing alignment, anchoring and position modes will be added. +Finally, there will be a unification of drawing objects and SO/OOo +Writer's so called fly frames, i.e. graphic, text box and OLE +objects. Many options that are available for frames will be made +available to drawing objects as well and vice versa. The user +interface of both kind of objects will also be unified.

Interoperability of numberings and +bullets, the third main area mentioned above, will also be addressed +by many small enhancements. Negative indents will be supported and it +will be possible to change the indent values for every paragraph +individually. Tabulators will be supported within numbers. Last but +not least, the the calculation of chapter numbers and table of +contents will be enhanced.

The fourth important area for +improvement can be summarized by the word “spacing.” +Although the differences are very small (typically less than half a +point) and will hardly be noticed by the user, the end result might +be that an imported page contains two lines less of text on a SO/OOo +Writer page. This again can result in images and text boxes appearing +on different pages, and the document may look completely different in +SO/OOo Writer.

4.1.1.2 SO/OOo Calc

Most interoperability problems +between Microsoft Excel and SO/OOo Calc that exist today result from +an incompatible feature set. The biggest advance in interoperability +can be achieved by adding new and changing existing features in Calc +to achieve better compatibility.

Currently, 32,000 is the maximum +number of rows in a Calc spreadsheet. Cell content beyond row 32,000 +is lost when a file with more rows is imported into SO/OOo. If more +than 32,000 rows are needed for a specific spreadsheet, there's no +easy way to get equivalent results using only SO/OOo's 32,000 rows. +It is therefore important to adjust our row limit. The number of rows +in a spreadsheet will be increased to 65,536, with provisions to make +it relatively easy to further increase that number in later versions.

The second important issue is +calculation. Although the set of formula functions is very similar +across most spreadsheet applications, some special-case features of +calculation with these functions are not yet supported in SO/OOo. +Currently, when documents that use these additional features are +loaded in SO/OOo, the formula cells will show error values or even +different results from those in the original document. To get the +same results as in the original, the spreadsheets would have to be +changed manually. Especially in the case of array formulas, these +required changes would be quite extensive, making it difficult to +create an equivalent calculation in SO/OOo. We have identified a set +of features that cause problems.They will be addressed in "Q".

Another important feature that will +be added to SO/OOo is the ability to create form controls (list +boxes, check boxes, etc.) that are connected to spreadsheet cells. +These controls get their values from the cells, and update the cells +if something is selected. With the increased flexibility that will be +needed to support the form layer's own new features, we will be able +to also implement this connection to spreadsheet cells.

SO/OOo supports slightly different +cell attributes than competing applications. This leads to +differences in the appearance or behavior of imported documents that +contain these attributes. We will add corresponding features to +SO/OOo to eliminate the differences in imported documents. We will +extend the validation feature, annotations, scenarios, ranges and +hyperlinks, as well as some cell formatting attributes. +

Currently, basic functionality and +interoperability is available in SO/OOo's DataPilot. In "Q", +we will extend the DataPilot to the state-of-the-art feature set for +reports based on spreadsheet cell data. The most important of these +features are page fields, settings for fields and individual +elements, and the table formatting options.

Finally, it's common amongst the +competing applications to preserve as much of the original sorting +order as possible, when sorting a spreadsheet according by some sort +keys. In SO/OOo they end up in a random order. We can change the +implementation of sorting so that the original order is preserved +where sorting criteria are equal.

4.1.1.3 SO/OOo Impress

"Geordi" improved +interoperability with Microsoft PowerPoint in many aspects. To +further improve interoperability completely new features need to be +added to the application and the drawing layer.

The current animation system of +SO/OOo Impress supports one effect per shape with all effect types +individually implemented. Execution of all effects is either +automatic or manually per slide. Users request to have an equivalent +set of effects and to preserve the order of execution of effects when +exchanging presentations between SO/OOo Impress and non-SO/OOo +applications. +

Instead of manually implementing +every new shape effect, it is necessary to support an animation core +that is flexible to handle new effects that may be added later. The +first step is to add a core component that can fully load and store +non-SO/OOo effects for improved interoperability. Due to the higher +demands for hardware supported rendering this first step will not be +visually equal on all effects. Also playing the effects in real time +will not be solved by this. +

To support a timeline concept, there +will be a timeline feature for SO/OOo Impress. With this timeline, +interoperability is enhanced by preserving the order and timing by +which the shape effects are executed. Users will be able to add more +than one effect to each shape and to have effects that are partly +automatic and partly triggered by mouse clicks.
This will also +include a user interface to change the new introduced timeline and +effect features. “Q” will also provide a shortcut, for +the user to select an animation theme for a slide, so that the slide +and shape effects are automatically set to fit the theme.

Interoperability with other +presentation programs, including Microsoft PowerPoint, will be +improved by adding means to use sticky note like comments in Impress. + Currently, upon import, SO/OOo Impress ignores this information. +This improvement will enhance interoperability by preserving document +content and by giving SO/OOo Impress users who need to interoperate +with other application users the ability to exchange comments on +their work.

Sometimes headers and footers in +Impress presentation slides get lost during a roundtrip from +Microsoft PowerPoint to SO/OOo Impress. The reason for this is the +different way headers and footers are used in Microsoft PowerPoint +and SO/OOo Impress. The SO/OOo Impress method for using headers and +footers is much more flexible than Microsoft PowerPoint's.

To meet this requirement and to +improve ease of use, SO/OOo Impress will provide easier access to +it's header and footer feature. This will not only enhance +interoperability by keeping header and footer information persistent, +but will also provide the user with an easier interface to create +them in SO/OOo Impress. There will also be an easy to use dialog to +change the header and footer for the current page or for all pages.

Often drawing shapes, such as +“AutoShapes” in Microsoft PowerPoint, can be found in +competing presentation program applications. They provide an easy +way of adding drawings to presentations. Therefore a set of +predefined shapes of different categories like 'block arrows', 'flow +charts', 'stars and banners', 'callouts' and 'action buttons' can be +provided. +

For example, in the current version +of SO/OOo, imported Microsoft Office documents that contain +Autoshapes are mostly displayed correctly. There does not exist, +however, the ability to edit WordArt objects or to change 3D-objects. + Interchanging documents between SO/OOo and Microsoft Office leads to +the loss of functionality of these drawing objects.

To meet this requirement, an +implementation for extended drawing objects in SO/OOo will be +designed, including new dialogs to edit imported WordArt objects and +to change imported 3D objects. This will not only enhance +interoperability through supporting all Microsoft Office AutoShapes, +but make them fully editable and allow SO/OOo Impress users to create +functionally equal drawing shapes themselves.

4.1.1.4 SO/OOo Base (Forms)

An evolving standard for data entry +applications are W3C's XForms. XForm controls can be embedded into +any XML based file format like XHTML, and they support data entry +based on XML schemes. It is likely that XForms will replace at least +HTML/HTTP forms in the mid term future. By adding XForms support to +SO/OOo, it will not only keep up with recent development trends, but +in combination with the OASIS OpenOffice XML file format it also +becomes a powerful alternative to XHTML/XForms. What makes it +interesting to use an OASIS OpenOffice XML and XForms based SO/OOo as +a data entry client is that it offers much more layout capabilities +than XHTML/XForms based clients, but uses exactly the same open +protocols as XHTML/XForms based clients on the server side. Moreover, +since SO/OOo is also a powerful tool to create forms, even form +creation gets easier and does not require additional tools.

While XForms are already an +improvement for data entry applications, it is conceivable that data +entry applications will improve further. In some of the recently +developed applications, data entry is not limited to classical form +controls, but arbitrary text or other content can by included into +the form data. Additionally, some applications provide the ability to +extend forms at run time. An example for this are meeting minutes, +where an agenda item might be duplicated any times. These +capabilities allow it to use data entry applications not only for +static and simple forms, but also for such complex things like +minutes, bills or letters. In any case, the actual form data will +stay in an XML schema. These schema could be either a user defined +one, or one that is standardized by organizations like OASIS. In the +later category are the UBL schemes that are currently developed by an +OASIS technical committee. +

In such scenarios, the user creates +new documents based on existing document templates. In the new +document, data can be entered only at predefined locations, for +instance within certain fields, controls or text boxes. Moreover only +very few editing features will be enabled. For instance, text +sections might be duplicated but not inserted at any location. This +way, it can be ensured that the document always has a defined +structure. This again allows it to bind every editable data to +elements of an XML schema and therefor to submit them as XML form +data.

SO/OOo capabilities for such form +based work flows will be improved. The starting point is the XForm +enhancements described above. Further steps will be the inclusion of +for instance field or paragraph contents into XML form data and +possibilities to enter data into them in Writer's read only mode. The +capabilities to specify application behavior within templates will be +improved. Finally, certain complex editing operations, like +duplicating a section, will be allowed in Writer's read only mode as +well. By adding data entry capabilities to SO/OOo step by step, more +and more work flows can be implemented with SO/OOo. +

SO/OOo will also improve its +interoperability with the form functionality of Microsoft Office, in +particular of Microsoft Word. Microsoft Word features two completely +different concepts for form functionality: form fields and form +controls. Form fields are the more ancient concept and are not +supported by "Geordi", but are nevertheless frequently used +by Microsoft Word users. SO/OOo will address this by implementing +equivalents for these form fields.

Form controls offer a functionality +similar to form controls in SO/OOo applications. For “Q”, +we will implement some new control types like scroll bars, toggle +buttons, and a rich text control, and enhance existing control types +with functionality currently not present, for example multi-columnar +list boxes, and spell checking in text controls.

4.1.1.5 SO/OOo Chart

Additional functionality will be +added to the Chart core. This added functionality will ease Bug +fixing and integration of new features. +

The most important feature that will +be added will allow data series to get their input from individual +cell-ranges for x-values, y-values, labels, etc. Without it, some +imports from non-SO/OOo spreadsheets can only produce an empty +output. Technically, this requires new interfaces for the +communication between SO/OOo Chart and either SO/OOo Calc or SO/OOo +Writer. Moreover, the source data concept within the SO/OOo Chart +needs to be redesigned completely.

Some new chart types have to be +integrated too – especially bubble and surface charts. A bubble +chart requires an additional input range for the bubble sizes. As +this additional range does not fit into the current source data +structure the new source data concept mentioned above is a +prerequisite for offering a bubble chart as well.

Moreover, the integration of a new +chart type into the old SO/OOo Chart core could jeopardize existing +functionality, as chart type dependent code is spread over the whole +project. To eliminate this fundamental problem a new SO/OOo Chart +core will encapsulate chart type dependent code in separate UNO +components with well defined interfaces.

The re-implementation of the SO/OOo +Chart core is a necessary, long-lasting task that has to be finished +before any of the requested new features can be started. The +re-implementation of the current functionality is expected to take at +least until the end of the calendar year.

The order of the items reflects a +proposed prioritization. The highest priorities are given to those +missing features that cause more information loss and are used more +often.

+4.1.2 Usability

4.1.2.1 Menu Structure

The redesign of the menu structure +will take the general concepts of the competing applications into +account. Two prominent examples of menu changes for “Q” +are the organization of menu items of the View menu and a new Table +menu for Writer.

4.1.2.2 Toolbars

The user interface of toolbars will +be completely redesigned. “Q” provides for small toolbars +that can be rearranged with drag'n'drop. The new design makes better +use of the screen estate by using the space more efficiently. The +dynamic exchange of toolbar content will be eliminated.

4.1.2.3 Terminology

The terminology used for the user +interface for menus, prominent dialogs and alert messages will be +revised in order to utilize the existing knowledge of office +productivity users.

4.1.2.4 Window Layout

Impress will get a new window layout +that introduces a tool pane for SO/OOo. The tool pane offers specific +commands for presentations to make it more easy for the user to +manage and edit slides, import styles and slides from other files and +to run her presentation.

4.1.2.5 Application Separation

For the user, “Q” will +also look more like separate applications. The Microsoft Windows +Start menu / Linux desktop panel, SO/OOo's “File” and +“Window” menu, document window titles, and the options +dialog will reflect this change. +

Along with this new concept we will +eliminate obsolete settings from the options dialog and make clear +which settings have effects in which part of the application.

4.1.2.6 General Interaction

The interaction model for text, +tables and images in Writer and for objects and layers in Draw and +Impress will implement state-of-the-art selection techniques.

For “Q” we will revise +the interaction concepts for compound tasks like mail merge and +creating charts.

Finally, the enhanced Undo +functionality will significantly improve robustness of the product. +

4.1.2.7 Usability of the Database +application

Currently, the database access (DBA) +functionality in SO/OOo exposes various differences from other +database applications. Those differences can be assigned to two +groups: usability and interoperability. These issues are +predominant with users who are not able to locate the functionality +they need (though often it is present). They then do not feel +comfortable with SO/OOo's user interface which follows a different +philosophy in this area.

Additionally, having a competitive +database application, instead of a set of database access components, +clearly is an important feature for potential users and customers.

We will address this with a redesign +of SO/OOo's database application. In the first instance, this will +lead to it being recognized as a state-of-the-art end user oriented +database application, and make former users of other database +products, like Microsoft Access, feel more comfortable. In the +second instance, it will address most of the problems customers have +with the current user interface.

SO/OOo DBA (with a new name which is +to be discussed) will be an own application, instead of hiding within +Writer, Calc and Impress documents. This will be perceived as a +competitive database application then, which will be equal to the +other major applications in SO/OOo.

This new application will be +accessible from the main menu – File|New is where users expect +to create a new database, so we will add a Database item, which opens +the application and offers the user a reasonable set of choices how +to proceed (e.g. create a dBase data source, connect to an existing +foreign database via an auto pilot).

We will not abandon the concept of +data sources. This is not only for reasons of feasibility (a +database engine is a very heavy-weight project), but also for reasons +of openness: We continue SO/OOo's philosophy to allow the user to +work with whatever database is already present in her work +environment, from client-side single-user file-based databases up to +server-side databases participating in a corporate work flow.

The layout and user interface of this +new application will, at the first glance, be recognized as +relatively similar to what typical database application users already +know. Where it makes sense, the application will provide a look&feel, +including functional concepts, that are intuitive.

As a consequence of this new database +access application, we will give it its own top-level topic in +SO/OOo's help system. This will increase the user's ability to find +help with database topics.

The functionality of the current Data +Source Administration dialog, and large parts of the functionality of +the current data source browser, will be merged in the new +application, providing one single entry point for database +functionality in SO/OOo.

We will re-implement the user +interface of SO/OOo DBA. We will move away from the current +technician-oriented user interface to a more end-user oriented work +flow and terminology.

In addition, several measures will be +taken to make the “data source” concept feel more like +the “database” concept the user is used to from other +office suites. Though the underlying core concepts will not be +changed, SO/OOo users then will have less problems when migrating +from other database applications.

We will change the way that data +sources in SO/OOo are administrated – we will put more focus on +meeting the user in her own vocabulary of concepts, by creating a +more intuitive user interface, and by exposing most of the technical +details to advanced users only.

An auto pilot will be created which +allows the import/export of data sources (file based), and thus +migrate them between installations. This will not only unburden the +user from the manual work which is currently required for this, but +also support the impression of a “database” in opposite +to a “data source” which the user cannot really control.

Form Documents provide a highly +customizable view to database data, thus they are the user's primary +choice when working with such data.

The main improvement desired by +SO/OOo users in the area of form functionality is usability. Thus, we +will make changes to SO/OOo affecting the user interface in several +ways. The user will recognize SO/OOo data-aware forms (which covers +form design as well as form usage) as a dedicated solution, in +opposite to the current situation, where form functionality is +recognized as a small and hidden add-on to SO/OOo text documents.

This list ranges from small and +rather cosmetic changes which will sum up to a much better user +experience, to larger projects such as a dedicated simple mode for +the property browser, which consists of specialized views for the +different object types, and presents only the most often used aspects +of these objects to the user, this way exposing the full power of the +property browser to advanced users only.

Additionally, functionality +enhancements will be made to SO/OOo's form layer. Included here are +additions to the form controls which are required in the Microsoft +Interoperability Chapter, but also new implementations (such as +real-time filter controls) which will bring SO/OOo nearer to the +current state-of-the-art.

We will provide the user with more +auto pilots for the most common tasks in the database area, +respectively enhance the existing auto pilots. In SO/OOo “Q”, +we will have an enhanced report and form auto pilot, and new pilots +for designing new tables, and designing customized data views aka +queries.

+4.1.3 Performance

4.1.3.1 Startup Time

The most visible performance +improvement in SO/OOo will be the substantial shortening of the time +required for first startup, in particular when the system has not +been used for some time or after a system reboot. The improved first +startup time will correspond to the time used by competing +applications.

Generally, the decrease in startup +time will be addressed through refactoring the code and removing the +strong interdependencies between:

In combination, these refactoring +actions shall result in loading a relatively lightweight framework +plus the necessary application code and document filters upon +startup, only, and will thus reduce both the startup time as well as +the initial memory consumption.

4.1.3.2 Document Open/Save Time

The second most visible performance +improvement in SO/OOo will be decreasing the time required for +opening or saving larger documents, in particular for documents in +the native XML format. This time improvement will be comparable with +competing applications.

SO/OOo will implement this time +savings with SO/OOo API enhancements that are optimized for XML +import / export and are fully supported by the application internal +implementations. Code optimizations along the entire import / export +component chain will be evaluated to identify and eliminate +bottlenecks.

"Q" +will speed up the graphics display and increase the responsiveness in +rendering complex drawing objects.

This improvement will be addressed +with a redesign of both the graphics toolkit, adding e.g., support +for modern hardware acceleration, and the presentation engine, making +use of double-buffering and other caching techniques.

4.1.3.3 Scalability

Large scale multi-user deployments in +which possibly hundreds of SO/OOo application instances are running +on a single multi-processor server will be improved beyond what +“Geordi” already addresses. Scalability issues can be +summarized and addressed as follows:

A high number of context switches per +second is caused by SO/OOo instances temporarily yielding control to +other processes or threads. This behavior induces a high load on the +system scheduler, and may as well adversely affect the responsiveness +of SO/OOo itself.

This will be addressed by giving up +current cooperative and timer based polling concepts in favor of +preemptive and event driven concepts.

The amount of non-shareable memory +per SO/OOo process to a large extend determines the number of +instances that can run simultaneously on a given server machine.

This will be addressed by reducing +the size of writeable data segments in shared libraries and special +purpose memory allocators for compact mass object storage.

+4.1.4 Programmability

4.1.4.1 UNO/Office API Improvements

The Office UNO API is very fine +grained. Although this offers maximum flexibility, programmers often +want to have simplified high-level UNO interfaces. This enables rapid +application development and helps even lower-skilled developers to +reach their goals quickly. To address this problem we need to provide +a new set of task-oriented high-level convenience UNO services.

UNO defines language independent +concepts like services, interfaces or the Any data type. The binding +to concrete languages often maps these concepts One to One. This is +not always the optimum because it may require the developer to learn +constructs that are unusual or even strange for a certain programming +language. A popular example for this is the queryInterface call, +which should be a simple cast in Java. For the next Office release we +will provide new UNO features which will simplify the usage of UNO in +general or for particular language bindings.

4.1.4.2 Integrated IDE for multiple +scripting languages

With the language independent +scripting framework it will be possible to script SO/OOo in any +supported scripting language. This raises the need for a lightweight +scripting IDE, which is integrated into SO/OOo and supports multiple +scripting languages including SO/OOo Basic, Java and JavaScript.

The scripting IDE will be based on a +language independent IDE binding concept. A scripting language can +only be integrated into the IDE, if the corresponding interfaces are +supported by the scripting runtime.

It is planned, that the current Basic +IDE and its dialog editor will be refactored and modularized, which +will be the base for the new scripting IDE.

4.1.4.3 Type Life Cycle

The Universal Network Objects (UNO) +Component Model with its support for different languages gains +popularity. UNO paves the way to access the SO/OOo API and +development of extensions by 3rd party developers.

This way, developers have to face +quite some problems introducing and using UNO types concurrently. If +it is feasible, it is desirable that UNO types have a controlled life +cycle.

4.1.4.4 .NET Bridge

SO/OOo uses software bridges in order +to have pieces of code, which may be subjected to certain language- +and runtime specific requirements and restrictions, interact with +each other. For example, Java code or C++ code cannot interact +naturally. The same goes for C++ code compiled with different +compilers. +

All those particular requirements to +a piece of code is referred to as environment and it is said that a +piece of code lives (or runs) in an environment. Now, to have code +from one environment access code in another environment, one needs to +have a bridge. Because of the multitude of possible combinations of +environments, bridges use an intermediary environment, namely the UNO +environment. +

If a new compiler is to be used or +software written in a new language, then one only needs to provide a +bridge into the UNO environment and all other environments for which +there is also a UNO bridge may interact with the new environment.

The CLI – UNO bridge enables +programmers to use languages which produce CLI (Common Language +Infrastructure) compatible code. This includes languages such as C#, +C++ .NET, and Visual Basic .NET.

4.1.4.5 Live Deployment and GUI

The development of 3rd party +extensions for OpenOffice.org using the OpenOffice.org API is gaining +popularity. The common tool to deploy those extensions into an Office +installation is pkgchk. The user raises the pkgchk deployment tool +specifying a package file to be installed. The tool then scans the +content of the package file and handles different content types with +respect to their file extensions:

Currently users have to shut down a +running office process before running the pkgchk deployment tool +adding or removing packages. It may be desirable that users can +deploy packages while running an office process and trigger removal +of existing packages. Moreover, the currently used pkgchk deployment +tool is a command line tool. If deployment can be performed while +running the office process, a proper user interface is nice, too +(e.g. in “Tools” menu bar).

The need to shut down the offices +using a shared installation is even worse, e.g. Imagine having a +shared installation used by a thousand users, before something can be +deployed into this shared installation, it has to be ensured that +every running office started out of this installation has been +terminated. Otherwise this office instances may work with +inconsistent data, which can lead to data loss or crashes.

Different content types are deployed +differently. Thus the problems that occur upon insertion/removal of a +package at runtime are different. +

4.1.4.6 Scripting Framework

Currently Scripting support for +SO/OOo exists for one language only, SO/OOo Basic. Users, Developers +and ISVs who wish to extend SO/OOo using scripting are locked into +this single offering. It is advantageous from strategic point of view +to support Java and Java derivatives such as JavaScript and +BeanShell for scripting. Other scripting languages such as Python +could also be added as the market dictates.

A framework is needed to allow new +scripting languages to be added and supported. It should be possible +to easily plug in additional languages runtimes. The framework needs +to provide an environment to enable users to easily and quickly +develop, deploy and execute scripts. Scripting should be easy. A +script developer should be able to write and test a script with a +minimal set of steps. They should be able to experiment and learn +within the scripting environment, enabling them to accomplish their +scripting tasks easily and quickly. +

Scripting in SO/OOo will be made more +easy, intuitive and low cost. This is mainly due to the complexity +and low level nature of the current SO/OOo API. In order for +scripting to be be easy, intuitive and low cost, the SO/OOo API needs +to be simplified. Such a simplified API should be well documented, +script focused and high-level. This would allow users to intuitively +discover the necessary objects and interfaces needed to program a +specific task rather than having to work through a mountain of +documentation.

+4.1.5 Integration into the Gnome Desktop, and Microsoft Windows

(Requirements for integration into +Microsoft Windows need to be determined later)

4.1.5.1 Look and Feel

“Geordi” emulates the +color-scheme and basic font setting of a running Gnome-2.x desktop. +"Q" is required to pickup the style of all basic widget +elements (buttons, slider, fixed-text, check-boxes and so on) in a +way that exactly reflects the current GTK widget theme. The majority +of dialogs should not show any immediately visible differences to a +dialog implemented in the GTK widget set. Focus, modality, and +guidelines for widget placement will not be adapted.

"Geordi" uses a proprietary +engine for installing, naming, and selecting fonts. Font names on the +system may be invalid in SO/OOo, or denote to a completely different +font and vice versa. The "Q" font handling scheme has to be +consistent with the Desktop and the major applications. Naming of +fonts shipping with "Geordi" or older versions of SO/OOo +must not change. Explicit settings for font replacement must remain +intact as well.

This will be addressed by using the +systems font configuration (Fontconfig2). Doing so will be as well +beneficial for the startup performance since "Q" will not +need to examine fonts at startup.

"Geordi" uses a mixture of +X11/cursorfont mouse pointer, pointer specifically designed for +SO/OOo, and pointer that are modeled similar to those found on other +platforms, like Microsoft Windows. This is inconsistent with other +applications on the Gnome desktop and it inhibits proper pointer +settings for accessible desktop themes (large cursor settings, high +contrast themes, ...). "Q" should use Gnome compliant +cursors where appropriate.

Hotkey/Accelerator scheme should be +aligned with the Gnome desktop. Common tasks should reflect in equal +keys. Keys already taken by the window manager should not be offered +or used for application bindings.

It would be nice to have Gnome input +methods available in SO/OOo as well (currently only available in +Gnome-edit and Gnome-terminal).

4.1.5.2 Printing

"Q" is required to be able +to provide the same printing experience as "Geordi" without +the need of neither own printer configuration functionality nor own +printer configuration data on a Gnome Desktop system. It may +eventually provide an own UI to the system configuration if the +systems UI is insufficient or otherwise unusable.

The CUPS system encapsulates and +provides access to locally connected printer, and remote printer +accessed through the IPP, LPD, SMB and many other protocols. +

CUPS provides a legacy layer that +enables "Geordi" to chose from and to print to all printers +configured within CUPS. However "Q" will be enhanced to +query printer capabilities from CUPS and comply with CUPS +configuration settings, thus making the proprietary SO/OOo printer +administration obsolete in favor of the according desktops system +solution.

Currently there is no system-wide +print dialog available. If there'll be shareable UI available in "Q" +timeframe it should be integrated instead of implementing a +proprietary UI.

4.1.5.3 Integration of network +neighborhood

"Q" is required to be able +to load and store files on SMB shares to allow for interoperability +in a network of Microsoft Windows computers. The UI has to be +extended to give convenient access to this functionality. Further on +it is desired to be able to handle all URLs that are valid in the +Gnome Desktop file manager (Nautilus)

Gnome provides a virtual file system +service (GnomeVFS). It makes various file systems transparent to the +user. Amongst others it is able to cope with protocols like HTTP, +FTP, NFS, SMB, local files, WebDAV. Further on it provides MIME +information and maintain an according application registry.

"Q" will be enabled to use +GnomeVFS. The main benefit is to improve interoperability with +Windows SMB shares. GnomeVFS will as well improve interoperability +with the Nautilus file manager since contents will be available in +both applications through the same URI. Further on SO/OOo will be +able to handle external data conforming to the system MIME settings. +

4.1.5.4 Desktop integration

A user of Microsoft Windows is able +to create new, empty SO/OOo documents on the desktop. The Gnome +Desktop shall offer a competitive feature. This will be addressed by +creating an according Bonobo component for Nautilus.

The most important applications on +the Gnome desktop will be immediately available from the Gnome start +menu. An according top level entry for SO/OOo needs be added. +

It is required to inform all +application on the Gnome desktop about how to handle SO/OOo files. +Especially the browser and the file manager need to be able handle +them appropriately and to show an appropriate icon. This will be +addressed by registering the SO/OOo MIME types in the according +system registry.

4.1.5.5 Application interoperability

Available browser plugins will be +made available for the SO/OOo “Insert -> Object -> +{Plugin|Sound|Video} mechanism.

4.1.5.6 Installation

The Gnome Desktop system will be +delivered as a set of packages in the +RPM format. It's necessary to seamlessly deploy and update SO/OOo +together with other parts of the operating system. +

Currently most Linux distributions +provide RPMs that correspond to a complete "Geordi" network +installation. "Q" will be delivered as a more fine grained +set of packages that enable individual installation, update and +patching of functional entities. Shareable files for system +integration will be installed in the system and not in every users +home directory as in "Geordi"

4.1.5.7 Configuration

SO/OOo makes use of a set of helper +applications. Application that can be used as helper application in +SO/OOo need to useable without further administration. "Q" +will make use of the Gnome desktop configuration where possible. +Examples here are default mailer, default web browser, and proxy +settings. The SO/OOo Configuration component will provide a +transparent access to the system settings, which will be resolved via +a plugable backend architecture.

+4.2 General Improvements

+4.2.1 Stability and Quality

4.2.1.1 Document Recovery

Any potential crash of SO/OOo that +could result in lost data will be addressed by defaulting to a new +Auto Recovery mechanism performing a regular backup of documents and +settings. This Auto Recovery mechanism will restore a users work +environment to the state before SO/OOo terminated.

The Document Recovery dialog will be +enhanced to guide a user through this Auto Recovery process of +restoring documents and to provide detailed feedback upon the +recovery progress.

4.2.1.2 Error Reporter

Stability improvements for SO/OOo are +required to be measurable. In order to be able to characterize the +current stability level, this requirement was pulled-in to the SO/OOo +“Geordi” release and has been addressed by an Error +Reporter application, recording crash data and user feedback about +document loss or preservation.

This Error Reporter will help to +identify and eliminate crash causes, as well as provide a metric to +show improvements in the stability levels achieved for SO/OOo “Q” +and subsequent releases.

+4.2.2 Administration and Deployment

4.2.2.1 Deployment +

The installation paradigm changes +from being primarily single user oriented to being administrator +oriented. It is looking for large scale installations and +administrations. This issue will be addressed by conforming the +installation process to the respective systems installer services, +since these services already provide or enable an existing +installation tooling.

The "Geordi" +user-installation as a required step of a network-installation will +cease to exist. The office applications will be fully functional from +the first start. Gathering user specific data will be postponed to +the first application start or queried directly from the system. +Document and setting defaults will be generated on the fly during the +first start or on demand.

The repair mode of the setup will be +dropped. Repairing the installed files is already handled by the +native package mechanism (usually by a reinstall). This does not +affect user driven changes since user and system files are strictly +separated.

Upgrading and patching will be +performed by means of the respective system installer.