Some of you have asked me previously whether or not we can share any test documents to demonstrate Calc’s new OpenCL-based formula engine. Thanks to AMD, we can now make available 3 test documents that showcase the performance of the new engine, and how it compares to Calc’s existing engine as well as Excel’s.

Download	Platform
OpenCL-test-documents-Excel-64-bit.zip	Excel (64-bit)
OpenCL-test-documents.zip	Calc (Windows, 32-bit) Calc (Linux, 32-bit) Calc (Linux, 64-bit) Excel (32-bit)

These files are intentionally in Excel format so that they can be used both in Calc and Excel. They also contain VBA script to automate the execution of formula cell recalculation and measure the recalculation time with a single button click.

All you have to do is to open one of these files, click “Recalculate” and wait for it to finish. It should give you the number that represents the duration of the recalculation in milliseconds.

Note that the 64-bit version of Excel requires different VBA syntax for calling native function in DLL, which is why we have a separate set of documents just for that version. You should not use these documents unless you want to test them specifically in the 64-bit version of Excel. Use the other one for all the rest.

On Linux, you need to use a reasonably recent build from the master branch in order for the VBA macro to be able to call the native DLL function. If you decide to run them on Linux, make sure your build is recent enough to contain this commit.

Once again, huge thanks to AMD for allowing us to share these documents with everyone!

Let me start with the second part of the head line of this article. Munich is a success. And not a little one too.

Already during the 9 year long migration to LiMux (looking for a reason why Microsoft can't count 9 ;) ) the saved money counts to 11 Mln Euro.

From the money spent to consultancy, nearly 50% has benefited (regional) SMB.

The user satisfaction has clearly increased - though there are still items in which improving is possible.

More then 14.000 of the 15.000 systems have been migrated. A larger number then was set as target.

De savings on licenses will count, year after year, millions.

(Also see Symposium LibrOffice in de Praktijk)

Now is this news? Not really. But it is something we cannot repeat enough - brief and clear.
There only needs to be one Microsoft-partner driven 'investigation' (see.. and this..) or one new major who recently has been doing business with Microsoft (see..) and there are new headlines seeding wrong impressions. FUD. Let's just mention all it is.

Then now the news :) One would of course say: such a huge success, where are all the others? Well, those are here (see..) but less visible. Munich simply is a real huge project that goes beyond just implementing LibreOffice.
But this October there will be an IT-top gathering from the German government in Hamburg and one open IT-Top gathering from Open Source Business Alliance and the party the Greens. "The use of open source in science and administration isn't just handy, but also offers an ocean of opportunities for innovation and security." "Hamburg and Germany must gain independence from the IT giants".
So it is. And it can be done!

I’m borrowing the post title that Tomaž and Andrzej used before to talk about the work that I have lately been doing at Igalia regarding LibreOffice on Android.

You might know there are several projects living under android/experimental in our code tree; it is exciting to see that a new experiment for a document viewer that uses a fresh approach recently arrived to the party, which can be the basis for an Android editor. I was happy to add support to receive view or edit intents to the shiny new viewer, so we could open any document from other Android applications like file browsers.

Besides, android/experimental hid some very interesting work on an Android-centric document browser that could be a good starting point to implement a native Android wrapping UI to LibreOffice, although it had some problems that made it unsuable. In particular, thumbnail generation was making the application crash – for that reason I’ve disabled it until we get a proper fix – and the code to open a document was broken. Fixing and working around these issues were the first steps to bring the document browser back to life.

I noticed that the browser was inconveniently dependent of the ActionBarSherlock library, which is not really necessary now we are targetting modern Android versions with out-of-the-box action bar support. I replaced Sherlock ActionBars with Android native ones, and that allowed to remove all the files from ABS library from our source tree.

I also took the freedom to reorganize the application resources (design definitions, bitmaps and so), removing duplicated ones. It was the preparation for the next task…

Finally, I merged the document browser project into the new viewer with this huge patch, so they can be built and installed together. I also did the modifications for the browser to open the documents using the new viewer, so they become one coherent, whole application.

Now both the viewer and the document browser can evolve together to become a true LibreOffice for Android, which I hope to see not too far away in the future.

pre.cjk { font-family: "Courier New",monospace; }p { margin-bottom: 0.25cm; line-height: 120%; }a:link { } One of many advantages of open source projects is for sure the eternal transition and evolutionary progress. This keeps people like my self busy just following the changes. Last week I was asked to help a large organization prepare their LibreOffice install package for Windows and

In a nice culmination of a month packed with family festivities and a gorgeous community event (our 2014 LibreOffice conference), today is the day that the LibreOffice project turns 4 years!

The project certainly has come of age since that special moment on September 28th, 2010, when after weeks of preparation (and an insane succession of all-nighters), LibreOffice entered the world. Run on a shoestring, off of a box thankfully sponsored by one of our initial supporters (but surviving slashdot), as of today the project has matured into an international community of thousands of contributors, hundreds of developers and a (small) number of employed staffers.

Highlighting just two of the rather (from a 2010 perspective) incredible achievements of the project – that the LibreOffice development team managed to clean up the inherited OpenOffice.org code base to a point that we’re leading the pack from a defect density point of view – and that as a first, substantial donated funds will be used to further a LibreOffice port into the mobile space.

I’m insanely proud of being part of this, and would like to express my sincerest gratitude to all of you who helped making the LibreOffice project such a fun ride & success – you know who you are!

Here’s to LibreOffice, here’s to our wonderful community. Happy Birthday! \o/

Graphic based on an original svg from Chris Noack

Filed under: LibreOffice, Personal Tagged: anniversary, libreoffice

 

