Windows Mozilla - on Android

I was reading a review of the much-anticipated Motorola Atrix, when I stumbled upon this beauty:

Nothing like running Windows Mozilla on an Android phone!

UI Guidelines for web developers

Now I know that there are no hard-and-fast rules regarding user interfaces for websites, but I thought I would put in my 2 cents.

I was thinking about button rollovers (think :hover pseudo selector) and in trying to draw a parallel with physical buttons a few ideas came to me.

TACTILE SENSATION

Physical buttons have a tactile sensation BEFORE you push them, letting you know that your finger is in the right place before you push down on them. On web apps, we don't have that luxury, at least not yet.  Enter the rollover.  We need to give the user a visual indication akin to the tactile sensation one receives when lightly touching a button in reality.  So we change the style of button, here is a good example of such a change:

Normal State:









Rollover (hover) State (slightly lighter in hue):

Down (clicked) State (less bevel, less shadow):








*Feel free to take these images if you want them


The normal state has a clearly defined bevel, a high drop shadow and full opacity on the gradient.
The hover state has a lighter opacity on the gradient.
The down state has a "flattened" bevel and a lighter gradient with almost no drop shadow.

It's very important to not confuse the user by using the down state for the rollover.  It is very tempting to only create 2 images and shorten the time it takes to make the style.  If you make the down state the same as the hover state, users may be confused and think that a rollover causes a click.

It must be very clear the difference between a rollover and a click because we don't have that tactile sensation like in real life.  The rollover is a substitute for lightly putting our finger on a key and lets the user know, "I've seen your cursor and you are in fact in the right place to make something happen."

Drop down list vs Radio button List


When should I use a radio button list vs a drop down list?

Use a radio button list when:

1. The number of items is finite or guaranteed to be fairly small.
2. You need the user to make a conscious choice and not just set a default (even though you can set a default if you want).
*I've used radio button lists for true/false questions, month selection, year selection, and others.

Use a drop down list when:

1. The number of items is larger than would fit in a radio button list.
2. The number of items changes greatly over time.
3. You don't care if the user makes a choice or not (you can always set a default value though).
     a. I've seen a lot of users not change the selection on a drop down list so the developer puts a blank choice at the top.  This leads to having to handle the blank choice in code by putting some null value or a -1 or something of the like.  Again, if the user must make a choice and the number of items is small, use radio button lists.


Any comments are welcome,  thanks for reading!

jQuery Datepicker & Date Selection

So I'm trying to set a property on my jQuery datepickers that I found out later is called "defaultDate", when I discovered this thread:

http://forum.jquery.com/topic/datepicker-changing-selected-date-should-always-update-text-input

A quick summary: 

These guys are disputing whether or not the date should change in the textbox when you choose a month or year.  Currently, the only way to change the selected date is to click on a date in the calendar part of the datepicker.  Choosing a different month or year will not update the date until you do so.

I found this, that will alter that behaviour (see bold part):

 $("#FromDate").datepicker({

        changeMonth: true,

        changeYear: true,       

        defaultDate: "-40y",

        onChangeMonthYear: function (y, m, i) {

            var d = i.selectedDay + "";

            if (d.length < 2) d = "0" + d;

            var m = m + "";

            if (m.length < 2) m = "0" + m;

            $('#FromDate').val(d + "/" + m + "/" + y);

        }

    });

So the question in the forum that they are debating is: "Should the selected date change when the month and year change?".  To which I will answer an unequivocal, YES!  I don't even think this needs explanation, when you change something, you expect it to change, end of story!

Un-phrases and other interesting things

This morning at a meeting, one of the participants shot out a couple of very funny phrases, which were essentially un-phrases.  What I mean is that they didn't make any sense because they in fact were a combination of 2 related phrases or just a complete mismatch.  Here's the first one:

1. "She's not the smartest light bulb in the the room".

And here are the two derivations, which if combined together produce the above phrase:

