Community Week: Design – get involved

LibreOffice Community Weeks

Earlier this week we talked to Heiko Tietze, LibreOffice’s user experience (UX) mentor, and then looked at some of the changes that the Design team has made in recent releases of the suite. You’ve seen that even the smallest updates to the interface can have a significant effect, and the Design team is always looking for new ideas and contributions. So read on to learn how you can get involved and make LibreOffice better for everyone.

1. Check out the design guidelines

When new features are added to LibreOffice, the Design team works to ensure they fit into the guidelines. These guidelines are part of an overall vision for LibreOffice on the desktop, which is: “Simple for beginners and powerful for experts”. Making software that appeals to both type of user is a challenging task, as workflows can vary so much. But if you read the UX manifesto you can see how this is achieved.

2. Submit bug reports and suggestions

Have you found a user interface bug in LibreOffice, or an issue that violates the guidelines? Learn how to submit bug reports so that the Design team can investigate them and work on fixes. Alternatively, if you have a suggestion for improving usability in the suite, you can submit an enhancement request on the bug tracker. Of course, the more detail you provide, the better: saying “Feature X is hard to use” isn’t helpful, but “Feature X could be improved by adding Y to Z or moving A to B” is much better. And you could even add a mock-up to show how you think an improvement would be implemented.

3. Start communicating

The Design team is active on social media, with a Twitter account, Google+ page and blog. Some activity takes place on the #libreoffice-design IRC channel on Freenode (webchat link), but it’s also worth signing up to the mailing list. Don’t miss the weekly Hangouts meetings on Friday – see here for details and minutes of the last meeting.

So with October coming to a close, that’s it for the Community Weeks! We hope you enjoyed reading about the different teams and projects involved in LibreOffice, and got a sense for what they all do. Most of all, we hope you’re encouraged to get involved – not only would your help be good for LibreOffice and free software in general, but participating in a well-known open source project is also good for your CV and future career. So join us!

Community Week: Design – recent changes, and communication

LibreOffice Community Weeks

On Monday we talked to Heiko Tietze who is LibreOffice’s user experience (UX) mentor, and today we’re going to look at some changes that the Design team has implemented in recent releases of the suite. You can see how new features are implemented to make them accessible without drastically changing the overall design of the software.

Single toolbar mode

In LibreOffice 5.2, Writer and Calc received new single toolbar modes. These provide alternatives to the default double toolbar configuration, and save screen space while helping users to really focus on their work. Click here to see the initial discussion and mockups that led to this design change.

Currency drop-down button

Here’s an example of a user interface change that barely takes up any screen space, but has a big impact on overall usability. Before LibreOffice 5.2, a single toolbar button was available for setting a currency format, but this button now has a drop-down menu to change between currencies. This only adds a few pixels on to the width of the toolbar, but it means users can quickly switch currencies without having to go into the menus.

Fine-tuning control points

It’s often useful to add multiple ways to achieve something, providing they don’t add clutter or too much redundancy. Take working with enhanced shapes, for instance: before LibreOffice 5.1, users customised shapes using the mouse on yellow handles and control points. But after 5.1, it’s possible to manipulate the exact positions of those control points with numbers. So some users will still prefer to do it manually with the mouse, but those who need exact position have the option as well.

Spreadsheet function tooltips

Some user interface changes aren’t just about making features accessible or speeding up workflows, but also making the software more intuitive. LibreOffice 5.2 introduced tooltips for functions in Calc, so that users can get a quick overview of what they do whilst typing them. This helps newcomers to get familiar with the software and reminds experienced users of what a function does without having to go through the help system.

 

Feedback from the design team – and have your say

The Design team strives to communicate its changes clearly and effectively to the wider LibreOffice community, and maintains a blog for this purpose. So if you’ve ever spotted a difference in the user interface between LibreOffice releases and you’re not sure why it happened, it’s worth reading the blog to get an explanation.