Today is the fourth anniversary of The Document Foundation and LibreOffice. Thanks to all TDF Members – Abdulaziz Ayed Alayed, Abe Takeshi, Adam Fyne, Adolfo Jayme Barrientos, Adriano Afonso, Ahmed Abdulmajeed, Ahmad Al Harthi, Akshay Anand, Albert Thuswaldner, Alexander Werner, Alexandre Vicenzi, Alfredo Parisi, Amit Bakore, Andras Timar, Andrea Castellani, Andrea Mario Trentini, Andrea Pescetti, Andreas Mantke, Andrzej Hunt, Anton Meixome, Aputsiaq Niels Janussen, Arnaud Versini, Barend Jonker, Bisal Singh Nayal, Björn Michaelsen, Brennan Thomas Vincent, Caolán McNamara, Carlos Moreira, Cédric Bosdonnat, Charles-H. Schulz, Cheng-Chia Tseng, Christian Kühl, Christian Lohmaier, Christina Roßmanith, Christopher Brian Sherlock, Christopher M. Penalver, Cor Nouws, Daniel Armando Rodriguez, Danishka Navin, Darshan Gandhi, David Emmerich Jourdain, David Ostrovsky, David Tardon, Diego Maniacco, Dinesh Patil, Domingo Sacristán Valdezate, Donald Evan Rogers, Douglas Vigliazzi, Dushyant Bhalgami, Eike Rathke, Eilidh McAdam, Ejnar Zacho Rath, Eliane Domingos de Sousa, Ellen Pape, Elton Chung, Enio Gemmo, Faisal M. Al-Otaibi, Felix Xiaofei Zhang, Florian Effenberger, Florian Reisinger, François Tigeot, Fridrich Strba, Friedrich Strohmaier, Gabor Kelemen, Gabriele Ponzo, Gerald Geib, Giordano Alborghetti, Gustavo Pacheco, Harri Pitkänen, Heinz Simoneit, Helio Jose Santiago Ferreira, Henderson Matsuura Sanches, Irmhild Rogalla, Italo Vignoli, Jacobo Aragunde Pérez, Jacqueline Rahemipour, Jan Holešovský, Jean-Baptiste Faure, Jean Hollis Weber, Jean Spiteri, Jesper Laugesen, Jesús Corrius, Joan Montané, João Fernando Costa Júnior, João Mac-Cormick, Jochen Schiffers, Joel Madero, Joren De Cuyper, José Guilherme Vanz, Kálmán Szalai, Katarina Behrens, Kees Kriek, Khaled Hosny, Klaibson Natal Ribeiro Borges, Klaus-Jürgen Weghorn, Knut Olav Bøhmer, Kohei Yoshida, László Németh, Laurent Godard, Leif Lyngby Lodahl, Leo Moons, Lionel Elie Mamane, Lior Kaplan, Luca Daghino, Luc Castermans, Lucian Oprea, Mahendra Kumar Yadava, Manal Alhassoun, Marc-André Laverdière, Marcos Souza, Marc Paré, Marina Latini, Markus Mohrhard, Martin Bayer, Mateusz Zasuwik, Matteo Casalin, Matteo Cavalleri, Matteo Ruffoni, Matúš Kukan, Michael Bauer, Michael Meeks, Michael Schinagl, Michael Stahl, Michał Newiak, Miguel Ángel Ríos Vázquez, Mihovil Stanić, Miklos Vanja, Milos Sramek, Miroslav Mazel, Muthu Subramanian, Naruhiko Ogasawara, Nikhil Nandkumar Walvekar, Noel Power, Norbert Thiebaud, Olav Dahlum, Olivier Hallot, Omer Eyal, Osvaldo Gervasi, Pallavi Jadhav, Paolo Dongilli, Paolo Mauri, Paolo Pelloni, Paweł Konefał, Peter Mato, Peter Schofield, Peter Szakal, Philippe Emile Clement, Pierre-Eric Pelloux-Prayer, Pierre-Yves Samyn, Priyanka Gaikwad, Rajashri Bhat Udhoji, Ravindra Vidhate, Regina Henschel, Rene Engelhard, Ricardo Montania, Robert Einsle, Roberto Brenlla, Robinson Tryon, Rob Snelders, Robson da Costa Farias, Rodolfo Ribeiro Gomes, Rohit Deshmukh, Roopesh Kohad, Sanjib Narzary, Shinji Enoki, Sigrid Carrera, Simon Phipps, Sonia Montegiove, Sophie Gautier, Sourav Mahajan, Stanislav Horáček, Stefano Paggetti, Stephan Bergmann, Stephan van den Akker, Stuart Swales, Surbhi Tongia, Sushil Shinde, Sverrisson Sveinn í Felli, Tamás Zolnai, Thomas Hackert, Thomas Krumbein, Thorsten Behrens, Timothy Lungstrom, Tollef Fog Heen, Tomaž Vajngerl, Tommaso Bartalena, Tsahi Glik, Tushar Bende, Umesh Kadam, Valdir Barbosa, Valek Filippov, Valter Mura, Varun Mittal, Vinaya Mandke, Vitorio Furusho, Volker Merschmann, Walter Pape, Winfried Donkers, Xosé Calvo, Yaron Shahrabani, Yifan Jiang, Yogesh Bharate, Zeki Bildirici – and to all the less known but equally important anonymous contributors for this incredible journey. Together, we have built an incredible free software project, and the best free office suite ever.

When you have a class like

class C {
    C(): hasId(false) {}
    // ...
private:
    // ...
    bool hasId;
    int id; // iff hasId
};

instances of which may under certain circumstances be labeled with an ominous, externally inflicted ID (with legal values anywhere in the INT_MIN–INT_MAX range), Coverity Scan will tell you that you have a medium-sized security hole and you should better initialize that id scalar member variable in the C constructor.

Is that helpful? I doubt it.

What shall I initialize it with? Zero? Why zero, what’s so special about zero? If the invariant for C was that “id contains a valid ID iff hasId is true” before, has that now changed to the more complex “if hasId is true, then id contains a valid ID, otherwise id contains zero?” If I do maintenance work on that class a year from now, do I need to worry to reset id to zero when I reset hasId to false in some place in the code?

A better value to initialize such a member variable with would arguably be bottom. After all, every C++ type is inhabited by that. But, alas, C++ doesn’t give you first-class access to bottom as a value to asign to a variable. The closest approximation is probably to leave the variable uninitialized and allow tools like Valgrind to detect violations of the invariant at runtime. The exact thing that Coverity Scan advises you not to do. Oh my.

So a programming error that would have been identified by Valgrind becomes a programming error that is drowned in a too-complex class invariant? “Defensive programming” deluxe?

Another option would be to combine hasId and id into a single member variable of type boost::optional<int>, but that can become unwieldy if multiple members shall be controlled by one conditional bool. Keep it simple.

A somewhat acceptable approach to make Coverity Scan happy might be to explicitly value-initialize id via an empty set of parentheses,

    C(): hasId(false), id() {}

That would still initialize id to that funny zero, but would at least give the adept reader a clue that it shall have no influence on any invariant, and is merely there to appease some automatic analyzer.

Forgive my rant, it’s Friday.

As we are approaching the 4th anniversary of the LibreOffice project in just a few days, an old theme has been reappearing on the Internet: Apache OpenOffice and LibreOffice should reunite. I would like to share my perceptions on this topic although I think it is not a really important one, at least as long as the LibreOffice or Apache OpenOffice do not officially call for such a reunion. Before I start, let me remind everyone that what follows is my own opinion and neither the one of the Document Foundation, nor the one of the Democratic Party, the one of my Government, nor, at last, the one of Bob’s Shipping and Handling Company.

I am obviously biased in my judgement; I’m even a party to this game. But I am also relatively well informed on these matters, and you may want to read Leif Lodahl’s excellent post for more background. Let me clarify first that reuniting the two projects is an inherently political concept that covers several questions. Among them, here are a few that need to be answered.

1. How would we reunite?

 When the LibreOffice project was announced, the project asked Oracle to join and transfer the brand ownership to the new project. That didn’t pan out well. Oracle waited some time before deciding they would license the brand to the Apache Software Foundation, alongside the code of OpenOffice.org itself. There’s one important word here: Oracle licensed these assets.

It did not give nor sell them to the ASF. The full ability to dispose of the brand name “OpenOffice” would be somewhat uncertain from the onset, and LibreOffice would then be the brand used. Even if that was not the case, how would it exactly work? Would we release the same software under two brands? Two distinct releases under two different names?

2. What would we reunite?

That’s where the licensing part comes in: The choice of license is probably one of the biggest technical hurdle to such a reunification. On the one hand the LibreOffice codebase can, thanks to its licenses, accept patches licensed under the Apache license, but the reverse is more difficult (although perhaps not absolutely impossible). This constrained flow of code would be decisive, in the scenario of a reunification, as it would lead to stop the licensing of any new patch under the Apache license while leaving the present licensing scheme of the Document Foundation intact. My educated guess is that I don’t see the Apache Software Foundation allowing that to happen .

