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.

I wanted to put up a post about Script.aculo.us a while ago, but for some reason have not yet. For those that are not familiar with the Script.aculo.us JavaScript libraries, I would recommend checking them out if you are a web developer. Built on the Prototype framework, these add-on scripts provide a ton of useful functionality for creating user interfaces and other “Web 2.0″ effects such as animations, drag-and-drop capabilities, Ajax controls, and more.

Without getting too technical about what Prototype and Script.aculo.us can help you with, they are a set of JavaScript classes and functions that make adding such effects very easy, and make it so that developers can spend their time creating effects and fine-tuning interfaces, rather than tediously coding out the scripts that they need to make their effects happen. This saves time, which when dealing with designers inevitably means that it saves money as well.

(more…)

The topic of whether or not to use flash in websites came up in our forum recently, and I thought I would do a post about the difference between flash and regular graphic images like GIFs and JPGs. First of all, I do not want to come across as endorsing either method, so I will start by saying that it is a personal choice which method you decide to use on your website. Like everything else in web design, it’s a matter of balancing what you want with the restrictions of how things work.

(more…)

Since I have been absolutely immersed in developing our new website, I thought I would put a post about JavaScript form validation. There are quite a few forms on that will be on our new site, and I have been putting a lot of work into making sure that there are as few server calls for those forms as possible. One way to do that is to ensure that forms are valid before submitting them to the server, which means checking the information that a user has put into the form before submitting it.

There are two ways to validate, one on the server side and one on the client side. The server side option is to submit the form as it is, and then let the server script (such as a PHP or ASP script) check the data. If something is not the way it should be, it will then return an error. Usually the same form would be displayed, with the information still filled in, that includes an error message telling the user what to do. The method requires that the form info be posted to the server, processed, and then a response received by the user. All of that just to let the user know that they forgot to enter their name.

A better way, in my opinion, to validate a form is to let the client’s browser do the processing via JavaScript. This method requires that when the form is submitted, a JavaScript function is called prior to sending the information to the server. That function will check the text fields, look for errors, and reply almost instantaneously since it doesn’t require a call to the server. If the information clears the JavaScript test, the form is submitted and the server is involved. This method accomplishes the same goal, however it can really add to the user experience since the validation process happens in an instant.

In order to do this, you will need to add either an “onsubmit” attribute to the form tag, or add a “submit” event to the form from an external file (which I recommend). The validation JavaScript function should return either “true” or “false” to denote whether or not the form should be submitted. Your “onsubmit” event should then return that value, which will tell the browser whether or not to submit. For example, say we have a form called “loginForm” that we want to validate with the function “validateForm”. That function will return true if everything is fine, and false if the form info is not valid. We would then attach the function by using something like this for the form tag:

form name=”loginForm” id=”loginForm” method=”post” action=”/login.php” onsubmit=”return validateForm();”

This becomes pretty easy once you have written a few, so if you are looking for help with form validation please post in our Community Forums, and I’ll see what I can do to help people out.

We are getting ready to begin the major development on the next generation of our website, at least once we get through some of the preplanning stuff. In the hopes that we will be able to present a new site on or around the New Year, we have a lot to do before then. Mostly it means that I have a ton to do in the meantime, although I will probably be recruiting some help for some parts of the new site. One thing that I have been working on while the planning happens is scripting some Ajax interfaces for various things on the site.

For example, we will be sending out a newsletter when we make our transition (did I mention that we are going to be focusing more on electronic delivery in the future?) and we would like for people to be able to sign up easily. Rather than having a page that a user must click to in order to sign up, we are going with a nice, simple signup form that can appear anywhere we want. Don’t get me wrong, there will still be a page explaining the newsletter and providing information about it. After all, who would sign up for something without knowing what it is.

However, for those that do, I would prefer that they simply fill out their email address and continue on their way. To get that simplicity I am creating simple Ajax forms to collect the signup information. Once the user clicks “Signup” on the form, they can go about their business while the database is queried and a response is sent all in the background. That would be the “asynchronous” part of Ajax. It’s a nice little thing, but here are the issues that need to be addressed when creating an Ajax form.

First, the form needs to be told to run the script. I attach the script that I want to run to the “submit” event of the form. In addition, I also disable the default action of the form (the page that it would load if there were no JavaScript) via JavaScript. This makes it so that if the user does not have JavaScript, the form behaves like every other form and works fine. However, for those that do have JavaScript (99% of web browsers) the JavaScript will take over, essentially “hijacking” the submit event of the form. From there, the script collects the data (email address), then validates it, and finally sends the information to the server and waits for a response.