For instance, here are some recent blog posts describing the background to changes in recent and coming releases:

The blog is also used to propose changes and get feedback. If you have an opinion on something, let the team know in the comments! Here are some recent posts:

That’s it for today – join us on Friday when we’ll show you how to get involved with the Design team and help to make LibreOffice’s interface better with every release.

Presenting LibreOffice Telegram channel

telegram_logo_smallFollowing the success of the LibreOffice Conference Telegram channel, we have asked our community – through an informal poll on the Telegram channel itself – if they wanted to keep the channel alive and change the name to LibreOffice Community. The feedback has been overwhelming, as 21 out of the 22 answers have been positive.

We have therefore changed the name of the Telegram channel to LibreOffice Community, and made the channel public to allow everyone to subscribe. The link is the following: https://telegram.me/libreoffice. To widen the reach, the channel is bridged to the #libreoffice-telegram IRC channel on Freenode. Please be aware that the objective of this channel is to share information and experiences amongst community members, and not to support end users.

End user support, as well as other strategic activities for the project, will continue to be managed through the current channels. For end user support, the different options available are listed here: http://www.libreoffice.org/get-help/community-support/.

In addition to the discussion channel, we have also opened a Telegram broadcast channel, which will be used to increase the reach of our announcements: https://telegram.me/tdforg. This channel will be used to broadcast announcements, and therefore will have a very low traffic.

Community Weeks: Design – meet the team

LibreOffice Community Weeks

We now come to our final Community Week for October 2016, and this time we’re talking to the Design team. Design is an essential aspect of LibreOffice development, and it’s sometimes tough to find the right balance: some users want the interface to change rapidly with each release, whereas others are more conservative and prefer an incremental approach. When new features are added to LibreOffice, they must be made accessible and easy to find, but not interfere with the workflow of experienced users.

The Document Foundation, the non-profit entity behind LibreOffice, has a dedicated user experience mentor: Heiko Tietze. He works with the Design team to research and implement user interface improvements, trying to take into account the needs and wishes of as many users as possible. We caught up with Heiko to see what he’s working on at the moment…

Heiko Tietze LibreOffice developer

What is your role in the Design team?

I’m the user experience (UX) mentor and my role is to support and facilitate work on the user interface (UI) of LibreOffice – how it looks and behaves. This includes giving my advice on Bugzilla tickets with the needsUXEval keyword, conducting surveys and quick polls, working on and publishing proposals on the design blog, managing weekly design meetings, defining human interface guidelines (HIG), creating prototypes, etc. In general, my task is to get more people involved.

How did you first get involved with LibreOffice?

In the 1990s I studied psychology with a focus on methodology and statistics. Scientific experiments typically end up with a mass of data, so getting familiar with programming is a big plus – which brought me towards usability. Some years ago I volunteered with a couple of tests about the icons used in LibreOffice.

Later on this moved forward to more advanced studies on how users deal with the product and what they expect (find all blog posts here). And finally The Document Foundation made a tender last year for a freelancer for UX and design work, and I was picked for it.

What does your typical workday look like?

Usability is about users, so basically I observe, talk, interview, watch videos, and read comments to get an impression of what our users need. My day starts with reading emails – typically a lot come in from the ux-advice mailing list. Commenting can often take some time when a ticket is not clear in respect to the workflow.

When working on a new UI design I start by researching the issue and collecting all the requirements first, and then I scribble mockups that follow our principles of simplicity, consistency, and ease of use. While this might sound straightforward, it isn’t always so. Usability is an iterative process where everything needs to be discussed and improved repeatedly. If you want to learn more about the work of the design team read “How we work” on the wiki.

What areas in Design are working well, and what needs to be improved?

Regarding the team, we are doing pretty well in my opinion. There is always room for improvement and we need to be faster with decisions on UX-related tickets. But that’s how open source works, slowly. And regarding the application, I believe we need to improve on simplicity and clear concepts. There are numerous functions for special workflows that hinder beginners. And on the other hand we have a lot of hidden gems that even experts never use.