3. Where would we reunite?

In other words: what repository? Where? Would we use the ASF’s SVN repository of the Document Foundation’s own infrastructure with Git as the version control system of choice? Perhaps a third party (existing or created ad-hoc) would be another option.

4. Who?

Who would be the parties deciding is another delicate matter. On one side, the Document Foundation is an obvious stakeholder. Depending on the kind of reunification (more on this below), there would likely be some areas of discussion that would be not even considered just because of the Statutes of the Document Foundation (a charity cannot just go ahead and give away its assets like that). Aside the Document Foundation and the Apache Software Foundation, Oracle would probably be at least a necessary party to the discussion; and obviously, IBM. I’m sure I forget a few… but judging by the table, the dinner would likely be a delicate matter to handle. Having said that, it is not entirely clear what would be the voice of the broader community: as it stands, the Document Foundation is the only entity here directly representing its members, who are individual contributors of the LibreOffice project. The ASF does that too, but Apache OpenOffice is but one tiny fraction of the whole ASF community.

5. What kind of reunification do we want?

Beyond the rather specific questions asked above, this question has broader implications, because this is one that points out the actual reason and meaning of an hypothetical unification of the two projects. Do we want a merge of equals into a new structure? Is it even possible? I have highlighted a few points above that suggest this scenario would be technically difficult. Do we want LibreOffice to merge into ASF and AOO ? Obviously I don’t, but the question has been asked before. Why would we do that? Is  it even possible? Licensing differences suggest that the LibreOffice-specific contributions would need to be dumped. It would end up meaning that LibreOffice would dissolve into AOO and disappear with all the work done for naught, and given the difference in size between the two projects it would just be like an elephant trying to go through a doorlock.  Do we  want AOO to merge into LibreOffice? Licensing-wise it would be possible. Would ASF want that? I don’t know. The Document Foundation can, I think accomodate the project and its members. We have seen massive migration waves before. We can certainly integrate the AOO team. Ultimately, the contributors of each project would be the judges by voting with their feet. And that is not something the Document Foundation, Apache, Oracle nor IBM will ever control.

6. What is it we’re trying to achieve?

When members of the old OpenOffice.org project used to sometimes discuss the future of that project with the good folks at Sun Microsystems, they would often hear the same question thrown back at them: “Tell us why a foundation for OpenOffice.org would help fix the project’s issues”. Invariably, any point that was raised in favour of a foundation was brushed away by providing whatever solution that did not involve the existence of an independent foundation. It used to illustrate perfectly the difference between real outcomes and the foreseen results based on a rational argumentation: the two don’t necessarily match. With a strange twist of irony, I must now ask the same question: “Why would the reunification help fix any of these projects’ issues?” I will quickly list here areas of concerns and topics that are usually pointed as reasons to unite the two office suites:

• common branding / stronger brand value
• everybody can now contribute to the same code base (yeaah!)
• there’s no point in having two similar office suites
• no more interoperability issues

The stronger brand value used to be a very good argument, perhaps even the best one, in 2010 and 2011. I started this post by highlighting that the LibreOffice project’s founders had actively sought Oracle’s consent to use OpenOffice for the new project. Now, we’re barely 72 hours away from the LibreOffice project’s fourth birthday. The project is doing well. There’s still much to do, but it has exceeded what many used to imagine would be possible. While the LibreOffice brand started from zero in 2010 and 2011, things have changed. Obviously, OpenOffice has a more known brand, as it capitalizes on 10 years of existence of its old project; I’m sorry to say that Apache OpenOffice has little merit in this achievement aside its very existence. But LibreOffice as a brand is now established and its brand value is growing pretty much everywhere. To destroy any one of these two brands all of a sudden would thus bear some painful consequences, although it may well happen in the end. Do we want this? Does anyone have an actual, sustainable and actionable plan for a brand transition? I have not heard of anything of that kind.

The fact that a common project could now contribute to the same codebase, thus making a “better and stronger” office suite is somewhat moot. LibreOffice took whatever it wanted from Apache OpenOffice through the licensing specifics of the two suites; but in sheer contributions, Apache OpenOffice has now little to offer to LibreOffice. Besides, the two contributors’ pools are so different in size that the addition of AOO developers would not be really meaningful to LibreOffice while if the reverse was true, things would be very interesting. However, it means that here again we pretend to play with contributors like we’re measuring army regiments. Community members come and go as they please, and a reunification is not something everyone is necessarily looking forward to.

There is indeed little value in having two similar office suites, although it is a fundamental expression of software freedom, and that alone should be enough. We also have something like 150 Linux distributions and if we really look around and apply this way of thinking,  we may want to merge with Calligra, Abiword and Gnumeric. That too, makes absolutely no sense. Remember, however, that neither AOO nor LibreOffice actually want to be “similar”, and despite a popular perception, they are growing rather different each quarter. The same can be said of Calligra, a project that runs on a very different code base. In a nutshell, clones may not make much sense, but choice is good especially if the choice involves real differences. There are now real differences between AOO and LibreOffice, in terms of features, of file format support, in terms of ecosystem and engineering processes as well. The choice between these two suites is becoming clearer as time goes by.  We shouldn’t forget that when we picture anything like a competition between Free and proprietary software, we are not implying that there should be only one option on either side.

Last but not least, interoperability issues have been mentioned by several well informed parties as being a problem and ultimately a hindrance to the adoption of Open Standards such as ODF. While this is a rather complex issue, it is also not a blindingly critical one, in the sense that the issues that can be met tend to arise in specific environments. These usually involve a userbase using OpenOffice.org or AOO together with LibreOffice and documents that have already been migrated to ODF. Growing differences in implementations invariably lead to visible differences in the presentations of documents (although there is no data loss) and therefore generate frustration and users’ discomfort. The only possible solution to these hurdles (aside a careful and diligent migration expert leading the ball) is to have AOO and LibreOffice cooperate on specific interoperability issues. But make no mistake: anyone else who would use Microsoft Office or Calligra with ODF documents would ultimately create its own incompatibilities. The actual scope of the problem is thus broader and has been expected for several years now; this is just not a mere AOO-LibreOffice  issue. A merger would solve this in the long term, but would still force some users to abandon one implementation for another.

Before I finish this very long post, let me just point out that when all is said and done on this topic, it really boils down to the actual will and intent of the stakeholders. It might seem unsavory for me to point this out, but to this day I still haven’t found any real reason for Apache OpenOffice to even exist. It does not mean that I hold this project’s members as idiots or incompetents, far from that. But if we talk about reunification, then it brings back the original question to the table: While we know why LibreOffice and the Document Foundation were created, we know of no real reason why Apache OpenOffice was started, aside one corporate will to license its own assets to a third party it is familiar with. So if the two projects were to reunite, one must pay close attention at the actual meaning of this movement and listen to the actual projects’ contributors. When Software Freedom is involved there is no point in bypassing the community.

“Alles hat ein Ende nur die Wurst hat zwei.”
— horrible 1980ies german folk song lyrics

