Basecamp is getting rebuilt. From scratch. This is music to my ears even though I don’t use the software. 37signals is a bar in our industry. They know their stuff and it’s inspiring to see what they do and read what they write. They’re progressive thinkers and they know it. The Web is new, and antiquated thoughts, processes, and business does not apply.

This decision going public reminds me very much of the way Apple approaches themselves: stay ahead of the competition by outdoing what you’ve already done. Apple is constantly killing products when something better has taken it’s place, that’s the whole point. Old business seems to suggest “do both” but Apple has proven that’s not the way to go every time.

37signals’ Basecamp is Apple’s iPod. Basecamp is going to be killed off by 37signals with Basecamp 2, and Apple kills off old iPods with every new generation for the most part. It’s aggressive and progressive but to me it makes complete sense. I can’t wait to see the new and improved Basecamp.

Advertise here with BSA

Back when standards were standards if you were building anything that didn’t have a fall back plan in place for a lack of JavaScript, you were doing it wrong. Yes it took more time and it took better planning but that’s the point. When you’re a professional you’re supposed to be doing it right, right?

The rise of (my) Web standards

Back when JavaScript was reborn, when its use began transforming into what we know and love today, the rules were still being written. I remember thinking about how I should approach learning this skill I knew would soon be essential. My first stop when teaching myself something is Google. Of course back in the day Google was still polluted with DHTML tutorial sites and wretched implementations. After reading countless tutorials comprised mostly of “copy and paste this snippet here and that snippet there” I knew it was time to hit the books.

It took about four seconds of poking around to realize that there was more than meets the eye when it came to JavaScript for me. I needed to learn about the DOM before I tried to manipulate it. If there’s one thing that drives me batty it’s the notion of ’learning the framework instead of the language’ and this is no exception. JavaScript though, has a completely new layer to work with.

I won’t detail the issues I have behind learning a framework or platform as opposed to the language here, but it can be applied to every programming language, every markup language, CSS, and JavaScript as well. To sum it up: learning the framework gives the language a bad name. We’ll leave it at that and the rest for another article.

I grabbed myself a copy of DOM Scripting by Jeremy Keith and to this day I’m glad I did. DOM Scripting was instantaneously followed by Bulletproof Ajax, also published by Mr. Keith. If I had to choose two books as a suggestion to someone looking to learn proper JavaScript I think these two are it. There are of course subsequent, more advanced books that I’d also suggest, but these two works will help you to realize which blog posts are junk and which are gold.

The theory behind writing JavaScript, as I took it, can be taken from DOM Scripting:

Separate behavior from structure using unobtrusive JavaScript. Add dynamic effects with progressive enhancement. Ensure backwards-compatibility through graceful degradation.

I lived by those rules. I still do. But am I stuck in the past while everyone is moving forward?

The new Web

Has building a proper Web stack become old school? What I’ve been curious about lately surrounds the trend that requiring JavaScript for your Web app is something we hardly blink at. MobileMe has just recently relaunched with a new look:

Looks really great, but if you hit the page with a JavaScript-incapable browser it’s a bit different:

Back in the day we’d all have scoffed at such a thing, comparing it to a “This site looks best in IE6″ badge straight out of the 1990s. What’s changed since then? Why is this now an acceptable practice? I understand that Apple is a progressive company, bringing the web in its best form to the largest population possible, and making it look great, but that’s my point. Is this new school of thought going to transform itself into common practice?

The entire point behind breaking away from closed platforms such as Flash (yes, it’s a closed platform no matter how much marketing gets put behind it) is to build a universally accessible Web. Devices are advancing, yes. Browsers are advancing, yes. But does that give us the liberty to put the fruits of our labor on a back burner now that we’ve reached some sort of plateau in the evolution of the browser?

I’m not dogging Apple

Apple isn’t the only one producing Web applications that show similar messages if you’re using a JavaScript incapable browser. In fact, other more popular platforms are doing it even worse:

