Compile. Fail. Cry.

Stopping link onclick from causing the browser to jump around

2011-03-07T22:04:00.000-06:00

Often we may use links to enact Javascript functions in this fashion:

<a href=”#” onclick=”dosomething();”>click me</a>

While this works, the browser thinks you clicked on an anchor link and may "jump" the browser view port to the top left corner of the content.

A common way to work around this is to have the method dosomething(); return false. By doing so the browser should short-circuit the event model and not enact the href call. I say should because everyone's favorite browser - IE6 - does not. IE6 does not pass the event to the function, calling false does not stop the event propagation.

This can work:

<a href=”javascript:;” onclick=”dosomething();”>click me</a>

But it may cause problems. This call propagates an event call specific to IE and can break certain functionality.

A safer way is the following:

<a href=”#” onclick=”dosomething(); event.returnValue=false; return false;”>click me</a>

This works perfectly. The event will not propagate and the href action will not occur.

I wish I could give credit to the individual who pointed this out to me, but I can't find the link any more.

Props to Web Developers Journal for providing me with the original concept.

Friends of Eclipse

2011-02-12T08:22:00.000-06:00

I just became a "Friend of Eclipse". I've been using the IDE regularly for both work and home projects and I figured it was about time I made a donation. I encourage everyone to help out by donating what they can to their favorite open source projects.

Developing a web browser support plan

2010-04-27T17:23:00.000-05:00

When I started working at my current company, our QA department was testing our website with every web browser they knew of. Certainly 100% cross-browser pixel-perfect rendering is every developer's dream, but it is often a nearly impossible goal to achieve (unless you have a very basic design). With very limited time and resources, I knew we had to pick and choose our battles. My goal was to establish guidelines so developers and QA knew in advance what to expect.

Know Your Audience

The first step is to determine what the visitors to your website are using. This is important as different sites can attract different types of users. Websites whose content revolves around web technologies will typically attract a larger than normal share of non-IE web browsing traffic. I would guess that MSN is likely at 95% or more IE traffic. Apple.com likely sees very large numbers of Safari users, as would many i-Pod/Pad/Poodle/Pomegranate/etc websites. Sites aimed at a youthful audience may draw more alternative browsers and mobile devices than one aimed towards an older crowd who may be less tech savvy and more likely to use the web browser their computer came with.

There are many statistics packages available, and honestly I do not have enough experience with them to recommend any in particular, so I will leave that exercise up to you. I will say that they are invaluable tools. Not only will you learn what web browsers your visitors are using, you will learn where your bandwidth goes, what pages are drawing the most visitors... etc. Discussing the full benefits would be another article entirely, so let's just say having such a package installed is a must for any website with any decent amount of traffic.

In our case, we had both Webalizer and AW Stats in place. Unfortunately they weren't configured very well and user agent data wasn't of much use. The one piece of information we were able to gather was that we were overwhelmingly an IE-visited site (perhaps 85-90%).

Be wary of the chicken and the egg problem when looking at your own website statistics. Most of your visitors may use IE, but that could be because your site is unusable, unreadable, or just plain broken in other browsers.

Know The Web

With that information in hand, the next step is to look at the web as a whole.

Gathering statistics was fairly easy as the wonderful Wikipedia community has already done most of the work, as found on the usage share of web browsers page. This should be your one and only reference. Personally I weigh Net Applications numbers more highly than any of the other metrics sites simply due to the massive dataset they use.

One serious mistake I frequently see is developers who quote W3 Schools web browser stats. If you take one thing away from this article, it should be this: do not use W3 Schools web stats. It pains me to see how many developers quote their website. There is even a disclaimer on that page which indicates the results are only for the W3 Schools websites which draw a much higher percentage of visitors who use alternative browsers. So please, just don't do it.

Know Your Region

Web browser stats can often be biased towards a North American audience. If you have (for example) a Chinese-language website and 99.5% of your viewers are in China, then it stands to reason that you should strongly skew your support towards the most popular browsers in China.

This information is often available, but it can be hard to find, and often it has to be paid for. Net Applications is one such source, but there are likely more.

Examine The Data

