As indicated in the previous posts, we have started to redesign a few really basic interactions in OpenOffice.org Impress in order to reduce the overall complexity of the UI. Currently, we focus on navigation through slides in various contexts, the visual appearance of different slide selection states and the handling of slide layouts. Today, I want to share some thoughts about a different way how to assign slide layouts.

The Challenge.

At present, OpenOffice.org Impress offers five ways how to change the layout of an existing slide. However, four of those merely trigger or point to the task pane. Consequently, there is only one “real” way how a user can pick and apply a slide layout, and there is no way doing that without the task pane. Thinking about a common scenario of creating a presentation, adding new slides, modifying existing ones, adjusting their layouts, one can imagine that switching the task pane on and off over and over again is an unwanted interruption. Keeping the task pane permanently alive is of course an option. Yet, if you want to concentrate more on the content of your work instead on the tools at hand, you’d rather prefer to disable the task pane since it consumes quite a lot of screen real estate.

Von OOo UI - Ideas and Mock-Ups

In addition, there is no way to insert a slide with a favored layout in only one step. Currently, the default work flow requires a user to insert a slide first, decide if the layout meets the expectations and then assign the preferred layout if expectations are not met. From our point of view, there should be a more elegant solution to that, too.

Another drawback of the current implementation of slide layouts is that their sheer number exceeds a practical amount that covers most use cases without getting too difficult to work with. Including the vertical layouts OpenOffice.org Impress 3.2 Beta offers 27 slide layouts. That is challenging for two particular reasons. The 27 slide layouts have to go somewhere in the UI, namely into the task pane, where they consume a lot of space. Since they are so many, it is often necessary to scroll through the task pane in order to get an overview what is available and during search. Picking one is also not always easy because in a worst case a user has to look through 27 options and then decide which one to pick. That takes time.

Possible Solutions.

Since OpenOffice.org Impress already has a dedicated “Presentation” toolbar that contains an “Insert Slide” and a “Slide Layout” button, the Renaissance i-Team started working on a solution that offers a technique to change slide layouts without the necessity to constantly use the task pane. Motivated by the visual concepts in our prototypes, we will try to add a preview pane into the toolbar such that users can directly pick a layout from a drop down toolbox, in the context of the task (insert slide, change slide layout). In parallel, we have decided to add more value to that particular “Presentation” toolbar by reducing its functionality to support the most important tasks only (insert slide, change slide layout, change slide design, set slide transition, start presentation).

Von OOo UI - Ideas and Mock-Ups

We have also considered options to handle slide layouts from various mouse context menus. However, this seems to be very challenging from an implementation point of view. Although we already have some design mock-ups, we need to explore the feasibility of that solution first on all platforms. So for now, the development team is investigating our options.

Von OOo UI - Ideas and Mock-Ups

One way to reduce the amount of slide layouts is to offer object placeholders in each layout that can be used to insert images, charts, tables and the like where usually text content would appear. That would make the need to create slide layouts with tables, images or charts separately obsolete.

Overall, these changes may seem small or less significant compared to other troubles such as the inability to create own slide layouts. However, having the goal of thinning out the current UI in mind, these redesigns and the sum of all forthcoming incremental improvements of the work flow will eventually keep us on the right track. For details about the ongoing work check out the Renaissance i-Team Wiki.

Best,

Andreas

tags: renaissance user-experience

Developer Snapshot build OOo-Dev DEV300_m67 is available for download.

DEV300 is the development codeline for the upcoming OOo 3.x releases.

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following download page:
http://download.openoffice.org/next

Release Notes:
http://development.openoffice.org/releases/DEV300_m67_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/DEV300_m67_md5sums.txt

tags: openoffice.org qa release snapshot

For performance and maintainability reasons, the configuration component of OpenOffice.org has recently been re-written from scratch, see the corresponding Wiki page. (The “configuration” or “registry” of OOo is where many of the per-user settings and corresponding system-wide defaults are stored, like for example settings you change via the “Tools - Options...” dialog and the “File - Recent Documents” list.) The re-write is currently inspected by the OOo QA department, and it will likely make it into the OOo 3.3 release.

