Since we have been rather silent lately, some might think that not much is happening in the project anymore. Therefore I would like to give all those who are interested a short update about what else, besides prototyping, keeps us busy.

In addition to going through gazillions of feedback regarding the prototypes on different channels, thinking and discussing further UX engineering initiatives, analyzing the data collected using a new, office productivity specific version of the IsoMetrics usability questionnaire, there are two university projects that we give advice to in parallel.

A study project team at the University of Osnabrueck, Department of Work and Organizational Psychology, has been working in the context of Project Renaissance since April 2009. This spring semester, the students were busy with getting into the basics of UX engineering from a theoretical and a practical perspective. Their goal for the first half of the project was to design alternative solutions of how to handle charts in OpenOffice.org Impress.

In July, the team under the supervision of Prof. Dr. Kai-Uwe Hamborg visited us in Hamburg and the students were given the opportunity to present their redesign ideas to the UX team and the whole Imress team. We had a great discussion about current usability problems and how the designs proposed by the students might resolve the issues. For further details, please visit the project’s Wiki page. In the coming winter term, the students will be busy conducting a usability study in order to validate the designs. We will keep you updated about their progress.

The second project was also initiated this spring with the support of Prof. Hamborg who is by the way one of the creators of the IsoMetrcs usability questionnaire. Our goal was to collect detailed information about the usage of office productivity applications in a university context. An intern of the Department of Work and Organizational Psychology conducted interviews to collect information regarding the tasks the students use office tools for. The task inventory was then used as input for a survey. This survey was conducted in several universities using the freely available LimeSurvey software which is also used by several OpenOffice.org teams. Data collection was just finished, so for now no detailed information is available. They only data that is available at the moment is that over a thousand students participated in the study, OpenOffice.org seems to not to be the leading (by numbers) office productivity tool in university context and Linux, as an operating systems, seems to be ahead of Apple Mac. A detailed analysis is what follows and as soon as the data has been processed, results will be posted here or in the Wiki of Project Renaissance.

The results of the cooperation directly support Project Renaissance. The data from the user feedback program gives us a clue about frequently used commands but with little task context, whereas detailed information from the task inventory survey will help us to map usage frequency on tasks. In addition, the study project might give us the opportunity to validate a few specific design solutions (e.g. sidepanes) with users. However, this is up to the study project team.

Best,

Andreas

tags: impress renaissance user-experience

The prototype phase didn't end on July 4 after as originally planned. It is still going strong and eliciting a great deal of enthusiasm and feedback. In this blog post we want to provide answers to some of the negative comments we've received. Of course we have been thrilled by all the positive comments, too, but the nay-sayers have been vocal, so we need to be vocal, too.

Some of the negative comments posted after in our July status update post were:

a) Oh no! Not like Microsoft!
b) My monitor gets wider not higher (horizontal vs. vertical UI)
c) Do not copy ribbons. Innovate do not imitate!
d) Why are you killing menus?
e) I/Everyone hate/s 'ribbons'!
f) Make it optional. Keep classic interface as an option.
g) 'Ribbons' are only for beginners/newbies.
h) Professionals (like me) are distracted by the new interface/'ribbons' because I/they already know were to find the desired functionality.
i) It is so ugly!

Before providing answers, we want to remind everyone of our goals and a tidbit about doing such development work in public.

Our mission:
“Create a User Interface so that OpenOffice.org becomes the users' choice not only out of need but also out of desire”

and our project goal:
"... to know and to understand our users as they are, and to help them accomplish what they want to, by providing efficient access to valuable functionality through a desirable user interface."

Please trust us that we will not implement anything that has not been tested and validated in real-life situations.

Working in the "open" can be tough. It seems that everyone under the sun already knows what we should do. Regardless of what we present we will always get at least one comment saying our idea is wrong/stupid (See a, c, e). The team always has to keep in mind that many comments are not from average users of OOo. The UX team has to weigh all comments carefully. Presenting a mid-fidelity prototype means risking that people do not understand the purpose and think the next product will look like this (i).

We also created a survey, that shows up when the prototype gets closed. (This requires Java 6 installed, because the system's web browser is called). The survey has more questions now since last Friday. New Prototype, new survey. ;-) The results of the survey are different from the negative comments on GullFoss. We think because those users who fill out the survey give the prototype a test drive at least for a moment. But who reads our blogs and tries the prototype? The average OOo user? No! So only real live testing can show us if a new UI is suiteable.

Developing a user interface (UI) for office sorftware is not an easy job, because this software is used by unique users with all skill levels and a huge range of tasks. Nobody wants to be a beginner, at least not for long :-) , so we have to focus on intermediate users while not distracting expert users.