With statistics in hand, analysis can still be somewhat nebulous. What if your website shows 10% IE visitors, regional data shows 80% IE users, and global data shows 55% IE users? Unfortunately there is no right answer as to how to interpret the data. If you want to focus on keeping your existing visitors happy, you should probably weigh your current visitor data more highly than the other data sets. If you want to attract more local business, maybe you need to skew more towards regional data. If you want to form a global empire, perhaps focus on use the global stats. There is no right answer. Try to come up with a fair interpretation that your organization can agree on. One blanket recommendation I can make would be to skew your current viewership most highly no matter what your goals are. You don't want to alienate your current customers or readership.

Web Browser Versions

Supporting multiple web browser versions can be a nightmare (most notably for Internet Explorer where there can be huge rendering differences). Utilizing your collected data you must decide not only which web browsers to support but which versions to support. Once again there is no right way as to how to do this. Perhaps only a small percentage of your visitors may use IE6, but if your website is hugely popular, that can still be a very large number of people.

For our support goals, we differentiated between IE and everything else. For IE, we would support every version that holds more than 5% overall market share. (Unfortunately for us that still includes IE6.) For other web browsers we would only support the latest version. Our reasoning is that if someone has enough knowledge to find and use an alternate browser, they would most likely be capable or likely to update the browser. IE6 is still in use mostly due to corporate infrastructures. It is doubtful other web browsers have anywhere near the same level of tie-in that IE does, so upgrading should not be an issue.

Determine Support Levels

With finite resources it is important to classify different problems into levels of priority. Your main site menu being broken in IE is a far more serious issue than some interior page images moving over a few pixels to the left in an old version of Opera. The former needs to be fixed right now, but the latter can wait, perhaps indefinitely. It appears we can quite naturally divide this problem domain into two parts: which browsers are affected, and what is the problem severity.

Browser Support Levels: Your web browser market share data comes into play here. You should assign each web browser (and/or browser version) a support level. What levels you assign or how you manage them isn’t important as long as you have a clear hierarchy as to what is important to your organization. In our case, we had the following:

Full Support: Every problem reported for these web browsers is considered valid
Partial Support: Problems have to meet a certain severity in order to be considered valid
Unsupported: Most problems will not be addressed (these web browsers are not even used by QA for testing)

Problem Severity Levels: How severe your organization considers the problem to be. This can be a tough one to nail down. For example, you can't group all graphic problems together, as some graphics may convey important data, may have the corporate logo or identity on them, or perhaps lead to a download or purchase page. We came up with:

Severe: Website core functionality or core business is affected, main landing page issues, or the corporate identity is diminished or adversely affected
Major: Non-core functionality or appearance issues that detract from the site but do not affect core functions or income generation
Minor: Everything else. Occasionally these problems are so small that they are deemed not worth fixing due to financial or time constraints.

Assign Support Levels

Data in hand, you can now assign support levels to different browsers. Compare your usage data with the problem severity levels and determine what your support goals will be. This has to be agreed upon by all parties involved.

We had decided that IE (all versions) and Firefox (latest) would have full support and would address Severe, Major, and Minor issues. Safari (latest) would have Partial support and we would address Major and Severe issues. Other browsers would be unsupported, but, while we would no longer actively test those browsers, we would still address any Severe issues when brought to our attention.

Review Periodically

It is important that you revisit web browser statistics periodically to ensure you are staying up to date with current trends. How frequently you check will vary based on your business and organizational comfort level, but likely you will want to check every 3-12 months. If you check more frequently you probably won’t see any noteworthy changes and by checking less frequently you will risk falling too far behind the curve. Our review period was set at 6 months and it has proven to be effective thus far.

Final Outcome

It is important to note that creating and assigning web browser support levels helps all aspects of the business. The developers know what they need to do to deliver a satisfactory product. QA has their workload managed by not having to support every web browser on the planet. Administrators will have more accurate estimates and will feel more empowered to make decisions on what issues are fixed in what order. It really is a win-win scenario for everyone involved.

Are 2-Digit Years Due For A Comeback?

2009-10-26T17:02:00.002-05:00

The problem Y2K embodied was that years were being stored as 2 digits on many software systems. 1999 was abbreviated as 99. When the year flipped to 2000, many were not sure what would happen with their computer systems. As a result, many dates were changed to 4-digits, or systems were re-architected to handle the transition in other ways.