There was a time, if I remember correctly, where Google Docs gave a notification similar to MobileMe as opposed to loading a non working pseudo interface that does nothing but confuse a visitor. Gmail still retains its fully functional JavaScript-less implementation, albeit behind a quick message notifying you what you’re in for:

Depending on your choice, you can end up at a really well put together version of Gmail:

To me, Gmail remains to be one of the best implemented modern Web applications because of this very attribute.

Where are we headed, really?

I’ve tried to wrap my head around these poorly implemented Web applications to find out the real inspiration behind them. Are companies rushing JavaScript dependent platforms out the door simply to get things live before the competition? Are metrics showing that supporting JavaScript simply doesn’t make fiscal sense? Are we to a point where leading Web companies care more about dollars and cents than users?

What about the Web applications themselves? We’re working with the most rich implementations of JavaScript we’ve ever seen. Many times, it doesn’t even make sense to offer a degraded version of an application simply because the desired feature is built within JavaScript from the ground up; there’s nothing else to show. This is not a bad thing. I’m concerned in particular for those applications that could in fact have a decent degraded version. Does it change the opinion we have behind the modern Web though? I’m speaking from a front end developer point of view here, a conversation between us professionals, not as users.

Do we need to move beyond this self-imposed requirement of providing a gracefully degraded version of our application? If so, would it not be a (short) matter of time before that school of thought trickles all the way down to the Coda Slider we plan to implement? In essence, what’s the difference? We’d all be thrilled if we could just make that AJAX request and call it a day without having to first build an alternate version, but is it the right thing to do as professionals?

The groundwork has been laid by some of the best thinkers in our industry, and neglecting to build a proper stack, to me, pushes all of that hard work aside in favor of (too) rapid deployment. If your metrics show a 99% JavaScript enabled audience, are you willing to forsake that 1%?

I’m not only concerned about that 1%, I’m (perhaps) more concerned about how it affects the overall implementation. Working from your degraded version is going to result in a much more stable environment upon which to build your behavioral layer. Skipping that valuable step can and probably will result in a less structurally sound document.

I have a tendency to remain loyal to influential circumstances that have shaped me as a professional, but I’m curious how (if?) these events are affecting other designers and developers, if at all. Do you continue to be curious about degraded versions of modern Web applications? I could be way off base in even thinking about things to this level, and if that’s it by all means feel free to call me out on it, but there’s something under my skin about what’s going on. Thoughts?

Advertise here with BSA

I wanted to jot down some of our thoughts on Adobe’s Flash products so that customers and critics may better understand why we do not allow Flash on iPhones, iPods and iPads. Adobe has characterized our decision as being primarily business driven – they say we want to protect our App Store – but in reality it is based on technology issues. Adobe claims that we are a closed system, and that Flash is open, but in fact the opposite is true. Let me explain.

The piece tackles the main issues brought up against Apple in an attempt to outline the significant reasons as to why Flash is absent on the iPhone OS platform. First, the opinion that Flash is an ‘open’ format is put to bed.

The next argument surrounds the opinion that “the full Web” is limited on the basis that Flash powers the mass majority of video on the Web. While true, all of the major players have already adapted to the open standard format that is HTML5 video. Next.

Next is security. Flash is plagued with Windows XP syndrome in that since it’s so popular, it’s a prime target for cracking. There have been plenty of security bulletins and emergency releases on the Flash platform and while it’s nothing specifically against Flash as inferior in any way, it’s a fact of its position.

Battery life is a huge concern when it comes to Flash. While hardware acceleration is coming; it’s not here yet and the Web has already progressed through HTML5. The Web moves too fast and by the time hardware acceleration is common place, the dust will already have been settled.

We also need to keep in mind the interactions we have with Flash. It’s all via mice. Touch doesn’t translate very well and Steve goes on to explain a bit more about that in the piece. Long story short, much of the Flash stuff people are smitten with would need to be (at least in part) rewritten to function properly.