So, three month ago, the ESC discussed if we would still support the NPAPI plugin to show documents in the browser. The discussion was ignited over an mostly innocent bug: fdo#45071, but the discussion soon dived into long-term viability of this technology and with Chrome “phasing out NPAPI support over the coming year” and as Mozilla Firefox “will no longer activate most plugins by default” it became quickly clear that trying to keep the plugin alive would be throwing good developer time after bad. So in LibreOffice 4.4.x there will not be a NPAPI plugin anymore, as the patch that was waiting on gerrit for a month is now pushed to the master branch. As by the time of release plugins will not be enabled anymore on the most common browsers using it, this likely will not make much of a difference to most users anyway.

Luckily, LibreOffice is not only deprecating old technologies when they become more and more irrelevant — it is also moving towards new technologies when they gain relevance.

Berlin, September 25, 2014 – The Document Foundation announces LibreOffice 4.3.2, the second minor release of LibreOffice 4.3 “fresh” family. Most of the over 80 fixes focus on interoperability issues when reading or writing Microsoft Office DOCX, XLSX and PPTX files.

LibreOffice 4.3.2 hits the marketplace just before the fourth anniversary of the project on Sunday, September 28, 2014. The community has been growing for the past 48 months, attracting at least three new developers per month plus a larger number of volunteers active in localization, QA and other areas such as marketing and development of local communities.

With localizations available in over 100 languages, LibreOffice can be utilized in the native language by almost 5 billion people worldwide. “LibreOffice has a key role in reducing the digital divide in countries where the native language is not English”, says Eliane Domingos, a Brazilian native, Deputy Chairman of The Document Foundation. “As a foundation independent from software vendors, we have the privilege of being able to look after user interests instead of running after sales targets or quarterly earnings releases”.

People interested in technical details about the release can access the change logs here: https://wiki.documentfoundation.org/Releases/4.3.2/RC1 (fixed in RC1) and https://wiki.documentfoundation.org/Releases/4.3.2/RC2 (fixed in RC2).

Download LibreOffice

LibreOffice 4.3.2 “Fresh” and LibreOffice 4.2.6 “Still” are immediately available for download from the following link: http://www.libreoffice.org/download/.

LibreOffice users, free software advocates and community members can support The Document Foundation with a donation at http://donate.libreoffice.org.

Now and then people ask me about LibreOffice or OpenOffice. Usually I point to the statistics about number of developers and such. And to the large difference in new functions. And of course the fixed old bugs. After explaining that to an artist, he came up with a nice drawing that I don't want to hide for you.

A nice and funny drawing. On the other hand it's of course possible that such a split in a - originally single - project has negative impact on peoples joy in work and ambitions. And might that be the case - it's something that I always regret - I do hope that time will have a healing influence. As it usually does.

Introduction

The introduction of the new Breeze icon set in KDE let us again wonder, what aspects of an icon set actually takes what impact on the usability of it. We investigated Oxygen and Tango Icons for the LibreOffice project before, but our focus then was on checking all icons of the standard tool bar. This time we focus on different icon sets and will use 13 common actions to compare them.

With this series we are going to test at least 10 different free icon sets: Breeze, Oxygen, Tango, Faenza, Nuvola, Nitrux, Elementary, Crystal Project, Humanity and Treepata. These icon sets differ on various aspects: use of color and details, flat or not and sometimes even on the metaphor used.

So, we generally want to analyze effects of icon design on the overall performance of an icon set. Statistics on this issue can obviously only be done after all icon sets have been tested. But with every test, we win some specific insights in strengths and weaknesses of each icon set tested.

In this post we share some findings about the Crystal icon set.

The study was finished by 513 participants (drop-out rate 5%) with an average handling time of 1:43 min.

Results of Crystal icons

Table 1 lists the aggregated quality indicators. They show how well all icons that we used for the test were suited to symbolize the different terms. It has a range from 1 (no fit) to 10 (perfect fit), whereas you would expect values of at least 9 for well represented terms.

Table 1: Quality of the icon set for different terms based on assignment ratio (percentage of missing assignments) and conspicuity (or speed of picking icons).

Term	Quality Indicator
Link	7.5
Open	9
New	9.5
Copy	9.5
Paste	9.5
Redo	9.5
Undo	9.5
Add	10
Remove	10
Save	10
Print	10
Search	10
Cut	10

Table 2 shows a cross-table with the percentage of false associations. These are terms where the intended icon was not chosen by the users, but some other icon was.

 Table 2: Cross-table of icons and terms with percentage of false associations. The direct match is inverted (1-value, e.g. 0.99 for Remove) to obtain comparable data.

Discussion

The Crystal icon set was the default in KDE 3.x and is still available in LibreOffice for instance. The style aims to have a distinctive “crystal” look, mainly consisting in icons that appear to be made of highly reflective surfaces.

The icon set shows a couple of issues. First of all, New is just a plain sheet without any indicator of the underlying function. Actually, the Open icon is similarly reduced, at least in low resolution, but works however. Copy uses the same metaphor as the other sets, and receives a comparable high amount of mix-ups. Redo/Undo seems to be less structured because both icons uses the same color, but the results are very comparable to other sets. Obviously, the color information does not help here. And last but not least the Link icon shows some issues. The original set doesn’t contain any link icon, so it was taken from the Open Office repository that provides only a small size and not the conventional freedesktop organization. But to avoid the bias due to different set sizes we kept those non-standard icons in the study.

If you know how to design icons and would like to help us to identify metaphors that work better, please contact us. Also, all raw results are publicly available on our open usability platform UserWeave.

As mentioned before: These results only reflect the internal quality of the Crystal icon set. The final interpretation will be done soon. So stay tuned. And, of course, feel free to discuss these findings with us.

• Mail chew, interview, partner call; lunch. Partner call, dug at Kendy's nice timer patch; found a corner case or two causing grief still, and did some testing; dinner; back to work - pushed timer patch.
• Rather pleased with Emma Watson's UN speech; with an encoruaging leading rebuke; I'd call myself a Feminist if it wasn't for the dismissive, man-hating, alternative fringe that she calls out. Still good to hear the obvious re-stated eloquently and helpfully: that women should be equal and we should be upset when they are not. Then again, I get tired of the horribly complicated issue of suicide being used to make political / gender points.

• Mail chew, friendly partner call; worked through bugs at some considerable length with Andras; more mail chew; team call, lunch. Even more unbelievable admin, another team call. Dinner, put babes to bed, partner calls until late; reviewed Kendy's nice mainloop patch.

The annual LibreOffice conference was held in Bern at the beginning of September. Main topic of the conference presentation “The Big Draw on LibreLogo.org” was about the successful Wikipedia contribution using LibreLogo, see the slides in a hybrid PDF with some extra notes. Thanks to András Tímár for the presentation!

• Off to NCC, Roy speaking; fine roast lunch, slugging in the afternoon. Watched the latest Material Science open university program with the babes; then High School Musical (hey ho).
• Caught up with Dave; Gordon sermon on 1 Samuel; bed early.

• Checked mail; played with babes, took a blow-lamp to broken trampoline spring to the point that it could be re-worked into a new spring. Lunch; out shopping, repaired this & that around the house, more mail in the evening.

• Mail, meetings, bit of hacking today - encouragingly implemented some "kernel32" alike VBA shims for Linux / Mac to get high resolution timing data, filed a couple of follow-on easy hacks, and discovered that Currency (a 64bit integer type) does not make it through our native code invocation framework.