People who were in the IT industry in the year 2000 know that Y2K was a significant problem. The fact that it did not materialize to much of anything was due to our diligence and the solutions put in place.

Now that we're approaching 2010 and double digits can once more be used to designate the year in a reasonably clear fashion, is it safe for new projects to utilize double digit years?

Storage Space

The main reason years were stored as two digits was that they took up less storage space. Space is cheap nowadays, so this is a far less compelling argument. However, for the rare date-oriented embedded or mobile app, or enormously large databases with many date fields, this may still be a valid consideration.

Y2.1K Is A Looong Way Off

The year 2100 would effectively be another Y2K for any system that utilized 2-digit years. But considering how fast technology changes, I can't imagine any data created now persisting for 90 years. Who knows what the face of technology will be then? Maybe we'll be storing our data in laser-stimulated protein chains by then.

Looking at it from the other side, some programs that were problematic during Y2K were 30+ years old and still in use, and it was somewhat difficult to find enough skilled mainframe programmers to repair them. If you develop a system in the year 2050, who's to say it won't be in use 50 years later?

Reduced Internet Traffic

There is a recent movement for URL-shortening. Shorter URLs mean very high traffic sites can save huge amounts of bandwidth by not having to transmit full URLs in HTTP headers or in content pages. Using 2-digit dates would reduce some overall internet traffic.

Downgrading Risk

If your current system utilizes 4-digit dates, it is doubtful that you have a compelling reason to re-architect your system to use 2-digit dates. Such a move would be costly and perhaps completely unworkable.

Compatibility

Many libraries (if not most) use a 4-digit year. If you switched to 2-digits, you may have to upconvert in your code to utilize those libraries, or create custom libraries, creating another point of failure for your software. If you use date math heavily, a 2-digit date is probably not for you.

Repeating Mistakes Of The Past

Whether or not there are compelling arguments for either side of the discussion, there is always the nebulous "we did it before and look what happened" factor to consider. Generally speaking, abbreviating data that does not need to be abbreviated is rarely a good idea.

Conclusion

In general it is probably a poor idea to utilze 2-digit years. However it is possible that there may be rare valid applications for its use, but even that should probably be limited to greenfield projects.

I have not seen this topic elsewhere so I thought it may make for some interesting discussion. What do you think?

Programming Doesn't Always Require Math

2009-10-09T03:06:00.002-05:00

This is a response to a recent blog post which poses the question "Do we need to know basic math as programmers?" The author seems to think little of those who have weak math skills. Based on the comments, it would seem many others agree. I appear to be one of the few dissenters, so I will voice my opinion here where I can expand on my reasoning more fully.

The author uses a "basic math" example of flipping the sign of a number. So -5 would become 5, and 5 would become -5. The author's solutions are good, suggesting either to multiply by -1 or to create a function which returns the negative of the parameter (my preference, as it avoids the use of a "magic number"). Some other solutions are presented, some of which were likely jokingly submitted by the respective author, and others perhaps not.

I'll be honest. Math is not my strong suit. When the question was first posed by the author, I had to think about the solution. This lead me to ask myself why I had trouble with this question when so many other people seem to believe the answer should be instantly obvious to anyone with two halves of a brain to rub together.

So I started to wonder - does this scenario even qualify as basic math? It would seem to be more of a factoid principle that is used in practice very rarely. How often would this scenario occur in day to day programming? When was the last time anyone had to perform this task in a real world environment? How often was this task put into practice by most people after it was initially learned? I would think fairly rarely. I can't remember ever doing it. As with all things, a lack of use will breed forgetfulness.

But I digress. Let's tackle the question head on: do all programmers need to know basic math? As per just about every other blanket statement ever uttered, the answer is not an unequivocle yes. My answer actually leans towards the middle, if not no.

I work as a web programmer. I write back end (and some front end) code for a fairly heavily trafficked website. Most of what I do revolves around data: displaying, querying, storing, modifying, etc. How much "basic math" do I need for my job? Unless we include the odd time I calculate widths for CSS properties or manipulate substrings using raw addition and subtraction, the answer is pretty much nil.

There are many websites like mine who's major functions consist of managing users and storing and displaying data. I would assume most of them get along fine with few applications of mathematics as well. I am also fairly confident that many other application categories - to do lists, day planners, system tools, reporting applications, basic control software - do not require much in the way of mathematics either.