When you analyse office documents, you see that most users only use a very basic set of features out of what OOo offers. So it seems that we are already done, because OOo could do so much more. Really? But why do those office documents look so basic even if they are made by experienced users? We only know a few people who are good in techniques and design at the same level. So users should concentrate on what they are the experts in: the document content, and not have to design/define/layout each and everything inside their document on their own.

Most expert users stated that they already know where to find the fucntionality (h) and that no new UI is needed, so that only beginners (g) would take any advantage of a new UI. We want to provide rich formated document pieces like tables, header, footer, indexes, etc. in galleries, so that the user can easily choose from professionally designed ones. This allows all users to create powerful and beautiful documents.We need some kind of new UI to offer those galleries.

This new UI needs a home. So the question was where to place it. The reading direction in western countries is from top left to bottom right and users are used to finding the interface on top of the document area. Furthermore the height available for a bar on, e.g. the left side, is too low for the amount of functions, especially on small displays like netbooks. Also we did not want to spread the functionality all around the application. So the team decided to go with a horizontal on top even if monitors are getting wider (b) these days. Most users use the software as it is out of the box, so we have to focus on a good default. But  there is nothting to say that the user can't configure it to fit their specific screen or work needs. It is a clear requirement that the new UI must support a minimized visualisation (fold open or change to float) and it should support a vertical visualization in a second step. Configuration possibilities could be added in future versions.

Our prototype did not kill the menus (d). They are still there! Even the new prototype, which is in the making, will keep at least the same structure (File, Edit, View, Insert, Format...) users are used to these days, but it will provide new graphical possibilites where we need it to provide rich formatted document pieces. The next prototype will also implement a context-sensitive interface approach.

We do not want to copy the ribbon (c) interface. But what makes the 'ribbon'? The tabbed interface? No. On top navigation? No. Rich formated document pieces in galleries? Maybe, but templates are not new and other products did provide those possibilities earlier. Do we have to keep the classical interface as a second interface? This would mean that it has to be maintained as well as the new one. So maybe it is a good idea to offer this as an OOo extension, if really required by users (f).

We hope that we provided some answers to comments/questions posted on the previous post on Project Renaissance.

Please stay tuned for the new prototype being released by end of next week!

Best regards,

The Renaissance Team

tags: impress renaissance user-experience

The project Renaissance prototyping phase will end this week,  on July 24.

There have been many prototypes along the way and now they are looking much more mature and promising. So much so, that the UX team decided it was time to test them on real users outside the OOo UX project. Innocent users caught unawares as it were, with no clue as to what was in store for them. :-)

Some of the UX team members visited a company in Hamburg (has to be a secret for confidentiality and other legal mumbo jumbo), to test the new UI design prototype. The 'Floating Toolbar' prototype got very positive feedback. Scrolling and tabbed toolbar prototypes just cannot keep up with this design. The new live sorter view with full editing and object moving capabilities (also from one slide to another) is a real 'wow' feature, too. The users at the customer company were so enthusiastic about how it would simplify their work that they asked how soon it could be implemented. They were glad to see that the old menus remained intact so they could use their prior knowledge of OOo, while still enjoying the new toolbar simplicity. You know, just getting used to the newness without the scariness of being forced to use it because all you have ever known is now gone.

For daily updates of the prototype, see: http://wiki.services.openoffice.org/wiki/Renaissance/Prototyping
(Java 6 required)

So, if you're the curious type...go on! Check out the prototype today.

Best wishes from the Renaissance Team

tags: impress user-experience

While Armin Le Grand did a great job at improving the load/save Performance for presentation documents by tweaking the application core itself, I took a step back and thought about performance improvement by using different technologies. The first step was to look at other techniques to deal with xml documents that would have one or more advantages over the current implementation. Since according to Helmuth von Moltke "No battle plan survives contact with the enemy" I had to test my assumptions and so my theoretical work on this resulted in a  prototype import filter implementation for impress. This is a short  summary of what techniques I looked at, why and how I used them in the prototype and the interesting results I got from it.

Mission Statement

The mission of this prototype was to gather data how the utilization of new technology could enhance the performance of the native OpenDocument Format (ODF) filters for OpenOffice.org (OOo). The focus of this prototype was to first look at the import of impress documents and achieve the following three goals

Goal 1 : improve overall filter performance

Goal 2 : make use of multiple cores/cpu through threading (where threading is not blocked constantly by calls to the OOo core which is currently not supporting multiple threads without blocking)

Goal 3 : support the implementation of load on demand (for example to display the first slides to the user and load the rest of the document in the background)

