May 2008 Archives

Testing your web pages/sites in multiple versions of IE has always been a pain. Mostly because you can only have one version of IE installed on your computer at a time (yes, I know there are some hacks you can use to have more than one installed, but they are buggy, prone to crashing and dont give you accurate results). And, if you upgrade your XP installation to SP3, it comes with IE7 with no ability to downgrade back to version 6.

I have long been a proponent of using Microsoft’s Virtual PC and their free Internet Explorer Application Compatibility VPC Images. These allow you to run virtual machines with XP and a specific version of IE (6, 7 or 8; no version of 5.5 available). While this works and is certainly handy, it means that if you want to see how your site looks on all the versions simultaneously, you will have to load up at least two VM’s. Depending on how much system memory your computer has, this can bog things down quite a bit. There’s also the annoying fact that these VM’s expire every 3 months.

So the method works, but it still leaves a lot to be desired. Looks like someone felt the same way, but actually had the know-how and motivation to do something about it!

Released earlier this year, IETester allows you to view your site in IE version 5.5, 6.0, 7.0 and 8.0 beta1 all within a single “window” in different tabs. You can now quickly tab through all 4 versions of IE to see how they compare!

Note that this is alpha software, so don’t be surprised if you experience some bugginess. For example, when I switched from tabs to a side-by-side comparison (similar to the image above) and tried to scroll horizontally, the screen for that IE version went blank and took about 10 seconds to come back. But once they can get these minor annoyances worked out, I can see IETester easily becoming a top-10 indispensable WebDev tool.

I love Firefox extensions. I already use the Web Developer toolbar, Firebug, Flashblock, etc. Now, our CMS has even gotten in on the game. HannonHill has developed a Firefox extension for CascadeServer, the content management system we use here in house.

It provides one click access to editing, publishing and more on any asset as long as it’s visible in the tree. Many users will foam at the mouth at this one; Josh already is. I can’t wait to try this.

ReadWriteWeb had a very interesting post today about how 7 out of the top 10 fastest rising search terms from last year were “navigational search” terms: searches for a website that the user wants to visit where adding .com to the search term would have take the user directly to the site. In other words, instead of typing “www.facebook.com” into the browser’s address bar, the user searched for the term facebook in order to get to facebook.com.

We, as developers, have long been taught that providing your users with an easy-to-remember, intuitive URL is the best way to ensure that your users can find your site. But in light of this new information, I wonder if we, as a campus, should begin discussions on how we can make sure all our various sites are optimized for search engines.

Firefox 3 has been in beta testing for a while now and it seems as though a bona fide release candidate is available. Remember this is only for testing and not a full release, so if you’re not into testing then wait just a bit longer for a full relase. If you’re interested in what’s in store, Lifehacker details the top ten features added to Firefox 3.

Being a usability weirdo myself, I find the feature that removes the back button entirely when there is no page to go back to especially ingenious. Now why in the world didn’t I think of that?

Since Paul wrote some posts on JavaScript frameworks before (part 1, part 2), I thought I’d mention something about CSS frameworks. I’ve begun using them on several projects and have found them to be a huge help. I find that laying out the page is easier, the most common styles are already set and browser bugs are few and far between.

What the heck is a CSS framework?

It’s pretty much a library of pre-built styles that help with designing a Web site. The goal of using a CSS framework is the same as other programming frameworks — to speed up development and ease collaboration between developers. A List Apart wrote a good article on the subject.

Usually, when beginning to style an XHTML page, I’d start with a few basic styles to override some of the browser’s defaults. Then I’d throw in a few other styles for hidden “skip-to” links and basic typography style. This would save me a load of time and without realizing it, I was using a CSS framework!

Other designers used similar methods and one of the first to become widely adopted was Eric Meyer’s “reset styles.” It was a set of styles that would override a browser’s default styles and give the designer a blank canvas eliminating a lot of browser testing.

CSS frameworks have taken this one step further and have included styles for typography, forms, browser bugs and layout grid systems. The methods in which styles are applied have structure so one designer doesn’t have to decipher another’s naming conventions.

OK, let’s get our feet wet with some real XSLT. This entry may seem beyond rudimentary to some, but it’s good to start with the simple XSL elements before we tackle the larger issues, i.e. <xsl:apply-templates />. We’ll hit that one in a couple of entries, but for now here are the XSL elements we’ll be looking at:

• XSLT doctype and <xsl:stylesheet />
• <xsl:template />
• <xsl:value-of /> and <xsl:copy-of />

It’s been two years since our office began our long, strange trip down content management highway. There have been many twists and turns along this road but quite possibly the biggest speed bump we’ve come across has been the application of a new coding language: XSLT. The idea of learning an entirely new language was daunting to be sure, and I’d heard from many seasoned programmers that mastering XSLT was not easy.

Google recently released Google Doctype, “…a Google-sponsored open encyclopedia and reference library for developers of web applications.”

I’m a little disappointed in the content of some of the “HOWTO” articles (they just aren’t very deep) though the security articles are very good. The DOM, HTML and CSS References are top notch and are sure to be EXTREMELY handy in the future.

