As I was packing my suitcase for the upcoming trip to the US the other night, I decided to give the new Olympus firmware a try. Having done the same process in the past with my old E-P1, I already knew that the process is a bit clunky and unintuitive with Olympus software, but I at least had a previous success in my memory, so it felt like an achievable task the night before traveling. (Three hours later, I definitely regretted that choice.)

The flaws in their documentation are obvious:

• The instructions in the firmware update tool just tell you to plug in the camera to the USB port, but in reality, the camera then prompts you to choose one of three modes. It turns out after some trial and error that the correct mode is the one in the middle of the menu (not the default choice). Pointing this out in the documentation wouldn’t necessarily cut down on their number of support incidents, but it would make for a much smoother product experience and it would reduce the user frustration, which would lead to a closer attention to what’s going on in the process. Crucially, however, this is an indication of a deeper issue at Olympus, which is that there is a disconnect between the developers and the people doing support documentation.
• After transferring the new firmware to the camera through USB, the update tool tells you that it finished updating the firmware and that you can either click Close to finish, or click the other button (I forget its label) to update the firmware on a different product, e.g a lens or another camera. However, the camera itself simultaneously shows a different set of instructions, or rather cryptic status indications. In reality, the update process is not finished, it’s just the USB transfer of the new firmware that is. Ensuring that the instructions on both screens are consistent would help reduce the likeliness of a user making the wrong choice in the process.

The latter point is where things broke down on my end, because I think I ended up turning the camera off by pressing the power button after having read the instructions on the computer screen to do so, but the camera screen was still showing some blinking icons that I paid little attention to at the time.

Boom. One second of not paying attention — two months without a working camera.

Documentation issues aside, having lead customer support for a major software product for the last five years, I’ve learned the importance of looking beyond documentation and rather focus part of the support efforts on fixing problems in the product itself and tightening up the loop between support and product development. Without this proactive type of support, you’re in trouble. Having gone through this painful experience with my almost brand new camera, I highly suspect that there is a disconnect between the support and development teams at Olympus.

Generally, you should remove as many possible points of user failure in the software itself as part of software design. In the case of the E-PM1, I have to wonder why it’s even possible to press the power button while the thing is updating — it’s an electronic button that they could easily disable during that critical moment, rather than exposing this ridiculously simple way of bricking your camera. I don’t know how many other people have had this problem, but having searched for it online, I know I’m not the only person. Another smart thing would be to ensure that there’s always a recovery bootstrap mode that enables the camera to communicate via the USB interface even after a failed firmware update attempt. That way, it would always be possible to retry and recover.

The brutal fact here is that I now have to send the camera to Olympus. The apathetic support rep that I was talking to on the phone today told me that their average processing time is at least a month due to their high support demand (no kidding!). Since I’ll only be in the Bay Area for a couple of weeks, this means I’m going to be without the camera for at least two months before I’m able to get back here again.

I tried to tell the support rep that I feel really strongly about improving processes like this that touch on customer support, because I have a full team of awesome people at Mozilla that do this for a living, and so I wanted to find the best venue to provide this type of feedback at a level where it would be listened to. He just politely said that he will pass on my feedback to “the customer feedback department” and that was the end of the discussion. Of course, what he really meant was “I’ll put some notes that I wrote into a system that will disappear among other notes that no one here really reads, and your problem won’t be solved proactively because I hardly talk to those that could do anything about this, and honestly I don’t really care either. Have a nice day.”

He didn’t really mean the last part — this is America after all.

What are SOPA and PIPA?

SOPA and PIPA represent two bills in the United States House of Representatives and the United States Senate respectively. SOPA is short for the “Stop Online Piracy Act,” and PIPA is an acronym for the “Protect IP Act.” (“IP” stands for “intellectual property.”) In short, these bills are efforts to stop copyright infringement committed by foreign web sites, but, in our opinion, they do so in a way that actually infringes free expression while harming the Internet. [...]

