Going mobile

I don't claim to know a lot about the cellular market but I do get riled up over how phones have been progressing. I've mentioned this to friends and colleagues alike: when I look at cellular devices, I view it --first and foremost-- as a "notification tool". Not a platform to compete with portable gaming devices. Not a device to let me surf web pages. Not a device that recites GPS navigational charts to me. I think of it as a device intended for me to designate what information is important to me and when I should be notified about it.

When I'm sleeping, I want the phone not to ring with the exception if my girlfriend is calling. When I'm in transit, I want it to vibrate. When I'm at work, I don't need it notify me about work emails because I'm already in front of a computer. When I'm in a meeting, I want this phone completely silent with no vibration; just blink a light if an email comes from a specific person. The phone I need must have multiple levels of notification preferences based on location, time, event, recipient, content, priority and personal preference.

There aren't many devices that can do this, let alone do this natively and out-of-the-box. I've been told on countless ocassions that the iPhone is a "better" device and I vehemently do not agree. If someone were to make that argument, they're probably approaching the device more as a multimedia, entertainment or mobile internet device than a notification tool. It's important to recognize that a telephony-capable MID isn't the same as a device built for alertion; but seeing that this line is slowly blurring, is it necessarily wrong to compare the two?

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.

Good for business

Although the work I do can really only be found on the web, I’m a huge proponent and advocator of having “less” on the internet. This statement will no doubt have producers shaking their heads in disagreement, but what I’ve been noticing has been a trend with agencies to over-produce for their clients. Very often, I will see clients sold on the idea that it is imperative for their business to have a trendy, custom-built, CMS-driven, W3C-compliant, accessible website because this will help reach their targeted audience.

As of yet, I don’t know of any established brands that have required one nor have I seen upcoming brands flourish by solely depending on it.

I’ve been looking at hardgraft.com and have been very pleased with its overall online presence. Are there any flashy, complex Javascript that makes things fly out or bounce around on the page? No. Do they require a bevy of art directors and designers to implement layers upon layers of designs and drop-shadows to make their products look “sexy”? No. Do they need an iPhone or Facebook app to help promote their business on the social landscape? No. All these additional things help to do one thing: drive the cost of development up.

I have no doubt in my mind that by building an iPhone app for a client, it will generate additional exposure. By building a scalable CMS, the client’s team will be able to easily update their site and grow with their business as it expands. Accessible websites will allow for a greater web audience and a sexy design will get them noticed. The question I have to all this is whether any of this matters in the longrun if the clients’ business goes bankrupt after having spent the majority of their advertising budget on a website?

Twittering

Several websites I frequent have been posting up ads to hire individuals to write/blog/tweet. What caught my attention about these ads were that they required applicants to have an initial base following. If you blog, you needed to prove you had x number of readers. If you tweet, you had to have x number of followers. I'm not completely familiar with the mechanics of it, but this sounds to me like these websites aren't as interested in "hiring" writers as they are looking more to purchase an audience base.

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.