... not the brightest light bulb in the room (or box as I've more often heard it)
... not the smartest person in the room

What is humorous about this is that LIGHTBULBS AREN'T EXPECTED TO BE SMART, since they are not sentient or even animate objects, they are only expected to be bright.

2. (Speaking of the time-frame), "We need to stretch it down".  This is a verbose way of saying that the time frame needs to be compressed or shortened.

3. The word BETA pronounced bettah. This was a first for me. I was very interested to hear him pronounce alpha, but couldn't seem to work it into the conversation.

4. "We will do this VICE doing that."  This would appear to be a mismatch of the phrases "vice-versa" and "versus".  The phrase rendered correctly should have been, "We will do this VERSUS doing that".

Have a good Monday evening!

Developer Tools Compared (IE,FF,Chrome,Safari,Opera)

This post is part 1 of 2 comparing the relative functionality among IE, FF, Chrome, Safari and Opera's web developer tools.

Here is a spreadsheet I created to show the differences in features among the different browsers.  I will continue to update this as I learn about more features and add-ons.

I've branched out a bit from just the javascript debugger and tried to cover some of the useful tools as well that are part of the browsers.  Eventually, I'd like to grow this spreadsheet into a full on comparison of virtually every feature/bug in all the browsers.

The spreadsheet is not editable, but feel free to post comments if you find any issues or want to add something to it.

So here is a quick summary of what I found:

1. All the browsers can debug javascript and update CSS realtime.
2. IE and FF had the best command line interfaces. I had a hard time finding the command line in the other browsers, but will continue to try and find them.
3. Safari and Chrome have virtually the same interface (Did Google license Safari's developer tools?)
4. One should have no problem whatsoever debugging javascript and CSS issues in any of these browsers.
5. IE was surprisingly the most robust feature-wise, with a great many more features than any of the other browsers and missing only a color picker.

In part 2, I will provide a subjective rating of each of the browsers abilities to help web developers debug issues with their websites.

Key Events

Keyboard events can sometimes trip up even seasoned developers. 

I'm listing the keyboard events below in order that they fire:

1. Keydown - fires 1st when a finger pushes down on a key

    a. You can prevent any input from displaying in the textbox or textarea.

    b. This is the event that fires when a key is held down.

    *   Use this event to prevent users from inputting numbers where text is expected or ensuring that the input is always in the correct format.

    ** You can detect the keycodes and map them or you can just translate them to charCodes and use a Regex to determine input validation.

2. Keypress - fires 2nd when a finger keeps a key down.

    a. At this point its too late to prevent the character from showing, but you can still remove it after it has      displayed.

    * If you check a character and then remove it after determining it is bad, the user will see a visible flash where the character shows up and then disappears, which is probably not the desired effect.

3. Keyup - fires 3rd when a finger pushes release a key

    a. Really just a point in time at which you can say all the input has completed and the decisions to show or not show the characters have already been made. 

    b. You can trim or remove or reformat at this point also.

    * Remember that this event fires before a "change" event, because the "change" events requires "blur" or clicking/tabbing off the textbox. (This also applies to the "blur" event of course.)

KeyDown vs OnKeyDown

Sometimes it can be confusing whether you should bind the events to "keydown" or "onkeydown".  The recommendation is to use jQuery's browser-agnostic "keydown" event to do the binding.  It will figure out the correct event name for the browser currently running. 

*This of course applies to keypress and keyup as well as most of the other bindable events.

You should always use jQuery's event.which.  This will normalize the input for all browsers so that you don't have to check event.which and event.charCode and event.keyCode.

Inception

This is the genesis of a blog called Client-Side Scripting.  Its aim is to provide web developers and anyone else who may be interested with some of the best and most interesting client-side scripting techniques.  It will not be devoted solely to Javascript, although much of its content will probably be in that vein.

I am interested in HTML5, SVG, CSS3, Javascript, UI Design, and layout techniques.  If something really good comes along, I will probably be interested in that as well.  So let's get going and start up some nice conversations and get some good information disseminated.

I will always endeavor to answer any comments that solicit such. However, I may not respond to angry or negative comments, as I am not interested in arguments.