Posts Tagged ‘Development’

The IE6 Rant!!!

Wednesday, February 25th, 2009

It’s no big secret that large organizations are slow to change. Especially with their technology. But I am constantly amazed by the number of people who are still being forced to use Internet Explorer 6 (IE6) by their work environments. IE6 was initially released in 2001. That’s 8 year ago! Stop reading for a second and look around the room your in. What technology do you see from 8 years ago? When are large organizations going to realize that it’s time to upgrade?

Big reason #1 for not upgrading: “Upgrading may break our current apps.”

IE6 behaves differently than every other browser, so it requires more development time. It is a last generation browser which doesn’t support many newer features. It is half the speed of most modern browsers (on a good day). This limits new applications, not to mention the price increases that accompany longer development processes. Google has been actively pushing people away from IE6. When you log into Gmail with IE6 you get a “Get faster Gmail” message which encourages you to switch to Chrome or FireFox. Even 37Signals has dropped support with an explanation of IE6’s limitations at http://37signals.blogs.com/products/2008/07/basecamp-phasin.html. It is much easier to upgrade an app to a modern browser, than develop modern apps to run in IE6. While these organizations may need to spend money on upgrading older applications, they will save money in the long run because all their new projects will be quicker and easier to develop.

Big reason #2 for not upgrading: “We don’t know the security and compatibility implications of upgrading.”

Even Microsoft has decided it is time to move on. They have announced that they will stop actively supporting IE6 in June. It will be grandfathered in, but will receive no more compatibility and security updates. If this isn’t an indication that it is time to move on I don’t know what is. In 2009, Secunia, a computer security company, reported 142 vulnerabilities compared to the 34 in Firefox (http://secunia.com/advisories/product/11/). I wonder how long it will take for IT departments to catch on that upgrading will be cheaper and easier than trying to support software that even the company that wrote it won’t support.

If anybody else has complaints about IE6, let’s hear it.

Is your software too fast?

Tuesday, November 4th, 2008

One of my primary roles as a developer is to look for ways to optimize software. It’s sort of my job, right? When we were developing the portfolios for SmibsNet profiles, I discovered that if code works too quickly, people can miss critical events. We had already developed the drag ‘n’ drop interface for resorting multiple portfolios, and were trying to figure out what kind of indicator would do the trick. It had to be something to make it clear to people that the resorting was being processed, and something that would prevent users from continuing the changes until the new order had been saved properly. Peter came up with the idea of having a translucent cover fading in over all the portfolios with an animated GIF indicator.

Screen shot of portfolios being reordered

Screen shot of portfolios being reordered

This solved everything, except for one little nagging issue. While the indicator had to be there for slow connections, the average time for this re-sort was fractions of a second. The moment the new order was saved, the cover would disappear. I wanted our users to be able to get back to work as soon as possible, rather than being slowed down by in-the-way animations. The consequences of this decision were dark flashes over your portfolios when a user would re-sort.

It turns out the solution was to slow things down. After adding some effects it now fades in over a second, and then fades out over a few seconds. While this would seem like two seconds wasted, no one seems to have a problem with this. In fact, we have received great feedback about this effect. Many people ask me if all the portfolio stuff was coded in flash, to which I can answer, “nope, just good old fashion javascript.” Next time I’m faced with  a confusing interface problem, I’m going to ask myself if the action has to be this fast. Maybe the best way to optimize the program is to slow it down.

——————
What other examples have you seen of software slowing down for the better?