Google Wave

Six tiny words that adequately defines my opinion of Google Wave: "too many features with no direction".

When I was first invited to play with Google Wave, I was all excited about it but immediately became overwhelmed with the sheer amount of features it had. It had features like my instant messenger. It had features like my email. It had features like a PowerPoint presentation. The problem? I needed to relearn everything. Again.

Then came the question of who the software was built for. Who were the target demographics? Who benefits from using this software? These things are relevent because the majority of people aren't creative enough to figure out how their lives can be enhanced by these tools.

To this day, I've yet to figure out the full benefits of Google Wave. Perhaps I will play with it again some time, but by then, it probably won't be around.

The grapevine

This morning, the media outlets were all blasting how Apple had been secretly creating their own "Flash alternative" as a means to circumvent their reliance on Adobe products on their platform. I only started reading up on it when someone mentioned "Gianduia".

Apple's Gianduia project is not new. It has been around for about a year and was never a "Flash alternative". It's a framework meant as a tool to assist web developers in building AJAX-driven, rich internet applications. Had these reporters investigated further, they would have uncovered the inaccuracies of the headlines. This isn't journalism; this is gossip. Facts were not checked before publishing.

This is a frightening approach at how media outlets are reporting information; essentially just writing about other writers' articles. There has been a longstanding debate on whether bloggers should be classified as journalists and thus protected by the legislation meant for journalists. This is a prime example against it.

Online Tutorials

I'm always weary of online tutorial websites that teach you how to effectively write HTML/CSS. Although the bios of the authors often refer to the amount of time they've spent working in the web industry, neither does it refer to the type of exposure they've had to different projects, nor does it mention their intentions.

If I were to develop CSS with a strong focus on browser compatibility, it would be far different from developing it with a focus on browser performance (read: Steve Souders). The same goes for CSS intended for longterm use and CSS written to support accessibility. These things are all different.

Websites like Smashing Magazine offer great tips on how to approach the technical issues inherent with web development, but the tutorials should be seen as just that; references. There's no such thing as a one-solution-fits-all. If there was, it would probably be one that far exceeds any clients' budget.

Font substitution, services & branding

I'm well aware of the different methods in replacing fonts on webpages because designers are always looking to add more tools to their design arsenal. sIFR has had limitations, but the recent methods such as cufón, typeface and Typekit have been gaining attention and I thought I'd mention some issues that are uniquely inherent about technical solutions involving 3rd party services such as Typekit.

Some immediate issues -- if their services go down:

1. How will this affect the client's site?
2. How will this affect the client's brand?

Relying upon any third party's services means your client's brand is susceptible to those services. I was on the Bank of Canada website when this error appeared. The service that provided BOC's date/exchange rates failed and produced an empty page with a horrible error message. Aside from a confusing message which a normal user would never understand, what should a user be thinking?

Not only does this error concern me, it doesn't make me want to trust BoC's online services nor does it give me faith in the BoC brand. There will always be a risk when dealing with external services, Javascript libraries or font-replacement services; the question is whether the gains offset the risks? After seeing this error, how much are you more willing to trust this online bank with your money?

Practical applications to reverse-engineering

I find myself spending a lot of time reverse-engineering other people’s work. That is, it’s rather typical that clients have existing systems and frameworks where the amount of documentation is tragically inadequate. The trick is to learn as much as you can about the author(s) and then emulate what they’ve done. And although it’s rather cliché to say this, you really can learn a lot about a person by sifting through their code.

I was working on a project last year which involved developing work specifically targeted for the Nintendo Wii browser. Even though it is powered by Opera, it doesn’t behave the same way as its desktop cousin. The issues are compounded by the fact that there is no official documentation from either Nintendo of America, Europe or Japan; thus it was necessary to break down the issues myself. The full list is a lot more explicit so I’ll simply fire off some of the most glaring facts:

1. There lacks metrical data to gauge the user's environment. The following issues remain unresolved:
   • There are different Nintendo Wii browser versions and they’re linked to firmware patches.
   • There are different versions of Adobe Flash for the Wii browsers. While one version of Flash can handle video well, the other doesn't.