The one change that people will probably notice is that the plethora of configuration files (with file extensions .xcs and .xcu) scattered across the OOo installation tree has been reduced, to just a handful of files (with new file extension .xcd). While the content and XML format of the original data files has not changed (much), the new files simply concatenate together multiple old files (mostly to reduce disk access costs during cold start). This means that if you used to fiddle with OOo’s private parts by directly modifying some .xcu file in the installation, that hack will need adoption (probably best by turning it into an OOo extension, see next). OOo extensions (i.e., .oxt files) continue to include configuration data in .xcs and .xcu files, nothing has changed there. Similarly, the per-user configuration changes in an existing OOo installation are migrated to the new format on first start.

If you would like to give this a try well before it hits the OOo 3.3 master, I made available a number of builds at ftp://qa-upload.services.openoffice.org/sb111/:

• Sub-directory 11ab4c658928 (corresponding to the Mercurial source revision of the same ID) contains OOo installation sets for x86 Linux and Windows, in US English and German.
  
• Similar to the regular OOo Dev snapshots, those installation sets are .tgz resp. .zip tarballs that can be installed in an arbitrary location (alongside an existing OOo installation; but see next item).
  
• However, unlike Dev snapshots, these installations by default re-use an existing OOo user installation from a previously installed OOo 3 (at ~/.openoffice.org/3 on Linux and at something like C:\Program Files\Application Data\OpenOffice.org\3 on Windows)—so that the user data migration is actually field-tested. ;) So, you should probably backup your existing OOo user installation before giving this a try.
• If you rather want these installations to have user installations of their own (like the regular OOo Dev snapshots), you need to edit openoffice.org3/program/bootstraprc (Linux) resp. OpenOffice.org 3\program\bootstrap.ini (Windows), changing the “UserInstallation” line to something like “UserInstallation=$ORIGIN/USER”.
  

tags:

The thinning out process for Impress 3.3 is in full progress. Please find the Project Renaissance status presentation for November/December at the OOo Wiki. The presentation provides first mock-ups of  the planned changes.

Feedback welcome.

Best regards,

tags: renaissance user-experience

• Our current build system is handling parallelization in a very cumbersome way: Both build.pl and dmake can do parallelization, but they do not know of each other, and thus a build -P4 -- -P4 might happily run 16 processes in parallel.
• Our current build system does not support full dependencies and especially not full dependencies across module borders. This can be really confusing for new developers, but even seasoned developers are bitten by doing "compatible builds" where they should not.
• All modern SCM -- and that includes Mercurial, which we are using now -- support bisectional bug-hunting. However, this is not much fun if one has to do a complete rebuild on each step. Full dependencies would allow to step forward or backwards through history doing rebuilds only of stuff that really changed. Also, the necessity to do a complete rebuild after a resync will be gone, when we have reliable full dependencies.
  
• The current build system has grown historically and documentation is spare. As a result, lots of makefiles contain amounts of cargo-cult-programming. For example there are still many makefiles that use the CXXFILES variable although that variable is unused.
• Our current source tree is not read-only. It is a lot easier for build tools and SCMs to have everything which is generated from the source outside the source tree itself.
• Our current build system starts a lot of processes: There is one makefile per directory and one dmake-process per directory, resulting in more than 2000 make processes created per build. While this is not too much of an issues on Unix-based operating systems, on Windows process creation is slow. A replacement should be able to build OOo in one process (of cause, smaller build units will be still possible: e.g. building only one library/one module or for split builds).
  

• GNU make
• a POSIX-shell (to be specific: a bash-shell in POSIX-mode, other implementations might work, but are not intended to be officially supported)

• build.pl (thereby removing one dependency on Perl, which is pretty huge)
• dmake
• mkdepend
• rscdepend

• is using only GNU make and POSIX sh (no Perl, dmake, build.pl).
• is designed to be able to build OOo with a single make process.
• calculates complete dependencies (also across module borders).
• unifies the parallelization issues.
• uses a small and easy to use domain-specific language or API to describe the work to be done in the module. See for example: The declaration on how to build a library in the writer module. The API is using object-oriented concepts, which should make it easier to understand for developers without having to fiddle deep in the internals of the build system themselves. We are even planning to use a documentation system like doxygen to generate the documentation for the build system.
  

