Why add-ons suck

This dialog, that's why:

 

Firefox 4.0 is officially out. I think it's great that Firefox has such a huge array of add-ons. They make a lot of people happy, and are often a justification for why people like the browser. The problem is when I upgrade to a new version and I can no longer use an add-on that is part of my core usage... This has happened a great many times...and every time it is less and less cool.



I'm probably in the minority for considering mouse gestures mandatory capability - but I do, and that requires an add-on in Firefox. There is hope, though.

The Firefox team seems to be taking a nod from Chrome's release cycle, and have vowed much faster, smaller releases going forward. From the "How to ship faster" section of the 2011 priorities/roadmap there is the following bullet point:

we must provide binary compatibility for Add-ons 

If that happens in 6-8 months (or whatever the timeline), it would remove my single biggest irritation with Firefox. Aside from the above dialog, Firefox 4 seems to bring an aweful lot of good to the table. I continue to happily keep 4 browsers installed on my machine...

Desktop Java Apps - to bundle or not to bundle a JRE?

First - here is my definition of bundling the JRE. Shipping your application with a JRE, such that it is the one used by default from your application startup scripts, regardless of the environment on the target system. The bundled JRE is not registered with the system, so it should not affect other applications on the system.

There are probably some good reasons not to bundle a JRE. Taking a moment to ponder, I can think of at least the following:

• Bloat
• No automatic security updates
• Less portable

There may be more - but I believe the pro's will outweigh them regardless, once I add some additional constraints. Specifically, I am concerned with Java on the Windows desktop. Further, I am talking about larger, high engineering effort commercial software deployed to big companies. Not a small, independent Java app deployed to individual consumers. (although there may still be cases where that simplifies things). At a minimum, I would argue for stating "Use 1.6 Update X or higher" somewhere in a README, even for a small app. I've just seen too many weird issues not to.


On to some reasons for bundling a JRE:

• Control over major Java version (1.4,1.5, 1.6) - this is less of an issue today, since 1.5 has reached its end-of-life and 1.4 is far behind that. Thank goodness for that.
• Control over the exact version (i.e. 1.6 Update 20) - to ensure mandatory functionality works properly
• So the end users don't need to install something additional
• So your program is not influenced by the system environment
• So your program does not influence other applications in the environment 
• Less variables for when customers report bugs
• No automatic updates - which could break functionality
• Less to test

See a theme? Better control. Also, better isolation from the environment and other things that can go wrong.

For instance, in the 1.5 days, I recall one release that had very misbehaved tabbing through components in a UI. In the era of Windows 7 - you need a minimum of 1.6.0 Update 18 - or you have missing icons in Open/Save File Dialogs. It is not acceptable to have a UI defect like that in a shipping app - any less, and you don't have full Windows 7 support. Except on 64-bit systems Update 18 has a bad habit of crashing the JVM a lot...so you need a more recent update. Then there's the Swing/AWT changes in Update 12 that alter behavior. Then I'm pretty sure depending on the version, applets load differently, if that's a factor (in one of our cases, integration with another process - it is).

You can avoid all that by picking a version you know works for your required situations. This means less to QA. Less potential headaches. The trade-off is losing faster security updates, increased application size (which believe it or not - still matters even in the age of 3TB hard drives), and portability. If you are in a Windows-only market, as I have seen several applications be, then portability isn't affected. Even if there are other target platforms - it's just a matter of repackaging for other platforms.

I believe there are some good reasons to bundle a JRE - on Windows, anyway.

Usability Fail - Confirm Then Swipe

I consider a fundamental goal of software, and technology in general, to make people's lives easier. To simplify, automate, and perform useful functions. When the above holds true, technology is a success. When technology gets in the way, is a hassle to use, or does not otherwise improve an existing process - it is a failing and does not have purpose.

First, a success story. Trader Joe's is a very pleasant place to shop, all the way through. The checkout process is one reason for this great experience. The first time I went to one was several years ago, and I was pleasantly surprised during checkout.

The Card Swipe device:

1. Made it immediately obvious that I could swipe my card at any time
2. Allowed me to enter DEBIT, PIN, Cashback options, all before the cashier had even finished scanning my items
3. Provided a final confirmation once all items were scanned

This is pure win, on all levels. I have true respect for the makers of this device. Others get 2 & 3, but some fail to make it obvious to the user that they can swipe early. No one likes waiting in line - this helps people wait in line for less time - both the person using the card swipe, as well as anyone behind them.

Imagine my surprise when my local Market Basket got new card swipe devices a year or two ago, and they did not share this amazing feature. On the contrary - it required the exact opposite. Enter the "Confirm Then Swipe", a giant usability fail.

Here is a basic rundown of the Bad Card Swipe Device (TM):

1. You must wait until the cashier has scanned the final item
2. The cashier then usually asks credit or debit.
3. The cashier reminds you to "Confirm then swipe"
4. You confirm the amount
5. You can then swipe your card
6. Debit PIN
7. Oops - you got your PIN wrong, try it again 
8. Final confirmation (?)

What went wrong for a device with such a basic purpose to have been made this way? Is it short-sightedness of the developer? Is it due to the other vendor holding software patents? (more on software patents another day...) Whatever the cause - it really bums me out. How many wasted words are there on a daily basis, just to explain to the customers that they must confirm first? (plus the time that could have been saved if the swiping process was completed while items were still being scanned) How much time is lost by the patrons due to this every day? Per Year? This should not be the case, but sadly it is.

Thoughts on OpenID

I've had an OpenID for over two years now, since I joined StackOverflow during the beta. A lot has probably happened since then. If memory serves correct, at least one OpenID provider went out of business. Others may have changed ownership - and new ones have surely emerged.

How have my first 2 years with OpenID been? Well, I've only set it up on a whopping 2 websites, both of which are technically oriented. I have recently started seeing OpenID as an option on a few more websites, but not a lot.

I attempted to set it up on a third (DZone), and although it allowed me to login, I could not verify my account, or join it to my non-OpenID account. This is probably just an issue with DZone, but if it was important enough, I would hope it'd be resolved.

What implications are there to third party authentication such as OpenID over time? (say, 5-10 years). Quite a lot can happen to a company in that timeframe. Especially tech companies.

Is it easy to switch OpenID providers? It seems like that is limited by whether every site you use supports adding a second OpenID or not. That may be a requirement of participating, I have no idea - so far, the two I care about have supported this.

What happens if my OpenID provider, say, starts getting hosted in China. What happens if my OpenID provider goes down for good? Will I ever be able to reclaim my account?

What happens, for instance, if my OpenID provider's SSL certificate expires? I can't get to my websites unless I accept an expired cert?

For the record - back in August (when first typing this), the MyOpenID login page was doing just this - showing expired certificate messages. Even though it wasn't apparently needed for authentication (because rest assured - I reject expired certs), it was still alarming. I hadn't even seen the domain name before - which was also worrisome.

This is what got me pondering OpenID. The concept is nice, but is it succeeding?

I am glad Google is a provider - would OpenID be at all usable still if they weren't? I at least feel safe that my Google account isn't going anywhere anytime soon. Also, it is rather convenient as I'm usually logged into gmail and just need to confirm to login.

I am curious what others think. Do you use Open ID? Do you think it is succeeding - is it convenient, or a pain? What provider(s) do you use? What websites use Open ID for the sole authentication system?