Wikipedians have chosen to black out the English Wikipedia for the first time ever, because we are concerned that SOPA and PIPA will severely inhibit people’s access to online information. This is not a problem that will solely affect people in the United States: it will affect everyone around the world.

For the record, I fully support Wikipedia’s protest — and so does Mozilla. However, this blog post isn’t really about that.

What if you really, really need to read that particular Wikipedia article today and you don’t have your mobile phone nearby, and you’d rather not disable Javascript of the entire browser? I thought I’d share this simple method that will allow you to quickly get access to the content:

Update: Asa Dotzler pointed out that there’s an even easier method than what I explain below: just replace the “en” part of the address of the article you’re visiting to “m” and you’re done — that will take you to the mobile-optimized version of the Wikipedia article. Example: change http://en.wikipedia.org/wiki/Toilet_paper_orientation to m.wikipedia.org/wiki/Toilet_paper_orientation. That’s it!

The original instructions were:

1. In Firefox, navigate to the Wikipedia article you want to read. You’ll see something like this:
   
2. Press Alt on your keyboard to reveal the classic menu of Firefox:
   
3. Click View > Page Style > No Style. You’ll then see a somewhat crudely formatted version of the original article:
   

This setting is not remembered in Firefox, so when you’re done reading the article, just close the tab and things will go back to normal when you open it the next time. (Wikipedia itself will also go back to normal, tomorrow. In the meantime, take action!)

The new placement of window controls in Ubuntu 10.4 (beta)

This is why Ubuntu’s recent change to move the window control buttons to the left side of the window in the latest beta confuses me, because it appears that a chance has been made for no real purpose whatsoever other than a vague hint that it’s preparations for “some innovative options” on the now empty right side. But those experiments won’t start until version 10.10, due out in October 2010.

There are a couple of problems I see with this redesign:

1. The Ubuntu layout is not just about switching from right to left — it’s introducing a completely unique layout never before seen in an OS. See how the Close button is still on the right side of the button group while the buttons were moved to the left side? This means that neither Windows nor Mac OS users will benefit from the change, as both user groups will have to relearn things here.
2. The actual icons/symbols on the maximize and minimize buttons are also completely different from both Windows and Mac OS.  While Windows uses a horizontal line to represent minimize, and a square box to represent maximize, Mac OS uses colors instead (yellow to minimize, and green to maximize/zoom). Again, this means that neither Windows nor Mac OS users will benefit from the Ubuntu change, which uses some stylish arrows instead (pointing up to maximize and down to minimize). The icons make little sense (isn’t maximizing more about changing the size of the window, rather than the direction? does minimizing a window always move it down — what if your task bar is at the top like I have it?). To make it even more bizarre, once a window is in a maximized state, the icon for restoring the window looks like the actual maximize button in Windows 95/98/Me/2000/XP/Vista/7.

Ubuntu’s design lead Ivanka Majic tries to explain why the changes were made, but fails completely. She instead lists some questions they were asking themselves without providing any answers:

- Why do Mac OS and Windows have the buttons where they do?

- What was the functional reason behind the Mac OS choice (or the Windows position for that matter)?

- Why, when most application menus are top left should the window controls go top right?

- Why, when we read left to right is the most destructive action first?

So, what are the answers? Given that I haven’t seen any, allow me to guess:

1. Mac OS and Windows have different conventions.
2. I don’t think there were any serious usability studies behind either of the choices.
3. Why not?
4. Because it’s the most common action on a window?

It’s things like this that makes me skeptical of so-called usability experts when they think they can get away with changing things for the mere sake of change, without any evidence whatsoever that it’s a change for the better.  Majic ends her blog post about the window control button placement by indicating the true reason why they went for a completely unique arrangement:

Personally, I would have the max and min on the left and close on the right.

Update: My insanely sharp colleague Jennifer Boriss writes about this topic more elegantly from a user experience expert perspective.

linux-humor, originally uploaded by David Tenser.

Björn hittar det roliga i den här bilden på två sekunder!

Pros