• Generating dependencies for C/C++ and resource files
• Compiling C/C++, resource and sdi files
• Linking shared libraries and linking executables (including creating automatic dependencies on linked-against libraries and header files)
  

• Do you think we are right in investing in modernizing the build system in this way?
• Have we missed a requirement or priority, that a revamped build system should support? (Maybe we are supporting the requirement, but just did not name it here. Feel free to ask!)
• Do you have other ideas, additions? Would you support the effort?

Since this a rather broad topic, I also would like to invite you to discuss a possible move to GNU make and its implications on the mailing list dev@tools.openoffice.org.

Best Regards,

Bjoern Michaelsen

tags: build gullfoss linux make openoffice.org parallelization scalability

Developer Snapshot build OOo-Dev OOO320_m7 which installs as OOo-DEV 3.2.0 has been uploaded.

The previously report issue is now fixed in this milestone: i107239 (Java GUI installer doesn't work).

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following link:
http://download.openoffice.org/next

Release Notes:
http://development.openoffice.org/releases/OOO320_m7_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/OOO320_m7_md5sums.txt

tags: openoffice.org qa release snapshot

I know some of you read the title and thought “Oh cool! I'm dying for a new user interface (UI). When will it finally be ready?” At the same time, some of you thought “Nooooooo! I like the UI already, even if there are a few little things here and there that annoy me. I wish they would stop this talk of a new UI.”

Before you read the more important stuff below this, let's just take a quick look at three basic questions.

1) Is there going to be a new UI for OpenOffice.org?
Yes. Improvements in interaction design (usability) will result in changes for the user interface. Good interaction design considers how fast you can do tasks which occur quite frequently and how easy you can figure out things you've never done before. BTW, "New UI" isn't a very exact term. We could just as easily say "revised UI" or "updated UI".

2) When will it be done?
Slowly but surely; over a long time; bit by bit. We will only change things if there is a good reason. And gathering and analyzing data (the "reason") takes time, as does designing improvements.

3) What is the goal of Project Renaissance?
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.

That said, the following is an elaboration on those three points and an attempt to clarify any incorrect interpretations of Project Renaissance.

There is a great deal to do within the scope of Project Renaissance, and since the OOo community regularly comes out with a new version of the OpenOffice.org office suite, each version is an opportunity to improve the interaction design. Slowly but surely. This usually involves UI changes, but sometimes may only result in performance or other intangible changes not visible on the UI. A motto for Project Renaissance is "form follows function".

In keeping with the goal of providing efficient access to valuable functionality, experience thus far has lead us to focus first on solving some fundamental problems so we can build on those solutions in later stages of Project Renaissance. One of the fundamental problems now in focus is reducing the complexity of the very large number of graphic elements on the UI. This is a big problem and so it will take time and many steps to work on it. Improvements will be noticeable here and there as we go.

We've always said that Renaissance is a long-term project. Unfortunately, many people got the wrong impression from the really real-looking prototypes (probably because our developers are really good at coding). Fortunately or unfortunately, depending on your preference, those prototypes were exploratory---just ideas we were trying out, not the real solutions. What they, and the design idea collection before them, did, was supply us with a lot of feedback that is invaluable in the continued unfolding of the Renaissance work. "Unfolding" describes not only the work but also what happens whenever we start to work on an improvement.

For an excellent explanation, I would like to quote UX Architect, Matthias Müller-Prove:

"Most, if not all UI problems get larger during the time you are working on them. To a certain extent this is natural because you get more deeply involved and gain a better understanding of the issue. You discuss the topic with colleagues and incorporate their point of view into the design. You discover new aspects that somehow match your topic. [...] The challenge is to keep the chunks of UI problems you address manageable. At the same time you have to keep an eye on the overall structure of the product."

If you have a minute, you really should read the entire text on The White Water Lily Effect.

So, fully aware of the challenge to keep the UI problems we address manageable, our current focus is the task-oriented optimization of interaction in Impress, due to be out in version OOo 3.3. More unfolding of Project Renaissance will continue, bit by bit, step by step. This is one of the first bits to reach the implementation stage.