Last, Steve touches on what he mentions as the most important reason: the third party aspect. He explains that Adobe’s first goal with Flash is cross platform development, and that often leads to sub-standard experiences and applications. He dictates that Adobe “has been painfully slow to adopt enhancements to Apple’s platforms” — so true.

Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

I whole-heartedly recommend that you read the piece, in its entirety, without any bias you may have. Thoughts on Flash.

My stance: regardless of this fighting, that coffin is so full of nails it looks like it were made of stainless steel.

Advertise here with BSA

Lack of client knowledge

It’s extremely rare that I’ve had an interaction with a client where the phrase ‘usability testing’ doesn’t garner an inquisitive look. At the very least, mentioning usability usually sparks an interesting dialogue, but it’s often the first time clients have heard of such a thing. That also mean it didn’t make it into the budget for this project.

Client assumption of expertise

If a client does understand the purpose and value of usability testing, they may be curious why you’d like to have usability testing sessions on their website if you’re a professional designer. If designing websites is your profession, why should you need to test your design concepts? Shouldn’t they work already? Why should we pay for that?

Where’s the value?

In my personal experience, usability testing, unless requested, is often an addition to project scope that clients aren’t willing to pay for. Unfortunately, client bias as far as their experience on the Web often has detrimental effects on their interface design when they begin to direct the project a bit too much. It’s at those times when a usability test would come in like The Dark Knight and save the interface once and for all.

While that list is extremely truncated and narrow, it gently sums up my experience with usability testing client work.

Fortunately, a negative response to usability testing isn’t completely consistent. From time to time a client will come in fully versed in the importance and value of usability testing. It’s a pleasant surprise to hear a client say they’d like to integrate testing into the process as a way to ensure their product will perform to the best of our ability.

Testing environment

The process of usability testing itself can be put together a number of ways. Much of the time, a usability test will be conducted in a closed room. The user being tested will sit at a workstation with an instructor, who will request certain actions from the user and observe his or her method of completing that request. The computer screen is recorded using additional software on the computer, and the interaction between the test subject and instructor is recorded with a video camera.

The process is quite basic, but the knowledge gained is invaluable. Viewing the footage from the camera in sync with the screencast from the computer will bring design flaws to the surface for examination. Compensating for weakness in the design and repeating the test helps to create a much more effective interface.

Enter Silverback

Silverback first hit the Web boasting a unique site and a killer application icon. The design itself quickly made huge waves among the design and development community, a genius move. No one had any concrete information on the purpose of the site, but we were drooling already. We knew Clearleft had something very interesting up their colelctive sleeve.

Skip ahead a few months and we find out exactly what Silverback is; Spontaneous, unobtrusive usability testing software for website designers. Fantastic! Silverback is going to bring usability testing to Mac in a big way.

What does Silverback do?

My favorite applications do one thing and do it well. Silverback will be one of those applications. The website follows the same path by explaining the purpose of Silverback in a short, to-the-point list:

• Capture screen activity
• Video the participant’s reactions
• Record the participant’s voice
• Add chapter markers on the fly
• Control recording with the remote
• Export to Quicktime

Silverback fills a niche market of designers looking for a quick and easy way to conduct usability tests that will integrate easily into a workflow. Silverback is it.

Silverback is an application that doesn’t need an instruction manual. While the feature set isn’t extensive, the application follows a natural workflow allowing you to easily discover application use within a few seconds.

After creating a new project, you’re able to begin your test sessions. Each session is logged for future reference.

Before each session begins, you’re able to ensure the camera used to record the user’s face is properly positioned. You can also record the users name as well as any notes you have about the session. After starting the session, the screen will blank out in preparation for your subject.

A straightforward instruction screen is in no way intimidating to your subject.

Sessions are neatly organized for future reference. It really can’t get much easier than that. If applicable, you’re able to easily export any session. You can set a number of options, including the size and position of subject footage.

