This needs a higher profile – a service to show you what any website looks like to someone with various sorts of colourblindness. (Example: compare WAI and colorblind WAI.) If you use the grayscale filter, not only will you know whether any bits of your page would be unreadable to one or more colourblind people, but it would also make it obvious where you haven’t explicitly specified colours (because the default colour will remain).
This is obviously useful to web designers, but perhaps it would also be useful to colourblind people too. When they complain about a website, they could send a URL saying “this is what it looks like to me”, to give the webmaster an idea of the problem.
Is it just me, or do the default OpenOffice.org Writer styles suck?
Given that most people don’t even use all six heading sizes in HTML, what made them think that it was vital to have ten styles, adjacent pairs of which are only distinguished by the presence of or lack of italics? Quick: is the italicised one more or less important? Heading 1 is not at all suitable for the top of a document, where I, at least, would expect something centred and perhaps underlined. And the spacing OOo leaves between the smaller headings and the previous paragraph is far too large, giving documents a “gappy” appearance.
In the default list, what’s the difference between “Default” and “Text Body” anyway? And where are the styles for common things like like “Quotation”, “List”, “Emphasis” and so on?
There’s a “Styles and Formatting” window which you can invoke when you want anything more than the default simple five which are in the toolbar dropdown (thereby making you pay a window management penalty). There are about five different ways of configuring the exact list of styles it displays, but it does not have a “New” button. The closest you have is “New Style From Selection”, which is one option on a combination pseudo button/menu in one corner with a totally unintuitive “Paragraph” icon on it. (After five minutes of searching, it turns out that you can create a new style from the context menu.)
Lastly, whenever I try and read a Word document, it always sets the margins too far in so some of the content is squeezed onto the next page. Do Word files not contain margin information? Grr.
There’s a big opportunity for the free software world to make a word processor which is actually usable – because it’s one area Word has failed miserably in recent years, hence their multi-million dollar new UI. The retraining this UI requires is an opportunity to persuade people to switch; but it’s going to be a hard sell if the alternative is even more complex than the original.
I’ve been following bug 366797, and discussions in mozilla.dev.security, with great interest, and I’ve been thinking about this for some time now. Here’s my (slightly long) attempt at a unified and consistent proposal for changing the way the location bar works for Firefox 3.
In the original design of the web, the URL was supposed to be an implementation detail. That hasn’t turned out to be the case, for better or for worse. Still, the URL bar itself has changed very little since Netscape 1. I believe there’s scope for changing the way it works to improve the user experience.
Don’t break stuff people use
Make the hostname stand out more to reduce spoofing
Reduce the risk of spoofing in other ways
Make the contents of the URL bar more understandable
Make common operations easier
Find a way of presenting information from EV certificates
1) Hide the scheme
The scheme (e.g. “http://”, “ftp://”) should be hidden permanently for HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP have long since ceased to matter to the average web user. The difference between HTTP and HTTPS is, of course, important, but we have other UI to indicate that. (And if it sucks, we need to fix it.) Eliminating the scheme also means we could do things like show some HTTPS connections as if they were HTTP – e.g. for self-signed certificates, which people just use when they want eavesdropping protection – without our UI being inconsistent. This is an improvement on the current behaviour, which is just to throw an error.
FTP could have a special favicon, as could file://.
2) Hide username and password
If present. Usernames and passwords over unencrypted channels, embedded in GET requests (which are cached) and links, are fundamentally insecure and their most common use is for spoofing (although we already have some protection against that). If people type them in, we’ll use them to try and log in, but we won’t show them in the location bar.
Yes, this makes them less useful – if you make a typo, you need to retype everything. I don’t think this is a bad trade-off.
3) Highlight hostname
Take either the entire hostname or the Effective TLD + 1 and highlight it in a button-like style. So either:
(We need to be careful with bold; with some fonts, it reduces the difference between letters such as l and i, which is bad from a spoofing perspective. Further research required.) There is some space (perhaps half an em) either side of the button.
Clicking the hostname “button” takes you back to the root of the site – and this would affect which of these two options we actually choose. Consider george.blogspot.com/archive/… – do we want to go back to george.blogspot.com or blogspot.com? Probably the former. But then that would mean that microsoft.com.foo.bar.baz.evil.com would be all on the button, including the microsoft.com part. Difficult.
For file URLs, you’d get:
on Windows, and
on Unix. Yes, these two are inconsistent with respect to the placement of the initial slash. I’m not sure how to deal with that. I think a prefix like
would be horrible, particularly on Unix.
Example of what I mean, so far:
4) Display EV business name and country
For HTTPS connections with EV certificates, replace the hostname with the O (Organisation) and C (Country) fields from the certificate. So:
Replacing the hostname rather than just adding to it means there’s a really big difference between the real site and an attempted spoof, which would have a domain name in that space rather than a textual name.
We need to include information about the country (there can be businesses of the same name in different jurisdictions), and the question is, do we use letters (US, UK, CM) or a flag? A flag is safe because we are actually talking about countries, not languages, and it might be more recognisable and differentiable. IE and Opera are using letters.
Example (ignore the unlikelihood of the URL):
The flag is next to where the favicon should be, which raises a risk of confusing of spoofing, but leads on to:
5) Remove the favicon from the URL bar entirely
We would keep it on tabs, of course. I realise this is controversial; here’s my rationale. Favicons in the URL bar are dangerous, because they represent the website having some control over what’s in the chrome. This is why we turned off website access to the status bar. We already have spoof websites having a little lock as their favicon, to try and persuade users they are over SSL. Let’s put the websites back into the content area box.
This would probably imply making the tab bar always visible – i.e. setting browser.tabs.autoHide to false – so that the favicon was always visible. I think this is good because it improves the discoverability of tabs and stops the content area jumping around when you go from one to two tabs or vice versa. I don’t know if the default setting of this preference is a controversial issue.
I believe that the only other function of the page-proxy-icon (where the favicon appears) is to be draggable to create e.g. bookmarks toolbar entries; that role could be taken over by the domain name button, perhaps. I admit there’s further thinking to do here.
6) Focus turns bar back to a text box
On focus, move back towards being a text box. People have important behaviours to do with URL bar hand-editing that we don’t want to break. Therefore, clicking anywhere in the URL bar (except on the domain button) or pressing Ctrl-L, focusses the URL bar and makes the following changes.
The 3D-ness of the domain button becomes faded and 2-D – so the separation is still visible, but the URL now looks flat. The URL bar acts as much like a single text box as possible. The spaces between different parts remain (to keep the text stable; the text must absolutely not move on focus, otherwise the caret appears somewhere different from where you clicked) but if you select and copy, the spaces don’t appear.
7) Change selection behaviour
People edit individual URL components. So, we should make it easier to select individual components. Like in a word-processor, a single-click focusses, a double-click selects a component (“word”) – hostname, path segment, URL parameter key+value or fragment identifier, and a triple-click selects the entire URL (equivalent to “select line”).
Again, I don’t know if this is a can of worms – I suspect URL bar selection behaviour has been discussed before.
8) Analyse font choice carefully
If we are emboldening some parts of the URL (e.g. the domain), we need to be very careful about choosing fonts where the bold version provides enough differentiation between visually close letters like i and l. For example, the font that my copy of Firefox uses for my example bold URLs (see mockups) has very bad i/l differentiation. Perhaps we might consider a fixed-width font in the URL bar? This would also make selection easier; at the moment, putting the caret in the right place in million.com is nearly impossible for those with less than perfect motor skills, and tricky even for those with.
Not all of these suggestions are interrelated; some could be removed without affecting others. This is not supposed to be a tightly-bound take-it-or-leave-it package.
More great data visualisation stuff. Imagine taking a map of the world, and having each country as a balloon. Then, inflate or deflate the balloon until the relative areas of the countries represent some statistic about them. You get a wonderful graphical representation of that data set which is much easier to understand than a long column of figures.
Here’s the base site – some researchers at the University of Sheffield. Some pictures that I found particularly interesting were:
My latest article for The Times Online, called “Chip and SPIN“, points out that the much-trumpeted switchover to using PINs rather than signatures for plastic card transactions in the UK may not have been as consumer-beneficial as the banks would like us to believe.
Since it was published, someone has emailed me the following additional information:
In 2005, fraud at ATMs stood at £74.6M, a rise of 81% on the previous year. (Source: Card Fraud the Facts)
A recent announcement from Tesco, relating to their attempts to combat card fraud, said: “Statistics show that skimming accounted for over £95 million-worth of losses to customer accounts across the entire network of ATMs.”
This is another rise (of about 27%) for 2006 so far.
It should be possible to contact your bank and opt for a “Chip and Signature” card if you feel unsafe using a PIN.
Yngve has an interesting post about how to deal with the problem of banks etc. doing login by submitting from an insecure to a secure page.
The aim is not to protect each user’s form submission when using the broken page; the aim must be to get the bank to fix the site. So we need to change the browser to inconvenience the bank’s customers enough that they complain to the bank, but not enough that they try and change browsers to one which does not have this “feature”. In other words, we need to carefully tune the level of user irritation ;-)
So how can you inconvenience the users? One option is Yngve’s popup on submission; make the users press a big button marked “Submit Insecure Data”. That should cause a few panicky calls to the bank’s tech support line. Another option would be to delay the rendering of the next page by five seconds or so, while displaying some sort of warning in the blank space; banks like their sites to be snappy, and they don’t like worried customers.
If we are going to make browser changes, we’d need to do it in a synced up fashion, so people didn’t simply reduce their security by switching browser provider.
One last option would be to sponsor a 3rd party “major banks security assessment”, which took in details like this, the format of emails they sent out, whether they used third parties for email delivery, and so on. Publicise the results, and try and shame the lagging banks into compliance.
I’ve just finished watching Jeff Waugh speaking about Ubuntu at the end of FOSDEM – I missed the talk because I was at the l10n session in the Mozilla developer room. He talked about how they had been making Ubuntu ready for the desktop; how open source software is often better than proprietary, particularly the out-of-the-box user experience; and how open formats are great, and everyone should be encouraged to use them rather than the proprietary stuff.
The encouraging nature of his words was only partly spoiled by the fact that I was watching an Ogg Theora video in Totem on a standard install of Ubuntu’s latest stable release, and the syncing between audio and video was on average out by about 20 seconds for the entire period of playback, and the video changed speed every half a second, alternating between super-fast and frozen.
I recently came across bsmedberg’s Locale Switcher extension. I was thinking that something like this was needed for Internet cafes, where successive people may want to use the browser in different languages. However, the ability to change languages on the fly is not common, and so the UI for doing so needs to be really obvious and up-front if people are going to find it and take advantage of it.
The problem is further complicated by a technical limitation. It’s not possible to change the language of an already-existing window. All you can say is that all new windows should have the new language. And so the UI can’t just be a set of buttons where you click one and get on with what you were doing.
Here’s my current attempt at the UI for an Internet Cafe Locale Switcher. Comments are very welcome.
Each browser window has a toolbar, which looks something like this (except fixed up and fitting with the rest of the UI and so on):
New windows in:
The toolbar appears in every top-level window, and changes to it are synced between windows.
As you hover over each control in the toolbar, two things happen:
The phrases “New windows in” and “Open New Window” change to be in the relevant language
A tooltip appears, saying “Make new windows use an English interface” or equivalent.
The space for the “New window in:” text is long enough for the longest configured string, so that the controls don’t move during mouseover.
This is the clearest thing I can come up with which reflects the fact that the change of language is really a setting for future windows rather than for the current window, yet makes it as easy as possible to get a new window in that language, without possibly losing or hiding any work the user may have in the current window.
I wrote it to solve the problem that currently, browsers don’t handle such links very well. When you click one, the page jumps rather than scrolls, which is disorienting, and the new content appears at the top of the viewport – except when it’s near the bottom of the page, when it could actually be anywhere in the viewport. This problem creates uncertainty, and makes intra-page navigation less usable than it need be.
For those doing usability studies on Windows software, DemoStudio is a free software screen and audio recorder which can output as AVI or Flash. Sounds like it would be great for recording what a user does during a test so you can play it back later in sync with your video camera to do your analysis. (Via NewsForge).
Why do the neither of the taskbars in the two main free software desktop systems behave in a sane fashion?
What I want is basically what Windows can do – a double-height taskbar so I can have several apps open and still see the titles on the window buttons, but with space economised to the left and right by using small icons for tray apps, QuickLaunch and so on. And I want it to fill up left to right, then top to bottom, so it’s easy to mentally thread it into one long row. And when I close a window, I want as few buttons to move as possible.
Windows fails to achieve perfection in only a few small respects. When you expand the taskbar to double height, the start button goes to the top left rather than the bottom left. In neither configuration is the Start button or the bottom row of window buttons a mile deep. And it doesn’t allow tray icons to wrap round the clock.
In Mandrake 10.0 KDE, you can get something a bit like this, but for some reason it decides to populate window buttons into the double height taskbar top to bottom before left to right, which means that when you close the first window you ever opened, 100% of your window buttons move vertically, and 50% of them also move horizontally! Nothing is where it was a moment ago! It’s incredibly disorienting, and I never found a way to change it.
In Ubuntu 5.04 GNOME, which I’ve just installed on my laptop, you can have multiple toolbars (the default install has two). However, the widget which displays the current window list can only appear on a single bar. So, to get two rows of buttons, I have to double the height of the bar. However, it now “helpfully” expands all the other widgets (like the “Show Desktop” button) from 24×24 to 48×48, thereby squeezing the available horizontal space. Doh! By the time I have all the other widgets on the bar at that size, there’s barely any room for window buttons at all.
It’s not as if my requirements are odd. “UI stability” is a reasonably well known UI maxim – so what’s going on with KDE? “Maximal space for window buttons” doesn’t seem like an uncommon use case – so what’s going on with GNOME? Or have I missed something?
Unfortunately, I can’t recommend it, because (and this is why this post is in the Usability category) the authors seem to have gone out of their way to make the program extra complex. To see what I mean, have a look at the online version, which you are supposed to use when you don’t have access to a copy of the extension.
Now, the ideal UI for something like this would be one where you enter your master password once, and then enter URLs, and an appropriate password comes back to you. At most, you have to enter two pieces of information. However, with PasswordMaker, you also need to enter:
“Use l33t” – whether you want to put the text through a l33t-speak generator at various points in the process. I can’t see the point of this, apart from to create more settings to remember. It doesn’t make the generated passwords any more compatible.
“l33t level” – a parameter for configuring the l33t feature.
“Hash algorithm” – why would a user ever want to choose the hash algorithm? The implementor should just pick any of the suitable ones, and stick with it. Yet another thing to remember, and gratuitous incompatibility and complexity. Note the number of JS algorithm libraries the page has to include.
“URL components” – choose which URL components are included in the hash to make up the password. I can’t see a use for this either – clearly, you should include the protocol, port, domain and path but not the query parameters. Sadly, in the online UI, that’s not one of the options – “query parameters” are bound to “path” in the same checkbox.
“Length of generated password” – this should just be the length which is long enough to be secure, and compatible with most restrictions people place on forms. I’d suggest 8, but you’d need to do research.
“v0.1 compatibility mode” – a.k.a. they didn’t think about all this stuff hard enough first time round ;-). Note that you can only select this if you remember that version 0.1 used MD5 as the hash algorithm – but it doesn’t say that anywhere.
In summary, PasswordMaker is an excellent idea, but it has a terminal case of featureitis. My recommendation: do a (backwardly-incompatible) version 2 with sensible defaults and no configuration, and it could really take off.