Mobile Browser Detection Hack

As was surely inevitable, I am now obliged to think more about the experience a user might have of a site while using mobile devices. I could have staved this off for a little while yet longer, but iOS and Android fire the mouseover event in jQuery. Why? Where's the mouse? This gets in the way with a new, mobile-friendly, dhtml menu system I'm creating - works through clicks as well as mouseovers.

Anyway, I thought to either investigate the event handling issue (maybe a jQuery issue) or go for browser detection. As there are more and more mobile initiatives rolling down the pipe for me, detection seemed like it might be more helpful. And, really, I didn't want to reinvent the wheel so I went looking for pre-existing solutions.

I found Detect Mobile Browser, an open-source tool, but it didn't think that iPad was a mobile device. In my framework speed dating session, I said goodbye quickly to the prospect of a long term relationship. I did notice, though, from the USER_AGENT that it was reporting, that all the mobile devices I was checking identified themselves as "mobile" somewhere in the string.

So, a quick hack that seems to do the trick emerged:


How Many Ways To Make A Link?

Been doing some research on page optimization and have come across a number of different ways to make a link. Most seem designed to avoid notice by search bots, but I can see some other uses as well. Anyway, these are the various specimen of hyper text linking that I have been able to accumulate:


Flex: Using Regular Expressions For RealTime Filtering

Another bit of UI fun that came up: Suppose that you are creating a form for an organization that requires email input for a single domain, but that they have specific rules that enable us to (1) make input easier and (2) prevent input errors.

In this case, let's suppose that numbers are verboten and that the typical format of the email address is the first initial and the entire last name (or the whole first name if that is all that is given). The email account name should be over-writeable in case it is an exception to the naming convention. Also, we need to remove any additional characters that might not be email friendly. Finally, the organization wants all email addresses are expressed in lowercase. An example would be:

"John Smith" >> "jsmith"

(This was an actual set of business rules, so don't ask me how they would differentiate James Smith from John Smith)

For the interface, we'll use a single TextInput for both the first and last name and we'll use simple binding to link that into the email TextInput. For good measure, there is a Label to show the company domain name.

So, moving right along we have a simple setup like:


Flex: Default List Item, Dynamically Populated ComboBox

I've been crazy busy, but here is a little GUI element that I have create for use in an AIR application designed to control a Flex app.

One of the features is the ability to create lists at configuration that are expressed as ComboBoxes in the application. When allowing the user to set the default, I thought it would be better to ensure that the input is valid by immediately populatig a ComboBox with the options. It is a very simple implementation, but I think the effect is pretty nifty:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="" layout="horizontal" viewSourceURL="srcview/index.html">

import mx.collections.ArrayCollection;
[Bindable] private var _options:ArrayCollection = new ArrayCollection();
private function optionValueChanges(values:TextInput):void {
var _use:String = values.text;
if (_use.charAt(_use.length-1) == ",") {
_use = _use.substring(0,_use.length-1);
_options = new ArrayCollection(_use.split(","));


<mx:TextInput id="tiOptions" change="optionValueChanges(tiOptions)" width="150"/>
<mx:ComboBox id="cbDefault" dataProvider="{_options}" width="200" />

To make it work, just type in a comma-delimited list of items. The little bit of conditional logic is to ignore the case when the string has a trailing ",".

View a demo of the dynamically populated ComboBox for the default selection.

Keyboard vs Mouse

Maybe it is because I am enamoured with the world's ugliest, but potentially coolest mouse, or maybe it's that my own mouse is developing quirks that cause me to believe that it is not long for this world, but I've been looking at acquiring a new primary HID. Along those travels, I came across a very old discussion comparing the Keyboards vs Mice. Apparently, Apple spent $50,000,000 in the late '80s, and that's when $50 million was worth something, to study the Apple Human Interface. The result was the discovery of two facts:

  • Test subjects consistently report that keyboarding is faster than mousing.
  • The stopwatch consistently proves mousing is faster than keyboarding.

Like many things tech, and especially since Apple is involved, opinions run strongly in many directions. My own concerns are my own requirements for interfacing with the hunk of plastic, silicon and dopants at my desk and what sort of experience do I offer users in the applications that I create, web or otherwise.

I gotta imagine that there are thresholds and conditions that would impact the truth of those two "facts". One person mentioned in the article says that "there are NO command key equivalents in my product, Smart Labels, except for Undo, Cut, Copy and Paste". The reasoning is that, even though the user may perceive there to be a value in using additional shortcuts, he won't allow it. That seems extreme. What happens when the desired action is hidden behind several layers of menuing or if the action is contextual and you are already using the mouse to highlight the text (modifying case through shortcuts would be very preferable to highlighting and hunting). My own inclination is to add keyboard shortcuts when time or interface will allow me. That doesn't always work and I have lost some recent battles at work to implement minimalistic interfaces that use only keyboard shortcuts.

In that case, it was a dialog box, created by a mouse event that just contained a single text input with listeners for ENTER and ESCAPE. My reasoning was that the act of calling the dialog would provide the context for the input, hence no label, and that ENTER and ESCAPE are natural behaviors. As I said, I lost and now the little interface that could have been was obliged to support a Label, a submit Button, a Cancel button (as the corner "X") and an instruction line. My opinion is that, styling aside, the interface is uglier and code is heavier. (Apparently, I might be a little bitter about this)

Anyway, where are the lines between performance and usability? I've been perusing user experience resources and the focus has been on eliminating the need for a user to think. And, for casual use software, that makes a lot of sense. However, for productivity software where a user will spend much of the day, I gotta imagine that the kind and thoughtful UI developer is going to allow for improvements in performance that occur through user training - though that means a lot more than just adding keyboard shortcuts.

BlogCFC was created by Raymond Camden. This blog is running version Contact Blog Owner