It seems that the Ext team has updated it’s licensing terms to a more restrictive license. Paul Duncan has an excellent review of what changed and what it means to developers who are considering using it.

What this means for us on campus is that if you are going to use the Ext framework, be sure that you read the license fully before you begin your project, and make sure that your project wont conflict with Ext’s new licensing.

Often in higher ed we use words that people outside academia (see, I just used one) don’t really understand. It’s sort of like a secret club and only those in it can participate in the conversation.

Recently, we started a list on the white board in our break room. This list was called: Words that are overused in higher education. We normally use our white board as a space to entertain, blow off some steam and otherwise have a laugh or two. However, it was really interesting and educational to see the list grow. So much so that I thought it should be shared on this blog.

As you read this list, think about how you communicate with your audiences. Are you telling your stories in ways those outside “academia” can understand? Are we relying on the same old catch-all words that amount to a lot of fluff and very little substance? Are we unintentionally creating the illusion of a special club by speaking in lofty terms that really don’t translate into the important messages we need to send.

There were a few other entries obviously added for laughs like football, bowl games, athletics, “your Mom”, etc. However, I’m sure you get the meaning. Take a look at the list and feel free to add a few of your own. After all, it’s all about the conversation, right?

• excellence
• paradigm
• engaged
• leadership
• diversity
• core values
• synergy
• utilize
• experiential
• impact
• enhance
• innovative
• success
• academia
• scholarly
• matriculate
• mission
• support
• dialogue (as a verb)
• multifaceted
• achievement

If you remember back to my New Technologies on the Horizon post, I talked about how I thought mash-ups, or simply combing disparate sources of information to create a richer experience, is going to be very important in the coming years. I came across an article today about a new project coming out of the Yahoo! labs that is a very good example of how this new method will change the current landscape.

SearchMonkey

SearchMonkey, through the use of php snippets, can take an ordinary search result like this

and turn it into something like this

Imagine being able to have the main missouri.edu search feature able to display not only the results of your search but also other relevant information, like a picture, contact information, etc. right inside the search results listing, thereby greatly enhancing the end users’ experiece!

Opera recently announced the release of their Dragonfly Web Developer application, that will be built directly into the Opera Browser.

From their website

Opera Dragonfly is Opera’s all-new set of developer tools, designed to give developers a lightweight-but-powerful application that provides effective mechanisms for web standards debugging and problem solving without slowing down the browser, and fits in nicely with the development workflow.

To evaluate it, you will need to download the 9.5 beta 2 version of the Opera browser. Once installed, launch the browser and go to Tools/Advanced/Developer Tools.

It appears that with Dragonfly, Opera is taking aim at Firebug. Although similar, Dragonfly is not yet as robust as Firebug, though it is easy to see that it has potential. This is a very early release, so it will be interesting to see what features Opera decides to add to this tool.

Of course, as a developer, ANY tool that helps us do our job in a faster, more efficient manner is appreciated.

Usability is not an exact science. Just because someone did a study that says light text on a dark background is hard to read doesn’t mean it is in your design. Just because Cynthia Says your site is accessible doesn’t mean it is. Every element on the page is relative to each other. To accurately determine readability and usability you have to test the site as a whole, not in little stand-alone chunks.

I agree with almost every article A List Apart produces. I like them so much that I regularly advise people to give the site a read, but I have to say something about their entry, Zebra Striping: Does it Really Help?, because I disagree with its process and what it implies.

I know the study wasn’t conclusive in any way, but this piecemeal approach to usability doesn’t accomplish much. There are too many variables in the way you can construct a table for a simple usability survey study to address. What about text alignment, font choice, line height, stripe color, borders, font size, contrast or table width? All these things affect usability and the study example didn’t vary in any of those ways.

What troubles me most about this type of inconclusive study is that when they get published on a site like A List Apart, it tends to be taken very literally. People read the generic conclusion and start removing zebra striping on their tables for no reason other than because the article said so.

Generic usability tests can be a nice place to start, but don’t let them determine your design and think for you. They are recommendations, not rules. When designing, take a moment to actually read and use the entire page you’re designing. Is it easy to read? Is there enough contrast? Can you tell the difference between navigation and page content? Can you scan the page? Common sense will answer almost all of your questions. If you have the time and the budget, usability testing your design as a whole should cover the rest.

I came across an article this morning and thought I would share.

Average Web Page Size Triples Since 2003

Within the last five years, the size of the average web page has more than tripled, and the number of external objects has nearly doubled. While broadband users have experienced faster load times, dial-up users have been left behind. With the average web page sporting more than 50 external objects, object overhead now dominates most web page delays. Minimizing HTTP requests by using CSS sprites, combining JavaScript or CSS files, reducing the number of EOs, and converting graphic effects to CSS while still retaining attractiveness, has become the most important skill set for web performance optimizers.

WOW. The average size of a web page is now 312K! Granted, if you have broadband, 312K is not that much, but just think back to how long that would take to download over a 56K modem. And while broadband adoption is increasing, most reports show that 20% of Americans are still using dial-up, the majority of which are in rural areas. This gives those of here at the University a very unique challenge: how do we keep our sites looking fresh and modern without leaving dial-up users behind?