Another great thing about Silverback is the slick integration of the Apple Remote. Using the remote, you’re able to interact with the recording behind the scenes. You’re able to insert markers in real time, allowing for quick navigation of an exported QuickTime composite. I think that’s a great idea and fantastic example of ingenuity.

Silverback is game-changing

In my opinion, Silverback is offering an extremely low cost, effective solution for many designers. At $49.95, you would be hard pressed to find a better option for Mac at this point. A big congratulations to the group at Clearleft for a job very well done. I’m very much looking forward to improvements made in the software.

Advertise here with BSA

As an update to the list of things I was looking to complete during my time off, it was just the thing I needed. I was able to spend some much enjoyed quality time with Carrie (she got us a Wii!) and I was able to get a number of things done with/for my family.

Some technical details

It was good to try and unplug for a short amount of time and focus on some other things going on. At the same time, however, it was great to have some more time to read up on some things I’ve been meaning to teach myself for some time. I recently cracked open Essential ActionScript 3.0 and try to get myself more versed in that area as well as Flex and AIR. I’ve been meaning to get into Flash for (literally) years, so what better time than now? My question to you is this: are you at all interested in me writing pieces on the topic of Flash? I’d love to start writing and thinking about the general effect the technology has and will continue to have on Web development, but I’d like to know if anyone is at all interested before doing so.

On top of that, I’ve been playing a bit with the Fireworks CS4 beta and (partially) opposed to some people, I’m loving where things are headed. I’d like to post updates on the application side of things as well, including text editors, FTP clients, and some of the other tools I find myself relying on quite a bit. My issue with that, however, is that the posts would turn out to be heavily Mac oriented, and I’m not completely comfortable writing articles that aren’t useful for everyone. Are readers using Windows/Linux opposed to articles written about Mac software? Please take a second to leave a quick note regarding your stance on the matter, even if you’re a Mac user, I’ll base my decision on whether or not to write articles of that type on the comments.

Please bear with me for just one more week

All in all, I hope I didn’t lose too many subscribers, and you can expect some new articles to be posted starting a week from today. Stay tuned!

Advertise here with BSA

So why did I switch to OS X?

There was a long time where I had no interest in anything Apple was doing. I’m not sure how to provide much detail, but I was put off by Macs since working with them in high school. There are a number of Macs in my office, but a lack of interest prevented me from doing much of anything with them.

It’s no secret that Apple stole the hearts of so many people in the design and development communities. Each may have their own reasons, and many take the time to let others know why they enjoy Apple so very much. Their reason didn’t appear to be because they’re (all) blatantly against Microsoft, the reason seemed different. When the Internet repeatedly became, dare I say, plagued with articles written about just about anything going on in Cupertino; my interest was piqued. To put things simply, I wanted to see what all the fuss was about.

It was about the software

A major driving force for my interest in OS X was the software. Time after time I would read an article referencing this gift of an application; TextMate. I watched a few screencasts and my jaw dropped; snippets would change the way I work completely! I tried my hardest to find a Linux equivalent, and ended up finding something that would suffice by using SciTE with TextMate style snippets. I was instantly hooked to tab-triggers. Not only do they save you many keystrokes, they can help you avoid frustration from forgetting a quote or semicolon somewhere. I came across E Text Editor at some point, and was again drawn to TextMate. The application was far superior to what I had pieced together using SciTE; I really wanted to learn more about it. Reading a few articles had me convinced that it truly was a fantastic editor for my personal use.

Another factor contributing to my eventual Apple endeavor was Adobe. While I had no major problems using a virtual machine to get Windows XP up and running, it was quite a resource hog paired up with Photoshop. Booting the VM and then running Photoshop would bring the machine from a steady sprint down to a moderate jog. Slicing and cutting comps approached annoying in the increased time it took to get things done. While running Windows inside a VM really wasn’t a huge deal, I’ve got a bit of OCD when it comes to productivity.