Our subscription form on this website is always a work in progress, but I wanted to post about a recent minor upgrade that we had to do. It seems that a lot of people are not quite familiar with which country they live in, or that it may be important to actually put the right country into the form. I will admit, I have just thrown values into web forms assuming that since I provided a US mailing address, it’s obvious that I am in America. Seems reasonable. The issue with us is that the subscription form uses your country of origin to determine whether or not to charge international shipping charges to your subscription.

In short, due to what I would consider a large amount of errors (enough to where we had to make changes), we installed some JavaScript validation that will ensure that depending on the state you choose in the drop-down menu the correct country is also chosen. I know, it’s surprising that we would have to do that. However, it will prevent people from pulling down “Manitoba” in the states field and then “United States” in the country field. It goes much deeper than that, and will essentially sound an alarm when you try and provide a combination that won’t work. Hopefully this will ensure that everyone gets their printed issues.

On this note, I would like to encourage all of our subscribers to log into their account on our website and click “My Account” at the top right of the screen. Then choose “Update Profile” and make sure that your mailing address and email information are correct. We have also recently installed a feature requiring subscribers to verify their email account before completing their subscription because we have seen a LOT of mis-spelled email addresses. If your profile is set to “me@mydomain.coom” you are probably not receiving the emails that you should. To ensure that we provide the best service, please take the time to update profile information. Thank you.

Alright, so we may have won the battle, but the war is probably never going to end. I wanted to post here about our recent email spam problems, as I have been chipping away at them for about a week. It all started with our community forums, and the issue of some robot that would create an account and then post spam on the boards. After changing the forum configuration to require that someone verify their email address, that one seems to have stopped. It’s interesting, as we will get FAILURE NOTICE emails every once in a while as they try to create an account by providing a bogus email. Each notice that we get represents a malicious spammy robot that has been denied. Nice.

Then there are the emails. A normal amount of email spam is rather normal, and I am a believer in using my local mail application for junk mail filtering, just in case an important message doesn’t make it through. However, we are talking about hundreds of emails a day, which is a problem. As I mentioned, there were two avenues that the spammers were abusing. The first was the reverse DNS lookup which leads to emails being blasted at random accounts on our domain. Simply denying all unrouted mail and using MAPS spam protection seems to have halted those. The second vector for blasting emails at us was through our online forms. Robots would apparently get the URL for the forms, and just hit those URLs with spam messages.

This one required me to change the scripts that handle the form. I’ll admit that they should have been this way to begin with, but they weren’t. Essentially, I wanted the script to verify that the form was being submitted by a visitor to our website, and not from some other source or robot. An effective way to do that, which will take care of most form abuse, is to compare the referring URL of the form data with your domain name. Simply put, unless the form data is submitted from our domain (the referring page) the script will not allow an email to be sent. I also added some other checks to ensure that the data is entered by a person and not by a robot.

One last note on email spam is that spammers scan website with robots to harvest email addresses. One of the things that I need to do to our site is to remove the email links as they are and have them written to the browser via JavaScript. For example, rather than having this code to create an email link:

<a href="mailto:sample@email.com">sample@email.com</a>

I would use JavaScript to write the code when the page is loaded in. Since getting the address then requires that a robot or spammer to run the script (which is probably not far off, but currently rare in automated email harvesters), they are a bit more protected. The JavaScript code (greatly simplified) would look something like this:

<script language="javascript">
var account = "sample";
var domain = "email.com";
var txt = "Email Us";
var link = "<a href=\"mailto:" + account + "@" + domain "\">" + txt + "</a>";
document.write(link);
</script>

This script would be placed in the same place that the other code would have been. Of course, this is a simple version which will work as is. There are also javascript encoders that will encrypt the email address to hide it. Using an encoder will be much more powerful than this, and is something to look at if you continue to have problems.

I have been playing with Javascript a lot lately in my spare time, and I thought I would put a post here about some of the ideas that I have been having. Most people are already familiar with most of these things, as big ecommerce sites like Apple, Amazon and others have already been doing this on their sites for a while. What I am talking about is interfaces that load information without reloading the web page itself, which is made possible via AJAX. AJAX essentially means using Javascript to talk to the server in the background, and updating a web page to display the response. This all happens asynchronously, so that the user doesn’t need to wait for a page reload.

So here are the ideas for our website that I would like to plan on putting into the next incarnation. Or if I get a moment, maybe try and get them in. Either way, I welcome comments to this post about what other people think, and how we can make this site more friendly to users. So here goes:

