Stephen (Steve) Withington - Web Usability

Mobile, Handheld Computing Devices: Where Does the Web Developer Fit In?

Tue, 27 Oct 2009 08:35:00 -0700

Recently, I was involved in a lively discussion at a ColdFusion and Flex developer conference (BFusion/BFlex) held on the campus of Indiana University in beautiful Bloomington, Indiana. Michael Labriola led the discussion, which took place during his keynote presentation, between a panel of many other developers who are active in the ColdFusion and/or Flex communities. Sometimes it's difficult to articulate your thoughts at the time of a discussion, hence I'm using this medium to do a sort of brain flush at the moment. I'm doing this also because I think the topic of discussion is an important one to consider for those of us who primarily develop applications for the web.

As for expanding the definition of 'who' actually develops applications for the web, I hope to include anyone who is involved in the process of creating rich internet applications (stakeholders, account executives, creative's, designers, developers, etc.).

Mobile Phone vs. Handheld Device

First, I think it's important for 'web' developers to try to disassociate the word 'mobile' from the word 'phone.' I myself prefer to use the word 'handheld' when referring to any type of 'mobile' device. 'Handheld' feels much more inclusive to me than 'mobile.' Whereas 'mobile,' while by itself is probably a more appropriate descriptor, can be more exclusive sounding due to its association with the more specific type of handheld device commonly known as a 'cell phone.' So when I use the word 'handheld,' I am attempting to include 'any type of compact, portable computing device.' I am purposely using a broad definition here since mobile phones only constitute one slice of the larger 'handheld, mobile computing' marketplace.

Don't Hate Apple Because Their Beautiful

Let's face it, Apple has definitely shaken up the market with their lineup of handheld devices including the iPhone and iPod touch. Whether you love, hate or are indifferent to Apple's handheld products, you can't deny that Apple's use of interface design and touchscreen technology has transformed the way other companies are designing and building handheld devices. Not to mention the number of features and available applications! I'm sure that there have been, and will continue to be, many conversations around conference tables about what works, what doesn't work and how the iPhone and iPod touch interfaces can be improved upon. Rather than throw my own subjective opinions into the mix at the moment, I will say that as an iPhone user, I certainly have my list of gripes. However, Apple has most certainly revolutionized how people can actually use a handheld device and interact with each other, the web and beyond.

Application Distribution

Take a moment to review this list of digital distribution platforms for mobile devices from Wikipedia. Considering the fact that the Apple App Store opened on July 10, 2008 and as of September 28, 2009 there are over 85,000 third-party applications available and over 2 billion application downloads to iPhone and iPod touch users, I'd argue Apple has definitely made some in-roads with software developers and end-users alike. Compare that with Google's Android Market with 10,200 applications as of September 2009 and you just might agree.

I'm not suggesting that the model Apple used to create their 'Application Empire' is the right one, but without a doubt, they appear to be doing something right. I most definitely don't agree with some of their practices, but one can't deny their level of success when compared to any other digital distribution platform.

Distributing Handheld Applications via the Web

As of today, reliably deploying an application on the web that is specifically targeted to handheld devices with a web browser is extremely difficult to do, assuming you want to offer anything more than some basic text and a few form fields. While work is currently being done to improve standards on 'technologies to enable Web access anywhere, anytime, using any device,' developers are pretty much left in the rain waiting for handheld manufacturers to adopt these standards and turn them into practices.

Once again, Apple has made significant strides in getting their handheld users online. In AdMob's Mobile Metrics August 2009 report, iPhone's worldwide operating system share has grown from 33 percent to 40 percent in the preceding six months. In addition, iPhone represented 50 percent of US smartphone usage in AdMob's network in August 2009, followed by RIM and Android devices at 14 and 13 percent, respectively.

What truly makes these numbers phenomenal is that Apple's handheld devices actually account for less than 15% of the overall Smartphone OS Market Share. Yet, this small group of users account for half of the US smartphone usage within AdMobs's network. This information more than suggests, it screams that iPhone and iPod touch users are actually using their handheld devices to go online.

As a side note however, it is frustrating that Adobe Flash is not yet supported on Apple's iPhone or iPod touch. Sure, efforts have been made so that iPhone and iPod touch applications can be developed with Flash and ActionScript 3, but users still won't be able to view Flash content delivered via the browser. To be clear, this is not the fault of Adobe. Apple, for whatever reason(s), has chosen not to support Flash at this time.

Final Thoughts

I think it's important for those of us who primarily develop applications for the web to continue our discussions and thoughts on how we can better address the needs of the ever-growing handheld device marketplace.

I believe we can learn from Apple's strengths and weaknesses to find and improve a model of 'handheld application development and distribution.'

I think if designers and developers can learn how to better account for users of handheld devices regardless of whether or not they visit a web site, overall usability can be improved for these users as they look for goods, services and/or information.

These are merely thoughts, and obviously they're constantly evolving ... even while I've been writing this article. I hope my thoughts also inspire you to think about this topic and look forward to reading and/or hearing your thoughts on this subject as well.

Disclaimer

I don't work for Apple nor have I received any compensation from Apple for writing this article. I wouldn't mind it if they decided to do so, but as of the date of publication, this has not actually happened. Finally, no handheld devices were harmed in the writing of this article.

MySpace Can Update Your Twitter Status ... Who Cares?

Mon, 21 Sep 2009 12:22:00 -0700

MySpace has announced users can now automatically sync their status updates with Twitter. Is having the ability to create a "Global Social Status" (yes, you can use that ... I just made it up) really such a good thing?

Not long ago I ran across an application in Facebook that would pull in my Twitter updates and automagically update my Facebook status. I quickly learned that this was not exactly the best idea in the world (and I'll tell you why in a moment), so I'm not so certain the efforts of MySpace are going to bring about any kind of improvements in the social media communities.

Let's think about this for a minute ... if you're a friend of mine on Facebook (or MySpace) AND you follow me on Twitter ... do you really want to read my status updates everywhere you go? For serious, does it make sense to "shotgun" your updates to every single social community you belong to? I think not.

Sure, there are rare occasions that you might want to do this ... but I say resist the temptation! I've found that for the most part, people I follow on Twitter are a completely different group of people than I have on Facebook. Sure, there is some overlap and that's to be expected, but the vast majority of people I know of Facebook (or MySpace) are people I've actually met, am friends with, family with, grew up with, you get the picture. Many of the people (and/or companies) I follow on Twitter are people I've never personally met (although many I hope to meet someday) but we share some commonalities ... maybe it's programming, maybe it's music, maybe it's geography. You know?

Where I'm going with this is that something I might "tweet" about may not necessarily be something I want to update my "Global Social Status" with. The audiences are completely different and often warrant their own unique message, even if the messages are very similar.

The flip side to this is if you like to Twitter ... and you know who you are ... you have the potential of overwhelming your family and friends with updates like "RT @stevewithington CF9 is the bees knees ... I have ORM, do you?" or "This site rocks: http://tinyurl.com/nv62na #muracms #mura #coldfusion #sql"

Heck, I don't know about you, but I already get a little irritated having to scroll through things like "Help Me on Mafia Wars" or the ever popular "Steve Withington took the 'What Kind of Car Are You?' quiz and got the result: You're a 1969 Bitchin' Camaro. Read more ..."

So if you're goal in life is to annoy the crap out of people in your social communities, then go right ahead and applaud the efforts of MySpace and others in their quest to become THE place to go to update your Global Social Status. In the mean time, I'll continue along, grumbling and complaining about silly things like this.

Using ColdFusion to Handle HTTP 404 Page Not Found Errors

Tue, 30 Dec 2008 18:37:00 -0700

This article will not address the onMissingTemplate method which only runs when a CFML page does not exist (i.e., wwwroot/directory/thisPageDoesNotExist.cfm). In addition, this article will not address using custom headers or a .htaccess file with Apache. This article will address those other "page not found" errors often found in Windows hosted environments.

Let's start by assuming someone tries to visit www.yourdomain.com/thisDirectoryDoesNotExist, or www.yourdomain.com/thisPageDoesNotExist.html and neither the directory, nor the page actually exist on your site. Or, better yet, you've just spent months building a new, dynamic site for a client using ColdFusion and their old site was an old, yucky plain HTML site with pages everywhere. Now, your client, who's a little savvy in the SEO department, (that's search engine optimization for you non-seo-knowing folk), has requested you setup redirects for each of his old pages to the new ones you've created.

If you're anything like me, I used to dread the thought of taking care of this. I used to spend a ton of time on this by creating a separate page for each of the "old" pages and directories, then using either JavaScript to handle the redirects (if the old page was vanilla HTML) or the "old" dynamic language (i.e., ASP, PHP, etc.) to create custom headers, etc. Regardless, it was a major pain to do this, especially because it cluttered my site with a bunch of extra files that were essentially useless.

Then, I had one of those "light bulb moments." I thought, "Hey, I'm already using a custom tag to handle 'page not found' requests, so if I could somehow capture the requested page, match it against a list of 'known-to-be-missing' pages, then I could code a way to forward to the 'new' destination." Sounds simple enough, eh?

For those of us using a shared-host provider such as CrystalTech or HostMySite, they're kind enough to allow us to create custom pages to handle certain HTTP errors, such as 404. It's usually found in the service provider's "control panel" under something like "IIS > Custom Error Pages." Once there, you usually have three options to pick from: 1) Default, 2) File and 3) URL. In most cases, "Default" loads the standard error page provided by our friends at Microsoft. "File" is just that, a flat, static, HTML page. What we want to use is "URL," so that we can use ColdFusion to help us out. In fact, I'll be nice and even provide a link to both CrystalTech's process and HostMySite's process. But before you do this, you'll need to at least set up a .CFM file somewhere on your site so you know what to enter into the URL path, right? So for now, let's assume you've created a file call "404.cfm" and placed in a directory structure like so: "/extensions/customtags/404.cfm"

So, assuming you've got your custom error page setup properly, you will now be able to capture a query string which contains the "requested URL" that really didn't exist. The easiest way to test this would be to enter this code onto your 404.cfm file, upload it to your site, then try a non-existent directory such as www.yourdomain.com/abcd/.



#request.queryString#

You should see something like this: "404;http://www.yourdomain.com:80/abcd/"

There's some great information coming through here. First, you'll notice that you're receiving the error number (404). Next, you'll see your domain also includes the port number being used. For example, if using HTTP, then you will most likely see the number 80, or if your using HTTPS, then you should probably see 443.

For this next part, you might have to adjust this if you ever use a colon ( : ) in your directory or page naming conventions (this is not generally used, so I wouldn't expect this to be much of an issue).

Look again at the query string that we've been given, what we really want to grab is everything after the port number. Or, the absolute path to the page or directory being requested. So this is what I came up with:




	


	
	
	
	

#requestedPage#

So, now if we use the same url we tried earlier, I should see something like: "/abcd/" Now, I've got a variable that I can use to match against to see if this is a "known" directory or page from our old site. Now we just need something to handle the "matching" and then receive a response to make decisions against.

Luckily, I've created a rather simple .CFC which can easily be modified to accommodate any "known" directories and/or pages, including .ASP, .PHP, etc.

Now, we just need to invoke the ColdFusion Component to see if there's a match.

As you can see, if no match has been found, a variable called "newPage" is merely left blank. So, now we can write a little more code to accommodate both "known-to-be-missing" and "truly-unknown-and-really-missing" directories and pages. If a page is "known-to-be-missing", I can pass a search engine friendly header so that everything runs as smoothly as possible.

Here's the final document, aside from the .CFC above which should be kept separate.











	


	
	
	
	



	
	
		
	
	
	
		
	
	
		
	









This page has moved to http://www.yourDomainHere.com<cfoutput>#newPage#</cfoutput>


This page has moved to http://www.yourDomainHere.com#newPage#





	Hmm, the page you're looking for can't be found.
	You may have clicked a bad link or mistyped the web address.
	
		Return home
		Go back to the previous page

As you can see, I like to use a custom tag to handle the layout of my pages, etc. You can find out more about that at Raymond Camden's site.

I hope this helps a fellow ColdFusion developer. Thanks for reading!

Why is My Browser NOT Supported?

Mon, 17 Nov 2008 10:24:00 -0700

I don't know about you, but whenever I run into a "Browser Not Supported" message, I just start to growl. Here's a screen grab of one I ran into this morning from Eloqua.com.

Um, yeah, here we are, coming into the year 2009 and there are still several companies in the marketplace that throw "Browser Not Supported" messages to the end user. It's not like I'm using some antiquated, or completely custom browser either, I'm using Firefox here. This is not what I call user friendly, especially for a company that tracks user behavior, among other services. I'm quite surprised by this. Am I alone here?

CFMail Best-Practices for Sending Web-Generated E-mail (e-cards, forward-to-a-friend, etc.)

Thu, 10 Jul 2008 13:57:00 -0700

There are a number of ColdFusion articles available addressing CFMail being detected as spam, etc. which primarily deal with the "Message-ID" contained in an email's header. Charlie Arehart has a couple of detailed examples on his blog which I recommend other ColdFusion developers consider reading:

While we will also be dealing with email headers, this article is primarily concerned with addressing suggestions brought forth by the Sender Policy Framework (SPF) and their article titled How web-generated e-mailers can avoid looking like forgers. In addition, the vast majority of projects I'm involved with are hosted in a shared-hosting environment. So we won't be modifying anything in the CFAdmin area.

If you're wondering how to view email headers, I found a pretty good link on the University of Delaware Police Computer Forensics Lab web site (I know, sounds pretty serious, doesn't it).

The code examples I use here have been tested on ColdFusion 8.0.1. However, these should work with CF 6, 7 and 8.0.0 with very little, if any, modifications.

To send a web-generated email, you should collect at a minimum the "From" email, the "To" email, a "Message," and preferably the senders "Name." Obviously, there are several other things you could collect such as "Subject" and who to "Cc" or "Bcc," but let's just keep this simple for now. So let's create a form to send a simple message using the following code:



	
		From Name:

		
		From Email:

		
		To:

		
		Message:

Running the code should produce something similar to this:

The form doesn't do anything just yet other than post to the page/template it resides on. So let's go over the important stuff and then add some processing to the page.

According to SPF's article previously mentioned, when a web site sends web-generated e-mail, a user interacts with the web site, and an e-mail goes out on their behalf. Unfortunately, under SPF, mail from this type of service appears to be a forgery thereby being flagged as spam — unless certain precautions are taken. SPF claims that evite.com and egreetings.com have made the necessary changes and holds them up as examples other developers should emulate.

Your knee-jerk reaction to creating a CFMail to handle the form submission above might look like this:





#trim(FORM.messageText)#

However, this might (probably will) appear to be spam because it would generate something like this whilst using mail.yourdomain.com to send it:

Return-Path: suzie.visitor@gmail.com
From: "Suzie Visitor" <suzie.visitor@gmail.com>
Subject: Message from Suzie Visitor

SPF claims that "messages that use the user's address, but come from your mail servers are considered suspicious by SPF. To solve this problem, just change the headers ...

Here's a recommended example from SPF:

Return-Path: info@yourdomain.com
From: "Suzie Visitor" <info@yourdomain.com>
Reply-To: "Suzie Visitor" <suzie.visitor@gmail.com>
Subject: Message from Suzie Visitor

Keys to remember:

Choose a general address from your domain (info@yourdomain.com)
Add / Change the return-path (or "failto" in the CFMail tag) to that address
Change the "From" header ("from" in the CFMail tag) to that same address
Add a "Reply-To" header (yep, you guessed it, "replyto" in the CFMail tag) that contains your user's email address

So, to summarize, you can simply add the following code directly after the form and update the appropriate fields as necessary:







	
	
	

	
	
		
	
	
		
	
	
		
	
	
		
	

	
	

	
		
		
		
		#trim(FORM.messageText)#
		
		
		
			#cfcatch.Message#
		
	

	
	
		Your message has been sent at #dateformat(now(), "long")# #timeformat(now(), "long")# as follows:
		TO: #FORM.messageTo#

		SUBJECT: Message from: #FORM.messageFromName#

		MESSAGE:

		#htmleditformat(FORM.messageText)#		
	
	
	
		
		
			Please review the following issues:
			
				
					#REQUEST.errors[intError]#

By following this example, you should be able to create some pretty interesting web-generated email applications that fit within the Sender Policy Framework guidelines.

If you have additional information, please feel free to share it! I hope this helps you in your next project.

How to Opt-Out of IE8 Standards Mode and Other Useful Internet Explorer Troubleshooting Information

Thu, 03 Jul 2008 13:40:00 -0700

As a web designer/developer, we should strive to make each visitors experience as pleasant as possible. So, whether you like it or not, if you've chosen the web designer/developer career, you have to work with Windows® Internet Explorer® (IE).

I use Microsoft's Virtual PC to test web site display and functionality on various versions of IE (6, 7 and 8 at the moment). Unfortunately, I was experiencing a display issue only in IE8. Now, I realize the number of people currently using IE8 is extremely small. Soon enough though, there will be tens of thousands of people using it right? I might as well try to correct it now rather than pull my hair out later.

Rather than go into the display issue itself, I found a very useful technique to opt-out of IE8 standards mode. Or, in regular terms, how to make IE8 display a web page as if it were IE7.

First, I should explain why I chose this route. For one thing, it quickly fixed the display issue. Is there a better reason?

All I had to do was include a simple meta tag to the page(s) where the problem was occurring.

Personally, I like to wrap IE specific tags with a bit of ColdFusion:

The downside to using this technique is that you will not be able to use the latest rendering features available in IE8. Sniff, sniff (cue smallest violin in the world) … oh well.

According to information I found on the IE8 Readiness Toolkit, you can also address this on a per-site bases by adding a HTTP header:

X-UA-Compatible:IE=EmulateIE7

Alternatively, you could use a slightly different meta tag on a per-page basis while still accessing "all Internet Explorer 8 has to offer."

Word of caution here, using the "EmulateIE7" technique did not fix my display issue though. I ended up using the first technique with "IE=7" to "correct" the problem.

Here are some other helpful links relating to working with Internet Explorer, IE8 (Beta 1), etc.:

Microsoft Virtual PC 2007
- Software virtualization tool that allows for running a variety of operating systems (OS) on one machine/PC.
Internet Explorer 8 (Beta) Readiness Toolkit
Windows Internet Explorer 8 Beta Download
- If possible, I would actually recommend using Virtual PC instead
Internet Explorer Application Compatibility Virtual PC (VPC) Image
- This is a link for the Virtual PC Hard Disk Images for testing web sites on IE (including IE6 XP SP2, IE7 Vista, IE8 XP SP2)
Internet Explorer Developer Toolbar
- A pretty decent tool for discovering web page display issues
Windows Internet Explorer Developer Center
- Web Developer Resources pertaining to Internet Explorer (and other web design/development activities)

How to Dynamically Check a Radio Button (and Checkbox) in ColdFusion

Fri, 27 Jun 2008 11:26:00 -0700

Although this may seem to be a simple task, dynamically checking a radio button in ColdFusion is not always as easy as dynamically checking a checkbox in ColdFusion. It's definitely not difficult either. I just thought it might be worth a mention here.

Let's first look at how to dynamically check a checkbox in ColdFusion.

Checkboxes are cool. You see them everywhere in forms throughout the web. And, let's face it, they're extremely easy to use. When used in conjunction with XHTML labels, they're even easier to use for visitors. For example, if you have a label next to a checkbox input, you can wrap the label with a "label tag" which then makes the label itself "clickable." Simply match the label tag with the checkbox input tag name. Here's an example:




	
		 
		I agree

For me, the most common use of a checkbox input is in back-end admin areas to determine whether or not a particular record is active or not. This only requires me to have an "IsActive" field for the record in the database table with a boolean type (yes or no, true or false, 0 or 1). I usually set the default value to true so that when a record is added to the database, it automatically becomes "active" on the back-end. When a back-end user attempts to update the "active" record, they will (or should) see a "checked" checkbox with an "Is Active" label next to it. Once the back-end user no longer needs the record to be active, they simply un-check the "Is Active" checkbox and click submit.

Now that the item has been archived, when the back-end user attempts to update the record again, the "Is Active" checkbox shouldn't be "checked" now, should it? So, how do I dynamically check the checkbox?

Since I'm updating a database record, I'll need a query to get the current values of the records' fields. So we'll want to make sure the query contains the "IsActive" field. Assuming it does, just call the query and set the checked value to the query's "IsActive" value. Like so:





		





	
	
		
			
			 
			Is Active
		
	
		
			
		
	
	

	
	Sorry, the selected record is no longer available.

In the update query, to capture the new value, I use something similar to the following:



, IsActive=

If you're not using a query, the following code might also be helpful in dynamically checking a checkbox:

Another reason for showing the code above is because it's similar to how I'll be dynamically checking a radio button. The previous code snippet should be easy enough to follow. We're simply setting the value of the variable "isActive" to equal true. Then, the checkbox input's "checked" state is set to be dependent upon the "isActive" variable. I guess it's easier to read the code than it is to articulate the meaning, eh?

So, as you may already know, radio buttons are used when you want to offer one, and only one, option from a list of options. We keep the list of options tied together with the "name" attribute. The "name" attribute simply groups the options together, so that of all options sharing the same "name," only one is actually selected. There are two differentiating attributes, one of which is obviously the "value" which is needed for passing to the database, etc. The other differentiating attribute is the "id." I use the "id" attribute to tie to the label tag. For usability, you should also use the "label" tag which will also allow the user to simply click the option label to select the desired radio button.

Let's assume you have two queries to work with. One contains the list of possible options for the radio buttons. The other query pulls the existing values for the specified record. The idea here is that we'll output all possible options for the radio button, then check to see if our current record has selected the option being looped over. If so, then "check" it. If not, don't. Simple enough, eh? Let's take a look at the code I've come up:





			











	

		

			
			
				
				
				
			

			
				 
				
				#htmleditformat(OptionTitle)#
			

			
				
			

		

	
	
	
	Sorry, the selected record is no longer available.

That's pretty much it folks. If you have a different way to handle this, please feel free to share. Hope this helps!

To learn more about the CFInput tag, visit http://cfquickdocs.com/cf8/?getDoc=cfinput#cfinput

What Width or Size Should I Design the Web Site For?

Wed, 14 May 2008 12:15:00 -0700

It's a question that comes up time and time again: "What width or size should I design the web site for?" Unfortunately, the answer is always the same, "it depends."

It depends on what? Well, it depends primarily on two major considerations:

Your target audience's screen resolutions
The amount of space needed to display the information in a readable format

If you don't know the screen resolutions of your target audience, then take a look at W3Schools Browser Statistics and specifically the Browser Display Statistics page. There, you'll find some fairly good information based on their log-files. Of course, if you have access to your client's web stats, check there first.

Keep in mind that if you intend to use the entire display width, be sure to leave room for the scroll bars and such. For the most part, simply subtract 20 pixels from the width to determine your maximum design width. For example, if your intended audience is using 800x600, then your maximum width should be 780 pixels.

I'm all for web site usability and would rather not have to force a visitor to scroll to the right to see important information simply because their monitor's screen resolution was set lower than the width of my intended layout. However, if your target audience utilizes for example 1024x768, then by all means, feel free to use the extra real estate ... but only if you need to. This might make sense in a corporate environment where you are designing an intranet and you know for sure what dimensions the employees are/would be using.

People are also visiting the web with their cell phones, PDA's and other handheld web-enabled devices at an increasing rate. By using Cascading Style Sheets (CSS), you can create an entirely different display to accomodate these visitors. So keep this in mind when planning your design.

One thing I try to bring up to my design collegues, is to think about how you personally use your web browser(s). Do you expand it to the entire width and height of your available display? I don't. I usually have several windows open at the same time and rarely do I expand the application to my entire available display. Why do I bring this up? Well, if my display is 1024x768 and the web site is using a full 1004 (or more!) pixels, then I'm probably having to scroll right to see any content.

So, whilst I'm standing on this soap box, I'll try to throw in one last thought here. If you are designing a web site for the general public, I would recommend keeping the width within 780 pixels. Why? Because as of January 2008, according to W3Schools Browser Display Statistics, approximately 8% of visitors are using 800x600 displays. I know, you're saying, "but that means 92% are using 1024x768 or higher!" You would be correct. However, I believe 10% is a significant number. Would you be willing to simply ignore or turn away 10% of your paying customers?