Interface_

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.

Personally, I use Firefox for all my web surfing and only use IE when testing websites. But, I know there are many people out there who prefer IE, or who have to use IE because their IT department requires it. In either case, I came across this article over at lifehacker.com and thought I would pass it on to all of you.

Get Firefox’s Best Features in Internet Explorer

We've been conducting several interviews lately for our programmer position. Though the position doesn't specifically mention it, any Web Application Programmer has to be familiar with Javascript. So, one of the questions I have been asking applicants is if they have ever used a javascript framework. If so, which one have they used, and what made them decide on that specific framework. To my surprise, not one applicant answered that they had used a javascript framework.

Wow.  If you aren't using a javascript framework, and you have to do any work with javascript at all, you really should consider giving them a try.  But let me back up and start out with explaining what a javascript framework is.  A framework is essentially a collection of code (library) you can use to make development easier.  If you've ever dealt with javascript before, then you are familiar with how difficult it can be to work with, especially when you need to make sure the code is cross-browser capable.  A javascript framework can do some of this "heavy lifting" for you and allow you to focus on the actual code design, instead of having to worry about browser-specific quirks.  Essentially, javascript frameworks allows you to be more efficient when coding javascript.

Now, you shouldn't go out and grab a framework and start building a site if you aren't familiar with Javascript.  Knowing the underlying language will make your code better, and there's a good chance, that at some point, something is going to break.  If you don't understand how the framework works, then it's going to be just about impossible to troubleshoot.

There are numerous javascript frameworks available to choose from (this is NOT a complete list!):

• Prototype
• Mootools
• JQuery
• Dojo
• Ext
• Mochikit
• Spry

All of them have their strengths and weaknesses.  The one you go with should be the one that best fits what you are trying to accomplish, has the feature sets you need, and provides the level of documentation that you require. 

But that really doesnt help you decide which one to use now does it?  Here are the things that I thought about when researching which framework to use:

1.  Does it add code bloat to the user's download?
For some of our projects, the page itself was going to be fairly simple.  I didnt want to add a 100K javascript file just to be able to add a nice effect.  I wanted the framework to be small enough that the majority of our users would not notice the additional download at all.

2.  Will it work with all browsers?
We have to support ALL of the major browsers in use, and a good portion of all of those browsers' various versions.  So the framework I chose had to have built-in support for as many browsers as possible.

3.  Does it have solid documentation?
I do a lot of php development, and php has some of the best documentation available.  In some ways, this has spoiled me when working in other languages.  I want to be able to quickly look up a function, see a brief description of its purpose and quickly and easily be able to tell what the function expects and what it will return.  I also expect a small code sample of the function in use.

4.  Does it support code reuse (is it extensible)?
Part of this is dependent on the developer, but I wanted a framework that easily lends itself to building code classes that can be quickly and efficiently reused.

5.  Is it unobtrusive and will it support graceful degradation?
Our sites and applications have to be accessible. This means that there is a good chance that some of our users will be using browsers or other technologies that do not use javascript, or might not have javascript available.  So I wanted a framework that didn't require me to litter the HTML with javascript everywhere.  I wanted to make sure that if javascript wasn't available, the page would quietly degrade back to pure HTML while still providing the user with all functionality and information necessary.

6.  Does it have an active community?
No matter how good you are in a language, at some point, you're going to get stuck.  I wanted to make sure that the framework I chose had an active, supportive community behind it where I could get some help if I needed it.

7.  Does it play nice with others?
I didn't want a framework that pollutes the global namespace and makes it difficult or impossible to use additional javascript libraries on a page.  So the framework needs to use a methodology that encapsulates itself from other script on the page, or provides me a method to allow it to be used with other libraries.

In my next post, I'll discuss which framework I'm using now and how it addressed each of my concerns.

I often get requests to put audio or video files on Web sites and turn them into “podcasts.” Unfortunately, an audio or video file alone does not a podcast make. I often don’t have the communication skills or the time to easily explain that you need more to make a podcast, so I just put the files up.

Now, thanks to CommonCraft there’s a fun and easy video to explain what podcasting is to anybody. Thanks guys!

More videos explaining other Web technologies at the CommonCraft Show.

Thanks goes to my brother for sending me this.

Design Coding