Who else is involved and what do they do?

The design team has many contributors who are experts from different areas including members of the development team. Some spend a lot of their spare time committing patches for menus or UI files, while others work on small aspects such as visual design or icons. Find a list of members see this wiki page.

How can regular (non-developer) LibreOffice users help out?

Everyone is an artist, and everyone is a user. The simplest way to contribute to LibreOffice is to file bugs and submit enhancement requests to our bug tracker. For those who want to do more, we have tasks for the very beginner (eg assign nice names to colors, create custom shapes), for experienced UX/UI designers (eg revamp the bibliography dialog), and for advanced developers (typically Google Summer of Code students). On our wiki we list the topics so everyone can get an impression about the demands: click here for all the details.

Finally, we’re currently running a survey asking users how LibreOffice should handle missing fonts. It would be great if LibreOffice users could read the survey and choose whether they like the change or not in the form at the bottom.

Thanks Heiko. Coming up later in the week, we’ll explore in further detail what the Design team does, and show you some more ways to get involved.

Community Week: QA – get involved

LibreOffice Community Weeks

Earlier this week we talked to LibreOffice’s quality assurance (QA) engineer, Xisco Fauli, about how the QA team works, what they’re involved with at the moment, and where they need help. Let’s now look at how regular LibreOffice users can get involved: even if you can only spare a little bit of time each week, you can really make a difference to strengthen and improve the software.

LibreOffice’s QA team is comprised largely of volunteers. The team works through bug reports submitted by LibreOffice users, checking them for accuracy, reproducing them (where possible), and assigning them to the appropriate developers or projects.

Reporting bugs

Bugzilla is used for tracking bugs, and it’s a very versatile tool that may look a bit daunting initially. But once you’ve submitted a couple of bug reports it becomes easier to work with. To submit a bug report, you need to be logged in there – so click “New Account” at the top to set up an account.