Current state

Currently ODF is imported with a SAX based filter that is accessed over the UNO API. Therefore the current SAX parser pushes notifications about the xml elements to the current ODF filter implementation in the order they appear in the xml stream. The filter itself has no control on choosing which elements to parse first or to postpone the parsing of the current element for a later time. It makes it also nearly impossible to measure the time spend for the current xml parsing because this tight coupling between the SAX parser and the ODF filter.

XML streams from ODF documents are usually encoded as UTF-8. The UNO API uses strings in UTF-16 encoding. Therefore, the SAX parser converts all strings from the xml stream to UTF-16 which is used by the UNO string implementation. To identify xml element and attribute names, expensive string compares are conducted.

Between the ODF filter and the current OOo application core is another UNO API layer. The filter has to convert the xml events to something  that can be send over this layer to the OOo application core. In most cases the implementation of the API layer must also convert the given data to the format used in the applications core.

the detailed flow of data is currently as follows

1. SAX parser reads xml data of utf-8 streams inside zip storages
2. SAX parser UNO implementation handles namespaces and converts element names, attribute names, attribute values and text content to utf-16 strings and feeds the ODF filter implementation
3. ODF filter implementation transforms utf-16 xml data to UNO representations for the OOo UNO API
4. The applications UNO API implementation transforms the UNO data to a core data representation

Assumptions

• While it is unknown how much the xml parsing accounts to the overall time to load a document, most developers agree that the conversions of all strings from utf-8 to utf-16 should be a significant and useless overhead.
• String comparison should be reduced to a minimum.
• Making the applications core multi threaded would require a major rewrite so its not a short term solution. To make use of multiple cores/cpu the filter itself has to delegate work that does not need access to the applications core.
• Implementing load on demand would require some kind of random access to the xml elements in the content and styles streams.

Alternative technology

XML Pull Parser (XPP)

XPP is a streaming pull XML parser. Unlike sax where the sax parser calls the filter, the filter itself makes calls to the XPP parser to parse the next xml element.

+ In contrast to sax, the filter can interrupt sax parsing after any element and continue parsing later.
+ Pull instead of Push leads to a cleaner filter implementation (cleaner code is usually easier to service and improve).

- Performance is equal to a sax parser
- No random access

Document Object Model (DOM)

A DOM is a parsed memory representation of a xml stream. This technology is used by modern browsers and the odftoolkit.org project.

+ Filter has random access to all xml elements
+ Random access leads to a filter implementation (cleaner code is usualy easier to service and improve).

- A DOM has to store a complete copy of the xml stream + management in memory during the filter process.

Fast sax parser

I developed the fast sax parser during the initial implementation of the Office 12 XML filters. It is basically a sax parser but uses integer tokens to represent known namespaces, element names and attribute names. Tools like the gnu gperf can be used to create perfect hash code to transform the xml names to integer tokens. Scripts can parse the dtd or relax ng of an xml format to automatically extract all the xml names that needs to be convertable to integers. With utf-8 xml streams, the tokens can be created without the need to transform the strings to another encoding first. Namespaces can be combined with xml names so each element or attribute name with a namespace can be identified with just one integer compare.

+ Reduces string handling (encoding, comparing, storing)
+ Leads to cleaner filter implementation (f.e. switch statements can be used to identify child elements instead of if .. else .. blocks which use the string compare functions)
+ Usage of perfect hash algorithms which are automatically created during compile time

- No random access

The Prototype

Since random access looks like the key to have a filter that supports painless load on demand, I decided to go with a DOM solutions. To minimize the memory footprint of the DOM tree, I used the fast sax parser to build the DOM tree and use the integer tokens for xml names instead of the strings from the stream. Now parsing the xml  stream itself does not need any interaction with the application core so this could be done in a separate thread. Converting the xml representation of attribute values to an UNO  representation is also something that could be done in almost all cases without the application core, so this should be done in the same thread.

The problem here is that a classic DOM is a generic and typeless representation of the xml data. The solution here is to use a technique we introduced in the odftoolkit.org project. Initially a xslt transformation was used to create dom node implementations for each element of the ODF format with type safe access to its attributes using
only the relax ng. Upkeeping xslt templates proved costly for such complex operations. So this was replaced with a code generator that I implemented in java which uses simple templates and configuration files to transform a relax ng schema to code files.

This code generator also allowed to create DOM tree element implementations for other languages than java which is used in the  odftoolkit.org project. Therefore I used the generator to create c++ source files for all ODF elements and I adapted the configuration files to create types for the attributes that are equal to the UNO types that the filter needs to pass to the application core. (The key difference between the ODFDOM from odftoolkit.org and the DOM tree for the prototype is that the former uses ODF based types for the attributes and the later uses UNO types).

