Among the many web development books in my library is a book called Defensive Design for the Web which I bought a couple of years ago. It’s a catalogue of usability tips, complete with examples of websites successes and failures. I strongly recommend it to anyone who programs web applications.
A lot of web usability is common sense, but when you compile all that common sense into a book, it’s an extremely valuable reference.
The PCI DSS is clear on how to handle CV2 (also known many other acronyms: CVV, CVV2, CVN, CCV, CVC). You may not store this number “subsequent to authorization”, not even encrypted. This means the number is highly sensitive. It is treated as the one true anti-fraud measure for Cardholder Not Present transactions. Of course, this is slightly odd - it’s written right there on the card for any old waitress to see - but the Payment Card Industry makes the rules and this is the rule they’ve set.
The user friendly model for e-Commerce payment is this:
Confirm these purchases -> Enter credit card details -> Please confirm that all of the above is correct -> Thanks, here’s your order confirmation.
The final confirmation is vital for making sure customers are informed about exactly what they’re agreeing to. Customers, en masse, are stupid, and they often get to this stage before realising they’ve messed up something. The difficulty then is that the request where the web application received the credit card details is different to the one where the customer authorises it to go ahead. This means that the credit card details must persist for at least one request. In the unhappy world of statelessness that is HTTP, that translates as ‘indefinitely’.
To investigate how other software tackles this I’ve come across a startling lack of awareness in open-source shops.
First I looked at Satchmo. Satchmo stores CV2 unencrypted in the database. I couldn’t see any code that deletes it after authorisation. It also stores the card number (PAN) encrypted symmetrically with a key from the settings file. This is incredibly naïve! A compromised server would compromise the card information for the entire order history.
Then I looked at osCommerce. Unbelieveably, osCommerce appears to return the CV2 to the customer… in the address bar! Where it will be stored in the browser’s unencrypted history for maybe 90 days.
These are the technical options as I’ve thought of so far:
Given these the only option that I am personally happy with is 2 so that is what I intend to implement. I don’t like the PCI DSS, incidentally. I don’t like global financial companies mandating what the little people must do to protect their profits. I don’t like the way it’s written - describing what you mustn’t do without offering it’s view of approved methodologies. I think it’s paranoid about network security, it overstates the benefit of firewalls, and it’s not comprehensive enough about application security. But I like security and I’m tolerant of this PCI DSS for that reason.
I’d very much like to hear if anyone has a better solution or a different opinion.
When in 1981 Steve Jobs said that “Rectangles with rounded corners are everywhere” he began a trend which today sees dozens of rounded rectangles on millions of PC screens almost all the time.
On the web the situation is even more desperate. Bound by the available technology, and aiming towards intuitive and usable HCI, designers often draw on rounded rectangles to make functional layouts appear more friendly and personal. More than that, using rounded rectangles is perhaps the simplest way to design a site that isn’t just boxy and dull.
In CSS, there are two well-known approaches. The fluid-width approach is to stick small graphics of rounded corners into each corner of a box - these cover up the box’s corners and make it appear round. The fixed-width approach is to have top and bottom images that comprise the corners, and a tiling background to blend between the two. CSS3 offers an improved background model that will render these hacks unnecessary.
Of course, it’s not necessary to stick to plain rectangles: using the above approaches, it’s possible to decorate them with drop shadows, highlights, stripes, cutouts or whatever else you’d like to. These aren’t just techniques for cutting corners - they generalise to techniques for decorating web-based boxes.
There are some caveats with nested rounded rectangles that you should watch out for. This is how nested boxes with rounded corners should appear.
The arcs for all the nested rounded boxes that share a corner should be arcs of concentric circles. In practice, this just means tweak the radii until they look right - so that they appear to focus on a point. Any square boxes should fall inside that focus.
Notice in the diagram below how square corners don’t work unless they are inside the focus. Nesting rounded boxes inside square boxes is an absolute don’t. A more common mistake is to use the same corner radius for an outer rounded rectangle as for a nested one. Most tools preserve the setting for corner radius, and that’s not what you want. Notice how the outer box appears proud in the diagram below, right (cf. above, left)
Notice below how when the boxes don’t share a corner, you can use the same corner radius, but the effect is slightly different. Using the above rule-of-thumb throughout will keep the design a little more down-to-earth.
I’ve just been reading the latest goss on Acid3 and I’ve come across the most wonderfully perverse announcement from Microsoft (this is a few weeks old, but it’s not like I regularly read Microsoft blags).
Since announcing that IE8’s renderer can pass Acid2, it transpires that they have a Catch-22:
To have IE8 conform to standards, you have to use a non-standard workaround.
Wow. I’d assumed Microsoft knew what standards were but couldn’t seem to achieve compliance. Not so! Turns out they can achieve compliance but they don’t know what web standards are!
On a couple of websites I’ve noticed an unusual style of side tab which oddly doesn’t seem to conform to the “tab” metaphor and which I find oddly baffling to use:
Jakob Nielsen offers 13 design guidelines for tabs but this is not covered. Not only does the the shape fail to convey these are tabs, the rounded corners appear to emphasise the deselected tabs over the selected one. It’s as if the selected tab is cut out from the set. Only a very slight change to the shape or shading would make these apparently negative tabs pop out, and usability would return.
I have been increasingly drawn into the world of blogging over the past few years. It is sometimes claimed that the blogosphere represents an information publishing revolution, and I wouldn’t disagree. Blogs are, in their simplest terms, a simplified content management system that has very simple and clear semantics and a very low barrier to entry. I sell customised blogs to my clients on exactly that basis. They are the cheapest websites we can offer.
Blogs are a trade off. Blogs make publishing easy, but the value of the collected content doesn’t increase as fast the quantity of posts increases, not in a single blog nor in the blogosphere as a whole. The archives of the blogosphere are hard to navigate. Where information can be found it may be wrapped up in reams of prose or buried way down in the comments. Most of the value of a blog lies in the most recent posts - the ones advertised at the top of the first page and the RSS feed. This, of course, is perfectly suited to news.
One comparison I could draw is with wikis. Wikis offer collaborative editing and this tends to increase the quality of the content as a whole (if the rate of improvement outpaces the rate of vandalism). Wikis are as a whole more up-to-date than blogs too, because old articles linger indefinitely in the archives of blogs, whereas wiki pages are replaced in situ. Personally I find a single wiki - Wikipedia - more useful than the entire blogosphere. It’s a very complex comparison to draw and an endlessly debatable one, but wikis offer a model which allows discussion or documentation of topics which are deeply interwoven - which is almost everything. Blogs mediate the actual mechanics of a single discussion better.
For professional publishing, we should try to identify and capitalise on the benefits of both of these models. It’s very tempting for me just to tack a blog onto a finished website so there is a channel for the owners to communicate with users, but lots of professional sites end up fronted by a rather dull blog, filled with unedifying news and other tidbits the authors think might engender some interest or at least turn up in search results. Instead, the heavily hyperlinked nature of a wiki could allow visitors to click from this sequential news to in-depth information, and collaborative editing (internally not publically, of course) could increase the quality of the content they find better than a shallow hierarchy of authors and editors.
I’d be interested to know if there’s an advantage to releasing content in “issues” like a magazine. I wonder in particular if visitors can get more engaged in a site when it complete refreshes once a week than when there’s a slow but steady drip of articles. Not a great proportion of sites do this although I can think of a few (The Onion, Linux Gazette). By publishing in issues your RSS feed becomes an invitation, not a medium in itself, an approach which would partly quench my long-standing gripes about RSS. But spending a fortnight writing and editing articles could be much more valuable than a constant drip of articles. But above all it could allow time to create unique and engaging graphic design for dynamic content, a holy grail for the web industry, and something I’ll talk about another time.
