Every developer looks for ways to save time and do things more efficiently, and I am no exception. That’s why I wanted to post about a service that I find myself using frequently, particularly with the rise of Ajax forms and other user interface demands, which save me quite a bit of time– AjaxLoad.info. AjaxLoad is an example, at least in my mind, of a web service that fills a niche very well. In this case the niche is the need to create animated GIF images that serve as loader icons for Ajax forms.

You see them more and more now on the web, especially now that Ajax forms are becoming more of the standard than the exception. Animated GIF images such as the spinning clock face, or the horizontal load bar, became somewhat of an expected interface item a few years ago when large sized flash sites came on the scene. Showing a user an icon to keep them occupied while a load is occurring, or to simply communicate that some sort of processing is happening, can go a long way towards usability. The problem for developers and site designers is that animated GIF images can be laborious to create, especially when you have to create a custom load icon for each project that you are working on.

(more…)

So I have been banging my head against a wall lately trying to figure out how exactly an ecommerce merchant, or anyone for that matter, determines whether or not they are required to abide by the Americans with Disabilities Act with regard to their websites. We have done some articles recently on accessibility, and it remains one of my interests. With that in mind, and having read as much as I think I can about it, here is what I have come up with. Keep in mind that this is not legal advice, or anything close to it.

First of all, the ADA provides protections for Americans with disabilities, ensuring that they are not denied access to employment and services based solely on their disability. For the most part, every employer is aware of their obligations under the ADA with regard to their employees, and if you aren’t, the I highly recommend giving the ADA a read. However, I am more interested in how websites play into things. Particularly since the highly publicized lawsuit brought against Target because their website was not accessible. Most recently the lawsuit was given class-action status which sets one of the first legal precedences in this matter. I suspect that there will be many more, based on the following.

(more…)

Recently I have been working on our new website, and one of the interface challenges that I have been facing has been modal windows, or windows that block input to other areas of the page until someone closes them. A good example that we are all probably familiar with is JavaScript alert boxes. These are the alert and confirmation windows that appear over your web browser (or sliding out of the top) when a warning is triggered or you are required to provide input. Go to our home page on this site and try to search for a blank term, and you will see what I am talking about.

JavaScript modal windows have their time and place. They are pretty limited in general, and I wanted some way to provide a modal window that will behave much more like a traditional pop-up window. The answer for me was with Lightbox Gone Wild, which is a great JavaScript and CSS creation by the very Chris Campbell over at ParticleTree. Based on the original lighbox.js by Lokesh Dhakar, this group of scripts that is based on the prototype JavaScript library makes creating a clean, browser compatible modal windows very simple. Not only that, but as the name suggests, it provides a clean “lightbox” effect for the content loaded in.

My experience with Lightbox Gone Wild has been positive so far. I agree with Chris, the author of the Gone Wild version, that the original Lightbox.js is a bit limited in it’s abilities, and when comparing the two I am impressed with how flexible the Gone Wild Version is. As a developer is is unobtrusive, required only that the scripts be linked to, and CSS classes be added to markup to add functionality. There are plenty of options, including the placeholder that is displayed while the real lightbox content is being loaded in. Oh, and did I mention that also does not break any accessibility guidelines?

Personally, I have been impressed. I’ve been trying very hard to keep an eye on accessibility and separation of content, formatting and functionality as I develop the new site. Additionally, usability is high in mind, and with tools like Lightbox Gone Wild out there, I am able to work much more efficiently.

Just kidding… you can’t. But it’s a good title for a blog post since if you run into the problem that I ran into, you probably searched for that. The reality is that iFrames are a bad idea, and have been for years. The harsher reality is that they are not allowed at all in xHTML 1.0 Strict, meaning that either a browser will not even display it (which is probably the better option) or it is displayed but causes your code to not validate. Usually this never comes up, since we usually just assume that frames are bad and to avoid them.

But what about when you need to upload some images and you want to do it without updating the page? Ajax does not allow for file uploads, so that is not an option. A good example of this is a Wordpress interface when you are creating a new article. In order to allow someone to upload an image for placement in their post, there is an iFrame there to accomodate that. At least in my installation, I wouldn’t be surprised if they have upgraded that part. Either way, I want our editorial staff to be able to upload images when they are composing articles without having to refresh the page (and potentially destroy their edits). An iFrame is not an option since I am taking great care to make sure that this application is XHTML 1.0 strict, and also compliant in the Big Four browsers.

(more…)

Today is a rainy day on the Oregon coast, probably the fifth or sixth in a row. Just the kind of day that you want to be going through a new web layout checking for inconsistencies in different browsers. So I sit with my Apple laptop and my super-cheap Compaq laptop running Windows XP. On my Mac I’ve got my website files open in TextEdit as well as views in Safari, Firefox and Camino. Camino is a bit repetitive since it is a Mozilla browser, but why not, right? On the PC I have almost no software other than Internet Explorer 7, Internet Explorer 6 and FireFox. As I develop a new website, I divide it into chunks so that as each chunk wraps up it is then put through some testing and other QA checks. That way I’m not building on a broken foundation, and the plan is to go through the pages that I need to check with each browser and root out inconsistencies. Then try and fix them.

