<select multiple> sucks
13/06/09 14:00 Filed in: Web development | Design
The select element is used to create list of options. In ‘normal’ mode it presents a popup box. In ‘multiple’ mode it presents a list which requires the user to hold a key to select additional items. The native list control in Windows and OS X works exactly the same.
I really don’t like this control. There are no visual clues that the user can select multiple items, which means that most users don’t know that multiple selections are possible. To address this problem websites often add a label to explain how multiple selections is made:
When notes and labels are added to things it’s a huge clue that the thing in question suffers from poor design. Also, the label in the screenshot is inaccurate. It is true in Windows, but not in OS X (and possibly not in true in GTK, QT etc).
The control requires the user to user press a key so that they can make multiple multiple selections - this means that the control is quasi-modal. Modes confuse the user and should be avoid. For such a simple task these failings are inexcusable.
Here’s a better approach:
<div style="overflow-y:scroll;height:6em;width:20em;border:1px solid black;">
<input type="checkbox">Jimmy</input><br />
<input type="checkbox">Jimi</input><br />
<input type="checkbox">Frank</input><br />
<input type="checkbox">Dweezil</input><br />
<input type="checkbox">Jeff</input><br />
<input type="checkbox">Keef</input><br />
<input type="checkbox">John</input><br />
</div>
The above creates a scrolling checkbox list by setting the size and overflow style attributes of the parent block element (in this case a <div>, but it could be applied to the <form> directly). Checkboxes lists are common in OS’s so the user will understand how to use the control.
I really don’t like this control. There are no visual clues that the user can select multiple items, which means that most users don’t know that multiple selections are possible. To address this problem websites often add a label to explain how multiple selections is made:
When notes and labels are added to things it’s a huge clue that the thing in question suffers from poor design. Also, the label in the screenshot is inaccurate. It is true in Windows, but not in OS X (and possibly not in true in GTK, QT etc).
The control requires the user to user press a key so that they can make multiple multiple selections - this means that the control is quasi-modal. Modes confuse the user and should be avoid. For such a simple task these failings are inexcusable.
Here’s a better approach:
Jimmy
Jimi
Frank
Dweezil
Jeff
Keef
John
Jimi
Frank
Dweezil
Jeff
Keef
John
<div style="overflow-y:scroll;height:6em;width:20em;border:1px solid black;">
<input type="checkbox">Jimmy</input><br />
<input type="checkbox">Jimi</input><br />
<input type="checkbox">Frank</input><br />
<input type="checkbox">Dweezil</input><br />
<input type="checkbox">Jeff</input><br />
<input type="checkbox">Keef</input><br />
<input type="checkbox">John</input><br />
</div>
The above creates a scrolling checkbox list by setting the size and overflow style attributes of the parent block element (in this case a <div>, but it could be applied to the <form> directly). Checkboxes lists are common in OS’s so the user will understand how to use the control.
The correct way to display time
28/02/09 08:36 Filed in: Design
I’ve just upgraded the hard drive of my MacBook. To do this I used the excellent Drive Genius 2 which was included in the MacUpdate Holiday Bundle. Drive Genius 2 is a great piece of software. It’s really easy to use compared to GParted and all the other fiddle Linux tools. The interface to Drive Genius contains lots of (superfluous) animation but on the whole is very clear. However, when I was duplicating the drive I noticed something that got my goat:
Why is time state as a decimal? This is confusing. For example, does ‘4.33 hours’ mean 4 hour 33 minutes or 4 hour 20 minutes?
Time should be displayed in its natural units; hours minutes and seconds. The work involved in converting ‘1.5 hours’ into ‘1 hour 30 minutes’ is trivial and the result is a better user experience.
Bonus rant: I much prefer analogue clocks that have a second hand which moves at a constant rate rather than one that ticks. I prefer them for two reasons. Firstly time is continuous, the discreet unit of a second is for our convenience, therefore continuous movement better represents this. Secondly, I hate the constant ‘tick. tick. tick.’ it drives me crazy!
Why is time state as a decimal? This is confusing. For example, does ‘4.33 hours’ mean 4 hour 33 minutes or 4 hour 20 minutes?
Time should be displayed in its natural units; hours minutes and seconds. The work involved in converting ‘1.5 hours’ into ‘1 hour 30 minutes’ is trivial and the result is a better user experience.
Bonus rant: I much prefer analogue clocks that have a second hand which moves at a constant rate rather than one that ticks. I prefer them for two reasons. Firstly time is continuous, the discreet unit of a second is for our convenience, therefore continuous movement better represents this. Secondly, I hate the constant ‘tick. tick. tick.’ it drives me crazy!
NSCollectionView Tips
04/11/08 11:55 Filed in: Cocoa
Recently I’ve been teaching myself Cocoa. I’ve been following the excellent Cocoa Programming For Mac OS X by Aaron Hillegass. Quality reference material like this book and Apple’s documentation makes learning much easier. Apple’s material is consitent, consisce and in the most part complete. However, there is one class where Apple’s reference is quite poor; NSCollectionView.
NSCollectionView is similar to NSTableView; they both display data with the help of a prototype which is copied for each piece of data to be displayed. NSTableView uses the NSCell for the prototype. The NSCell draws its self directly onto the NSTableView. NSCollectionView uses NSCollectionViewItem for the prototype. NSCollectionViewItem is a simple controller (it inherits directly from NSObject), it has no visual element. NSCollectionViewItem has two properties, representedObject and view. representedObject holds the object that the view will display and is set by the NSCollectionView. It is the responsibility of the NSCollectionViewItem to provide the view object.
When an NSCollectionView is created in Interface Builder two additional objects are created:
Well, it’s great for a short while. Problems arises when you want more than simple bindings between the view and the representedObject. There are two parts to this problem:
The next problem is that unlike the bindings the in the NSView, the IBOutlet’s specifed in our NSCollectionViewItem subclass are not connected when the prototype is copied. So how do we connect the IBOutlet’s specified in our NSCollectionViewItem subclass to the controls in the view? This problem is trivial once you realise that Interface Builder is not being very clever.
Interface Builder puts the custom NSView in the same nib as the NSCollectionView and NSCollectionViewItem. This is dumb. The solution is to move the NSView to its own nib and get the controller to load the view programmatically:
[NSBundle LoadFromNib:@"viewItem" owner: result];
//we can configure other aspects of result too [result setPopupMenuDelegate: [self popupMenuDelegate];
return result; } /*This might not be the best place for LoadFromNib:. If it was place in setRepresentObject: we could load different views depending on the class of the representedObject.*/
Problem solved. We now have much more control of NSCollectionView. (Remember you can still bind to representObject).
NSCollectionView is similar to NSTableView; they both display data with the help of a prototype which is copied for each piece of data to be displayed. NSTableView uses the NSCell for the prototype. The NSCell draws its self directly onto the NSTableView. NSCollectionView uses NSCollectionViewItem for the prototype. NSCollectionViewItem is a simple controller (it inherits directly from NSObject), it has no visual element. NSCollectionViewItem has two properties, representedObject and view. representedObject holds the object that the view will display and is set by the NSCollectionView. It is the responsibility of the NSCollectionViewItem to provide the view object.
When an NSCollectionView is created in Interface Builder two additional objects are created:
- An NSCollectionViewItem which is connected to the prototype outlet of the NSCollectionView
- An NSView which is connected to the view outlet of the NSCollectionViewItem
Well, it’s great for a short while. Problems arises when you want more than simple bindings between the view and the representedObject. There are two parts to this problem:
- where do we put our controller code?
- how do we access the IBOutlets specified in our controller code?
The next problem is that unlike the bindings the in the NSView, the IBOutlet’s specifed in our NSCollectionViewItem subclass are not connected when the prototype is copied. So how do we connect the IBOutlet’s specified in our NSCollectionViewItem subclass to the controls in the view? This problem is trivial once you realise that Interface Builder is not being very clever.
Interface Builder puts the custom NSView in the same nib as the NSCollectionView and NSCollectionViewItem. This is dumb. The solution is to move the NSView to its own nib and get the controller to load the view programmatically:
- Move the NSView into its own nib (thus breaking the connection between the NSCollectionViewItem and NSView).
- In I.B., change the Class Identity of File Owner to the NSCollectionViewItem subclass.
- Connect the controls to the File Owner outlets.
- Finally get the NSCollectionViewItem subclass to load the nib:
[NSBundle LoadFromNib:@"viewItem" owner: result];
//we can configure other aspects of result too [result setPopupMenuDelegate: [self popupMenuDelegate];
return result; } /*This might not be the best place for LoadFromNib:. If it was place in setRepresentObject: we could load different views depending on the class of the representedObject.*/
Problem solved. We now have much more control of NSCollectionView. (Remember you can still bind to representObject).
Ramblings on Keyboard Shortcuts
27/07/08 11:11 Filed in: Design
On the surface keyboard shortcuts seems like a rather small topic: ctrl + s to saves and alt + f4 to closes, what else is there to know? But as with most things there’s always more than what meets the eye.
First of all lets state what a keyboard shortcut is and what it does:
A keyboard shortcut (or accelerator key, shortcut key, hot key, key binding, keybinding, key combo, etc.) is a key or set of keys that performs a predefined function. These functions can often be done via some other, more indirect mechanism, such as using a menu, typing a longer command, and/or using a pointing device. By reducing such sequences to a few keystrokes, this can often save the user time, hence “shortcut”.
Wikipedia - Keyboard shortcut
For a system to be sucessful it needs to be sympathetic to its user. We therefore need to look at limitations of the user and how to accomodate them.
Physiology (ergonomics)
Anyone that paid attention in biology class will have heard the term opposable thumbs. The “thumbs” of other animals evolved into wings, hooves or flippers, but ours have shift around a bit to be opposite our fingers. This change in position allows us to grab things, it has also resulted in our thumbs becoming the strongest and one of the more dextrous fingers. Our fingers decease in strength as they move away from the thumb. It therefore follows that any good design should utilise this fact by making good use of our superior digits; the thumb, index and middle (ring) fingers.
The brain (cognetics)
Designing an object so it is sympathetic to our bodies is only half of the story. A well designed ‘thing’ must be sympathetic to the constraints of our minds too.
Modes are a major design consideration for good shortcuts.
In user interface design, a mode is a distinct setting within a computer program or any physical machine interface, in which the same user input will produce perceived different results than it would in other settings.
Wikipedia - Mode (computer interface)
Some examples:
The second consideration is human memory. Our short term memory is quiet limited. We can store around 7 items of data in our short term memory. This has an impact on the way we use shortcuts. When a user is performing a task they will concentrating on their data than the tools for manipulating the data.
There are a few ways to reduce the burden of remember how to use a system. The first is to remove the burden of remembering - this is done by clear labelling. The second is by creating meaning relationships between the desired result and required action. Meaningful relationships allow users to understand the system as a whole rather than having to learn a collection of unrelated and arbitrary actions.
Current systems shortcuts
Lets see how Windows XP and OS X Leopard far with the above criteria.
Ergonomics:
The physical design of Mac and standard PC keyboards are almost identical. The most noticeable differences are the modifier keys. A standard PC keyboard has ctrl, alt and windows keys, a Mac keyboard has ctrl, alt and cmd keys.
Left side of a mac keyboard
Left side of a Windows keyboard
In Windows the most common modifier key used with shortcuts is the ctrl key. The crtl keys are located on the bottom row at the far left and far right of a standard keyboard.
It is the little finger (pinkie finger) that people most often use to press the ctrl key. The little finger is a feeble thing and tires quickly. Also the degree of stretch required to move the hands from the standard typing position is quite pronounced which makes it prone to a RSI (see How To Avoid The Emacs Pinky Problem).
OS X fairs better. The modifier key used is always the cmd key which are located directly to left and right of the space bar (additional modifier keys may also be used). The positioning allows the modifier keys to be pressed with the thumb - ideal.
Modal design:
Windows has many mode based issues. To issue a in shortcut we have to press either ctrl, alt or the ‘Windows key’ which is often followed by pressing another key. The ctrl key is the most common modifer key to be used in a shortcuts, fortunately the ctrl key does not suffer from modal issues. Unfortunately the same is not true of the alt or Windows keys, both of which are modal. Worse still the behaviour of the alt and Windows keys are inconsistent.
The alt key is generally used to move focus to the menu bar and for window management (eg, alt + f4 to close, alt + tab to switch to another window), but occasionally the alt key is used in ‘normal’ shortcuts. The key press cycle of alt key in a normal application (eg Notepad, Windows Explorer, Internet Explorer) is as follows:
The key press cycle of the Windows key is as follows:
Labelling:
The on screen labelling of shortcuts in OS X and Windows are largely similar. Both try to use mnemonic to imply a system. For example cmd +s is saves, cmd + l is loads and cmd + p is print. There are limitations to this approach.
Firstly conflicts soon arise, for example should cmd + s be save or search? Windows applications tend to address this problem by using a different letter, thus breaking the mnemonic system. OS X sometimes uses a different letter but also uses additional modifier keys, but which additional modifier key is unpredictable. Both of these approaches are some what arbitary as they are not part of a system which the user can learn and therefore predict the shortcut. (OS X has a convention of using the shift key to perform related actions. For example cmd + s is save cmd + shift + s is save as, cmd + z is undo cmd + shift + z is redo.)
The second problem is internationalisation. The mnemonic system is fine when the system is in english but becomes arbitary when the same shortcuts are used in conjunction with other languages.
In addition to the onscreen labeling it is also worth noting the keyboard labelling. In OS X the labelling of these keys are largely consistent with their behaviour; the cmd key is used when issuing commands, the alt/options key will often give an alternative option, and the ctrl key will show controls. In Windows this is not the case, modifier keys are assigned without regard to their label.
Sidenote: interaction with the mouse
It is not sensible to consider the keyboard without mentioning the mouse. Most people are right handed (70% to 90% according to Wikipedia) and therefore operate the mouse with their right hand. While mousing the available keys are limited to those which are accessible by the non-dominate hand (ie the left hand in most cases). I am left handed. For example, when I use Safari to browser the web I use a combination of the cursor and keyboard to navigate. I use my right hand to switch between tabs while my left hand moves the cursor to links and other things that catch my eye. The shortcuts I use to switch between tabs are cmd + alt + left and cmd + alt + right. This approach would not work for a right handed person.
Improvements & alternate implementation
What can be done to improve keyboard shortcuts? The most effective fixes need to take place at the operating system level, which is unfortunate as it means little can be done by individual developers. It is possible for an application to alter the standard operation but this leads to inconsistencies between applications which cause more problems that it solves.
My suggestions are simply to implement what I have discussed above.
Shortcuts should use thumb based modifier keys
Jef Raskin points out in The Humane Interface that the current keyboard design makes poor use of our thumbs. Raskin was involved with the Canon Cat which had two ‘leap’ keys beneath the space bar. The ‘leap’ keys allowed the user to ‘leap’ forward and backwards in a document. While I question the usefulness of leap keys in relation to modern GUIs it is certainly true that our thumbs are still ‘twiddling’ and should be put to better use.
Limited use of modes - shortcuts should utilize quasi-modes
Modes are an inherent feature of the desktop/windowing metaphor. However we can certainly reduce their negative impact by carefully considered design. Keep to the any standard shortcuts that are in use by the operating system. (The alternative is to purse other computing metaphors such as ZUIs (as outlined in the Humane Interface), or life streams).
Clear labelling
Clearer labelling is harder to achieve, however there are a few systems for doing this. Digidesign produce custom keyboards for their Pro Tools system. Having used one of these keyboard I can testify to their usefulness. The problem with having the details printed on the key is that they are only applicable to one application.
A more generic solution to keyboard labelling is the Optimus Maximus keyboard. Each key of the Optimus Maximus has an embeded OLED screen. These screens are used to show different glyphs in different circumstance. For example when using Photoshop the keyboard displays the icons of the on screen tools. Unfortunately the Optimus Maximus is considerable more expensive than a standard keyboard (it also has received critisim for its typing experiance). However the Optimus Maximus is the first of its kind - I expect more affordable and more tightly integrated solutions will soon emerge.
Further Reading
First of all lets state what a keyboard shortcut is and what it does:
A keyboard shortcut (or accelerator key, shortcut key, hot key, key binding, keybinding, key combo, etc.) is a key or set of keys that performs a predefined function. These functions can often be done via some other, more indirect mechanism, such as using a menu, typing a longer command, and/or using a pointing device. By reducing such sequences to a few keystrokes, this can often save the user time, hence “shortcut”.
Wikipedia - Keyboard shortcut
For a system to be sucessful it needs to be sympathetic to its user. We therefore need to look at limitations of the user and how to accomodate them.
Physiology (ergonomics)
Anyone that paid attention in biology class will have heard the term opposable thumbs. The “thumbs” of other animals evolved into wings, hooves or flippers, but ours have shift around a bit to be opposite our fingers. This change in position allows us to grab things, it has also resulted in our thumbs becoming the strongest and one of the more dextrous fingers. Our fingers decease in strength as they move away from the thumb. It therefore follows that any good design should utilise this fact by making good use of our superior digits; the thumb, index and middle (ring) fingers.
The brain (cognetics)
Designing an object so it is sympathetic to our bodies is only half of the story. A well designed ‘thing’ must be sympathetic to the constraints of our minds too.
Modes are a major design consideration for good shortcuts.
In user interface design, a mode is a distinct setting within a computer program or any physical machine interface, in which the same user input will produce perceived different results than it would in other settings.
Wikipedia - Mode (computer interface)
Some examples:
- The caps lock key is modal (ie it creates a mode). When the ‘k’ key is press a ‘k’ is displayed, but when caps lock is engaged pressing ‘k’ will display ‘K’.
- In TextEdit pressing cmd + t displays the font pallette, but in Safari pressing cmd + t opens a new tab. The same key presses have different results. (Conflicts such a this are common due to the current computing paradigm of independent applications which is inherently modal).
The second consideration is human memory. Our short term memory is quiet limited. We can store around 7 items of data in our short term memory. This has an impact on the way we use shortcuts. When a user is performing a task they will concentrating on their data than the tools for manipulating the data.
There are a few ways to reduce the burden of remember how to use a system. The first is to remove the burden of remembering - this is done by clear labelling. The second is by creating meaning relationships between the desired result and required action. Meaningful relationships allow users to understand the system as a whole rather than having to learn a collection of unrelated and arbitrary actions.
Current systems shortcuts
Lets see how Windows XP and OS X Leopard far with the above criteria.
Ergonomics:
The physical design of Mac and standard PC keyboards are almost identical. The most noticeable differences are the modifier keys. A standard PC keyboard has ctrl, alt and windows keys, a Mac keyboard has ctrl, alt and cmd keys.
Left side of a mac keyboard
Left side of a Windows keyboard
In Windows the most common modifier key used with shortcuts is the ctrl key. The crtl keys are located on the bottom row at the far left and far right of a standard keyboard.
It is the little finger (pinkie finger) that people most often use to press the ctrl key. The little finger is a feeble thing and tires quickly. Also the degree of stretch required to move the hands from the standard typing position is quite pronounced which makes it prone to a RSI (see How To Avoid The Emacs Pinky Problem).
OS X fairs better. The modifier key used is always the cmd key which are located directly to left and right of the space bar (additional modifier keys may also be used). The positioning allows the modifier keys to be pressed with the thumb - ideal.
Modal design:
Windows has many mode based issues. To issue a in shortcut we have to press either ctrl, alt or the ‘Windows key’ which is often followed by pressing another key. The ctrl key is the most common modifer key to be used in a shortcuts, fortunately the ctrl key does not suffer from modal issues. Unfortunately the same is not true of the alt or Windows keys, both of which are modal. Worse still the behaviour of the alt and Windows keys are inconsistent.
The alt key is generally used to move focus to the menu bar and for window management (eg, alt + f4 to close, alt + tab to switch to another window), but occasionally the alt key is used in ‘normal’ shortcuts. The key press cycle of alt key in a normal application (eg Notepad, Windows Explorer, Internet Explorer) is as follows:
- The alt key is pressed in. This moves the focus to the menu bar, illustrated by an the underlining of letters required to access the menus.
- At this point there are 4 possible sequence of events:
- Alt key is released resulting in the focus moving to the first menu (normal the File menu).
- A key that is underlined is press which results in the associated menu being displayed and the focus moving to the first item of that menu.
- Another valid key is pressed (eg, F4 or alt)
- A key that is not underlined is press resulting in the focus remaining in its current loci (eg the text area in Notepad).
The key press cycle of the Windows key is as follows:
- Windows Key is pressed in (there is no on screen indication that this has occurred).
- At this point there are 3 possible sequence of events.Note that events b and c can occur numerous times without releasing the Windows key:
- The key is released resulting in the Start menu being displayed and the focus moving to it.
- A valid key is pressed resulting in the related action being executed (the only way to discover valid keys is to read the documentation). When the Windows key is finally released the Start menu is not displayed.
- A non valid key is pressed. The key press is ignored by the Windows key and is handled by the application with focus. When the Windows key is finally released the Start menu is not displayed.
Labelling:
The on screen labelling of shortcuts in OS X and Windows are largely similar. Both try to use mnemonic to imply a system. For example cmd +s is saves, cmd + l is loads and cmd + p is print. There are limitations to this approach.
Firstly conflicts soon arise, for example should cmd + s be save or search? Windows applications tend to address this problem by using a different letter, thus breaking the mnemonic system. OS X sometimes uses a different letter but also uses additional modifier keys, but which additional modifier key is unpredictable. Both of these approaches are some what arbitary as they are not part of a system which the user can learn and therefore predict the shortcut. (OS X has a convention of using the shift key to perform related actions. For example cmd + s is save cmd + shift + s is save as, cmd + z is undo cmd + shift + z is redo.)
The second problem is internationalisation. The mnemonic system is fine when the system is in english but becomes arbitary when the same shortcuts are used in conjunction with other languages.
In addition to the onscreen labeling it is also worth noting the keyboard labelling. In OS X the labelling of these keys are largely consistent with their behaviour; the cmd key is used when issuing commands, the alt/options key will often give an alternative option, and the ctrl key will show controls. In Windows this is not the case, modifier keys are assigned without regard to their label.
Sidenote: interaction with the mouse
It is not sensible to consider the keyboard without mentioning the mouse. Most people are right handed (70% to 90% according to Wikipedia) and therefore operate the mouse with their right hand. While mousing the available keys are limited to those which are accessible by the non-dominate hand (ie the left hand in most cases). I am left handed. For example, when I use Safari to browser the web I use a combination of the cursor and keyboard to navigate. I use my right hand to switch between tabs while my left hand moves the cursor to links and other things that catch my eye. The shortcuts I use to switch between tabs are cmd + alt + left and cmd + alt + right. This approach would not work for a right handed person.
Improvements & alternate implementation
What can be done to improve keyboard shortcuts? The most effective fixes need to take place at the operating system level, which is unfortunate as it means little can be done by individual developers. It is possible for an application to alter the standard operation but this leads to inconsistencies between applications which cause more problems that it solves.
My suggestions are simply to implement what I have discussed above.
Shortcuts should use thumb based modifier keys
Jef Raskin points out in The Humane Interface that the current keyboard design makes poor use of our thumbs. Raskin was involved with the Canon Cat which had two ‘leap’ keys beneath the space bar. The ‘leap’ keys allowed the user to ‘leap’ forward and backwards in a document. While I question the usefulness of leap keys in relation to modern GUIs it is certainly true that our thumbs are still ‘twiddling’ and should be put to better use.
Limited use of modes - shortcuts should utilize quasi-modes
Modes are an inherent feature of the desktop/windowing metaphor. However we can certainly reduce their negative impact by carefully considered design. Keep to the any standard shortcuts that are in use by the operating system. (The alternative is to purse other computing metaphors such as ZUIs (as outlined in the Humane Interface), or life streams).
Clear labelling
Clearer labelling is harder to achieve, however there are a few systems for doing this. Digidesign produce custom keyboards for their Pro Tools system. Having used one of these keyboard I can testify to their usefulness. The problem with having the details printed on the key is that they are only applicable to one application.
A more generic solution to keyboard labelling is the Optimus Maximus keyboard. Each key of the Optimus Maximus has an embeded OLED screen. These screens are used to show different glyphs in different circumstance. For example when using Photoshop the keyboard displays the icons of the on screen tools. Unfortunately the Optimus Maximus is considerable more expensive than a standard keyboard (it also has received critisim for its typing experiance). However the Optimus Maximus is the first of its kind - I expect more affordable and more tightly integrated solutions will soon emerge.
Further Reading
- Donald Norman - Design of Everyday Things (I highly recommend this book).
- Jef Raskin - The Humane Interface.
REST + XMLHTTPRequest + 401 != joy
27/05/08 15:38 Filed in: Web development
For the last few months I’ve been working on a web app using PHP that I’m trying to be as RESTful I can. It’s been a learning curve, and has been both satisfying and infuriating. Over the weekend I’ve been working on the authentication. As it is a RESTful app HTTP digest authentication is the obvious (only?) choice. This being 2008 I also want the app to be pretty, like all the other web 2.0 apps (I hate the term “2.0″. If the internet was made of technologies that could be broken in to discrete versions then life would be so much easier. While IE6 is still around the web will be stuck in beta testing).
Unfortunately, after much keyboard thumping and bouts of pseudo-tourette, I’ve reach the conclusion that RESTful apps haven’t got the style to get into Club Web 2.0.
This conclusion is based on the assumption that the standard browser authentication dialog box should be banished to 1997 and has no place in a 2008 web app. I must mention that I have only tested this on Firefox 2, Safari 3 and Opera 9 on OS X 10.4. FF and Safari both suffer from the problem outlined below. (Opera will always display the ugly dialog box even if a username and password were supplied to the xmlhttprequest object).
There are a few tutorials that say that you can use the xmlhttprequest object to suppress the browsers dialog box. It is true that the xmlhttprequest object can do this, but it only works in very select conditions. This is because of two features (bugs?) of the xmlhttprequest:
1. Firstly the XHR only answers the first 401 response per resource. Any subsequent 401 responses will cause the ugly dialog box to pop up. There a quite a few scenarios where the server might respond with a 2nd 401 response. The most common is when the username and password supplied to the XHR object are incorrect. Another common occurrence is that the nonce used in the digest expires causing the server to send a new nonce with the 401.
2. Above I mentioned that “the XHR only answers the first 401 response per resource“. This means that we could re-authenticate using a different resource. The problem with this is that browser send a mix and match of digest information. Here’s an example:
Lets say that www.example.com/restricted/ requires authentication. Once the server has authenticated the client, the client will continues to send the the authentication details to all resources within www.example.com/restricted/. This is the correct behaviour.
Next the client tries to access www.example.com/restricted/secrets.html. When the client sends the request it also sends the authentication headers as before but this time the server response with a 401. The credentials that were valid for the rest of the site are not valid for this one resource. If we this request is made with the XHR object then it counts as the first 401 response from that resource. Therefore the XHR sends the request again using the username and password. So where’s the problem? The problem lies with the fact that the client (Firefox 2 and Safari 3 at least), continue to send the nonce from the very first 401 response. The server may not accept the old nonce for this request and will send another 401 response. This second 401 response will cause the client to show the ugly dialog boxes.
I have developed methods to work around both of these problems so that the XHR could be used. I’m not going to use either of them because they are ugly and complicated. I always strive for simplicity as simple code is easier to understand and there’s less chance for things to go wrong. Introducing unnecessary complication into an authentication system is asking for trouble.
Unfortunately, after much keyboard thumping and bouts of pseudo-tourette, I’ve reach the conclusion that RESTful apps haven’t got the style to get into Club Web 2.0.
This conclusion is based on the assumption that the standard browser authentication dialog box should be banished to 1997 and has no place in a 2008 web app. I must mention that I have only tested this on Firefox 2, Safari 3 and Opera 9 on OS X 10.4. FF and Safari both suffer from the problem outlined below. (Opera will always display the ugly dialog box even if a username and password were supplied to the xmlhttprequest object).
There are a few tutorials that say that you can use the xmlhttprequest object to suppress the browsers dialog box. It is true that the xmlhttprequest object can do this, but it only works in very select conditions. This is because of two features (bugs?) of the xmlhttprequest:
1. Firstly the XHR only answers the first 401 response per resource. Any subsequent 401 responses will cause the ugly dialog box to pop up. There a quite a few scenarios where the server might respond with a 2nd 401 response. The most common is when the username and password supplied to the XHR object are incorrect. Another common occurrence is that the nonce used in the digest expires causing the server to send a new nonce with the 401.
2. Above I mentioned that “the XHR only answers the first 401 response per resource“. This means that we could re-authenticate using a different resource. The problem with this is that browser send a mix and match of digest information. Here’s an example:
Lets say that www.example.com/restricted/ requires authentication. Once the server has authenticated the client, the client will continues to send the the authentication details to all resources within www.example.com/restricted/. This is the correct behaviour.
Next the client tries to access www.example.com/restricted/secrets.html. When the client sends the request it also sends the authentication headers as before but this time the server response with a 401. The credentials that were valid for the rest of the site are not valid for this one resource. If we this request is made with the XHR object then it counts as the first 401 response from that resource. Therefore the XHR sends the request again using the username and password. So where’s the problem? The problem lies with the fact that the client (Firefox 2 and Safari 3 at least), continue to send the nonce from the very first 401 response. The server may not accept the old nonce for this request and will send another 401 response. This second 401 response will cause the client to show the ugly dialog boxes.
I have developed methods to work around both of these problems so that the XHR could be used. I’m not going to use either of them because they are ugly and complicated. I always strive for simplicity as simple code is easier to understand and there’s less chance for things to go wrong. Introducing unnecessary complication into an authentication system is asking for trouble.
Shuttle K45 - optical drive? Check.
20/04/08 18:41 Filed in: Hardware
I recently bought a Shuttle K45 to run Ubuntu server. I’m waiting until Hardy Heron is released proper until I set to work setting up the software. However, there are a few things about the K45 that I think are of interest.
- Firstly, there is space in the case for an optical drive:
As you can see from these photos there is space for an optical drive, albeit a slim line one. The problem is that the plastic image sheet and the perspex that cover the front (abscent in the photos) don’t have a slot for the drive. This is a only a minor problem, however. - I bought my K45 from Misco. It didn’t come supplied with the Shuttle ICE cooling system. The ICE system is far quieter than the standard CPU fan that comes with the Celeron I bought. Also the instructions (which are a bit thin, consisting only of one large colour sheet) show and refer to thumb screws. I like thumb screws, they’re nice and chunky, however, my K45 only came with normal screws. Boo.
- The IDE socket is very picky. My original plan was to have two SATA hard drives and an compact flash to IDE converter. I was going use the CF/IDE to run the OS from and use the harddrives exclusively for storing data. Unfortunately the K45 doesn’t like CF/IDE converters. I tried two of them and each time the K45 refused to boot from them, no BIOS fiddling seemed to fix this. I empathises ‘boot’ as it does recognise the drive. Infact, I managed to install Ubuntu to the CF/IDE but it wouldn’t boot from it. This isn’t a major problem, but it is an inconvenience. My first attempt at a solution was to use a USB CF reader and run the OS from that. But the CF reader I bought wasn’t bootable, so I’ve gone for a normal USB flash drive which will complicate the install, but where would the fun be if everything was easy?