2. During the initial launch of the console, the Wii browser costed $5. Someone found a hack to enable one of the apps –which then allowed for a modified version of the onboard browser to run: The legitimate $5 browser had a different resolution than the hacked. In 2009, the decision was made to offer the Wii browser at no charge, but the divide was already set.
3. What are the dimensions one can work with on the Wii browser? 800x600? No. An obscure width to the likes of 813px. What’s even more strange is that when the <BODY> has a CSS width of 100%, any <DIV> set to “100%” will be locked at 813px.
4. The Wii has a feature that allows users to zoom in and out of the page. This feature – coupled with the onscreen menu — throws Javascript haywire because the viewable screen height constantly changes.
5. Anchor tags <A> as well as tags which can be clicked (ie. adding the Javascript function "location" to a div) will always have a visible border around it. I've yet to find a CSS or Javascript solution to this unsightly issue.

From this experience, I can only conclude that web development experts weren’t initially consulted by Nintendo before the browser was integrated onto their console. Since I don’t personally own a Wii, the likelihood that I'd develop personal work for such a platform is very slim. In any case, good luck to all those who have an interest in it!

Screen resolutions

I’ve been having discussions with my coworkers about screen resolutions and I think it's quite unanimous that screen resolutions will get bigger as time goes on. That is, it will increase for desktop computers. Yet, upon further analysis, there is also another argument that is progressively clear: we have no idea *how* a user will browse web pages as time passes. We recognize screen resolutions on desktop computers will increase, but will desktops be the predominant method of accessing the internet? Apple’s iPad, HP Slate and even cheap netbooks are in high demand. In five years time, how certain are you that you’ll be viewing websites from a desktop computer?

The website that took over my computer

Practically every creative director I’ve come across seems to have this fixation on full-screen, Flash-based marketing websites. I don’t disagree with how immersive a full-screen site can be, but there is one rule that I feel needs to be addressed: don’t alienate the user.

I visited a website recently and upon landing on the homepage, the site’s full-screen video immediately initialized, encompassing the entire screen, disorienting me and ensuring that I no longer have control of my own computer. Not only was this upsetting, I immediately had no intention of ever going back to the site again. This is how you alienate your user: take away their control.

Would it be so hard for the homepage to offer a selection? Give me the option to view the site in a window? Perhaps even prepare me for the fact that the website will commandeer my desktop? What purpose does it serve to force a user to see the site in a specific manner? Does it help the client’s brand or does it help the creative team’s vision? Which is more important?

Hacks

A coworker of mine recently sent me a link to a website that showcased what CSS is capable of doing in terms of mimicking Javascript rollovers and basic behaviours. Although the site did appear to work as stated, I opened up the source code to discover extraneous hidden HTML markup that littered the page. With this new information, I’d have to say that the CSS didn’t work as stated.

CSS is supposed to contain the presentation markup. Javascript holds the behavioural scripting. HTML holds the content. When CSS is used to replace Javascript by means of littering on the page content, this becomes a hack. Using HTML and CSS to create behavioural hacks to do what Javascript can easily do. It’s a cool concept to execute, a poor architecture for implementation.

Limitations and Guidelines

I've been working on a project where one of the personal goals I have set for myself is to try and maintain a consistent user experience. I'm well aware that "user experience" is often used quite loosely and if I were to ask a dozen people, I'd receive a dozen different answers. Regardless, I do think it's necessary to bring to light some of the things that have been surfacing in my head lately about online software development.

I'll first start by saying that I feel it's always necessary to maintain standards. Just as much as the iPhone has a consistent "swiping" animation, these visual aids --whether they're animation, behavioural or even just an underline on a text link-- need consistency. A user should be able to predict what happens when a cursor hovers over a button or when it is clicked. Intuitive design requires a level of predictability.

Even though the creative team has been rather reluctant with setting "limitations" to creativity, I've been trying to set guidelines. These guidelines are rudimentary at best, but they include standards for CSS, animation and behaviours on a per-project basis. Perhaps this may prove to hinder our designers, but I can't comprehend how ten different button rollover animations will help the end-user other than confuse them.

Fonts

An interesting thing occurred just now. I wandered onto a Flash-based website and when I was about to start browsing, Mac OS X displayed a warning telling me that the application (Adobe Flash) was trying to access a specific font in my system. I'm conflicted. In terms of security, this feature is great. Yet in terms of usability, I think this is horrible.

This is the hypocrite in me speaking. I absolutely love the security features that Mac OS X has and have no reservations in tending to a few additional burdens provided that they are required. However, if I were a Flash developers with the intention of building an online Flash application, it would be upsetting to know that a portion of my audience base would get a security warning concerning them about a particular font.