• The screen is pretty good, and I rarely have a problem clicking on links and buttons using my thumbs. The fact that it’s resistive feels like an advantage in this incredibly cold Swedish winter. Next to a Nexus One, however, it’s obvious that the color reproduction could be better.
• The Mozilla-based MicroB browser really is awesome. Scrolling and zooming is so smooth and quick that it feels like surfing on the iPhone, only this time you’re using the real web. By far the best web browsing experience I’ve had on a mobile device.
• The fact that I can use it to call VoIP, Skype, Gtalk, and regular cellular networks is amazing.
• The Conversations application seamlessly integrates IM and SMS in an intuitive manner.
• The media player handles almost anything you throw at it after installing a few extra software packages.
• Great synchronization with Exchange-based mail services (e.g. Zimbra, which Mozilla uses).
• Nice multiple desktop solution (though lacks useful widgets).
• Battery life is impressive in active use such as in a phone call. Though see the standby time below…
• The “one-click” (actually a few clicks) publishing of both photos and videos to services like Facebook and Flickr is really neat. Though see below about the camera quality…
• It really is fun to use it. And it’s open source! And it can run Firefox!

Cons

• This thing is heavy! I thought my N95 was heavy, but this is significantly heavier. It definitely feels like a solid device, for better or worse.
• The camera is actually worse than the 3-year-old N95 camera in a number of ways: terrible colors in low light, terrible metering, light leaks making the subject in focus appear washed out, and the field of view is narrower than the N95 camera. In comparison, here’s a photo taken by the N95. Both are 5-megapixel cameras.
• The standby time is a joke. I don’t know what I’m doing wrong, but sometimes I can just keep the phone in my pocket during the whole day and it will discharge in less than 8 hours. I first kept all accounts logged in (Skype, VoIP, Jabber), but have since then compromised a bit and only keep Jabber online. Still, the battery isn’t impressive.
• The horizontal layout is annoying most of the time. When I’m out and about, it feels awkward that I can’t use the phone with one hand. I understand the “handheld computer” legacy (I even owned an N810), but feel that my typical use is much more like a regular smartphone than a portable computer. Ideally, all applications should support both layouts.
• The keyboard, while certainly better than the N810, is still not really good. It’s too easy to click on the wrong keys, and there’s no auto complete feature that can detect (and correct) common spelling mistakes.
• The auto suggest feature only shows one suggestion, so 90% of the time it’s not suggesting the word you want and as a result you end up ignoring the suggestions altogether.
• The physical unlock switch is only comfortable to use when in horizontal layout. It’s nearly impossible to reach with one hand if you just want to make a quick call.

This week, TikiWiki community lead/member Marc Laporte is paying me a quick visit in Eskilstuna, Sweden to discuss our current situation and to figure out what to do with SUMO. We have identified three potential plans:

• Plan A: upgrade SUMO to TikiWiki 4.x. This is what I’m hoping we’ll be able to achieve. The question is how much work it means to get to 4.x and how much better things will be once we’re there.
• Plan B: fork our current codebase and continue to add our own features on top of it. This is essentially what we’re doing today, and it’s not exactly ideal since we end up doing work in parallel with TikiWiki, and we’re wasting precious resources.
• Plan C: migrade our content to another CMS, e.g. Drupal. By far the most costly effort in the short term, and not clear whether the benefits outweighs the investment cost.

Now that Marc and I have the opportunity to spend two full days working face to face, I’m hopeful that we can not only pick Plan A, but come up with a solid plan for the first few steps to make the plan a reality.

If you’re part of the SUMO or TikiWiki community, I would love to hear what you think and if you think there are things we should focus on discussing!

We’ve made the decision to continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around, with rich tools that our Word customers have enjoyed for over 25 years. Our customers enjoy using a familiar and powerful tool for creating e-mail, just as they do for creating documents.

The Power of Word in Outlook

How do you want your e-mail experience to look like in the next five years? If you think Microsoft is on the right track, take no action. If you think they should switch to modern standards, send a tweet asking Microsoft to improve standards support and make sure you include fixoutlook.org in your tweet.

Or just switch to a better e-mail program.