LibreOffice MUFFIN risks being half-baked

Off the Beat: Bruce Byfield's Blog

Dec 26, 2016 GMT
Bruce Byfield

On December 21, The Document Foundation announced that LibreOffice 5.3 would include MUFFIN (My User Friendly FLexible Interface) -- a feature for configuring toolbars that includes an option similar to Microsoft's Ribbon toolbar. With its emphasis on choice, MUFFIN is being well-publicized, although one documentation did worry that it would require LibreOffice's manuals to be completely re-written. However, while I like choice as much as anyone, while investigating I found MUFFIN an over-hyped and misplaced effort that is right in the middle of an old controversy in office suites.

To start with, when I enabled MUFFIN from Tools > Options > LibreOffice > Advanced > Enable Experimental Features and rebooted, I found that three of the four configurations could already be obtained by selecting from View > Toolbar. The real news was the fourth default, the highly-configurable Notebook Bar, which resembles Microsoft Office's Ribbon Bar.

The trouble is, as even The Documentation Foundation admits, limited space means that the Notebook Bar means the removal of a few features, including Find and Replace, Spellchecking, Non-Printing Characters, Insert page breaks, Fields, and Special characters. Maybe as a writer, I take word processing too seriously, but that seems a high price to pay for more configurability. Even though I can add the missing features that I need, the end result will only be what I already have with the standard setup. Even beginners, the intended audience for the Notebook Bar, would be better off being able to see the complete feature list from the start.

True, a poll conducted by OMG! Ubuntu! as part of its coverage of MUFFIN shows the Notebook Bar is favored by 57% of those taking the poll, opposed to only 16% who favor the existing Default toolbar. However, a design decision being spun as a matter of choice is always going to be popular, and I'm guessing that most of those who replied to the poll did so without actually trying the Notebook Bar. Whether the vast majority would even bother to try it might be another matter altogether.

Style vs Overrides
However, what bothers me most about MUFFIN is the statement in the announcements that software must adjust to the users, instead of the other way around. Obviously, software should be as intuitive as possible, and no harder to learn than absolutely possible, but MUFFIN goes too far in the opposite direction. No matter how many efforts are taken to make LibreOffice user-friendly, as with any software, a certain irreducible logic is built into LibreOffice, and, at a certain point, a user must learn that logic if they hope to use it with any expertise.

Specifically, LibreOffice -- to a far greater extent than Microsoft Office -- is built around the concept of using styles, setting a group of formatting choices once, and then applying it as needed throughout a document. Later, if you want a similar document, you can use the original as a template, and use the styles all over again.

By contrast, toolbars are designed for manual formatting. By that, I mean, they are for the use of those who use a word processor as a typewriter, formatting each place where a feature is needed one instance at a time. This approach is adequate for a document of a few pages, or one than will only be used once, but in general it is slower and more inefficient than setting up styles.

In the introduction to my book, Designing with LibreOffice, I compare manual formatting to using a car for coasting downhill and braking by dragging your feet, and never realizing that the car has an ignition and a brake you can use. It does its job after a fashion, but makes everything more difficult than necessary.

Yet manual formatting is exactly what toolbars encourage. The four MUFFIN defaults -- including the Default toolbar -- emphasize manual formatting, although styles can be found here and there. None of them, though, result in a toolbar oriented towards formatting with styles. And a Ribbon-like toolbar, with its omissions, is the worst choice of all for using styles.

Bringing choice to the toolbars is a popular endorsement of user preference. But it encourages inefficient habits -- and to my way of thinking, that does users no favor. Nothing would be wrong if styles were given equal time, but as things are, the availability of MUFFIN means that many users are unlikely to discover features that would make their work easier. Since the Default remains the same, there are other aspects of LibreOffice that should have higher priority than the toolbars displayed.

Documenting it all
I admit that, as a writer about LibreOffice, I have a personal stake in this issue. My book is mostly about styles, and would be next to useless if I ignored them. Nor do I desire to write each procedure once for every default toolbar, even if I could.

Fortunately, there is a tradition for such a problem. Instructions about software have always had the tradition of describing actions primarily in terms of the menus. Toolbars, sidebars, and keyboard shortcuts take second place, if they are mentioned at all.

I don't know how LibreOffice documenters plan to approach the problems presented by MUFFIN, but I plan on describing most situations in terms of the Default toolbar. I have no particular love for the Default toolbar, and would welcome improvements to it, yet it is the only one that includes all available features, and I do not see that changing. If people learn from the Default toolbar, then they can branch out into other options with the advantage of knowing what features are available.

LibreOffice, with its frequent releases, is always a moving target for those who write about it, and trying to cover MUFFIN thoroughly can only compound the difficulty. Restricting coverage to the standard interface will help both writers and their audiences as well.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More