With the next version of Ubuntu Linux coming out in about a month, many of the Ubuntu blogs have been buzzing with a range of topics - discussions on new features, examples of the improvements, reports on bugs that have been addressed (and new ones that have popped up) - most of which are relatively normal. One recent post, however, caught my attention - The #1 Problem in OSS Usability and What I’m Going To Do About It. I’ve been tossing around the things that she’s discussed in that entry, and figured I’d post my thoughts here.

The author makes some really good points in her article and so I’m going to try to avoid repeating too much of what she has already said. Before getting into it, though, I’d like to concisely summarize my opinions on development and usability without going off on a tangent:

1. Programmers should not be the sole people responsible for building the interface. They should be responsible for designing the software and building the interface around specifications determine by designers - not throwing in an interface element for every single function in the software.

2. Designers should not pretend that they are programmers, but should have a solid understanding of what the software is supposed to be doing. Don’t decorate the interface with unnecessary elements - minimalist, intuitive design is key.

Unfortunately, one of the down sides of open-source software is that a large majority of the interfaces for software that is developed is done so by programmers. That’s why it’s not surprising to see something like this, versus seeing something like this
on any given Linux distribution.

So why is her idea awesome?
First off, she not only understands usability, but she understands what the problem is with regard to usability in the open-source community. Usability is something that is already greatly ignored in software development, but even more so in a community that is primarily made up of geeks and software developers. We care more about something working versus how it looks, and it shows whenever you look at almost any piece of software that’s been hacked together.

Secondly, she’s got direction on how to address the issue. Because lack of research is the largest factor contributing to low-levels of usability, and because there’s no set standard or method of documenting the research, there’s no way to move forward with improving usability if there’s no reference on what to improve. Developing formalized documentation from the open-source community is an awesome place to start.

Lastly, she knows where to begin. She doesn’t really have a half-baked idea - she’s not only addressed the problem or how to solve it, but she’s addressed how to get it started, has explained how’s she’s going to do it, and has the personal investment in the project to keep it going. She’s got direction and you can’t drive anywhere without good directions.

Why I think this will work
Having “Open-Source Usability” is something that I’ve never really thought about, despite the fact that it makes sense. I’ve typically associated the open-source community with geeks - people that care more about good looking code rather than graphical user interfaces, people that care more about decreasing the number of cycles their algorithm costs just for the sake of decreasing it, and, generally speaking, people that care more about increasing functionality rather than experience.

When I first read this article, I was kind of quick to write it off - not because I thought it was a bad idea, but just because I didn’t think it was feasible. I’ve read the article several times and have been thinking about it for a few days. The more I thought about it, the more interested I became in this whole initiative. I then began to think about the open-source community and if it would be, well, open for something like this. I kept thinking about all of the ways in which people who care about design, usability, etc. would be deterred from Linux - then I realized it has nothing to do with the operating system. It has to do with what you’re passionate about doing, and being able to see the manifestation of your work - Linux is definitely provides a platform for doing this. I then began to think about other platforms that was open to a wide array of different users each with a range of different interests where they all cooperate - Wikipedia. I’m sold.

Open-Source Usability is step in the right direction for not only continuing to bring Linux into the mainstream (because I hold the opinion that it still isn’t ready despite so many awesome advances in the past three years), but for improving on the open-source model that has worked so well over the past several years (over a decade, even!). I’m pretty excited to see where this will go.

Joel on Software is a site that anyone and everyone oriented in application or web development should read. Nearly every post he makes has value to it, but his most recent post on web standards is excellent. It does an amazing job of saying absolutely everything that should be said and nothing that shouldn’t be said and it does so in best way possible.

Over the past few days, I’ve noticed that a number of people are downloading Slideshow JS. That’s great, but I also noticed that I never formally discussed the script here, so I thought I’d take the opportunity to do that now.

I’m not going to belabor the project here as you can read much more about it on the project’s page, but I thought I’d highlight some of the features of the script here, what it seeks to do, and how to contact me regarding bugs, feature requests, etc.

About The Script
The purpose of the script is to provide a very simple way of cycling a set images in an HTML document. It doesn’t require any knowledge of CSS, JavaScript, or nuances of browser performance - it only requires that you know how to actually add script tags to the head section of your page.

