My WAC700′s hard drive died a while ago, and my efforts to find a disk image I could use to clone a replacement didn’t pan out, leaving me with three useless WAS700 stations which I wanted to reuse as generic stations playing back from a software ps3mediaserver solution. But the blasted stations were configured to use some now long-dead wifi configuration I wasn’t using anymore and they need the station in order to be reconfigured to use a new wiki config.

This thread looked promising, but no success

On the other hand the source for the WAC700 is available from philips, so with a bit of digging it turns out the WEP key for the WAS700 ad-hoc installation mode network WASC700-INST is PHILIPS123XYZ and not Philips123ABC or PhilipsABC123

With the right key, then the WAC700 emulator works wonderfully to reconfigure the stations, and then they can easily find and playback from the ps3mediaserver via auxillary input->select server.

—
1. wget http://www.p4c.philips.com/files/w/wac700_05/wac700_05_osf_eng.tgz
2. tar xf wac700_05_osf_eng.tgz
3. strings src_release_r4258_6720_1.2.10_en/linux/work/has/appfs/resources/fpm_firmware/20060221_was5_code_IVT1.2.10_release.rom|grep PHILIPS

Well I’ve procrastinated doing stats for March (and now I’ll be behind in April as well) – but I opted to do a quick post about our unconfirmed bugs right now. Quick overview of Jan 15th – April 27th. I pulled bugs *almost* every day. In my opinion our biggest duty as QA is to keep the unconfirmed bug count down and try to tackle triaging bugs as fast as possible. While we continue to press towards this goal the increasing number of users – and more specifically users who are willing to report bugs – continues to challenge our small QA team but, these stats highlight just how great our team is and continues to be. Tremendous thanks to each one of you who even take a few minutes out of your busy days to triage a bug or two.

Without further delay:

Between January 15th & April 27th 3,002 bugs were reported – I’m serious, no lie, over 3,000 bugs reported! Thanks (partly sarcastic?) to our fantastic users for reporting problems when you find them. This period covers 103 days (so about 29 bugs per day reported). Just maintaining our unconfirmed count would have been a tremendous success…..but, WE DID BETTER!

The week # is determined by Spreadsheet’s “WEEKNUM” function, the last pull of the week is the # of bugs on the right.  As can easily be seen we DECREASED the overall UNCONFIRMED bug count by 101 bugs in 103 days – so putting the numbers together (number reported – (net change)) we get a whopping 3,103 bugs triaged during this period!

Truly incredible, again, thank you all for your hard work

We’ve now reached 200 dialogs and tabpages converted from LibreOffice’s classic fixed widget size and position .src format to the GtkBuilder .ui format. These are still our own widgets, we just reuse the file format and map the Gtk widgets to our own equivalents. I’ve now finally refreshed the original sample screen shots to reflect the current reality.

I estimate we require an additional 200 to 400 .ui files, unless a lot of the existing .src dialogs turn out to be orphaned dialog descriptions that are not in use. (This is unlikely)

The How to conversion guide is still relevant, and help is appreciated.

Additionally, there’s a short list of selected dialogs awaiting review for any HIG compliance issues or general layout improvements. We have a python script as ./bin/lint-ui.py (thanks leighman) to check for basic compliance with guidelines, but there’s room for improvement, e.g. checking that widgets have mnemonic widgets, etc.

Spending part of my time to LibreOffice QA, I look over the web page displaying all the commits for LibreOffice code (1) from time to time.
The last months, I saw an large amount of commits related to ‘Coverity’. I remembered that name from years back, in the old OpenOffice.org project.
To explain: Coverity is a project that runs all kind of automated code checks, discovering typical but often hidden programming errors. Memory leaks, but also errors that may cause little, not so often encountered errors for the users. The reports from Coverity are a valuable contribution to – among others – the LibreOffice development process.

The work on using the Coverity reports for LibreOffice is done by a variety of LibreOffice developers, some on the building and testing, others on the other work to fix the issues. In the first months many hundred improvements have been made, making LibreOffice more robust, better. There are still some few thousand issues left however So pls get in contact if you like to help with these improvements.