To get a better idea of what "task-oriented optimization of interaction in Impress" means, to see which issues are in this "manageable chunk" so far, and to follow how the work is progressing, see the new pages in the OOo Renaissance wiki.

Best regards,
The Renaissance Team

tags: impress renaissance user-experience

Developer Snapshot build OOo-Dev DEV300_m66 which still installs as OOo-DEV 3.2 (see i107355) is available for download.

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following link:
http://download.openoffice.org/next

Release Notes:
http://development.openoffice.org/releases/DEV300_m66_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/DEV300_m66_md5sums.txt

tags: openoffice.org qa release snapshot

Developer Snapshot build OOo-Dev OOO320_m6 which installs as OOo-DEV 3.2.0 has been uploaded.

ATTENTION:
Due to P1 issue http://qa.openoffice.org/issues/show_bug.cgi?id=107239 the Java based installer will not work on all platforms where it is used. This issue will be fixed within the next milestone OOO320_m7.

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following link:
http://download.openoffice.org/next

Release Notes:
http://development.openoffice.org/releases/OOO320_m6_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/OOO320_m6_md5sums.txt

tags: openoffice.org qa release snapshot

As Christoph Noack opened a time capsule, let me do the same. Mine goes back 2 months to Sept 17/18/19 when specially invited members of the German-language OpenOffice.org community came to Hamburg. The visitors pictured above, plus me and Marcus Lange from Sun who joined the photo, were (l to r): Marcus Lange, Florian Effenberger, Daniel Stoni, Christian Lohmaier, Elizabeth Matthis (aka Liz), Thomas Hackert Uwe Altmann (not pictured: Gerald Geib, Volker Merschmann)

It was so wonderful to meet face to face people otherwise only known from email and to be able to thank them for their dedication and support. They each traveled here at their own cost (from far corners of Germany and even from Switzerland), which further shows their enthusiasm and dedication to our thriving open source product. On Thursday evening, those who were already in Hamburg met at a pub (Max&Consorten) for a first get-together. Afterward, most of us concluded the evening with a round of beers and more talk at my home---which I jokingly called "Motel Matthis".

Friday started out with a heartfelt word of welcome and thanks from Michael Bemmer, Senior Director of StarOffice/OpenOffice.org Engineering, and unfolded with a series of talks and snacks, including lunch and several smaller group meetings about special topics, until concluding at approximately 5:30 PM.

There were entertaining and informative talks by Stefan Taxhet on OOo in general, Gerd Weiss on infrastructure---including a personal tour of the server rooms to underline some of his points about the hardware, Andreas Bartel on Renaissance and Uwe Fischer on documentation, as well as tours of the engineering facility and opportunities to say hello to many of the OOo developers in real life.

At the end of the very busy but fun day, those of us who still had time went out to eat together at an Italian restaurant (maybe this was to get in the mood for the OOoCon in Italy!) and, several courageous visitors even spent a second night at Motel Matthis! This time Uwe made sure we had enough beer to let us talk long into the night. Thanks, Uwe!

Some comments I received after the visit are:

thackert: "It was interesting to become acquainted with some people I'd only known the mail address or nick of, and to hear really interesting talks as well to "sightsee" SUN. All in all a nice trip and - the best of all - a really nice stay at "Motel Matthis" with a perfect hostess (Liz!)"

floeff: "Thank you very much to everyone who made this visit in Hamburg possible! I'd never been at Sun Hamburg before, and it was a really nice day meeting old and new friends, getting insight on how the OpenOffice.org development works, and after all, we also had a lot of fun and a real great time. Liz is a wonderful hostess and we all enjoyed some very special days in a community that more and more becomes a real family."

VolkerMe: "Thank you again for such a nice day, which was very much too short for me. The opportunity to have personal talks with the engineers at SUN was so interesting, I wasn't able to discuss everything, so I hope I can come back another time. And although it has been said so often: Thanks Liz for hosting the meeting, for the well-prepared accommodation and for being our always smiling guide!

Saturday came too quickly and I had to say goodbye to my delightful guests. I hope to organize another visit to thank additional and like-wise dedicated community members in 2010.

Kind regards,
Liz

tags: community user-experience