Additionally, I began to question what I would do five years down the road when it came to working in Photoshop. It’s flat out essential for me at work. I tried to picture Adobe taking the time to announce their effort to port the most popular applications from the Creative Suite to Linux, but we all know that isn’t happening any decade soon. I refused to explore the possibility of running Windows Vista, so would I continue to use Windows XP until the day I retire? Neither option sounded very compelling.

It was about the hardware

It’s true that there have been quite a few articles published which act as a horror-filled documentation of an individual experience with Apple, but they’re computers. Bad things happen from time to time, take a look at some of the review threads on Newegg, you’ll find opinions from one end of the spectrum to the other for nearly every product available. Overall, I heard many good things about the hardware itself. I checked things out in more detail and I was impressed with what I found. The build quality of Apple hardware is impressive, and that’s a huge selling point for me. I’ve had my fair share of “discount” hardware and been sorely disappointed.

One thing I was also looking forward to was the “it just works” factor. With Linux, things will definitely work, it’s just that sometimes they require a bit of elbow grease to get the gears turning. If you’re into that sort of thing (which I can truly say I am), then Linux is really that much more fitting for you. I had a lot of fun working with Linux, but when it came down to it, I wanted to get work done faster. Plugging in an external monitor and having OS X automatically enable the display and find the native resolution was a welcome change to editing xorg.conf. There are many more details about the hardware itself that was a selling point, but the overall quality of Apple products was another attractive feature to look forward to.

At the end of the day

Finally, I went ahead and picked up a MacBook running a 2GHz Intel Core 2 Duo, popped in 2 gigs of RAM, and went on my way. The first couple days were all discovery, but nothing out of the ordinary. I had spent nearly two years in a Linux-only environment, so I was partially used to working with an entirely new operating system.

I made the switch to Mac about six months before the time of this writing, and I can say that overall I’m glad I did. I now see why so many designers and developers simply love OS X. With a bit of tinkering, you could make a Linux installation look quite good, but OS X is quite stunning out of the box. The great thing is, applications follow suit. Many applications written for OS X pride themselves on their design.

After six months, I can say that I’ll probably be sticking with Apple for the foreseeable future. The software is great, the hardware is great, and the aesthetics are a nice bonus. I wanted to make sure I had at least some experience before writing that I had made the switch, whether it be good, bad, or great. I really enjoyed my time working with Linux, and had there been a native version of Photoshop to accompany it, I may have never made the switch to be honest. I still use my Ubuntu machine quite a bit. It’s an in-house development server, a file server, as well as the machine on which I capture and touch up photos (using LightZone which used to be a free download for Linux). Linux is by far the operating system I would suggest to someone looking to change things up a bit. You’ve got all the benefits of a UNIX-based machine (as you do with OS X) without the cost. If you’re not strapped to working on tight deadlines, Linux with a virtual machine to run that application or two you simply can’t live without is a completely great solution.

I hope this article didn’t come off as my waving a brand new Apple flag, I simply wanted to offer my experience of switching from Linux to OS X as opposed to the usual Windows to OS X move. If you’ve been back and forth asking yourself whether or not a Mac is for you, the best way to find out is to try. I know it’s an expensive trial, but simply working for a few minutes on a friends machine really doesn’t help you see whether or not OS X is for you. If you’re simply itching to rid yourself of Windows, give Linux a shot with a virtual machine. You really can’t go wrong with a free operating system filled with free software.

I hope to offer some more detailed accounts of what I like about OS X, but I thought I’d test the waters with a bit of an introductory article to see if it’s anything readers have an interest in. Would you rather me not single out software/hardware in what I write? I know that articles written about Apple in general can come off a bit fanboy-ish, and that’s what I’d like to avoid, as I’m not trying to tout OS X or Apple in any way. If readers might be interested in finding out more about the tools I use and my process with them, I’d be more than happy to put some pieces together over the next few months.

Advertise here with BSA

The Mobile Web as it currently stands