The main page at www.missouri.edu comes in at a slim 43K (thank you LORI), Which is about 12 seconds over a 56K modem. A quick, non-scientific sampling of other web pages throughout our University show that most pages appear to be in the 75K range, with a few topping out at over 400K (which would take almost 2 minutes to download over a 56K modem). So what are some easy things we can do to trim down our pages?

Two very simple things you can implement immediately are to save your javascript files and CSS files in a minified version. There are free online tools to help you minify your CSS and to minify your javascript. For example, the styles.css file in use on the www.missouri.edu main page is currently 18K, but could be reduced another 4K if we were to minimize it. And we were able to shave 66K off of the javascript file we are using on the main site.

Be sure to check out websiteoptimization.com’s Speed Tweaks for other tips/tricks on how to speed up/trim down your pages.

In my previous post, I explained what a Javascript Framework is and the criteria by which I used to determine which one I chose. In this post, I’ll talk about which framework I ended up going with, and how it did, and some cases, didnt, meet that criteria.

Before I begin, I need to point out one downside to using a framework that I didn’t mention previously. That is, the code you write for one framework, will most likely NOT work for a different framework. In other words, if/when you decide to switch frameworks, you’re going to end up having to either rewrite your code, or continue supporting the “old” framework even though you might not be using it anymore.

I played with Ext, prototype (mostly because of scriptaculous), dojo, and motools, and ended up choosing mootools. The one that I didn’t try out that I am still planning on evaluating is jQuery.

So why mootools?

1. Does it add code bloat to the user’s download?

One of the great thing about Mootools is you can customize the framework to only include the components that you need. This allows you to customize the mootools javascript file to be as small as possible. Even with every possible component added, the framework (compressed using the YUI compressor) is only 64KB in size. That isn’t to say that other frameworks are larger. For example, jQuery is only 29KB (compressed).

2. Will it work with all browsers?

MooTools is compatible and fully tested with Safari, Internet Explorer 6 and 7, Firefox (and its mozilla friends), Opera and Camino.

3. Does it have solid documentation?

This was one of the deciding factors for me. Mootools has excellent documentation. While it is not 100% complete (for example, there seems to be no documentation on the bind() function), the documentation is easy to navigate, at a glance you know what the function expects (arguments), what it should return and contains a sample of the function in use. In my opinion, it has the best documentation of any of the javascript frameworks (though Dojo comes in at a close second). In addition, Mootools has an incredibly thorough tutorial.

4. Does it support code reuse (is it extensible)?

Not only does it support code reuse, it is a primary focus of the Mootools framework. The whole framework is class-based and modular (which is why you dont need to download every available component). It has been designed to assist Javascript developers to more easily build reusable code. Because of this, there is a multitude of plugins/extensions available for Mootools.

5. Is it unobtrusive and will it support graceful degradation?

This was also one of the deciding factors for me. Mootools contains a custom event called domready that executes a function when the dom tree is loaded, without waiting for images. What does this mean to you as a developer? When combined with the various selector methods, It means that you can keep ALL of your javascript in the head (or in a separate javascript file) and not have to litter the html with javascript snippets, or worry about “element does not exist” error messages (because you tried to access the element before it loaded). It also means that you (or your web designers) can more easily design the page such that, if the user doesnt have javascript available, they wont see any difference.

For example, on the RJI site where we first used the MU Story Gallery rotator, the page is designed statically to display one story, headline, and teaser text. If you do not have javascript, or have it disabled, this is exactly what you will get. But if you have javascript enabled, on domready, the script will take over this section and create the rotating story gallery.

6. Does it have an active community?

In a word, yes. Announcements are regularly made regarding updates to the framework (v1.2 is close to being released) and answers to my questions in the forums are usually answered within the same day.

7. Does it play nice with others?

Yes, and no. Mootools (and Prototype ) both make heavy use of altering the prototype of native objects (String, Array, Function). Contrast this with JQuery and Dojo which are highly name spaced. What does this mean? This means that JQuery and Dojo will (usually) place nice in situations where you either don’t control the other javascript present on a page, or where you want/need to use more than one framework or javascript collection. Mootools, because of the way it alters the native objects, when used with other javascript libraries, can sometimes cause conflicts. So if you use another framework or library that alters the native Array object to include an .each() function, you’re going to have problems. Of course, this is no different than having a library that has a function named foobar() and then try to use another library on the same page that also has a function named foobar().

As I mentioned earlier, Mootools may or may not be the right framework for you. In fact, I plan on giving jQuery a try in a future project just to see if I might like it more. I strongly encourage you to download two or three different frameworks, and try them out. See which one “fits” you best. But no matter which one you end up going with, you will be AMAZED at how much more efficient your JavaScript development will be.

EduStyle, a Web design gallery dedicated to higher education websites, has announced nominations for their inaugural Higher-ed Web Awards and our own Mizzou Wire has been nominated for Best Magazine Site.

Be sure to check out all the other nominees and sign-in to cast your vote.