Chad, 22 Tools for Testing Your Websites Usability

Luke, Analytiks iPhone App
A little while ago I stumbled upon this little app for my iPhone. For those of us that don’t sign in to our Google Analytics often but know we should this app will be very valuable. Analytiks shows me just the important information I’d like to know about my websites on my phone. I can check it quick and get back to whatever else is going on that day. The interface is quite nice. I would ditch the rusted sign look myself but other than that it is fantastic. It is 99 cents in the app store.

Benjam, impress.js
It’s not much in the way of content, but the way that content is displayed. It’s simple… yet eye catching and very intriguing. Makes me very excited about where the web is heading.

Methods Return the jQuery Object
It’s important to remember that most methods will return the jQuery object. This is extremely helpful, and allows for the chaining functionality that we use so often.

$someDiv
.attr('class', 'someClass')
.hide()
.html('new stuff');

Knowing that the jQuery object is always returned, we can use this to remove superfluous code at times. For example, consider the following code:

var someDiv = $('#someDiv');
someDiv.hide();

The reason why we “cache” the location of the someDiv element is to limit the number of times that we have to traverse the DOM for this element to once. The code above is perfectly fine; however, you could just as easily combine the two lines into one, while achieving the same outcome.

var someDiv = $('#someDiv').hide();

This way, we still hide the someDiv element, but the method also, as we learned, returns the jQuery object — which is then referenced via the someDiv variable.

The Find Selector
As long as your selectors aren’t ridiculously poor, jQuery does a fantastic job of optimizing them as best as possible, and you generally don’t need to worry too much about them. However, with that said, there are a handful of improvements you can make that will slightly improve your script’s performance. One such solution is to use the find() method, when possible.

// Fine in modern browsers, though Sizzle does begin "running"
$('#someDiv p.someClass').hide();

// Better for all browsers, and Sizzle never inits.
$('#someDiv').find('p.someClass').hide();

The latest modern browsers have support for QuerySelectorAll, which allows you to pass CSS-like selectors, without the need for jQuery. jQuery itself checks for this function as well. However, older browsers, namely IE6/IE7, understandably don’t provide support. What this means is that these more complicated selectors trigger jQuery’s full Sizzle engine, which, though brilliant, does come along with a bit more overhead. Sizzle is a brilliant mass of code that I may never understand. However, in a sentence, it first takes your selector and turns it into an “array” composed of each component of your selector.