The Mobile Web in and of itself requires a different mindset when designing & developing. For instance, while you’re still working with varying screen resolutions, they’re on a much smaller scale. With that comes an entirely new set of limitations that you’ve got to take into consideration with each piece of your design. Designing for a small screen is an adjustment similar to coming up with a style sheet the browser uses for print. It can be considered a limitation, but it’s possible to provide a functional solution at the end of the day.

Moving beyond screen resolution differences, there are also functionality differences when it comes to the Mobile Web. It is a challenge to ensure your designs are properly represented on the various Web browsers available for the desktop. Fortunately, it’s quite reasonable to have a testing environment in which you can test the vast majority of OS and Web browser combinations you’ll need to target. Unfortunately, this isn’t the case when it comes to the Mobile Web. There are countless handsets in production, each with a varying degree of Web “browser”. Some should not even be referenced as a Web browser, but that’s what they’re used for. I can’t begin to fathom what a test environment for every mobile device would look like. Point being, it’s very difficult to test for the majority of Mobile Web browsing environments.

There are also numerous usability concerns that should be taken into consideration. Many concerns have roots in the fact that a much smaller screen resolution needs to be kept at the forefront of thought. For instance, in-page navigation links become more of a convenience if used properly. The Mobile Web is not something I have extensive experience working with, but saying I’m excited to read Mobile Web Design by Cameron Moll is an understatement. From the website:

Much has been written about mobile devices. Much has been written about developing websites for the so-called “standards era” of the web. However, little has been written about the two colliding. This book aims to fill that void.

I can’t wait for the publish date.

So how does the iPhone fit in?

The iPhone brings to the table a feature that has been implemented before, but in my opinion on a much lesser scale. For those who aren’t aware, the iPhone provides a version of Safari specifically adapted for the iPhone. While it is technically the Mobile Web, it works to make the interaction as close to the desktop as possible. It achieves this by providing the same websites we see on a computer, but allows you to zoom in and out using a combination of finger taps and pinching in order to read page content. It’s really quite innovative, and will more than likely have many more people browsing the Web on a mobile device that otherwise wouldn’t have.

Previous mobile browsers have tried similar methods including server pre-processing in an effort to adjust the site design before it reaches your handset. The newly released Opera Mini provides functionality very similar to Safari on the iPhone, only without the touchscreen functionality. Personally, I haven’t had a chance to try either browsers, but I’ve heard good things about both. There was also a version of Opera meant for the Nintendo DS that included a ‘zoom view’ and ‘overview’ embracing the same idea; represent the entire design, but allow zooming to read content.

Other mobile handsets choose to apply any provided CSS with the media attribute set to "handheld". This is a completely different approach which is more or less ignored by the previous method. It is this set of handsets where your Mobile Web research will prove most useful.

The changes we can possibly expect

In my opinion, the iPhone does a fantastic job in providing access to the Mobile Web. The device removes many of the limitations of other Mobile Web browsers, and will be an attractive solution for many people. What’s interesting, is that even though you’re browsing the Mobile Web on an iPhone, the only considerations you’ve got to keep in mind are those you deal with when designing for the screen. The iPhone has brought the desktop Web to a mobile device. Does that mean we should no longer put thought into media="handheld"? Absolutely not. Simply because Safari on the iPhone is very advanced, you can’t discount all other devices and browsers. While many of the high end smart phones could very well adjust their implementation to be more like the iPhone, there will always be lesser powered devices that will not be able to perform at the level of the iPhone. As always, you should be mindful of usability concerns, graceful degradation, as well as accessibility guidelines.

Keeping this in mind, there are a couple things I do feel will change about the websites we visit on a daily basis. I think due to the fact that the iPhone is strapped to an EDGE network, many of the websites we visit often will begin to again take bandwidth and load time into consideration. While it’s a stretch to even suggest it, at the very least, site owners could see that a significant number of readers are viewing their site with an iPhone. While bandwidth should always be a primary concern with the Mobile Web, it hasn’t been a primary concern for many websites in my opinion. This effect may no be very widespread, but more prominent on websites with an audience of iPhone users.