Obviously there are a huge number of important and direct applications for mathematics within computer science. After all, if there weren't, math courses wouldn't be featured so prominently in related educational programs. Scientific computing, technical applications, modeling, advanced control software, and more, are all very math intensive. Those of us not blessed with an abundance of mathematical ability would be advised to steer clear of such problem domains. However even within those domains the entire programming team does not have to understand all, or perhaps any, of the mathematics involved. Often there is plenty of room for specialists in other areas - database, clients/server, GUI, etc - within those applications.

Years ago pundits were extolling the virtues of the widget. They theorized that one day business analysts would be able to manipulate widgets to create programs of their own, and that programmers could become a dying breed. While those days are certainly not yet here (and in my opinion will not likely arrive in my lifetime), there is something to be said about the ever-growing level of abstraction we are presented.

It wasn't all that long ago that most programmers used assembly code. I wouldn't be surprised if many younger programmers never do so. I think we can all agree that the vast majority of programmers would never consider writing a major application using nothing but assembly language. We have been spoiled by increasing levels of abstraction.

But this abstraction can be applied to mathematics as well. Just as the "+" operator is an abstraction for the assembly code lurking behind executing that operation, higher level functions can be abstracted as well. In Java, I can use the Math library to perform trigonometry. Even if I were to write an application that involved heavy mathematics, given the right tool set, I may never need to know much about the math involved.

Don't get me wrong. Math is valuable. I envy those of you who excel at it. People like me will rely on people like you to perform - or abstract away - our heavy numerical lifting. But as time goes on and libraries and programming languages abstract away more and more of the lower level programming tasks, as a group, our need to know basic math may diminish.

IE 6: The End Is Nigh

2009-10-09T00:35:00.004-05:00

Ahh Internet Explorer 6. Non-standards compliant. Unsecure. Unreliable. A web designer's arch enemy and a support person's nightmare. There aren't many insults one could hurl at it that it hasn't heard before. Yet still it stands tall, perched atop a hill, high above the rotting carcasses of technically superior and more cosmetically appealing and functional browsers.

In reality, the carcasses aren't quite so rotting, and that hill is shrinking rapidly. This topic has been discussed to death across the interwebs, so I will attempt to gloss over as much rhetoric as possible and show you why the proverbial light at the end of the tunnel is glowing brighter by the day.

Who's To Blame?

Why is IE 6 still popular? Ok, "popular" is pushing it and likely to make some people's head explode, so let's rephrase that as "still in such widespread use".

Designers? Some claim that if designers stop supporting IE6 then users will be forced to upgrade. This simply isn't true. There are too few websites powerful enough with sufficiently unique content to force users to upgrade. People will not upgrade, they will simply move to one of the 10 other websites that do the exact same thing as yours (but which do support IE6). The decision is a business decision, and as such, many designers have little power to influence the outcome. If this was not the case, IE6 would have been laid to rest years ago.

Businesses? There are web apps integral to company processes that require IE 6. (For example, the company I work for was unable to upgrade to IE7 until 4th quarter last year. It took that long for our team to find a window to upgrade our website content management system to a version that supported IE7.) Until those applications are updated, some companies simply do not have a choice. If your visitors tend to browse while at work (which *ahem* none of us should be doing...), dropping IE6 support could be a significant blow.

Users? This is where I believe the true problem lies. Most people who use computers simply don't know enough about them to know other options exist. Or they simply don't care. IE6 is built in to their operating system, so that is what they use. "Good enough" is a mantra most people ohm to. I'm sure there are many people with Windows Update turned off and don't even realize an upgrade is available. Those botnet agents have to be on someone's PC after all.

Licensing? Due to Windows Genuine Advantage, IE6 is the last version of Internet Explorer that people with pirated copies of IE6 can use. They would have to figure out how to bypass the security check to upgrade to IE7 or IE8. Many people likely wouldn't bother. Regretably, there are a lot of pirated copies of XP out there. Honestly, I doubt this aspect of the problem has much of an overall effect.

The End Is Nigh