Introduction

The introduction of the new Breeze icon set in KDE let us again wonder, what aspects of an icon set actually takes what impact on the usability of it. We investigated Oxygen and Tango Icons for the LibreOffice project before, but our focus then was on checking all icons of the standard tool bar. This time we focus on different icon sets and will use 13 common actions to compare them.

With this series we are going to test at least 10 different free icon sets: Breeze, Oxygen, Tango, Faenza, Nuvola, Nitrux, Elementary, Crystal Project, Humanity and Treepata. These icon sets differ on various aspects: use of color and details, flat or not and sometimes even on the metaphor used.

So, we generally want to analyze effects of icon design on the overall performance of an icon set. Statistics on this issue can obviously only be done after all icon sets have been tested. But with every test, we win some specific insights in strengths and weaknesses of each icon set tested.

In this post we share some findings about the Humanity icon set.

The study was finished by 522 participants (drop-out rate 7%) with an average handling time of 1:53 min.

Results of Humanity icons

Table 1 lists the aggregated quality indicators. They show how well all icons that we used for the test were suited to symbolize the different terms. It has a range from 1 (no fit) to 10 (perfect fit), whereas you would expect values of at least 9 for well represented terms.

Table 1: Quality of the icon set for different terms based on assignment ratio (percentage of missing assignments) and conspicuity (or speed of picking icons).

Term	Quality Indicator
Remove	7
Add	9.5
Open	9.5
Save	9.5
Copy	9.5
Paste	9.5
Redo	9.5
Link	9.5
New	10
Print	10
Search	10
Cut	10
Undo	10

Table 2 shows a cross-table with the percentage of false associations. These are terms where the intended icon was not chosen by the users, but some other icon was.

 Table 2: Cross-table of icons and terms with percentage of false associations. The direct match is inverted (1-value, e.g. 0.98 for Add) to obtain comparable data.

Discussion

The Humanity icon set is the default in Ubuntu. It is based on Elementary which, in turn, is more or less a fork of Tango. The design concept of Humanity focuses on usability with clear, consistent, and concise metaphors, on practicality, and on constant evolution. Does this user-centered approach works?

It does. Humanity performs very well. Even the newly introduced metaphor for Save gets remarkably good results. Copy/Paste as well as Undo/Redo are mixed-up similarly to corresponding icon sets. The only bigger issue is found for Remove. Here the cancel metaphor fails and a lot of participants just do not assign any icon to the term.

If you know how to design icons and would like to help us to identify metaphors that work better, please contact us. Also, all raw results are publicly available on our open usability platform UserWeave.

As mentioned before: These results only reflect the internal quality of the Humanity icon set. The final interpretation will be done after all sets have been tested. So stay tuned and please participate in our follow-up tests. And, of course, feel free to discuss these findings with us.

Our Chairman of the Board announced this:

Dear members,

with the preliminary MC election results posted last Friday, and having received no objections within the challenge period, that ended last night, it is my pleasure to now declare the official results of the 2014 Membership Committee Election.

The board declares the following Members of The Document Foundation elected into the Membership Committee:

• Cor Nouws
• David Emmerich Jourdain (tied for first with Cor)
• Jan Holesovsky
• Charles-H. Schulz
• Gabriele Ponzo

The board declares the following Members of The Document Foundation elected as deputy members of the Membership Committee:

• Klaus-Jürgen Weghorn
• Andras Timar

Full detailed election materials are to be found at

https://elections.documentfoundation.org/2014-mc/

, with the processed STV result here:

https://elections.documentfoundation.org/results.php?election_id=6

, and the list of all votes here:

https://elections.documentfoundation.org/votes.php?election_id=6

The board wants to take the opportunity to thank all past and new members of the Membership Committee for their service to the community, and all candidates for running. Congratulations to the newly elected committee members and their deputies!

With best regards,

Thorsten Behrens,
on behalf of The Document Foundation board of directors

Over the course of the summer I’ve been adding some minor improvements to various parts of the Impress Remote — both on the Server and Android components.

Remote Deauthorisation & Dialog Improvements (for WiFi connected remotes)

(Implemented at the Paris Hackfest.)

Prior to this, authorising a remote was a permanent and irreversible action — now you can remove them again (this only applies to WiFi/network based remotes — Bluetooth remotes are managed using system utilities).

At the same time some further improvement work was carried out on the dialog to remove some other annoyances (e.g. occasional flickering), in addition to the fixing of an (admittedly minor) memory leak (shhh, apparently I wasn’t aware that C++ didn’t have a garbage collector when I first started working on LO), and finally improving the pin-entry (i.e. auto-focus on the pin-entry box, and no useless/junk “0” in that pin box anymore).

Ultimately it would be cool to use fancy new widget layouting to assemble the list of remotes, instead of the current custom vcl widget (which would make it easier to add more functionality in future if desired, and there is certainly no lack of ideas in that department), but that’s a story for another day (and no idea how simple/complex the conversion would be).

Emulator auto-discovery

This actually existed in the early days of the Android Remote, but unfortunately got lost at some point. It’s the work of only a few lines but makes the lives of developers simpler — especially so for first time developers who may not be aware of the networking infrastructure around the emulator (the “real” host is reachable under 10.0.2.2 from the emulator).

(This was implemented at the LibreOffice Conference Hack-Night, where I was wanting to work on the bugs/features below, but couldn’t actually test the remote on my phone as my laptop’s Bluetooth adapter was borked, and the University WiFi was blocking the remote too. I couldn’t actually remember the correct host IP, and had managed to type it incorrectly on the remote development wiki page back in 2012 too…)

Grid View Current Slide Highlighting

The grid view previously offered no hints as to which slide is selected, that is now remedied:

The design is far from final, and can easily be adapted in the resource files, but the functionality now exists.

Refactoring and Bugfixing

Over time the code has become a bit untamed — fixing a bug in the laser-pointer mode (where the displayed slide wouldn’t be updated when the slide is changed on a different device and/or server) involved some refactoring that not only deduplicated a chunk of slide-change listening code, but also allowed easier (and more correct/simpler) implementation of some of the above features, e.g. the grid-view highlighting.

The future

There’s never a shortage of ideas/bugs, just too little time. There’s no plan, but some things that might be cool would be features such as storage of presentations on the remote (to allow transfer between PCs), chromecasting of presentations (although that would be very complex / would require using the full LibreOffice on Android porting work + a good chunk more — a very pie in the sky idea), Android Wear integration (probably mainly for showing athestopwatch), in addition to just more polishing of the existing functionality.

Finally, a big thanks to Google for sponsoring the initial implementation of the Impress Remote as part of the Google Summer of Code 2012, Michael Meeks as my first GSOC mentor, and the LibreOffice development community in general for their support and advice.

Please participate in our little game! (Study closed)

It is fun, takes a maximum of 5 minutes and helps us to better understand effects of icon design.

For more information please check our initial post on the idea and background of this series of small icon tests.

RollApp has just announced the availability of LibreOffice on Amazon Kindle Fire and other Android tablets. Applications running thanks to RollApp virtualization technology can be accessed at http://www.rollapp.com/libreoffice! Storage is provided through seamless integration with Google Drive and Dropbox.