The one caveat to using the script is that the images that you wish to cycle must be placed in a div container. All of the styles for this container are managed by the script, so you won’t have to write any CSS. The script is flexible in that it won’t interfere with any of your current styles, and that you can customize the placement of the images however you wish. Details on how to do this can be found on the project’s page.

Slideshow is cross-browser compatible between IE6, IE7, Firefox, Safari, and Opera. It also has two modes of cycling the images - it can fade the images, or cycle them with no transitions. Unfortunately, IE6 does not support opacity so fading does not work in the browser.

For more technical information about the libraries that Slideshow uses, and how it operates with respect to the DOM, see the project page.

Contacting me regarding feature requests or bug fixes
I was initially only developing the script for myself, but as a few friends showed interest in the script, I decided to try to make it as robust and flexible as possible for others to use. I’ve attempted to test it as much as possible, but it’s impossible to test every single use case.

If you find a bug, definitely send me an email and let me know exactly what you did to discover it. I’ll do my best to address it.

Slideshow’s purpose is to provide a simple way for you to cycle your images without worrying about CSS, JavaScript, or cross browser quirks. If you’ve got a feature request that you think falls in-line with this purpose (such as showing an image title overlayed on the image), then also send me an email.

With sites like YouTube and flickr providing a seemingly endless amount of storage, it’s becoming increasingly easier to find places to backup all of your various media. I personally don’t use many of these services either because I don’t agree with their privacy policy, their price, or their vague details of how my information is kept secure.

I have no reason to believe that Dropbox will do anything different in these areas, but if this service goes above my expectations and has a really good price tag, then I’m sold on it. I don’t wanna get my hopes up, but I’d be lying if I said I weren’t a little excited about it.

Recently, I’ve been working on some client-side code for a web application that needed to encode some data prior to invoking an AJAX request, and then needed to decode the response data upon receiving a successful response; however, I discovered a nuance in JavaScript’s replace() function that required a little bit of extra work to get it operator with the degree of flexibility that I wanted.

Because ampersands are usually used to delimit query string parameters, the server wasn’t handling the submitted data correctly. To mitigate this issue, the ampersand character needed to be encoded. We stored the encoded representation of the ampersand in a local variable [creatively] called _ampersand.Next, we wrote a function that takes in the data to be sent across the wire, encodes the characters, and does some additional processing, before returning the encoded data:

function encodedData(strInput) {

return strInput.replace(/&/g, _ampersand);

}

It worked fine; however, the replace() function proved to require a little additional work for it to decode the data correctly. Since we needed to do a global replacement of the ampersand token, we were using the g operator, but inserting a variable into the replace() function does not work. Actions speak louder than works, so here’s what I mean:

// this does not work…
function restoreAmpersands(strInput) {

return strInput.replace(”/” + _ampersand + “/g”, “&”);

}

At first, it seems as if it work work fine - concatenate /’s on the value stored in _ampersand and then let JavaScript get to it. Unfortunately, this isn’t how it works. One solution would be to simply hardcode the value of the _ampersand variable into the replace() function, but that’s poor coding. The solution I ended up using is actually extremely simple and it makes perfect sense.

Because replace() requires a regular expression to work its magic, giving it a concatenated string literal will not work. Instead, I ended up first creating a regular expression that includes the _ampersand variable and the global operator, then I passed it into the replace() function. Have a look:

var sRegExInput = new RegExp(_ampersand, “g”);
return strInput.replace(sRegExInput, “&”);

Extremely simple solution to a problem that, in my opinion, shouldn’t have been much of an issue at all. Oh well, at least I know that I wasn’t alone.

Zuckerberg said the episode taught him an important lesson. “Almost all of the mistakes we made, we didn’t give people enough control,” he said. “We need to give people complete control over their information. The more control and the more granular the control, the more info people will share and the more we will be able to achieve our goals.”

One of the main problems I have with Facebook is exactly this. I’m glad that Zuckerberg acknowledges his mistake, but how many times can you keep making the same mistake before you learn from it? Furthermore, I think he, and others, should realize that not everyone wants to share everything.
Read more from the article here.