First, a word about browser consistency. There are a ton of things that look different in different browsers and different operating systems. For example, on a Mac my site uses the font “Lucida Grande,” however on a PC it defaults to “Arial” since many PC’s to not have the Lucida font. In a reverse twist Safari will put a purple “highlight” border around text areas that have focus, whereas other browsers will not. In some cases these differences are things that do not affect usability, and are nothing to focus on. Unless you want things to be perfect as they can be, like me. In my case, I have put a ton of work into creating an interface that will look and behave as consistently as I can get it across different browsers. By using JavaScript and CSS, I have been able to incorporate my own text area borders (hiding the pesky Safari ones) and interactive effects that work in all browsers.

(more…)

Sorry about this, I know that I was supposed to put a post about expiring caches in Rails, and I will. I have been busy with other things lately and have not gotten much past changing my ways to reflect the RailsEnvy cache sweeper methods that I posted last time. Alas, this will be a small post, and a diversion, but I had to put my two cents in about the iPhone. I recently received mine, and there are a couple of things that I wanted to chime in about as a web developer. (more…)

Now that the iPhone is out there and in full-swing, there is an interesting set of challenges that web designers are going to face more and more as mobile devices become more Internet friendly, and that is how to design sites for these devices. To start, let’s take a look at how the iPhone accessed websites, and what it does to display them.

To start, the iPhone uses Safari as it’s web browser, which is nice since Safari is a compliant, high-performance browser with some pretty cool features that designers can take advantage of. Nothing new there. There are 2 areas that are going to be new to web designers. The first is that the input device with an iPhone is not a mouse, but rather a pair of the users fingers. The second issue is the display size, which offers two variations on the size of the screen- either a wide-screen (short and wide) or a portrait screen (thin and tall). To start with, designers will need to be able to determine what users are using an iPhone and can find out using the user-agent string included with all requests. For an iPhone user, the string will look like:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+
(KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

As you can see, the platform string contains iPhone; U; CPU like Mac OS X; en, which is nice since that makes it easy to find iPhone users. Using that information designers can have a specially formatted website sent to iPhone users. Now that we are able to target iPhone’s, let’s see what the above challenges are going to mean. Another (better) method is to provide a separate CSS stylesheet to users with small screens (such as mobile devices) by using the CSS3 media query inside your LINK tag for your stylesheets:

link media="only screen and (max-device-width: 480px)"
href="small-device.css" type="text/css" rel="stylesheet"

This piece of code with select out only iPhones, since they only have “screen” CSS capabilities and the maximuum screen width (device width) is 480px. By doing it this way, you can publish your content only once, and use varying CSS stylesheets to provide the user experience that is specific to a user’s device.

(more…)

As this week wraps up, we are getting ready to implement some of the changes to the website that we have been working on for a couple of months. To start with, we are upgrading to PHP5, due to some of the performance gains and also security improvements. At the same time, we are replacing the database abstraction layer on the site. This represents the PHP objects and code required to interact with the database, which in the past was causing us some performance issues during traffic spikes. One of the most taxing elements of the website to the database is the advertising mechanism, which serves and tracks ads on our site. Since there is a lot of database interaction, we took the time to re-write that section (including improvements to our database structure) so that it would not cause bottlenecks.

As it stands, we are going to be in a position next week where I don’t think that we will see a performance issue with the site again until it is a hardware related problem, such as getting so much traffic that we reach the limits of what our server can do. We’ll deal with that when it comes. As for me, I will looking at putting in a mechanism to control some of the article comment spam that we have been dealing with.

(more…)

This should be a fun one. I wrote an article recently for the magazine about Ruby on Rails, which was meant as a primer to those that aren’t really immersed in programming. Some developer was bound to chime in, and they did, and in fact it went exactly like this:

“Rails is a full-stack, Model-View-Controller (MVC) web framework, designed using the Ruby programming language.”

Which was followed up (after some prompting) by this further explanation:

“Model-View-Controller is a software development pattern. In MVC, you put your business logic in models, your presentation (web pages) in views, and use controllers to connect them.”

Both of these are completely accurate (thanks, Lee) and from what I can tell are something that it wouldn’t hurt to explore more in a blog post. If nothing else, it’s worth a stab at trying to relate this to everyone, since it is an important topic.

(more…)

Well, our work is being done, and things are starting to improve. Over the weekend some of our optimizations were implemented in the live site, with more to come. As some of you may have noticed, our site sometimes slowed down in previous weeks, particularly when there has been periods of heavy traffic. For those that just tuned into this saga, it took a while for us to nail down exactly what was causing the problem, which primarily has been in the interactions with the database. To get more specific, the mechanisms that track the ads on our site needed to be optimized, as they were causing slow downs. I won’t get into too much detail, but it had to do with the database checking IP addresses and such to determine whether ad viewers are first-timers or not.

In the process, we were able to nail down a few other measures that we can take to improve performance over the long term, and to ensure that we will not be presented with this problem. Make no mistake about it, the primary weakness in the site has been my programming limitations, but considering that I built the site myself, it could have been much worse. By the beginning of May we hope to have the following changes implemented: (more…)