So in conclusion, a DOM tree builder is started in a worker thread and parses the xml stream by using the fast sax parser (The prototype actually starts two worker threads, one to build the tree for the styles.xml stream and one for the content.xml stream). It uses the sax events to create a tree where each element is the instance of a class that was specifically generated for that element from the relax ng schema. All attribute values are parsed and stored into an UNO Any with preferable the same type as used in the UNO API of the OOo application. So for example if the attribute is a length value then something like "12cm" is converted into an UNO Any containing an integer value of 1200 (12cm converted to 1/100th mm).

This worker threads would never block or wait for the OOo thread. But this would not make sense if at the same time the office thread idles and waits for the tree builder to finish. So the tree builder notifies the filter as soon as an imported element has been fully parsed. For example if the office:styles element is completely parsed the filter thread can start and import the styles. If the filter gets notified that a slide has been completely parsed, it can check if the needed styles and master pages are already imported and then import this slide. If the filter is also executed in a separate thread, the office thread can paint the already imported slides to enhance the responsiveness of the application to the user which results in a 'subjective' performance gain

To implement the filter I borrowed code from the existing ODF filter and transformed it to use the DOM tree instead of sax events. This mostly resulted in much less and cleaner code, as expected. For a reliable comparison with the existing filter I had to implement a minimum set of functionality so that for selected real world documents the prototype imports all the functionality available in that document.

I ended up implementing

• Import of graphic and presentation styles (with the exception of  rarely used attributes like 3d or form attributes)
• Import of numbering styles, page layouts and presentation layouts
• Import of draw styles like gradients, bitmaps, hatches and markers
• Import of master pages including their notes
• Import of automatic styles for shapes, paragraphs and spans
• Import of draw pages including their notes
• Import of common shapes (placeholder, text, rectangle, graphic and ole)
  

Results

First I used an average real world document with 47 slides and lots of graphics and some chart ole. It showed that the prototype filter was around 2% faster than the original filter. This was less than expected.

Next I created an artificial document. A presentation with 188 slides and only formated text, no graphics, no ole. This pure xml document would be uncommon for a presentation but a good approximation what the gain could be for a writer or calc document where the xml to graphic/ole ratio is much higher. This lead to a performance gain of 10% which is not bad since the prototype is not yet profiled and optimized itself.

I tested this on a dual core 3Ghz system. Experiments with the original filter showed that we are cpu bound and since we use only one core, the processor usage is only 50%. So I expected better results with the threaded prototype by making use of the 3Ghz from the second core. A quick look at a cpu monitor showed that this didn't happen, processor usage was still capped at 50%.

This made me suspect that the actual parsing, tree building and xml to UNO conversion did only account for an insignificant amount of the time the filter needs to import this document. After removing the threading I measured the time it took to parse the xml streams and to actually import the document. It turns out that building the DOM tree for the styles.xml and content.xml accounted for less than 2% of the overal time. So when opening a document that takes 10 seconds to load, the second core is only used 0,2 seconds. Remember that this does not only include the actual xml parsing but also creating the DOM tree in memory and converting most of the attribute values to UNO types.

The interesting finding here is that the overhead from the xml parsing is much less than the typical 'developer gut feeling' about xml. So any performance work in the filter or the application core  would be much more efficient then trying to speed up the xml parsing.

Since the usage of DOM is often criticized for its memory consumption, I also took a look at this. While I replaced most strings with 32 bit integer tokens I figured that the memory consumption of a DOM tree should not be greater than the xml stream it was parsed from. My expectation was that for most cases it should be even smaller.

The first measuring showed that it was actually 10 times more than its xml stream. After further investigation I found the source of the problem which is the overhead for each allocated instance from the memory manager.After converting attributes from individual instances to a single vector this dropped to 2x the size of the xml stream. For an impress document this is not a problem as the xml stream size for average documents is seldom more then 1 MB. For a writer document this may also be no problem as for example the huge OpenDocument specification has less than 10MB of xml streams. For calc this may be a problem as calc document with many cells can have xml streams of 100MB and more. For current office  workstations this may not be a problem at all, but if OOo runs on a server for multiple users or if OOo would be ported to small devices then this could become an issue.

Conclusion

While the prototype showed that this method of implementing an ODF import filter does result in a performance gain and the option to support load on demand, for an impress application the performance gain of only around 2% for real world documents is out weighted by the actual cost to implement this filter. I currently estimate an effort to at least 6 man month for implementation of only the impress import filter (this is without time for testing which is also crucial to find regressions). For a calc and writer filter these figures may differ.