1. Integrated Search Function: Currently the search function on our site searches the database of articles and brings back the results according to relevance. While an “advanced search” page would need to be created (especially as time goes on and our article archive grows), I would like to see the search box on the right side perform the search in the background. You would enter a search, and when submitted a “loading circle” or something would inform the user that the server is being queried. Once the results come back, the top ten or so would be displayed in a scrolling box, which would appear in the search form. Of course, you would need an option to click to a full results display, but I think that it would be an interesting feature.

One common AJAX implementation lately is the live search, which send a search request to the server every time a character is typed into the search field, and relevant search suggestions are displayed. Not going there, since they bother me. But I thought it was worth mentioning.

2. The Subscriber Login: When a subscriber logs into the site, I would like to see that happen in the background as well. Rather than the current method, which logs them in and re-directs, AJAX would allow us to send the login information in the background. Again a “loading circle” or something would display while communication is happening, and then the response would trigger a change in the page. A successful login would display a greeting and account links, and a failed login would explain the failure and show login form again.

3. The Newsletter Signup: This is another spot where there is user interaction, and the page is reloaded to show the results. I think that we could get this one to be the same as above, with the signup form being greatly simplified and the interaction not disrupting the user experience of the site.

4. RSS Feeds: Another fun little AJAX trick is to pull RSS feeds from various places and display them. This can be done all the time, or started when the users clicks a button. In this case, I think it would be cool to have the latest blog entries from each of our blogs show on the main blogs page, or even the home page. This would be a “ticker” of sorts, that accesses the feed and simpy scrolls through the RSS feed, displaying a summary of each entry for about 30 seconds or so. Again, nothing too crazy, but fun.

5. The Subscription Form: Don’t get me started. This thing could be made much more intuitive using AJAX, but that will require an overhaul on the subscription system that we use. I haven’t gotten there yet with it, but know that I am looking into this one, and I’ll post about it again soon.

So these are simple little things, which we could use AJAX to make a little easier. However, in the end they make the website more user friendly, and they afford us options in displaying various content should we ever decide to take advantage of that.

Again, I would love to hear comments from readers about where they would look at streamlining the site, whether these improvements would be worth it, and what other people have to say about these ideas.

In our May 2006 interview with Zoovy.com’s CEO, David Steel mentions AJAX a little bit when he is talking about new web technologies related to the “Web 2.0″. I wanted to post a small explanation for those who are a bit confused with the Web 2.0 thing, as well as AJAX.

First off, the “Web 2.0″ is a buzzword for a shifting paradigm in the way that developers and engineers are looking at the web. In a nutshell, “Web 2.0″ encompasses an idea that the web can be used as a platform for applications. For example, you may have read news as of late about Microsoft competing with Google and Sun to get web services available that will keep it’s Office suite competitive. The root of this is that Google, Sun, and a bunch of other companies are recognizing that they can offer web-based services like word processing and spreadsheets. Rather than having to buy the application and run it on a Windows platform, users can access the application online, using the Web as a platform. Make sense?

What makes a lot of this possible is improvements in JavaScript, CSS, XML, and XHTML, and the way that browsers are able to handle this stuff. By making the browser do more work (client side), developers are learning how to provide robust web services and unique user experiences. Look at Google Maps or Google Suggest as the beginnings of these services. Google Suggest queries a database every time you type a letter into the search box, and returns suggestions for your search.

This is impressive because the interaction with the server happens without a new page loading, or in the background (asynchronous). Enter AJAX, which stands for Asynchronous JavaScript + XML. Due to the XMLHttpResponse Object (and the Microsoft ActiveX equivalent for Internet Explorer) in JavaScript developers can now write scripts that communicate with a server in the background. This allows developers to create much more robust interfaces and retrieve only the information that the user requests from the server, eliminating the need to constantly reload pages. The maturation of the browser DOM allows XML data to be parsed and displayed, which opens up a world of possibilities.

While the advantages are numerous, especially from the standpoint of getting information to the user, there are set-backs. Search Engine Optimization becomes increasingly harder, since much information in AJAX applications is called by JavaScript, which search spiders do not read. Also, don’t put too much stock into the “technology” behind AJAX. If you were to ask me, AJAX should stand for “JavaScript finally works!” I look forward to seeing what people come up with when it comes to AJAX.

As a Flash geek, and someone that loves the possibilities that Actionsript provides, I have a feeling that we are going to see some VERY impressive websites built with AJAX techniques.