IE6 is on its deathbed, and the spectre of death clutches at its web-designer-spit-covered remains. Many will claim credit for it (just Google "IE6 sucks"), but the truth is, it will have died a peaceful death due to natural causes.

Word Of Mouth Eventually the most recluse shut-in will have a friend or family member who notifies them that there are other alternatives available. Or they will stumble on alternatives accidentally. Many people likely don't care to exercise those options (see the "Good Enough" mantra above), but those who do will slowly add to the conversion rate.

Google I currently use Google Chrome as my main browser. I am in the minority, but that minority is growing. Chrome has already overtaken Opera's market share and is gaining on Safari. Thus far Google hasn't marketed their browser and you have to dig around just to find a link to download it, but if they decide to really push it, and if it is the default browser on the upcoming Google OS as I expect it to be, its share will grow substantially.

Apple iPhone popularity continues to push Safari numbers higher. It has also somewhat recently (as of version 3) been made available for Windows too, but that hasn't seemed to have made much of an impact thus far.

One IE per OS Without jumping through some serious rings of fire, you can only have one version of Internet Explorer on any Windows OS. As people upgrade their computers, IE 6 will no longer be available to them.

Lack Of Support Yes, this is a somewhat hypocritical counterpoint to my previous position indicating designers do not have much influence. Some absolutely huge sites are slowly dropping IE6 support and notifying those users that other browsers are available. This will help educate users that other alternatives are available.

But, the real champion for the death of IE6 is a somewhat unlikely candidate: Microsoft itself.

Windows 7

This will be the single greatest influencing factor in IE6's decline. Many companies (perhaps most) skipped migrating to Windows Vista. With the release of Windows 7 imminent, many of those same companies will be upgrading this time around. Few companies want to fall more than one release behind the upgrade curve, as the expense to migrate becomes larger and larger with each release. Windows 7 will have IE8 as it's default browser. Expect to see IE 6 usage drop like a stone over the next six months, followed closely by IE7, and for IE8 to respond with more or less equal gains.

Windows 7 Professional will have XP mode and some companies will be slow migrating their IE6-dependant apps, but you can bet their employees and managers alike will complain about having to use IE6 in the virtual machine instead of the fancier IE8. Those complaints, aided by the likely already in development upgrades to said apps in preparations for the Windows 7 migration, will ensure that those older apps are replaced within a reasonable timeframe. This will remove any remaining excuses for corporations to keep IE6 among their supported applications.

The Decline Has Begun

IE6 usage has been declining somewhat steadily for years. This decline will continue. Here are some significant signposts of that decline.

YouTube YouTube posts a warning message to visitors using IE6, indicating that their browser is out of date. Other tech-savvy sites will be sure to follow their example.

W3C The godfathers of the internet *cough* track browser stats which illustrate that from Jan '09 to September '09, IE 6 visitors have dropped by 6.4%. Many people extrapolate W3C's site stats and apply them to the internet as a whole, but that is a gross mistake. Not only are all such statistics regionally spun, W3Cs stats appear to revolve mostly around visits to their own website. (They do monitor other sites, but to what extent I do not know.) At the very least, we can assume that there are less web designers visiting their site with IE6, which indicates support for IE6 on a whole is experiencing a downward trend.

Net Applications In my opinion, Net Applications has the best browser stats available on the internet. They amalgamate data from a huge amount of varied sources. I won't reproduce their data here, but here is a comparison of browser support from Sept '08 to Sept '09:

IE (all versions)	down 9.4%
Firefox	up 5%
Safari	up 1.4%
Opera	up 0.1%
Chrome	up 2.7%

The only major browser to lose market share - and a substantial chunk at that - was Internet Explorer.

The end is coming folks. I'm not sure any of us have the power to hurry it along, but be patient. The end is coming. I predict IE 6 will have 5% market share or less by this time next year. That's a number that is safe enough for most conservative designers - and businesses - to drop support.

But Until Then...

Supporting IE6 can be made easier. I have gathered many tips for working with IE6 over the last little while. I apologize but I am unable to accredit most of the original sources as I do not know who they are, but their efforts are appreciated.

Design with standards first, then compensate for IE6 afterwards. This will save you time in the long run.

Use a CSS reset style to bring all browsers closer to a baseline default.

Use conditional comments to add an IE6-only CSS after other CSS links have been applied. This is the most efficient way of supporting the dinosaur.