Again it’s lovely to see that core and volunteer developers work together to get thousands of improvements in the LibreOffice code.
Of course in this special case it only can be done with to the work of the Coverity team, that helps open source projects to become more stable and improve quality. Thanks a lot for that!

The trigger of this event

"How about hosting LibreOffice Conference in Japan in the future?"

"Yeah, but we have less experience, so we should start from smaller events."

"Debian-JP people now start to grow their experience with annual whole-day event to have a miniconf in the future, and to host a DebConf.  We should follow their way."

"I hope we'll have Japanese ODF plugfest in here, Aizu-wakamatsu. Because here is a special place.'

The e-mail had come

"Meisai Univ., the place next OSC Tokyo will have, have enough space to do something each communities separated by OSC.

No rent fee is needed.  You need nothing about venue because everything about venue is by OSC organizer.  But you have to gather attendee by yourself and OSC organizer have no responsibility to advertise your event, because your communities events are totally different event with OSC itself."

Pros.

• OSC is most famous event series in Japanese FLOSS world, so lots of people come here.
• We had attended OSC Tokyo at Meisei Univ., so we already know how about projection system, power sources, and so on.
• Nothing contract, nothing fee we need.  It makes entry level low.

Cons.

My work ... publication

We succeeded or ...?

After the success of the LibreOffice Impress Sprint in Germany last month, we are very happy to announce the first LibreOffice Bay Area Meetup. It will take place on May 11, 2013 starting at 2pm in the Hacker Dojo in Mountain View, California. Simon Phipps and Bjoern Michaelsen will be there and have some hopefully interesting topics prepared:

• “Foundations and Empires” (Simon)
• “LibreOffice, the Document Foundation, the universe and all the rest” (Bjoern)

We will also have time for some good Q&A, and most importantly: some hands-on work on how to get involved in the project.

We are excited this was made possible in collaboration with the friendly local folks helping us out here (notably and among others: Mike Higashi, Geo Mealer and Alison Chaiken) and hope to meet and greet many of you there.

You are invited, please consider dropping us a note here!

Continuing the previous post about commits and bugs, I’d like to review some mistakes I saw recently. Mistakes do happen, but mentioning them here is meant to teach others and hopefully to reduce similar ones in the future. This post isn’t about shaming the authors/commiters. Also, the points I highlight are what I consider as a mistakes or problems, other people might think differently.

