Indistinguishable from Direct Manipulation

If I worked for Diebold and wanted to help republicans win, I wouldn't do something easily detectable like changing 2% of votes to be for my candidate or making some machines break down at 5pm to give the the working class a difficult time. Instead, I would work harder on usability for machines going to friendly districts.

With this scheme, blame for any election-tipping would mostly go to "user error" rather than poor design. Even better, the voters who committed the errors will mostly be democrats, which will make democrats look dumb once again.

Drawn by Prof. Goguen in CSE 271.

In college, I knew some people with strong opinions about text editors.

Erika: gvim is one of the two true text editors.
Gabe: The other being vim?

Professor O'Neill defines mode error for the User Interface Design class and gives some examples.
Student: So when I'm using vim, and I forget to press 'i' before typing text, that's a mode error?
O'Neill: Yes. Using vim is a mode error.

I use Win32Pad for most editing. It's faster than Notepad, supports most of the keyboard shortcuts I'm used to (Ctrl+Left, Ctrl+Shift+Right, clipboard operations, etc.), and includes a few of the features I think every text editor should have, such as block indent, auto-indent, and clickable URLs. It's missing a few features I'd like, such as preventing me from opening two instances with the same file. It also doesn't support Unicode well, so I have to use Notepad for web pages that contain both Polish and French text.

Jakob Nielsen, Top Ten Web-Design Mistakes of 2002:

1. No prices. No B2C ecommerce site would make this mistake, but it's rife in B2B, where most "enterprise solutions" are presented so that you can't tell whether they are suited for 100 people or 100,000 people.

I also thought no B2C site would make that mistake, until I tried to purchase an SBC phone line for my apartment. After I clicked "Residential customers", clicked "Local > New Phone Service", and entered my address, the site asked me for billing and credit information. At no time did I see a price or even a link labelled "prices".

I decided not to purchase a phone line.

There seem to be five ways to set character encodings in Firefox.

1. Options > General > Languages > Default character encoding
2. View > Character Coding > Auto-Detect > (select a language or "Off" or "Universal")
3. View > Character Coding > More > (select an encoding)
4. View > Character Coding > Customize > Active character encodings
5. View > Character Coding > (select an encoding)

What do these options do? How do they interact? How can the options and how they interact be made more clear in the UI, or even in Help? Note that I only have a vague idea of what a character encoding is and why a user would need to select one.

Google didn't get me far. Help in Firefox only says "View > Character Coding: Allows you to manually change the character encoding on a Web page. Firefox usually does this automatically." Bug 181541 comments 61 and 62 helped me understand a little.

I discovered arbitrary code execution holes in Firefox, Internet Explorer, and Opera that involve human reaction time. One version of the attack works like this:

The page contains a captcha displaying the word "only" and asks you to type the word to verify that you are a human. As soon as you type 'n', the site attempts to install software, resulting in a security dialog. When you type 'y' at the end of the word, you trigger the 'Yes' button in the dialog. I made a demo of this attack for Firefox and Mozilla.

Another form of the attack involves convincing the user to double-click a certain spot on the screen. This spot happens to be the location where the 'Yes' button will appear. The first click triggers the dialog; the second click lands on the 'Yes' button. I made a demo of this attack for Firefox and Mozilla.

These types of attack work on any security dialog that can be triggered by untrusted content. The attack is most useful in a dialog where one of the buttons means "Yes, let this untrusted content run arbitrary code". Firefox has such a dialog in the form of the extension installation (XPI) dialog. Similarly, Internet Explorer has the ActiveX installation dialog and Opera has an "Open" button for downloaded executables. Programs other than browsers might also be vulnerable.

Firefox's solution, from bug 162020, is to delay enabling the "Yes"/"Install" buttons until three seconds after the dialog appears. I believe that this is the only possible fix other than completely denying untrusted content the ability to pose the dialog. Unfortunately, this fix is frustrating for users who install extensions often.

Some users have been intentionally lowering the delay to 0 seconds, which frustrates me. These users think the delay was added merely to force everyone to read the dialog. It surprises me that these users were not able to figure out the security hole given the fix. Ironically, advanced users are the most susceptible to these attacks, because they type and double-click faster than they react to unexpected stimuli.

It might be possible to lower the delay to less than three seconds, making it less annoying, without jeopardizing security. Designing experiments to determine the minimum "safe" delay would be tricky. You would want to do everything an attacker could do to increase participants' reaction time: give them a complicated task, make new rectangles appear every second to make the dialog less unexpected, etc.

It might make sense to make the dialog appear only after the user clicks a statusbar indicator that means "This web site wants to install software". This would get rid of the problem of choosing a delay, and it wouldn't require users who want to install extensions to wait.

I signed up to interview with Expedia on Monday. I figured I should look at their site for a few minutes before interviewing with them, but I ended up playing with their basic search feature for over an hour.

Should I spend my 30-minute interview pointing out how their site sucks* or trying to get a job?

The form on the front page

• "Search for flight" (for submitting the form) looks like a link, not a button. IE users are used to losing form data randomly when they click on links, so they'll spend a lot of time looking for something that looks like a button before clicking the link.
• The return date textbox is prefilled with "mm/dd/yy". Prefilling textboxes like that is usually frowned upon, in part because it makes people like me skip the textbox. But I think I understand why Expedia prefills it.
• If the return date textbox is prefilled, it should clear itself onmousedown!
• Why make it look like I have to enter a year? I'm very unlikely to book a flight more than a year in advance. And I'm still typing the year as "03" out of habit, even though it's been 2004 for a month.
• The single-digit date for February in the "Depart" textbox makes it look less like a date.
• Why can't I get a flight and a car without a hotel? I can get every other combination of flight, car, and hotel.
• I think the form should use 3 checkboxes (flight, car, hotel) rather than 7 radio buttons (each nonempty subset of {flight, car, hotel}). Using checkboxes would make the UI simpler but would require more clicking.
• "Morning, Noon, Evening, Anytime": What times does Expedia consider "morning"? More importantly, what times are "noon"?
• "Morning, Noon, Evening, Anytime": Where's the "middle of the night" option?
• The DHTML calendar does not work in Firebird.
• In the DHTML calendar, double-clicking the right button only goes forward one month. This is a bug in IE, but Expedia should work around it because it affects almost everyone who books a flight two or more months in advance.

Leonard Lin is teaching animation students basic programming so they'll be able to use Maya's MELScript and Flash's ActionScript. He chose JavaScript as the first language for his students because JavaScript and ActionScript are both variants of ECMAScript.

I made a simple JS learning environment to cut out the save-switch-reload cycle and the "magic" HTML that surrounds a short JS program. If an error occurs, it highlights the line.

I reused a lot of code and UI ideas to make it. The overall UI comes from the Real-time HTML editor, the print() function comes from the JavaScript Shell, and the error-selecting idea and code come from the "blogidate XML well-formedness" bookmarklet. If you want to look at the code for the JS env, most of it is in the "buttons" frame.