If you use of an Amazon Kindle Fire, you can get the LibreOffice applications directly from the Amazon App Store. On other Android tablets you can launch the apps in a browser via http://www.rollapp.com/libreoffice. Yet, the best way to use the apps is to install them on your device.

Here is how to do that in four easy steps:
1. Go to https://www.rollapp.com and choose the app you like (for example, LibreOffice Writer).
2. Tap the “Add to Home Screen” button under the app’s icon.
3. Tap the menu icon in Chrome toolbar, and choose the “Add to Home Screen” menu item.
4. Confirm the title by clicking “Add”, and voila! The app is installed and is just one tap away.

“We’re thrilled to introduce LibreOffice suite on Android and bring it to Amazon customers, giving them a better way to work with their documents. The apps for Kindle Fire and other Android tablets on RollApp are available with all of the features users have come to love on their desktop computers”, said Vlad Pavlov, RollApp Founder and CEO.

LibreOffice is growing on every platform, as the numbers confirm: in fact, in addition to 100% of Linux users there is a growing number of Windows and MacOS users pinging for software updates (80 millions, and counting). RollApp announcement complements TDF tender for a native Android editor, to be released in early 2015. Similar announcements are expected for the end of October.

The account requests for the LibreOffice templates site are handled within an imap account now. Thus I worked on the email send feature of the Plone addon (used for the form) and got the resulting email in a better shape.
Another step forward to retire OTRS.

Writer has long had Master Documents. A master document lets you manage large documents, such as a book with many chapters. One odt per chapter, bundled into a single document via a master odm

LibreOffice 4.4 introduces Master Document Templates. What that means is that these Master Document Templates can be added to the Template Manager and from there you can create a new Master Document (odm) based on a Master Document Template (otm). The new odm of course having the same initial content as the Template it is based upon.

Thanks to Máirín Duffy (of Red Hat, Inc.) for prompting this feature. Any failures in execution are mine however.

As you may know i was participating in this year Gerrit User Summit, 21-26 March, followed by Developer Hackathon in Mountain View, CA.

I had three presentations: Gerrit@LibreOffice with detailed explanation of Gerrit Buildbot plugin and two feature requests:

• inline edit
• dedicated notification channel for patch set verifications

Among other presentations Edwin summarized new features in upcoming Gerrit 2.9 release, that was later converted to regular documentation page in Gerrit. Shawn presented plans for future Gerrit/Git development:

• Moving from database to Git to store meta data
• Provide alternative Git storage backend(s) to file system backend.
• Improving Git submodule feature set

During the Hackathon i continued the work on inline edit feature: to allow to change code during review directly in browser. It should also have support to create a new empty isolated change and a follow-up change from a given change directly in browser and allow to populate it with code changes.

On Sunday we had mountain bike tour in Santa Cruz national park. Thanks Edwin for these great pictures:

Big thank to The Document Foundation for funding my participation.

Because the infra team of the Document Foundation wants to shut down the OTRS instance I worked on a new Plone addon that sends the data of a form to an imap account. The header and content of the email seemed to be in a good shape. Let’s see if the tests validate.

Last week we had a great LiboCon 2014 in Bern, organized by a great team and a great (and often not known well enough) city. We had what has become some sort of tradition, by which I mean the Libreoffice Marketing Strategy Workshop. This year was a bit special however in that the workshop itself came after a series of other workshops dedicated to media training and messaging by Italo Vignoli and another session aimed at helping non-native English speakers promote LibreOffice in their language. All these sessions did prepare the audience to the strategy workshop but were also a very nice addition to it. I was also happy to notice a stronger attendance than previous years to the workshop, as well as a more diverse one that included at the same time active contributors, contributors of native-language projects, and “simple” visitors of the conference. Some of them actively contributed to the session, and I found that to be very useful.

While there was no shakedown of the marketing strategy this year, there was however a strong focus on online campaigning and volunteers’engagement methods. It was also a good opportunity to let everyone share ideas and experiences. Below are the main discussion points of the workshop. You may download the slides supporting the workshop directly here.

Achievements

This year we had several notable successes, despite remaining a project with a small marketing team. First, our new website has been one of our most visible achievements and has been in most cases very well received. LibreOffice needed a more visually appealing website, and there was an interesting discussion as to how we were conveying the idea of what LibreOffice is, both as a software and as a project. We will come back to that in the latter part of the post.

Second, there is a real momentum around LibreOffice on social networks, with the presence on each online service acting like a specific channel for a certain type of activity and conversations. For instance, Facebook is our the network with our biggest outreach, yet it is probably the most passive one, with very few conversations taking place. The volume of the audience however makes it worth maintaining an active presence there. On Twitter we have two accounts, @tdforg and @libreoffice . We started tweeting irregularly through @tdforg and got lots of success for three years; but we had kept @libreoffice under wraps. Starting in 2014, we started to differentiate between @tdforg being more about official announcements, and @libreoffice tweeting several times a day. In both cases we reached several thousands of subscribers and are engaging in (short) conversations with users on a regular basis. Google + is also a big success and a quite interesting one. Here again, we have several thousands of followers but what’s really interesting is that it is a place where people discuss topics and post new ones. Users support is also happening sometimes there.

Reddit was a modest (several dozens of members) channel for us and has now grown to several hundreds so it’s definitely something to keep an eye on.

All this work described above has led to one specific and recurring objective: Increasing LibreOffice’s brand awareness and growing our contributor’s base. We still have lots of work to do, and we had a discussion about the results of the LibreOffice ad in the german special edition of Die Zeit. We realized that should we decide to go for these traditional ads, we would need to have a more comprehensive campaign with an actual story line in order to yield measurable results.

Another set of achievements has been the real improvements in how the communications on the LibreOffice releases are handled  throughout the community. Thanks to a clearer and more inclusive process, the LibreOffice native-language teams have the time to localize the release and announce it by translating the press release in due time. This is no little effort when you consider the work put into the localization, the quality assurance on the various betas and release candidates, and the translation of the PR itself. Last but not least, and before we skip to the other parts of the workshop, this year was also a successful year in terms of articles written about LibreOffice and the Document Foundation. This also helps us increase the brand awareness and help us grow our userbase and our community.

Challenges & Solutions

Despite our achievements, our marketing team remains small (around 4 individuals contributing on a non permanent basis, sometimes daily, sometimes weekly). The discussion this year suggested that we put more effort into contributor’s engagement and while this used to be somewhat of a tricky question, I think we now have enough hindsight to make it work. In order to understand the situation one needs to take a step back and consider the following.

When the LibreOffice project was created it was one of the best opportunities to start afresh in the way the community and how each of us contributes to the project was valued. As a result, it was decided that a strong meritocracy would be instrumental in improving the low rate of contributions of the former OpenOffice.org project in a substantial way. It worked and still works really well for most of the project, but marketing or promotion did not overly benefit from that. Of course, it helped us gain time and stop wasting energy dealing with distractions such as endless (and pointless) discussions on “product marketing mixes” and so on. Yet it did not help us multiply our base of marketing contributors. The principle, which remains the same, that in order to be acknoledged by the community you must first contribute something to it, did not, however, handle too well the kind of contributors who would be happy just with little things, such as badges. While developers tend to not pay any kind of importance to these details, we also had to deal with the fine line between handing someone a badge and some sort of formal role, and giving a title to someone just because he or she would have asked for it. A title in itself is little, and probably nothing. Yet our experience with OpenOffice.org showed that it was very easy to have titles, and even easier to do nothing to earn it. Thus, anything that had to do with badges was viewed with skepticism, if not prejudice.