Moving past bandwidth considerations

Beyond that, I truly don’t see the iPhone having a significant affect on the Mobile Web; it embraces too much of the desktop Web to make a huge impact. It can almost be compared to the release of Safari 3 on Windows in that the event has garnered a lot of attention, but the direct effect will be significantly less. What I do hope to see is an increased interest in the Mobile Web as a whole, not only for the iPhone, but by many manufacturers as well as developers. What do you predict?

Advertise here with BSA

Safari Available for Windows

I’ve read a number of articles that were written as a direct response to this event, a post by Mr. Hicks as well as a reaction from Mr. Snook, among others. While Mr. Hicks offers some intriguing questions, I found myself agreeing with much of what Mr. Snook had to say regarding this release.

He said that the release for Windows really doesn’t do all that much for developers working in Windows, with which I agree 100%. Safari uses WebKit, and Safari 2 uses a completely different WebKit than Safari 3, so a Windows developer getting their hands on Safari 3 isn’t doing anyone much good. The improvements implemented in WebKit are exponential in it’s current form when compared to the version used in Safari 2. If you’re looking to test using various operating system and Web browser combinations, it’s best to use them natively (or at least in a virtual machine) in my opinion.

It can’t be ignored what a big change it will be for Windows developers to be able to test in Safari, but in my opinion, this situation (when Safari 3 comes out of beta) will be very similar to the IE6/IE7 mixed distribution. While it will be nice for Windows developers to be able to test in one browser, it will still require a run-through in Safari 2 as well. As will happen with IE6, Safari 2 will eventually be overrun by Safari 3, but that will take quite a bit of time.

Will anyone really care about the release?

So if the release doesn’t help Web developers, will it have any sort of effect on the general population? In my personal opinion, Safari wasn’t ported merely to give Windows users a better experience on the Internet. It was ported because it was seen as a viable way to show Windows users the way of Apple. Many people refer to this type of thing as the iPod effect, iPod halo effect, Apple Envy, or some sort of variant. Hitting Windows users with an application they can use for free, an application they could theoretically use every day, is one more step for Apple in an otherwise Microsoft-oriented world. A Web browser can be a very personal choice for a person, and Apple wants people to choose them.

Firefox has been ridiculously successful in providing people a better way to browse the Web. Apple has seen this success, and in my opinion, feels it is now the best time to capitalize on the idea that Internet Explorer is not the end all be all Web browser for Windows users. It is their time to show that they’ve got a solution as well, and their solution has anti-aliasing in menus to boot. Let us not forget there are also snappy page loads, a small footprint, and that spiffy interface! Safari is an interactive advertisement for Apple, and porting it to the most widely used platform gives the application a very big stage to present itself.

The newest battle in the Browser Wars?

Personally, I’m a big proponent of open competition. If there are a number of high quality Web browsers openly competing to be the best, I think it will force browser manufacturers to provide the best product they possibly can, or else their user base will shift to a provider who can. A very large number of people have embraced Firefox as an alternative to Internet Explorer after it has proven time and time again to be a sub-par Web browser.

To this day I discover quirks and bugs that have continued to prevail in Internet Explorer 7. While it is a slight improvement over IE6, the entire Internet Explorer family of products is truly a sad state considering what is being released elsewhere. At the very least, it’s my hope that Microsoft starts to take their browser more seriously than they have, and the release of Safari for Windows will help to try and make that happen.

The true issue to keep in mind, however, is that the average reader isn’t going to care whether or not you were able to take your design to the next level because you didn’t have to worry about z-index bugs, the only thing that gets noticed is when things go wrong. Many of the drawbacks to Internet Explorer are not seen, heard, or cared about to many people other than Web designers and developers. What does get noticed is a better feature set, a cooler interface, and any performance differences that may be in place. Superior applications will reign supreme when it comes to that criteria, which will eventually decide a winner in any sort of Browser War.

Advertise here with BSA