Tuesday, March 21, 2017

LibreOffice 5.3.1 is out

Last week, LibreOffice released version 5.3.1. This seems to be an incremental release over 5.3 and doesn't seem to change the new user interface in any noticeable way.

This is both good and bad news for me. As you know, I have been experimenting with LibreOffice 5.3 since LibreOffice updated the user interface. Version 5.3 introduced the "MUFFIN" interface. MUFFIN stands for My User Friendly Flexible INterface. Because someone clearly wanted that acronym to spell "MUFFIN." The new interface is still experimental, so you'll need to activate it through Settings→Advanced. When you restart LibreOffice, you can use the View menu to change modes.

So on the one hand, I'm very excited for the new release!

But on the other hand, the timing is not great. Next week would have been better. Clearly, LibreOffice did not have my interests in mind when they made this release.

You see, I teach an online CSCI class about the Usability of Open Source Software. Really, it's just a standard CSCI usability class. The topic is open source software because there are some interesting usability cases there that bear discussion. And it allows students to pick their own favorite open source software project that they use in a real usability test for their final project.

This week, we are doing a usability test "mini-project." This is a "dry run" for the students to do their own usability test for the first time. Each student is doing the test with one participant each, but using the same program. We're testing the new user interface in LibreOffice 5.3, using Notebookbar in Contexttual Groups mode.

So we did all this work to prep for the usability test "mini-project" using LibreOffice 5.3, only for the project to release version 5.3.1 right before we do the test. So that's great timing, there.

But I kid. And the new version 5.3.1 seems to have the same user interface path in Notebookbar-Contextual Groups. So our test should bear the same results in 5.3 or 5.3.1.

This is an undergraduate class project, and will not generate statistically significant results like a formal usability test in academic research. But the results of our test may be useful, nonetheless. I'll share an overview of our results next week.

Saturday, March 18, 2017

Will miss GUADEC 2017

Registration is now open for GUADEC 2017! This year, the GNOME Users And Developers European Conference (GUADEC) will be hosted in beautiful Manchester, UK between 28th July and 2nd August.

Unfortunately, I can't make it.

I work in local government, and just like last year, GUADEC falls during our budget time at the county. Our county budget is on a biennium. That means during an "on" year, we make our budget proposals for the next two years. In the "off" year, we share a budget status.

I missed GUADEC last year because I was giving a budget status in our "off" year. And guess what? This year, department budget presentations again happen during GUADEC.

During GUADEC, I'll be making our budget proposal for IT. This is our one opportunity to share with the Board our budget priorities for the next two years, and to defend any budget adjustment. I can't miss this meeting.

Friday, March 17, 2017

Learn Linux

Recently, a student asked me about career options after graduation. This person was interested in options that involved open source software, other than a "developer" position. Because this blog is about open source software, I thought you might be interested in an excerpt of my recommendation:
These days, if you want to get a job as a systems administrator, I recommend learning Linux. Linux administrators are in high demand in pretty much any metro area. In the Twin Cities metro area, it's hard not to have a job if you know Linux.

Red Hat is the most popular Linux distribution for the enterprise. So if you learn one Linux system, learn Red Hat Linux. While it's okay to use GUI tools to manage Linux, you should know how to maintain Red Hat Linux without a GUI. Because when you're running a server, you won't have a GUI.

A good way to learn this is to install Linux (Red Hat Linux, but Fedora can be "close enough") and run it in runlevel 3. Set up a cheap PC in your house and use it as an NFS and CIFS file server. Install a web server on it. Set up DNS on it. Learn how to edit config files at the command line. How to partition, format, and mount a disk (even a USB flash drive) from the command line. How to install packages from the command line. Learn how to write Bash scripts to automate things.

If you want a book, try Linux Systems Administration by O'Reilly Press. For formal training, I recommend Red Hat Sys Admin I and Red Hat Sys Admin II.
My advice mirrors my own background. My undergraduate degree was in physics, with a major in mathematics, yet I managed a successful career in IT. For me, it was about following my interests, and doing what I enjoyed doing. There's nothing like getting paid to do something you wanted to do anyway.

When I got my first job, I was a Unix systems administrator for a small geographics company. We used a very old Unix system called Apollo AEGIS/DomainOS, but had a few HP-UX and SunOS systems. I introduced a few Linux systems to do back-office work like DNS, YP, LPD, etc. My second job was a working manager for a document management company, and while we were mostly AIX, HP-UX and Novell, I installed Linux to run our core "backoffice" services (DNS, file, web, etc). At my third job (working manager at a Big-Ten University) we ran a mix of systems, including AIX and Solaris, but I replaced some of our "Big Iron" AIX systems with Linux to save our web registration system.

From there, was promoted into larger roles and greater responsibility, so left my systems administration roots behind. At least, professionally. I still run Linux at home, and I maintain my own Linux server to run a few personal websites.

But I still remember my start as a Unix and Linux systems administrator. I was fortunate that my first boss took a chance on me, and let me learn on the job. That first boss was a supportive mentor, and helped me understand the importance of learning the ropes, of understanding how to do something at the command line before you can use the "shortcut" of a GUI tool. So I encourage others to do the same. Yes, modern Linux has lots of GUI tools to make things easy. But it's better to know how to do it "the old fashioned way" as well.

Saturday, March 4, 2017

Open source branding

I recently discovered this 2016 article from Opensource.com about branding in open source software. The article encourages projects to kill off extra brand names to help your project get recognized.

The article describes the issue in more detail, but here's a summary:
Let's say you are the maintainer for an open source software project, which I'll make up. Let's call it the Wibbler Framework.

Maybe this is a website builder. Developers can use Wibbler to create awesome, dynamic websites really easily. Wibbler is based around different modules that you can load on your website to do different things.

One day, you get a great idea for a new chart display component. So you spend the weekend writing a module that provides a super simple way for websites to display data in different formats.

You think the new module is pretty cool, so you give it a name: ChartZen.
Pretty realistic scenario, right?

But the problem is this: you've added an extra "brand" to your project. When new users find your project, they are confused. Is it Wibbler, or is it ChartZen? How does ChartZen connect to Wibbler? Do I need to get Wibbler if I just want to use ChartZen? Do I need to run two different servers, one to run Wibbler and another for ChartZen?

By adding the second name, you've confused the original project.

It gets worse if you continue to add new "branding" to every new module. If you continue to add new names for every new module, you end you with a confusing forest of competing "brands": Wibbler, ChartZen, AwesomeEdit, FontForce, FormsNirvana, DBConnSupreme, and Pagepaint.

It's better to just name each component after the main Wibbler project. Keep the Wibbler brand intact. ChartZen becomes "Wibbler Charts," which is easier to remember anyway. And it's immediately clear what "Wibbler Charts" does: it's a component for Wibbler that makes charts. Similarly, you also have "Wibbler Editor," "Wibbler Font Picker," "Wibbler Forms," "Wibbler Database Connector," and "Wibbler Page Designer."

How do you manage your open source software project's "brand"? Do you have different names for different components? Or do you maintain one core "brand" that everything connects to?