This year, we are going to start improving the quality of our contributors’ engagement with the project at least in non-technical areas. A badge does not imply any sort of hierarchy, or formal role. It does not replace the membership to the Document Foundation. It is just what it is, a badge.

At the same time, we would like to drive the same experiment than the one our Design and UX team had a few months ago: a full migration to the RedMine platform hosted on the project’s infrastructure. While we may stick to a few of our existing tools (the existing wiki), RedMine essentially turns your team’s activity into a project and tasks’ based workflow, while eliminating much of the noise. The discussion, because of the tools, are directly related to tasks, and tasks behave pretty much like issues opened in a bug tracker.

We had an interesting discussion about the need to engage in communication campaigns that tie in to specific news or moments. We should be able to “join the conversation”, when one of our competitors claim something we can talk about as well. These campaigns would definitely help us raise our brand awareness too. This will also require that the marketing team starts working on its own banners and online material without necessarily hogging the resources of the Design team.

Last but not least, we have experimented with something called LOWN (LibreOffice Weekly Newsletter), thanks to William Gathoye. This newsletter is not really meant for people outside our community. On the contrary it is designed for community members, who want to stay in touch with all corners of the project and learning about what’s going on in other teams. We may want to make it a montly newsletter, but it is encouraging to see this becoming a community based effort.

As a conclusion to this very long post, I would like to thank everyone who joined the workshop this year, it was a great moment of sharing and I think it will help us moving forward for next twelve months, be a better community and a more efficient project.

Playing around with some Mac OS X fonts under Linux I noticed that LibreOffice wasn't listing a lot of them despite fontconfig announcing their existence. A little digging and some very small tweaks means that we now have mac ttf fontname encoding support along with support for version 2 ttc fonts. This is more fixing some oversights (version 2 of ttc came into existence after the ttc support was added so there was a "only if version is 1" condition) than implementing anything particularly new, but now LibreOffice under Linux works with a lot more ttf/ttc/otf fonts than it did before.

p { margin-bottom: 0.25cm; line-height: 120%; } This proposal has been said many times over the last couple of years and lately repeated by Daniel Brunner, head of the IT department of Switzerland's Federal Supreme Court.https://joinup.ec.europa.eu/community/osor/news/open-and-libre-office-projects-should-reunite. And from the first point of view I can only agree. There is no reason what

Notice: These are my opinions as an individual, not as a member of the Board of Directors

Note: Slight updates to “accounting” section due to clarification from my good friend :)

From bug reporting on bugzilla, to user/QA mailing lists, all the way to the QA chat, users (and contributors) ask “why not just do a targeted crowd-funding for X,Y,Z.” X,Y,Z has been mostly large projects and/or ideas– including but not limited to Android development, revamping our UI, or even individual “pet bugs” that people have reported. So, in theory crowd-funding sounds fantastic…right? Well, here I’ll try to convince the doubters that TDF doing targeted crowd-funding is indeed, anything but a great idea :)

Accounting

This is perhaps the easiest one to explain. TDF is incorporated in Germany (this is not implying that it would be any easier in another Country) and with that comes of course, German laws (which are likely the same in other countries). These just add a new layer of having to track different “pools” of funding.