Since writer and calc are more xml centric then impress documents, a prototype for these applications may show that the overall gain still does out weight the costs.

tags: api import impress odf openoffice.org performance uno xml

tags: impress renaissance user-experience

Project Renaissance is in full swing. 

As of this very minute, the call for UI design proposals wiki page has been accessed 70,332  times. The count goes up every second! Until the morning of May 11th, the day of the proposal submission deadline, there were only a couple thousand hits on this page. What a difference!

If you haven't already, you might want to leave a comment or question for one or more of the proposal writers. There are 16 proposals to inspect and question.

All members of the OOo community can write in the respective wiki pages (see space for comments at the bottom). You have until May 25 to do so, preferably sooner so the authors answer your questions by May 25, too. That is the deadline for the revision phase.

BTW: A very big THANK YOU to all the proposal writers for your hard work. There are truly impressive designs there.

Liz

p.s. Now the page has been accessed 70,342 times. I'd better post this message quick or it'll be out of date ;-)

tags: impress renaissance user-experience

The Project Renaissance UI design proposals have been submitted and are awaiting your comments and questions. There are 15 proposals now, some very detailed, some less detailed, but all show a tremendous amount of intellectual energy around Project Renaissance.

You have to be a member of the OOo community to write your questions to the authors in the respective wiki pages. In this phase (till May 25), the idea is to get additional clarification from the authors for things in the proposals that might not be described enough or clearly.

All proposals can be commented on or questions asked until May 25th. By then, the authors also have to revise their proposals based on questions and comments from the readers, so that the final results on May 25th are unambiguous, clearly defined proposals that then enter the next stage of evaluation and move one step closer to the prototyping stage.

I think it is so mega-fantastic that Project Renaissance's search for a new and improved UI concept for OOo can generate amazingly high interest: the wiki page linked above was accessed nearly 40,000 times since the proposal deadline arrived---after a member of our UX community got excited about the proposals on slashdot. Hey---we love that publicity! Our wiki was however unprepared for this surprise and capitulated. Our apologies to those of you who got stuck with an error message. It should be more able to handle the load today. So go ahead and take a look.

Thanks for your support!

The Project Renaissance Team

tags: impress renaissance user-experience

Recently I blogged about the call for proposals for design ideas. Well, now Project Renaissance can report that six people have begun writing proposals for improving how functionality is accessed in Impress.

Did you realize how seriously important these proposals may be?

If a proposed new concept works for Impress (that means that it stands up to the tests and usability evaluations in the prototyping phase of Project Renaissance) then that concept will be adopted for ALL of the office suite!

That means that if you want to do something big for OOo, then you need to get into the proposal mood now. Suggest a new way for menus and Co. to work; enhance use of shortcut keys; eliminate all text and only use icons; make the whole office suite have bunnies, etc.

Whatever your idea, make a proposal for Impress and maybe you'll change the way millions of people accomplish their tasks in future versions of OOo.

Liz

p.s. You don't have to be a designer or professional of any kind. Just have a good idea and let everyone know about it. 

tags: impress renaissance user-experience

Get Busy! Get Creative!

It's finally here...the official begin of the prototyping phase of the Renaissance project. The call for design ideas in the form of proposals has been posted on the wiki. Please hurry and check it out. There are instructions and a schedule: deadline for submissions is May 4th!

Here is an excerpt from the wiki page (see wiki for full details):

Procedure

In order to participate in submitting a design proposal, please follow these steps:

1. Use the template for creating a design proposal and work out your design (see Design Proposal Template).
2. Send a short email to ui@ux.openoffice.org to announce that you have started working. This is so that everyone knows how many people are working on proposals and how they can be contacted.
3. Work while keeping your proposal contents secret until the date for publishing the design proposals (see Schedule).
4. Publish your proposal on the wiki and announce it with a link on ui@ux.openoffice.org (see Design Proposals Submitted and Design Proposal Wiki Template)

If you have any questions or comments at any time, please send a mail to the ui@ux.openoffice.org mailing list.

If you have great ideas, you won't want to miss this chance to be involved. Even if you aren't interested in designing a new user experience for accessing functionality, then pass this announcement on to your friends who might be.

Start working as an individual or as a team today and maybe your idea will be one that gets implemented in OpenOffice.org Impress! 

tags: impress renaissance user-experience

A short overview about Anti-Aliasing in OOo 3.1 and related features. It demonstrates the obvious, but also sheds some light on related things which may be not so self-evident on the first thought.
[Read More]

tags: 2d 3d chart draw drawinglayer graphics impress openoffice.org