1. Mentioning two bugs in one commit message, which our system doesn’t support right now. So the second bug doesn’t get the commit notification, and that should be done manually (example: commit 2933935 and fdo#53278).
2. Referencing gerrit changes as part of the commit message (example: commit 87f185d). Giving references as part of the commit is great and helpful, but I would prefer to see the reference to the actual commit and not to its review process. This is meaningful when you search the log. If the followup change is suggested when the first change is still in review it should be combined, otherwise it already have a commit to reference.
3. Following up a commit, and not mentioning the bug it references (example: commit 87f185d). In this specific case, the we’re talking about a meta bug for translating comments from German to English (fdo#39468), so no harm done. But this important when you want to cherry pick a fix for a bug to other branches and might forget the follow up commits. It’s also relevant to more technical meta bugs (example: fdo#62096).
4. Referencing a mailing list which reference a commit and a bug instead of referencing them directly (commit 21fea27, fdo#60534). This bug shows very well why correct referencing is important, a commit was made to fix the bug, a follow up commit was done without proper reference, and than the first commit was reverted. No one involved in trying to fix that specific bug knew about the follow up commit as it wasn’t documented anywhere.
5. Referencing bugs though full bug URL instead of the right format (example: commit e1f6dac). Also the bug is referenced in the commit in the body of the message instead of the first line (header) which is more visible.
6. Referencing non existing bugs (example: commit 3a4534b). Which got a manual notification in the bug by the comitter (fdo#33091).
7. Using shortening services URL as part of commit messages (example: commit 86f8fba). There’s no way to know to what the reference is without using the service, which in this case was leading to a post on one of the projects mailing list. There isn’t any problem giving the direct URL to the list’s archive. It’s interesting whether we should link to our URL and is it “OK” to use other external services who also archive our mailing lists (example: commit e83990a).

To conclude, having references in commit message is really helpful, but please reference the right resource to help people find it easily and to let our automated services parse it.

The basic cue to the provided function of unlabeled controls are tooltips. We recommend to define naming conventions to make those tips meaningful.

Naming Convention

Suitability for learning and self-descriptiveness, two of the basic usability goals, depend largely on the information users can read directly. Most graphical user interfaces use toolbar buttons to provide access to core functions. Those buttons usually contain an icon but no caption. The function is revealed by common sense (left most icon provides New), iconic depiction (a floppy points to Save), and tooltips that are shown when the mouse hovers the control. Obviously the latter are most important and it’s a good idea to have conventions for these labels.

It has become apparent that some of Libreoffice’ toolbar buttons provide confusing and sometimes misleading tooltips. Better labels would not only support learnability but also help to solve some of the mix-ups we found, e.g. in the case of the Navigator. It is common practice to name English functions starting with a verb followed by a noun or adverb. But take care with localization: different languages might have a different grammar! For instance, in German a verb-noun sequence has a strong imperative connotation and it’s better to have noun-verb labels. Anyway, the functions in each languages should be labeled consistently with the specific grammar in mind.

Recommendation for Libreoffice functions in the standard toolbar

We recommend to label all functions starting with a verb followed by noun or adverb (in case of English). Text should be concise, helpful, and easy to read. If the function can be started by shortcut it is added to the text in parentheses. Normal shortcuts combine the control-key (Ctrl) with a letter; the use of simple function keys should be avoided.

¹ It should be considered to remove this function from the standard toolbar

² Some functions need redesign, e.g. toolbar buttons must not get ‘overloaded’.

Conclusion

Functions should be labeled in a definite and unified way. Well named functions help users to understand the program and to learn how to use it efficiently. Convention for labels should be defined depending on the localization.

What do you think about these suggestions? Do you agree?

Metaphors determine the association between a function and its icon. But sometimes these metaphors are misleading or ambiguous. With your help, we want to improve the metaphors used in Libreoffice.

What has happened before

Metaphors are the basis of any good icon design. For instance, scissors are used to cut something and this metaphor fits perfect for the respective computer function. On the other hand, it is rather difficult to associate a filing cabinet, for example, with the function Save.

There are different ways for improving the usability of a specific function and its respective icon. Depending on the problem one might change the label, change the icon to be more obvious or change the underlying metaphor altogether.

As we compiled the results of our last study, it became apparent that some metaphors of Libreoffice’ standard toolbar do not work in their intended way. Our next step is to prepare new icons based on stronger associations between the underlying function and its graphical representation.

What we plan to do

As a starting point we selected the functions that have room for improvement and investigated alternative metaphors user could associate with these functions. We tried to be creative in our vantage points and also incorporated some of the ideas you had when you commented on our previous articles.

We selected ten functions, that need improvement and created a few alternative metaphors for each of these functions. These are partly from the original, natural pendants of these functions, partly from associations found in cultural and historical contexts and partly from connotations we had for the word, i.e. the function itself.

The function undo could for instance be represented by the metaphor ‘correction fluid’, because both the function and the metaphor erase the last written words. Of course, undo does more than that, but the core functionality might be better represented than with the depiction of a clipboard as it is today.
The metaphors we are searching for do not have to be perfect. We are rather in brainstorming mode and ask for your support, because everyone will have different things in mind when hearing about a certain function. Additionally we want to compare as many different solutions as possible. Also we need some distractors in between to evaluate the strength of the association.

The ten selected functions with their original metaphor in LibreOffice Writer and some examples of the metaphors we created are listed below.

function	original metaphor	example	suggestions
New document	document	egg	explosion sprout on/off sign
Save	floppy Disc	piggy bank	lock purse HDD downward arrow
Copy	two documents	RAM unit	key C copy machine x 2 arrows from a node
Paste	clipboard+Document	glue	key P pinned document tooth paste puzzle pieces
Undo	anti clockwise arrow	clock backward	correction fluid bin washcloth eraser
Redo	clockwise arrow	reversed bin	sisyphos’ rock clock forward pyramid caged animal
Format Paintbrush	brush	palette	stylised As clipboard+T brush+wrench
Page Preview	magnifier+printer	glasses	washing mashine magnifier + document
Navigator	compass	sitemap	road sign navigation device document with headings
Hyperlink	chain links	globe	spider ‘WWW’ underlined blue ‘link’

We need you!

Every function should have at least four good alternatives. This is where you come into play. Please help us to improve the study with your ideas for alternative metaphors. These can be quite diverse and from different contexts. So every input is appreciated.

Once we have found sufficient metaphors for each of these functions we need to create icons to these metaphors that fit in one icon set. And at this point we need your assistance again since we are not designers but usability experts. Icons should be redesigned to not have any biases because of the color, style, etc. It does not need to have a really fancy design with 3D effects or the like. But the layout must not influence users decision which one to choose in the upcoming test.

In this final study we will present these icons and users decide which of the icons / metaphors is fitting best to the function. This way we hope to find unambiguous metaphors that solve the mix-ups from the LibreOffice study and that most likely can also be found in other applications.

Summary

Can you think of other metaphors for these functions? Do you have any suggestions concerning our approach? If you are a designer, or know one, who would like to help us in creating these test icons, please contact us.

At SUSE, we recently had a Hackweek. It’s one week for all developers employed by SUSE to hack on any innovative open source project they want. Last years, I worked on libcmis and libcmis-c. And this year, I started implementing a GVFS backend for CMIS using libcmis-c. GVFS is the one of the low-level layers of GNOME to access files. A backend is a set of features like mount, unmount, read a document, writ a document, navigate in folders, etc. Currently GVFS has backends for FTP, SSH, WebDAV, Trash, Audio CDs, and quite a lot of other useful things. Having a CMIS backend would allow any Gnome application to access documents stored on a CMIS-enabled server.

What I achieved in one week:

• mount and unmount a CMIS repository
• read a document
• provide the content of the folders and repositories
• provide some of the CMIS properties

To have a complete backend to upstream, I will need to implement:

• creating / writing files
• deleting / moving items
• creating folders
• setting properties

The code can be found on a gvfs git clone in my freedesktop home. I wan to thank the Gnome hackers who kindly answered my beginner questions during this week.

Hyphenation in cells and shapes was fixed a few days ago for Catalan (for example, paral·lel » paral-lel, instead of parall-lel), Hungarian (eg. asszonnyal » asz-szony-nyal instead of az-szoy-nyal) and Dutch (eg. omaatje » oma-tje instead of omaa-atje, cafeetje » café-tje instead of cafeét-je). Swedish, Norwegian and partly Dutch need only hyphenation dictionary extension to support non-standard hyphenation in LibreOffice, Greek and Dutch need also Writer and Calc/Draw (editeng) development to support the alternation after the hyphenation break. More information: bug 63711 (closed), bug 42383 (open), Hyphen library (see tests/unicode.* example for non-standard hyphenation patterns of Dutch, Greek, Norwegian and Swedish).

I have been working recently on finishing the work on a python script for Libreoffice that automatically imports documents and tests if we crash there. The plan is to run this script automatically against all our bugzilla documents on a regular basis.

I have been running similar tests for calc files(the TEST_BUG_FILES) case already before the 3.5 and the 4.0 releases and fixed these crashes with Eike and Kohei before the releases. However this work was done half manually inside of an “unit” test and as soon as it crashed I had to restart the test. As a result of this complex setup it took me between 4 and 6 days to import all 6000+ calc documents. Back then I already had the idea that this task could be automated and moved to a TDF server.

I already tried to convince someone at the Munich hackfest to write such a script as an Easy Hack but had to wait till December until Joren picked up the task. Based on convwatch.py he implemented the first version that has undergone several iterations now and can be found in the Libreoffice dev-tools repository. The script is still looking quite ugly as I have been only adding code and it still contains a large number of debug output for me but the current version should work fine against current Libreoffice master.

After several toolchain problems, one needs a libstdc++ created with at least Linux binutils 2.23.52.0.1 or newer, I finally published the results of the current test run at the Libreoffice developer mailing list. In my latest test run I had a collection of a bit more than 24500 documents with the file extensions cdr, doc, docx, fodg, fodp, fods, fodt, odg, odp, ods, odt, ppt, pptx, pub, rtf, vdx, vsd, wpd, xls, xlsx. While 60 crashes might sound like a lot one has to remember that many of these crashes will never be seen by users. The test is run with a dbgutil build which means that we enforce the exception specification, we switch the standard library to the gcc debug library which has additional assertions and some crashes are related to the special set up of the test. Nevertheless we are planning to fix all these crashes and use the script as part of our automatic testing.

And finally a special thanks to the amazing Libreoffice community who was incredibly supporting in realizing this crazy concept.

Some of the icons of LibreOffice are confusing. Based on the findings of our last study we present some quick and easy changes that improve functionality.

Introduction

In this article we want to provide suggestions to solve some of the mix-ups that we found in our LibreOffice icon test. We examined the standard toolbar icons of LibreOffice Writer. Over the past few weeks we published a few articles, where we discussed some of the more striking outcomes of the test. On the basis of these findings we derived guidelines for creating icon metaphors in general and some long term ideas to design new icons  for Libreoffice. Now we want to present our recommendations for quick fixes to some of the problems and mix-ups that we found.

General advices

A toolbar is primarily used for fast access to frequently used functions. Additionally, it provides an overview of core functions and hence helps users to operate the software efficiently. It’s always a challenge to find a good balance between both requirements and to avoid clutter in the toolbar. We recommend to double check the usage not only by the developers but also with users.

Furthermore, every structure that can be added to the toolbar is beneficial. While the main menu allocates all functions in categories the toolbar only provides small separators. Functions that belong to the same category should be placed together. Different categories have to be separated. If possible those categories should be supported by different wording for labels, e.g. ‘Show’ for sidebars and ‘Open’ for dialogs. And, last but not least, icon design should consider to adopt categories, as done with color codes for mime types for instance.

In the following we present recommendations to remove functions from the toolbar in order to reduce clutter.

Page Preview

Term	Tango	Oxygen
Page Preview
Print File Directly

Both Page Preview and Print File Directly have basically the same icon except that page preview has a magnifier / eye over the printer and Print File Directly has a lightning bolt (only Oxygen) above the printer. It could be assumed that the differences between the icons are too little and hence cause the mix-ups we found. On the other hand Page Preview gives a full overview of the current pages and allows to adjust the margins for the finished papers. This is always useful before printing, so Print File Directly could be integrated into the Page Preview view to improve functionality and reduce clutter.

Spelling and Grammar

Term	Tango	Oxygen
Spelling and Grammar
AutoSpellCheck

Again Spelling and Grammar and AutoSpellcheck use almost the same icon. Therefore there are a lot of mix-ups. Spelling and Grammar opens a wizard and suggests different spellings for a single term. AutoSpellcheck toggles the marking of words that might be wrong and offers alternatives via a right-click. By the same drop down menu the function Spelling and Grammar can be accessed for more information. We suggest to remove Spelling and Grammar from the toolbar, as it is can easily be accessed by other methods.

Format Paintbrush

Term	Tango	Oxygen
Format Paintbrush
Show Draw Functions

As discussed in ‘What is a pencil used for?‘ these two icons are often mistaken for one another. Format Paintbrush can copy the formatting and apply it to different areas. The function is not accurately named and the icon metaphor does not associate well with its function. We recommend changing both the name of the function and the icon metaphor. Show Draw Functions could then remain unchanged.

Data Sources and Gallery

Term	Tango	Oxygen
Data Sources
Gallery

Data Sources and Gallery are seldom used functions in LibreOffice that get mixed-up quite a lot. Data Sources is a function that allows access to databases, such as LibreOffice Base. Our Motifs of LibreOffice User-Study showed that only very few users make use of Base. Gallery can be used to insert media from different ‘themes’ into the document (maybe it would be easier to just insert the specific media manually instead of first adding it to these themes). Both functions should be removed from the standard toolbar.

Navigator

Term	Tango	Oxygen
Navigator

Navigator is another seldom used function. This might be due to the fact that its label is not quite feasible. An alternative might be ‘Show Document Structure’ (see Naming Convention). The metaphor behind the icons is a compass, which is fitting for the label Navigator ,but not for its function. The name of the function and its metaphor should be changed to improve usability.