The next accounting related issue is what happens if we are short or over (ie. we don’t hit our #’s or we overshoot the #). Well then we’re in a pickle. On one side, if we undershoot the target, do we refund people? Do we merge the money with general funds? Do we just indefinitely hold it in case we ever hit the #? All of these sound quite tiresome/time consuming/confusing. Now if we overshoot, again the same problems arise. Do we refund the extra money? Do we put it in the general funds? Either way accounting for these can be difficult and time consuming.

When push comes to shove, this would just eat up our employee’s (or a tremendously dedicated volunteer’s) time just tracking the #’s and I don’t think anyone would be happy with these results.

Expectations

Donor expectations are another area that becomes overly complicated with targeted funds. Person X donates $100 to “make UI better”, person Y donates $10 to “make UI better.” Now the two don’t agree on what making it better means (one suggests one mock up, the other suggests a radically different mock up). Who wins? If we decide on person Y’s mock up, does person X get a refund because they actually think it’s a horrible UI? What about the difference in contributions – one gave 10x the amount of the other, should that matter at all? Perhaps it shouldn’t…but try explaining that to person X with a straight face. Do we put it to a vote? And then the losers of such a vote get the option to demand a refund?

The reality is that targeted funds come with expectations, and no matter how clear the message of the targeted funds, someone is bound to be unhappy with the result. We’d hate to offend our donors by saying “deal with it” if they get a result that they aren’t happy with and contributed funds specifically for that thing.

Funding for “Less Sexy” Things

Person X has $20, they go to the donation page and they see “general fund” (with some description of what that mean) and then they see “awesome NEW FEATURE!” . . . where do they donate? Exactly, you get the point. While it’s fun to fund new exciting and sexy things, the “non sexy” things are quite (probably a lot more) important. These include paying for infra (quite expensive), employees (who do amazing work), and events. Worst case would be to have a bank account with $50k for “awesome sexy flying monkey feature” and $0 for “general operating expenses.” The response might be “set aside some amount in advance for day to day,” in theory possible, but time consuming and when that amount runs dry – what do we do? Pull “sexy awesome flying monkey feature” from the donation page to “encourage” donors to donate for the necessities?

 

As you can see all of this is quite complicated.

So…Now What?

Well there are indeed options and the Board takes this (and similar) issues seriously. For instance with Android port – we heard, and we acted. We now have a public tender which we are using to solicit bids to start the port to Android. Beyond that:

1. There are of course grass roots crowd sourcing sites, we don’t vouch for any of them, but we don’t discourage trying to use them. That being said, please note that the risk is on you (the founder of the campaign) and not on TDF to deliver. If you raise $100k and promise to fly everyone to the moon, it’s on you to deliver. But in all honesty, if you raise money and “think” that it might be enough to fix some pet bug or something, ask around the dev channel to see if anyone is interested in doing it for that price – but please please please be aware that if you have no background in programming, you’re likely going to underestimate the cost of development by multiple factors. Before starting a campaign, best to ask for a rough guess at cost from someone who knows the code.
   1. Options: kickstarter of course, and freedomsponsors – again I am not endorsing either, I’ve just seen both used
2. Volunteer time
   1. Do the leg work! Our group is a meritocracy, doing the leg work tremendously pays off. For instance instead of saying “fix the UI” – build a community, get support for a concrete proposal, get documentation together for functionality, etc… etc… Too often I see a mockup with nothing more (a single image done in an hour or two) and then demands that we implement – this simply won’t work.
3. Join our public board call – trust me, we’re happy to have the public in (that’s why it’s a public call). If you have strong feelings about something (and are willing to put in work/time/money/etc…) we’re willing to listen. This does not mean jump into the call and demand the world and not give anything in return – again this won’t get us closer to anything other than a headache.
4. Despite the cons listed above, TDF hasn’t 100% ruled out the possibility, we’re just not ready to make the leap right now. Perhaps at some point in the future it will happen, but until then, I highly encourage our users, donors and contributors, all to find creative ways to get their projects done.

 

 

Please participate in our little game! (Study closed)

It is fun, takes a maximum of 5 minutes and helps us to better understand effects of icon design.

For more information please check our initial post on the idea and background of this series of small icon tests.

Introduction

The introduction of the new Breeze icon set in KDE let us again wonder, what aspects of an icon set actually takes what impact on the usability of it. We investigated Oxygen and Tango Icons for the LibreOffice project before, but our focus then was on checking all icons of the standard tool bar. This time we focus on different icon sets and will use 13 common actions to compare them.

With this series we are going to test at least 10 different free icon sets: Breeze, Oxygen, Tango, Faenza, Nuvola, Nitrux, Elementary, Crystal Project, Humanity and Treepata. These icon sets differ on various aspects: use of color and details, flat or not and sometimes even on the metaphor used.

So, we generally want to analyze effects of icon design on the overall performance of an icon set. Statistics on this issue can obviously only be done after all icon sets have been tested. But with every test, we win some specific insights in strengths and weaknesses of each icon set tested.

In this post we share some findings about the Treepata icon set.

The study was finished by 491 participants (drop-out rate 4%) with an average handling time of 1:41 min.

Results of Treepata icons

Table 1 lists the aggregated quality indicators. They show how well all icons that we used for the test were suited to symbolize the different terms. It has a range from 1 (no fit) to 10 (perfect fit), whereas you would expect values of at least 9 for well represented terms.

Table 1: Quality of the icon set for different terms based on assignment ratio (percentage of missing assignments) and conspicuity (or speed of picking icons).

Term	Quality Indicator
Link	5.0
Open	9.5
Paste	9.5
Print	9.5
Remove	9.5
Add	10
Copy	10
Cut	10
New	10
Redo	10
Save	10
Search	10
Undo	10

Table 2 shows a cross-table with the percentage of false associations. These are terms where the intended icon was not chosen by the users, but some other icon was.

Discussion

The Treepata icon set works really well. We do find the – by now expected –  mix up of Copy & Paste and Undo & Redo. Also New shows some slight problems, but none of these are really critical. The only real problem we found is the metaphor used for Link, which has been left out by many users.

If you know how to design icons and would like to help us to identify metaphors that work better, please contact us. Also, all raw results are publicly available on our open usability platform UserWeave.

As mentioned before: These results only reflect the internal quality of the Breeze icon set. The final interpretation will be done after all sets have been tested. So stay tuned and please participate in our follow-up tests. And, of course, feel free to discuss these findings with us.

The LibreOffice extensions and template site uses currently the ticket system OTRS for the admin workflow. Because The Document Foundation is moving away from this system to Redmine I have to work on a solution for the extension and template site. The infra team decided to use an imap account instead of OTRS. I made some tests with such a setup and in general it would work. But I need to work on a Plone addon first to get the user message in an appropiate way into the mail account. Hope to get that done in the next days.

After a somewhat painful debugging experience*, it’s now possible to view Calc documents on Android too.

This combines the Calc Tiled Rendering work (thanks to the Google Summer of Code) with the LibreOffice Android Viewer developed by Collabora (thanks to Smoose):

This work is still on a branch (as some of the changes affect Calc’s normal rendering, and still need to be fully verified as to not introduce unwanted bugs there), but should hopefully be mergeable soon.

* Using the r10-ndk it was possible to at least set (and make use of) breakpoints on methods, however gdb seemed to be blind to any other debug-info, making this a pointless exercise. With the r9d-ndk, gdb wasn’t even able to connect to the application. (Fortunately we can still get log output via adb logcat — resulting in slow but useable debugging.)

(Update: It’s also worth noting that we don’t use the standard ndk build system (the LO build system is hugely complex already), and we have problems with the standard android linker due to the sheer size of what we do, currently we therefore link all our (usually separate on a desktop) libraries into one huge library (but restrict building debug info to only a few modules so that we can still link that huge library without running out of memory), which might also not be so helpful for the ndk-gdb. I’ll be back on my main machine soon, so can experiment with a full debuginfo build there hopefully, but on my laptop that just isn’t feasible.)

Merhaba,

First of all thanks all of the guys for the great conference. It was a great experience for me as always. So I am making another blog post which is more like a travel post, so it will be on my main blog instead of this.

So I will summarize shortly what I learned. About project itself.

- LibreOffice code itself is big, but the people who working on it is not that much. Yes, yes I know there are 2-3 person projects which are awesome. Yes I know we are huge if you compare us with them. But we are not “THAT” big.

-LibreOffice development speed is fast. I mean fast as the car which overtakes you in autobahn when you were going 180kph, and you couldn’t see the color of the car.

-Unit tests are important.

-Use icecream! And don’t tell your colleagues. :-)

-We have much more better OOXML support compared to last year. I mean much much much more better.

-Unit tests are important!

-Watching Fridrich presenting is the best thing I have done in my entire life!

-Did I mentioned Unit tests are important? If I didn’t, Unit tests are important!

-We have OpenGL on charts and Impress ! How cool is that!

-Unit tests ar……… *cough* *cough*…

 

Here are some pictures I took with my cellphone. So they are potato quality photos.

https://plus.google.com/photos/115301608275454477024/albums/6055704218280733569

If you don’t like your presence on the photos contact me so I can delete it if you want.

 

Thanks everyone! Stay awesome!

I’d like to share the slides I used for my talk at LibreOffice Conference 2014 in Bern, Switzerland.

During my talk, I hinted that the number of unit tests for Calc have dramatically increased during the 4.2 bug fix cycle alone. Since I did not have the opportunity to count the actual number of unit test cases to include in my slides, let me give you the numbers now.

	ucalc	filters	subsequent-filters	subsequent-export	total
4.1	65	10	49	9	133
4.2	107	13	54	15	189
master	176	15	67	34	292

The numbers represent the number of top level test functions in each test category. Since sometimes we add assertions to existing test case rather than adding a new function when testing a new bug fix, these numbers are somewhat conservative representation of how much test case we’ve accumulated for Calc. Even then, it is clear from this data set that the number has spiked since the branch-off of the 4.2 stable branch.

Now, I’ll be the first to admit that the 4.2 releases were quite rough in terms of Calc due to the huge refactoring done in the cell storage structure. That said, I’m quite confident that as long as we diligently add tests for the fixes we do, we can recover from this sooner rather than later, and eventually come out stronger than ever before.

Change Image in Writer

Thanks to Jennifer Liebel, writer now has a change image option in its graphic context menu like Impress/Draw.

Some of our community people already wrote some good reports about this awesome conference, but please let me add some with my poor English ;).

Bern is small but really beautiful city with the quite nice river (as a kayak lover, I checked the river), and University of Bern, which is our venue, is also nice.
Every food provided local crew was so yummy (especially cheese in sandwiches), and "hacker's energy" drink!  I love it.

All of the talks really excited me, and everyone who I met was so kind.  Really nice community, I love all of you!

Thanks to Kohei and Kendy, I had an opportunity to do a lightning talk.  Here is my slide.
<iframe allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/38827118" style="border-width: 1px; border: 1px solid #CCC; margin-bottom: 5px; max-width: 100%;" width="427"> </iframe>


Thanks you, and see you next year!