(Not) Found on the internet

Over the past six months, I had been working quite intensely on Nintendo-related projects that include developing work to be viewed on the Nintendo Wii browser. The whole experience has been quite frustrating since -- unlike Xbox or PS3 -- there are no official “Nintendo-sanctioned” devkits or resources to assist the dev community in the development of webpages for their browser. Consequently, anyone looking to develop for the Wii platform must rely heavily on the internet to solve their problems.

This in itself is a paradox. Developers don’t develop for the Wii browser because there are no resources. There are no resources because the development community isn’t large enough where people can and/or are willing to write them.

I had been thinking about whether to post my findings on Wikipedia but I’ve opted against it. I don’t want this work thought of as being “official” on any level. However, I do recognize there are a lot of differences between the Wii and Opera browser engine from which it is based upon and these findings are better off distributed to the public. Instead of releasing all the information I’ve accumulated, I will try to post entries that relate specifically to Javascript development and limitations inherent with the Wii.

In other words: those who have no interest in Wii development are going to see this blog as becoming very boring, very fast.

Naming schemes

Here is a list of minor things about the naming schemes of CSS classes, files and URLs which I've accumulated over the years. Some may be outdated, but nonetheless they were issues found over the course of the last decade of web development:

1. Back in the Netscape days, some of the versions did not play well with underscores. This meant that underscores were specifically avoided to prevent CSS issues associated with Gecko browsers. This may not be an issue anymore but it is still avoided for SEO purposes.
   • GOOD: <A CLASS="db-item">
   • BAD: <A CLASS="db_item">
2. Search engine optimization methods suggest using hyphens over underscores for both CSS classes and files.
3. When CSS classes have numbers immediately proceeding hyphens, the Javascript in some browsers will error. This issue still exists in some IE browsers. Avoid numbers after hyphens!
   • GOOD: <A CLASS="db-item1">
   • BAD: <A CLASS="db-1">
4. In the past, older, legacy servers weren't able to differentiate upper and lower case letters. They would call upon the same file regardless of case. This problem has been “fixed” and therefore, it opens up the possibility of having two different files named “test.jpg” and “Test.jpg”. I highly recommend filenames and URLs containing only lower case. Domains can never be case-sensitive, so why complicate this procedure by introducing capital letters into the URL? Does it make things easier for a user to remember the word AND casing?
5. Classes as contextual information. Naming classes based on a visual aspect “middle-column” has always been frowned upon because CSS is supposed to separate presentation information from the HTML. Instead, class names that describe the component or information works far better.
   • GOOD: "breadcrumb" or "main-content"
   • BAD: "left-column" or "font-size12"

When it comes to web development on large-scale projects, I firmly believe in simplicity and consistency. When a decision has been made on the naming schemes, however wrong it may be, it's best to stick with it. This is a more pragmatic approach because it addresses several things:

1. Developers will always need to work within some sort of limitation.
2. As a developer, you probably weren't brought onto the project to re-code existing work.

And to be completely frank, if ever you *are* brought onto a large-scale project, the naming scheme should be the least of your concerns.

Targeting

<A href="URL" target="_blank">

For those who are unaware, a more "proper" way of writing HTML is to exclude the target parameter from the <A> anchor tag. This has been commonly used on many sites to open links in new windows. From the different documentation that I've read on the internet, using HTML to open new windows is deprecated because it causes problems with braille readers and other devices meant to assist the impaired.

Accessibility aside, my own thoughts on this matter are that web users should be given the choice as to when they feel it's necessary to open a link in a new window or not; HTML shouldn't dictate this. However, when approaching this in a business perspective, there are also many legitimate reasons that justifies why links should open in a new window. One way to overcome the accessibility requirements is to:

1. Build the site where <A> anchors do not contain the target parameter
2. Instead, add a class to those anchors <A CLASS="external-link"/>
3. When the page loads, use javascript to:
   • crawl through the page
   • check all <A> anchors with the "external-link" class
   • inject the "target" parameter into the tag

There are different ways to approach this issue and depending on the business goals, this isn't the always best. The downside to this method, although minor, is that by crawling through the page, you are increasing the rendering time when the page loads. This is, of course, only an issue if the browser is on a slow device, the page contains a lot of objects or if the user is running on IE6.