Now, let’s say you’ve found a bug in LibreOffice and want to report it. The process goes as follows:

  1. Click New at the top of Bugzilla, choose LibreOffice, and you’ll end up on this page
  2. Many bugs have been reported multiple times already, so scan through the list to check your issue isn’t already being dealt with
  3. Also, try typing some keywords associated with your bug (eg “docx import” or “PDF crash” in the box under the list, and click “Find Similar Issues” to check if someone else has submitted the bug already
  4. Otherwise, click “My issue is not listed” and fill in the form
  5. Provide as much information as possible: the component of LibreOffice affected (eg Calc), what hardware you’re using, and LibreOffice version
  6. Provide a short summary and detailed description with as much useful information as possible
  7. Add steps to reproduce, the results you get, and what you expected
  8. For the “severity” part, only choose a high ranking if it’s extremely serious (like, it can cause major data loss

Once your bug has been submitted, a member of the QA team will check it and ask for more information if required. Also see this page for more information on submitting good bug reports.

Confirming and triaging

But what happens if you bug has already been reported? It still helps the QA team if you confirm it as well, especially if you’re using a different operating system or version of LibreOffice. In that way, the QA team can narrow down the cause more quickly. So it’s worth taking the time to confirm even if a bug report from someone else already looks detailed enough.

If you’d like to get more involved in the QA team, maybe to build up experience for a future career in QA, you can help by triaging bugs. This is the process of confirming and prioritising bugs so that developers know what to work on. As it’s a large and complex piece of software used by tens of millions of people, LibreOffice receives many bug reports, so it’s important that they are organised correctly.

Then there are Easy Hacks you can help with, which help the QA processes and team. These vary from improving the QA infrastructure to more creative topics like making a video to assist newcomers. Have a look at the page – something is bound to take your interest!

 

Join the Bug Hunting Session

On Friday October 21, from 08:00 UTC to 22:UTC, a big testing effort to fix bugs in the upcoming LibreOffice 5.3.0 release will take place. There are many new features in this next version of LibreOffice, so your assistance in making it rock-solid is very much appreciated. Here’s how to get involved:

See the wiki for more information on the Bug Hunting Session – and thanks in advance for any help you give. Millions of LibreOffice users around the world will benefit from your efforts, and free and open source software on the desktop will keep getting stronger!

Community Week: QA – meet the team

LibreOffice Community Weeks

Having covered development and documentation, we’re now into our third LibreOffice Community Week: Quality Assurance (or just “QA” for short). QA is an essential element of the LibreOffice development process, and affects the suite in many ways. For the benefit of end users, QA helps to identify and fix bugs – whether they’re glitches in the behaviour of the office suite, or problems that arise when importing certain files, or just issues with the user interface.

But QA is an integral part of new feature development as well. When a LibreOffice developer adds something new to the office suite, QA processes ensure that it doesn’t impact other features, and that the rest of the software continues to be stable and robust.

LibreOffice has an active QA community that works on tracking, reproducing and fixing bugs, and The Document Foundation (the non-profit entity that backs LibreOffice development) recently hired a dedicated QA engineer, Xisco Fauli. We caught up with him to see how the QA process works and how newcomers can help out.

Xisco Fauli LibreOffice developer

What is your role in the QA team?

My role is to act as a middle-man between the QA community and other teams, such as participating in the Engineering Steering Committee (ESC) meetings for instance.

I’m also in charge of organizing the QA meetings, which take place every other Tuesday, and organizing the bug hunting sessions, the next one being on Friday October 21 for LibreOffice 5.3 Alpha. I also spend time maintaining Bugzilla, our bug-tracking tool, updating the wiki, helping other users on IRC, and triaging and reporting bugs. Lately I’ve been working on collecting stats from Bugzilla so that they’ll help us to analyze the status of bugs and users in the platform.

How did you get involved?

I started working for The Document Foundation just one and a half months ago, in the beginning of September, so I’m a newbie here. However, I had already contributed to the LibreOffice project in the past, mostly doing bibisections in QA or working on Easy Hacks and small fixes in development. Besides, I participated in the Google Summer of Code in 2011, converting some Java wizards to Python.

What does your typical workday look like?

So far I think no two days have been alike for me, so I’ll try to summarize it as much as possible! Normally, the first thing I do when I get connected is check the email and the IRC history. Then I take a look at the new changes in Bugzilla (new unconfirmed bugs, new bibisectRequest bugs, etc.) and eventually I work on the main task I have planned for the day. In case I have a meeting, I also spend some time getting things ready beforehand.

What areas in QA are working well, and what needs to be improved?

Definitely the best part of QA is the volunteers themselves, who expend their own time on the project, keeping the unconfirmed bugs low, triaging bugs, providing backtraces, etc. as this would be impossible without them.

I also find tools like the bibisect repositories really great for triaging regressions. On the other hand, as the amount of bugs in Bugzilla is quite high, I believe we need to improve how duplicated bugs can be identified more easily, as well as finding ways of attracting new volunteers to the team and encouraging them to stay in the project.

How can normal (non-developer) LibreOffice users help out?

One of the best ways a normal day-to-day Libreoffice user can help out is by reporting clear and detailed bugs when they find a problem, making the chances of getting the bug triaged, and subsequently fixed, much higher. A good bug report must have:

  • Operating system and LibreOffice version
  • Enumerated reproducible steps
  • Simple attachments where appropriate
  • Observed or expected results

Besides, they can also help to confirm bugs or retest bugs that might be fixed.

Finally, participating in the next Bug Hunting Session on Friday October 21 is a good way to start helping out. Newcomers can contact us on IRC (#libreoffice-qa on Freenode) or via the mailing list if they have any questions.

Thanks Xisco. So, that’s an overview of the QA team and what it does – later this week we’ll show you exactly how to get involved, confirm a bug report, and help to make LibreOffice stronger and more robust for everyone.