// Rough idea of how it works
['#someDiv, 'p'];

It then, from right to left, begins deciphering each item with regular expressions. What this also means is that the right-most part of your selector should be as specific as possible – for instance, an id or tag name.

Bottom line, when possible:

• Keep your selectors simple
• Utilize the find() method. This way, rather than using Sizzle, we can continue using the browser’s native functions.
• When using Sizzle, optimize the right-most part of your selector as much as possible.

Context instead?
It’s also possible to add a context to your selectors, such as:

$('.someElements', '#someContainer').hide();

This code directs jQuery to wrap a collection of all the elements with a class of someElements – that are children of someContainer – within jQuery. Using a context is a helpful way to limit DOM traversal, though, behind the scenes, jQuery is using the find method instead.

$('#someContainer')
.find('.someElements')
.hide();

I hope this first installment has been useful to someone out there in the interweb, and if not, maybe my next few will be!

Mark, Your Landing Page Sucks!
When we do our planning here at Code Greene we always wait until the end to do the homepage with our clients. The homepage of any website in my opinion is often the very most important page of the site. The homepage acts sort of like the grand unification of the website. I see the purpose of the homepage is to be a place that user’s initial reaction is “oh this is a good site” and secondly its used to point them to the most important parts of the site. In some cases a site can be really flat and the homepage  or landing page may do almost all the work of the site, in those cases it has to be perfect. Recently I saw an article on landing pages and thought it further delved into some good examples. Check it out and rethink your homepage or landing page if it sucks.

When I heard the news that IE has dropped just below 50 percent market share on the desktops, I reflected on when I started to develop for the web. When I started web development seriously, I was working for the Davis School District in Utah. We were required to use IE5, but when IE5.5 came out I was so excited. So hearing this news brought back memories (some good and some bad).

To this date I do not use Internet Explorer. I still like Firefox myself, but I do have Chrome installed. I mostly use Firefox out of habit and knowing how to work my tools or plugins with it keeps me happy. But I have not used Internet Explorer myself since IE6. I moved on to a better, safer, faster, and more compatible browser.

I don’t have anything against Internet Explorer like some other developers. I think it is because I have built many PCs, I have worked on even more PCs, and I have had to interact with the owner of those PCs. They use Internet Explorer out of ignorance. You ask them what browser they use and most of them will say “I use Google.” Then if you follow up that answer with “Oh you use Chrome?” they will say no and you will discover that they use Internet Explorer and Google is their home page.

People don’t know the difference between browsers like developers or geeks. This is where we can help educate them. But before you can educate them you need to really know what the problems are. Don’t just hate it cause it is what most developers do. Know or learn why. I used to swear by Internet Explorer, not at it. But as I learned about ‘web standards’ and I started swearing at Internet Explorer.

Now with Internet Explorer falling below 50 percent market share on the desktop and less then 0.2 percent on the mobile, does this mean we need to stop cross browser testing? No. There are still people out there using the default browser that comes with Windows and they don’t know better.

We as web developers need to still provide the best web browsing experience possible to the end user no matter what browser they use. We need to test the site fully to ensure that it will work in Internet Explorer as best it can. This may not be the exact same experience as when a user uses Firefox, Chrome or Safari but we need to support the Internet Explorer users. Even if you don’t like Internet Explorer there are users out there that will visit your site, your companies site, or your own personal blog that use Internet Explorer.

Another responsibility we have as web developers is to educate the users or your clients to the differences the end user will experience when using different browsers. Not only different browsers but different operating systems with different browsers. Fonts render different, colors are different, and at times the code will need to be tweaked to display differently.

Internet Explorer is still here and still the biggest and strongest player on the Internet. On top of that it is job security that we still have jobs fixing bugs. With the growth of popularity of Macs and more people using mobile browsers I feel that Internet Explorer will become just another browser out there, but will not dictate how the Internet should be displayed as it used to. The browser that will become the biggest player on the Internet will be the one that works well on desktop and mobile.

What browser do you use most often? Where do you see Internet Explorer in 5 years?

What all this has meant to us at Code Greene is that finally more and more of our customers are asking us to design and build for these devices in addition to regular browsers. It has been our philosophy to not venture down dark and lonely roads, so we will often sit back a little to see where new technologies are headed before diving into a pool with potentially only one foot of water in it. Admittedly there have been times we’ve missed waves, but there are other times we’ve ended up saving ourselves a lot of wasted energy. We are at the point that cross device compatibility is now a well lit path we are going to travel on.

There are three different paths that can be taken to develop for these different technologies which are:

1. M.versions approach
2. App development
3. Adaptive/responsive design

It is sometimes hard to decide which path is best so I will explore each and tell you what we will most likely do the most of and why.

M.versions stands for Mobile Versions.  It is basically an approach where the server asks the device what are you? If it comes back saying I am a mobile device, it will then call up a mobile version of the site, which will be smaller and is usually a cut back version. The downside to the m.versions in our opinion is the potential for double work. Coding a regular version and an m.version(s) will inevitably will lead to more coding.

The App approach is probably the most difficult (at least if you are doing an iPhone app), the process to register with Apple and review your app with them is tedious, time consuming, and you could be rejected. Nevertheless, apps have a place and we see people making fortunes through apps. Nonetheless, because our focus is typically on more of a results driven basis, we don’t see a lot of business app requests. The other thing to consider, which to me seems like common sense, but sometimes isn’t seen by the customers, is if you build an app version of your website, at the very least a customer will need to find that app and download it. If you were selling online for instance, where most decisions are being made impulsively, there is high risk that in those two steps you could lose a sale. To support this, I recently read a review of the Magento Mobile version where it was reported that 66% of people surveyed would rather have a browser version than go to all the trouble to download an app.

Lastly, adaptive/responsive, though not a new idea, has re-birthed itself better. For a long time it has been possible to code a site to scale to different browser widths. Now it is just easier. The old process was significantly more labor intensive, requiring several little calculations.  In contrast, the new process works using percentages, eliminating the tedious work, making this a viable and good option. In our opinion, the adaptive technology couldn’t have come at a better time. However, there is a sort of a catch.  If a person has already coded their website, the entire site would have to be recoded to accommodate the adaptive/responsive functions. So, to put it simply, this is something that should be decided upfront and planned, designed, and coded that way from the start. Otherwise, you might be best off with options one or two as an add-on to a current site.

In summary, we feel increasingly more convinced that the growth on the new devices cannot be ignored, and we are primarily recommending the adaptive/responsive approach when making a choice between the three options. If you are interested in learning more or want us to plan out your next project, let us know.  We’d be interested in helping you accommodate your customers who may be seeking your products or services through other devices beyond the traditional browser.

Which version of a mobile website have you tried? Sound off in the comments below.

Mark, Art and The Web Texture
I thought this was a nice article and analysis of Textures by Nick Petite. Though to many people texture may seem like a subtle thing we feel it is an important part of a website for creating the right mood. The thing that Nick points out is how much more dynamic a website can seem once a more interesting texture is added. In web design, I personally really like the layered texture strategies because it helps to neutralize an otherwise potentially overbearing texture, Nick covers the gambit of options and provides some examples, check it out.

Brian, JavaScript Powers Linux In A Browser
I get asked all the time ‘Why Linux?’ and ‘How lightweight it is?’. My usual reply references how Ive seen a Linux web server run off a 2GB thumb drive, but this article trumps even that. With all the overhead the operating systems of today require, people usually assume a servers absolute minimum is even higher. Running Linux in a client-side script like this just blows my mind!

CSS3 PIE makes some CSS3 features work in IE6 – 9. It supports border-radius, box-shadow, and linear-gradient. It works great and is super easy to set up. Unless you use it in WordPress. After some Google searching, a fair amount of testing, and a lot of grumbling I got it working in a WordPress site. It is really simple. I hope that this will save others from some headache.

1. Put the PIE.htc file in the WP Root directory and then reference it in your css as – behavior: url(“PIE.htc”);
2. All the elements that use CSS3 features will need either position: relative or position: block on them

Smashing Magazine – HTML5/CSS3 Cheatsheet – http://bit.ly/aj0yfA

Ben Ludman – URL shorteners and CakePHP – Snook.ca http://bit.ly/btTmSP

And this site – HTML5 Doctor – I couldn’t track down the tweet that I found it from, but it is a great resource for HTML5.

I looked for some tweets about Magento, but just couldn’t find any that were appealing.

The need for this site stemmed from feedback from 3M sales reps. The reps didn’t want to continue to carry around heavy laptops to just show a couple of videos, so 3M provided iPads to accomplish this feat. Rare Method was involved in the execution and design and we provided a solution to their problem.

We knew the site would have a fixed height and width since this was only going to be on the iPad and not used anywhere else. We coded up the site and embedded the videos using the HTML5 <video> tag. There were advantages to this but also disadvantages. If the rep was in a spot with shady WiFi or typical AT&T coverage, then the videos would load slowly.

We also built other pages the reps could use in their sales pitch as well as a contact form that the client could fill out if they were interested.

Luke, Redesign v. Realign
I really liked this article. As designers when we are approached by a client we always start to redesign their project. Sometimes all they want is a realign though. This article defines what a redesign is and what a realign is. The way each is approached is different and when they are followed I think it will lead to more happy clients. The hard part is defining when each is needed. This article will help with that. Web designers give this a read.

Mike, Better Buttons with CSS3
With better browser support, CSS3 is finally starting to get some traction. While IE is still emerging from the dark ages, there’s no reason we can’t start using CSS3. Web Designer Wall recently published an article on creating web buttons with nothing more than CSS. Even though rounded corners, gradients, text shadows, and box shadows aren’t all supported, your buttons will look fantastic for browsers that do, and perfectly usable for the ones that don’t.