If you are doing something noteworthy on your site that is not supported by IE6, utilize conditional comments and/or JavaScript let those visitors know what they are missing out on.

Java Import Brilliance

2009-09-24T18:13:00.005-05:00

I am working on a project that originated from a third party contracting company. The code base is horrendous and full of the most amaturish code you can imagine. Here is a sterling example:


import java.lang.String

Yes folks, they are importing core language features explicitly.

Of course, there is also this awesome example of their handiwork:


import ours.blah.group.AClass
import ours.blah.group.ASecondClass
import ours.blah.group.AnotherClass
import ours.blah.group.AFourthClass
import ours.blah.group.YetAnotherClass
import ours.blah.group.ComeOn
import ours.blah.group.StillGoing
import ours.blah.group.YouNeedToStopThis

Actually I think I was merciful, that list looks a little short, there were probably a few more explicit classes there.

I'm so glad I got the go-ahead to rip apart some of their stuff.

Timely Obsessions

2009-09-20T19:45:00.000-05:00

Every day I see more and more tech benchmarks. Years ago it was mostly for PC video cards and CPUs. To me that makes sense. You need a relative perspective to see how much you're getting for your money.

But now it seems there are benchmarks for everything. JavaScript runs faster in Chrome than Firefox. People are obsessing with Windows 7 benchmarks to see if it boots up faster than XP or Linux. Boot times? Seriously? Do these things matter to anyone without an agenda to persue? Is your time so valuable that you would pick an operating system based on whether or not it saves you 5-10 seconds a day? Does anyone writing or running these benchmarks believe anyone but the ubergeeks care?

In general, people do not care. No one will choose an operating system because of boot time. They want to know if their software runs on it. No one cares if JavaScript is faster in Chrome. Maybe their browser of choice just "feels" better to them. Many people decide what vehicle to buy based purely on it's looks and/or the status it provides. And they spend a heck of a lot more money on that vehicle than on any software product you're likely producing.

Most low-end computers purchased in today's market have far more resources than consumer applications can consume. We have reached a plateau. People are hesitant to switch from Windows XP because it already does everything they want it to. They aren't upgrading their computers as often because their current one is still as faster or faster than they need it to be.

If you want a larger customer base for your audience, speed is not going to give it to you*. I think we would all do well to take a look at the big picture. Focus on what your users want. Give them uncomplicated features they can and will use. Streamline your UI, then streamline it again. Ensure everything works rock solidly and as expected with no unpleasant surprises. Quality is king.

I know Ubuntu uses less resources. I know Chrome is faster. But I will still be using Firefox when my copy of Windows 7 arrives. I have a few seconds to spare, and I'm not afraid to use them. And so will many other people.

* Of course, in the web realm, this is all bunk. If your site doesn't load quickly, people will go elsewhere. Welcome to the new ADD world!

Top X List of Y

2009-09-17T20:24:00.004-05:00

If you're a fan of South Park, or even if you're not, maybe you've heard of the following business plan (courtesy of the Underpants Gnomes):

Step 1 - Collect underpants
Step 2 - ???
Step 3 - Profit!

Ahhh yes, Step 2 remains elusive for many of us, whether it applies to fiscal profit, or even social or emotional gains. Some of you may nod or smile as you recall your erstwhile ideas which you had failed to concretely realize. Those of us ("us" as a species, not as in... whatever I am) who do become noteworthy and appear in textbooks, magazines, tabloids or tweets.

Unfortunately, there are always people who's coveted Step 2 is to latch on to the coat tails of others and leech off their exposure. They are the Kevin Federlines of the digital realm. Why work when someone else can do it for you? They have replaced the above steps with the following similar formula:

Step 1 - Collect links to other people's articles on Y
Step 2 - Post a Top X of Y list on a blog
Step 3 - Profit!

This tedious concept is especially prevalent in the technology realm. How better to catch people's attention than by claiming that not only do you have information on X, you have more of X than the next person?!

Please, I beg of you, before you post a Top X list of your own, consider if you are bringing anything new or interesting to the table. A Top X list is fine if it is mostly your own content. Otherwise, don't bother, we have Google, and whatever your X and Y are, I'm comfortably sure Google has more.