To those companies that follow lots and lots of people in an attempt to get people to follow them back: here are some tips on how to get me more interested in following you, or at least to seem a little bit less sleazy and desperate:

• Be relevant to my location or interests. I'm looking at you, roofing company in San Diego--I don't have a house (which, to be fair, may be a bit difficult to tell), I no longer live in San Diego (that's right in my profile), and I never, ever talk about home improvement projects.
• Talk about something besides yourself. If you're fishing for followers like this you're going to get people who aren't necessarily interested in you but are interested in the general field that you're in. Talk about things that are related to what you do that are interesting to the people you want to attract. For instance, the aforementioned roofing company might remind people about routine gutter cleaning or provide tips on safe ways to install things on the roof alongside promotions of their own products and services.
• Interact with your followers. Even if you're not willing to talk about anything but your own products, you can still prove that there's an actual person behind the account and not just press releases, someone I could ask for advice or details about your products if I find them sufficiently interesting. Also, if you have a link to your website or a press release in every single tweet you look like a spammer; this is a good way to break those up.
• Don't follow me more than once. If I didn't follow you the first time I'm sure not going to do it if you keep bugging me.

So, if you haven't heard, some web browser vendors are considering adopting -webkit- css prefixes because a whole lot of developers have been writing css that only uses the webkit prefixed versions of some of the new css3 properties. Bruce Lawson has a nice longer summary of what's been going on, if you want it. Frankly I haven't been paying a huge amount of attention because it all seems so silly (haven't we been down this road before? IE6 was the good browser...), but I've been informed that my point of view is an unusual position that no one else has been taking, and that I should blog about this. This probably means that no one agrees with me, but anyway.

The thing is, after several years of using new css3 properties, I kind of like vendor prefixes for several reasons:

• They're a big red flag that says that this property, in particular, is not stable or finished, and is subject to change (see, for example, the gradient property, which has changed quite a few times over the past couple of years). I should use it with caution, pay attention to future changes in the spec, and be prepared to update my code. I have limited amounts of attention, so it's nice to know right when I'm using them which ones in particular might break.
• They let me turn things off for particular browsers. Webkit implements things early so you can play, but it's often sloppy and doesn't always address all the edge cases right away. Usually when something makes it into firefox it's got all of the common uses covered. I have, in production code, intentionally put in the -moz- and un-prefixed version of a css property and left the -webkit- version out. I can still do this, since it's the webkit version that may get implemented in other browsers, but imagine if it were the other way. I like being able to separate one browser from another when it comes to the new experimental properties.

Now, I will grant you that using the prefixes is annoying and harder to read and maintain, but as someone who has made sites work with the IE peekaboo bug and other nasties, it really isn't that hard. Annoying, but really not that bad. And I don't compile my css, but I hear there are tools that will automatically prefix for you. For me, the potential benefits outweigh the difficulty.

And I do honestly wonder how many actual production websites are ruined in non-webkit browsers because the developer only used -webkit- prefixes. I've seen all sorts of webkit-only demo sites that could in fact work in other browsers if the developer had made the extra effort, but I don't think tech demo sites should really count. What are the broken mass-market websites? And what is broken, and why? If there are properties that are only available in webkit that are necessary for a site to function, perhaps the better answer would be to fast-track those properties into the spec?

I may be a bit late to the party, but I just joined Pinterest. Mostly it seems to be used for crafts, recipes, interior design, and fashion, and my friends that enjoy those things have been on it for a while (beating my early adopter techy friends at early adoption). After playing with it a bit, I realized that it might also be good for mood boards, which are something I've been wanting to try but haven't had a new, from-scratch project to try them on.

Mood boards let you pull together design elements that match a particular theme ("shiny and slick", "old fashioned type and paper", etc.) to help agree on what the theme for a site should be. Pulling similar things that you like together is exactly what pinboard is good for--you can "pin" new design elements that you find on a site, add a new picture, or repin from Pinterest's very nicely browseable interface. I could imagine having clients create a collage mood board with Pinterest, especially using the repinning feature, to pull together elements that match what's in their heads, and then working with them to create a more structured mood board based on the elements they find.

If you're using NVDA to test your website accessibility (which you should! (Note to self: actually do that on this blog...)), you may be as pleased as I am to discover that there are some alternative voices you can use in place of the default synthesizer.

I had been using Microsoft Anna with the Microsoft Speech API v 5 (I believe this is also called SAPI5), but, while I find it less painful than the default voice synthesizer, it's not very good. I'm trying out the Microsoft Speech platform, available starting with NVDA 2011.3, which has a number of voices available.

Starting with NVDA version 2011.3, the Microsoft Speech Platform is now supported by NVDA. You will first need to install the Speech Platform Runtime. Then you may browse the redistributable language packs for the specific voices for the languages you prefer. Some voices are low quality, so you may have to hunt around for the good ones. These are voices which are by default available in Windows 8. Be careful though not to install the MSSpeech_SR MSI files, as those are not voices. Those are for speech recognition. Keep looking down the list and you'll come to the MSSpeech_TTS MSI files for the individual voices, those are what you'll need.

I like the "ZiraPro" U.S. English voice, and the British one seems nice too. To enable the new voice:

• Install the speech platform and the the voice pack
• Start NVDA and go to the NVDA menu (Ins + N) -> Preferences -> Synthesizer and change the Synthesizer to "Microsoft Speech Platform"
• Go to the menu again, Preferences ->Voice Settings and pick a voice

There! So much more pleasant and comprehensible!

For the past couple of months I've been doing a lot of work with accessibility.  Parts of the design of the website I'm working on are very dynamic, with ajax and inline changes and dialogs.  It's relatively easy to get these things to be keyboard accessible (though that has its difficulties, too, perhaps that's another blog post), but the big challenge is getting it to be comprehensible to those who interact with the site with screen readers.

One example of something I've done is a list with delete buttons.  When a user clicks the delete button, the item it belongs to disappears and a message appears informing the user that the item has been deleted and asking if they want to undo that action.

It used to be safe to assume (or so we thought, anyway) that screen reader users would have javascript turned off.  So as long as a site had a non-javascript fallback, it was "accessible."  Users with screen readers would get a new page, and their screen reader would read all of it including whatever changed, others would get something fancier like an in-page reload. So in the example above, screen reader users could get a completely new page with a shorter list and the success message at the top, everyone else would have the item removed inline.

But the WebAIM 2009 screen reader survey says that the "vast majority of screen reader respondents encounter scripted content".  Only 10% of those surveyed said they turned off javascript, 75% said they didn't, and 15% didn't know.  If 75-90% of screen reader users are getting the javascript version, just having a non-javascript fallback isn't going to cut it anymore. That means that in my list example most screen reader users would push the delete button, the inline removal and status message would appear, and the screen reader would not tell the user either that the item has disappeared or that a status message has appeared without further work by the developer.

Announcing new content with focus control

One method for getting a screen reader to announce new content is by controlling focus. When you click on items or tab through the links you change the focus, and every time the focus changes the screen reader announces the newly focused item.  Javascript can also cause the focus to change, and thus get the reader to announce something new.

This technique is limited in several ways.  First, only interactive elements cannot be focused in older browsers--in other words, the paragraph explaining that the item has been deleting cannot be focused (or announced), but the undo button can be. It's not a great experience, but it's probably better than a full page reload or no feedback at all.

Second, changing the focus also moves the screen reader's position in the page. If the user is in the middle of a list and the announcement is at the beginning, now they've got to move all the way through the list. The screen reader probably has hotkeys to let them do it quickly, but still it would be nice if they didn't have to do that.

Finally, it's just hard to get this to work reliably in all browsers (this is web development, what did you expect?! ;)).  Sometimes the focus just disappears unless you add a timer to wait before focusing. What it focuses on when you hit tab at that point varies widely, sometimes within the same browser. I even got firefox to decide that tab meant select the next line of text, or to say one thing and highlight another, or to just have the screen reader announce "Unknown object" or nothing at all.  Sometimes the presence or absence of a screen reader affects whether it works or not. All in all it's a pain in the butt.

Announcing new content with ARIA

A newer alternative to using focus is ARIA Live Regions. (If you're new to ARIA and accessibility, I highly recommend the design pattern section of the ARIA author guide, it's very helpful not only for the ARIA properties but for keyboard control and other accessibility best practices) ARIA live regions allow the screen reader to announce changed content or all content of a given section of a page whenever something is added, removed, or changed.

ARIA is still a spec, however, and not fully supported anywhere. And the wrinkle with using it is that it must be supported both by the browser and by the screen reader or you're back at the no accessibility at all state.

Since it is still a spec, I imagine there are a lot of screen reader users with browser/reader pairs that don't support it yet (if someone has real numbers on that I'd would seriously love to have them), so I tried to combat that by using both aria and focus.  Theoretically, ARIA-enabled users would have the entire "Item X has been deleted. [Undo]" message read to them, non-ARIA users would have just "[Undo]", and everyone else wouldn't notice anything.

That is not what happens. In some ARIA-enabled browser/screen reader combos, the reader will begin to read the status message, then get interruped and just read "[Undo]". This is actually worse than not adding ARIA at all.

The need for feature detection

This is actually a classic problem for web development. Theoretically, a site can be designed so it works well for the lowest common denominator, and is progressivly enhanced for newer and newer browsers. However, in practice the browsers that fall between no support and full support frequently implement only some of the required features, or they implement them badly or incompletely, making the experience much worse than the no support scenario. But we can detect which features are available, or sometimes check how they're implemented (e.g. IE6's box model) to figure out if the experience needs to be degraded to the next tier down or otherwise altered in some way.

The list example would be a great place to use feature detection--if there's no ARIA support, focus the button, otherwise don't.  Unfortunately, so far as I can tell there's no way to detect if there's a screen reader at all, let alone anything about ARIA support, which leaves me with the following options:

1. Remove javascript, provide a worse experience for non-screenreader--users (most of them) but a semi-accessible one to the screen reader users
2. Give up on the new stuff, just use focus--most users will not notice a difference, some screen reader users will have a worse experience than they could have but it will be semi-accessible for all of them
3. Design for the future, expect users with old screenreader/browser combos will eventually upgrade to a much better experience--users without screen readers again won't notice a difference, users with screen readers and ARIA will have a pretty nice experience, for everyone else it's inaccessible (but it's a decreasing number....)
4. Provide a second site without javascript
5. Give up on the whole accessibility thing entirely, it's just too hard

I don't like any of those options, but I need some help from browsers and screen readers to make good compromises possible.

I have heard people argue against just what I'm asking for, or screen reader detection in general (and I appologize that I can't find links to the arguments). The people who don't want it worry that web developers will misuse the power, and we'll have sites that say "Sorry, you can't see this site because you're not using Jaws forWindows" when in fact the user has a browser that's perfectly capable of handling it.

The thing is, though, we've already done that and learned it was a bad idea. I remember sites I couldn't access for not using Netscape 3 when I was using IE 5 (back when that was a good browser). We know better now, and I think those of us who know enough to create an accessible site in the first place can handle the responsibility of screen reader feature detection.

It is possible that you will see sites that are alternative versions specifically tailored to screen reader users. And some people seem to think that's a problem, too, but personally I wonder if it's really that bad. Alternative versions don't mean less or different content, they usually mean different presentation. Mobile users get alternate versions all the time because the full-size desktop version just isn't a good experience on a mobile device for all sorts of reasons, but the developer can provide something better.  I wonder if maybe that's ok here, too.

And let's not forget, some sites already have alternate, "accessible" versions of their sites (option 4 above) because getting the original working is just too hard.  Feature detection might actually make it easier for them to consolidate by making it easier to make the original accessible for all users in the first place.

I always find it a little jarring when I see email in my inbox from my parents with their full names. I don't think of my parents as Carol and Larry, they're mom and dad. It's worse when I want to send it--I think every single time I write an email to my mother I start by typing mom, backing up and replacing it with her name. This is especially irritating because I know a lot of other people with similar names, so I have to select between them or type the full email address, but I've only got one mom.

I figured out some time back that I can fix that on my cell phone by adding nicknames, and it just works when I start typing in mom or dad. I noticed tonight that gmail contacts also has this option, but apparently it doesn't use it anywhere. Their full names are still in my inbox and typing in "Mom" brings up nothing in the "to" field. Plus the contacts section, though better since the redesign, is still an awkward way to do this--what I'd kinda like is something more like the way IM client aliases tend to work, where I can just right click and nickname someone right there.

Oh well. I got sorting 10 after 9 in filenames in Windows 7, maybe there's hope that they'll get this one right someday, too.

I've been thinking a lot about mobile design lately--what makes a good small-screen design, what makes a good touch-screen design, and how does that compare to devices that have  a cursor like some Blackberry models, etc.  To that end, I've been trying out a lot of mobile apps.

One that I was playing with recently is called DreamScape.  It's a very pretty, enjoyable little game, the object of which is to pop bubbles.  More points if you pop multiple bubbles together with one tap.  It's very relaxing, rather like popping bubble wrap but with a little more skill, more aesthetically pleasing sounds, and pretty backgrounds.

I realized after a few minutes of playing that this game is all about Fitts' Law.  You get more points for more overlapping bubbles, and the more bubbles you have overlapping the smaller the clickable space is likely to be.  You get more points when you get the upgrade that makes the bubbles move faster.  I believe you get more points for smaller bubbles, though the rules don't really specify.  And the bubbles that are an instant game over are the largest size.  And it's doing all of this with a notoriously inaccurate stylus--the finger.

It's not really anything novel, games have been making use of size and speed to increase difficulty for ages, and this certainly isn't the only iOS game to do so.  But what struck me as interesting for other sorts of touchscreen applications is that the bubbles in some parts of the screen seem more difficult to hit because of the way I was inclined to hold my hand there: there are some angles where the place I think I'm pointing at does not actually match the place that my finger actually touches first.  That means that there are some places on the screen where you can get away with smaller buttons or targets than others.

It's something to think about for future designs, and to keep in mind when testing them.

I'm always thinking about design. Sometimes this leads to some really nerdy observations at inappropriate moments, but my friends say they love me anyway. Lately, having just finished (hah, "finished"...) moving, I've been thinking a lot about design with regards to furniture arrangement.

It's absolutely amazing how much less stuff I feel like I have when it's not in boxes or disassembled for moving.  It takes up so much space on the floor, and then it's out and in an appropriate place and hey, I can see the floor again.  Surely it's taking more space than it was before, and yet it feels like it's taking up so much less.

Part of that is I'm not having to vault over it just to get across the room, but I think it's more than that.  I think that things that are useful become somehow invisible until you need to use them.  The boxes and disassembled bookshelves are not useful, they are in the way, and they're a reminder of all of the work that's left to do.

I've heard people talk about technology like microwaves as "becoming furniture," which is the same sort of effect--it's no longer a gadget that must be oohed over or deciphered, it's a useful tool that lives over there and that no one thinks about much.

There's a lesson for me in interface design in there, though I haven't quite decided what it is yet.  But as I design in the future I'll be thinking of turning menus, etc. into furniture.

Periodically I encounter some problem with html and css layouts that could be solved by adding a few extra presentational tags to the html source (like <br/> or text bullets in the case I'm about to describe), but there's no easy way to do it in CSS.  I almost always end up caving and doing it that way, but I like flailing around and trying new things first before giving up.  I feel like sharing the most recent example because I'm almost proud of it, and in some circumstances it might actually be the right thing to do.

What I have is a list of links for a blog.  This is an excellent candidate for an unordered list, except that I want them presented like so:

one - two - three

four - five - six

seven - eight

The trick here is getting the dashes so they show up only in the middle of each line.  But there's no easy way to tell where the natural line breaks are, so I cant just have the first <li> per line not have a dash in front of it.  That means I'm probably going to need to insert some line breaks so I know which ones are at the beginning of a line, but I'd still rather not do it in the html.

I ended up with this:

.blogroll { text-align: center; }
.blogroll li { display: inline; padding: 0 6px; }
.blogroll li + li:before { content: '-'; position: relative; left: -8px; }
.blogroll li:nth-child(3n+1):before { content: '\a'; position: static; white-space: pre; }

The first two lines just make the elements centered, inline, and separated a bit. The third line puts a dash before all<li> elements that come after another <li> element--effectively everything but the very first in the list.  The fourth one is the magic: it uses a new css selector nth-child to select the element after every third element (that's the "3n+1" bit) and replaces the dash with a newline character (that's the "\a" bit).  Normally newline characters are just converted to spaces, but setting the white-space to "pre" makes the line actually wrap there.

It almost works!  Unfortunately, there is a case it doesn't handle well.  If one of the items is too long, the lines will wrap before the third item and you end up with this:

one - two - three

four - reallyreallylong

- six

seven - eight

Oh well.  I guess I'll be putting those line breaks in by hand after all.  But if you don't have to worry about that, it might actually be a good technique!

The last piece of account management for the reminders project that I haven't mentioned yet is account deletion.  One of the goals I try to keep in mind is that every action should be reversible.  So if you create an account, you should be able to delete it.  But the converse should also be true--if you delete your account, it would be nice if you could get it back, at least for a little while afterwards.  Some sites get around this by not having true account deletion, only deactivation, but I don't really like that approach; I'm a big advocate of users being able to have control over their information, and if they ask for it to be deleted then by gosh it should actually be deleted.

So I'm going to go with more of an email trash folder sort of approach here: users can hit a delete button and it gets scheduled for deletion some amount of time later, and during the intervening time they can come back any time and export their data or cancel the deletion.  After that time window the account is irretrievably gone.

Design requirements

Account deletion will live on an account settings page along with turning turning emails on and off, changing passwords, changing email addresses, and exporting all reminders to various calendar formats.  The user should be aware before they delete their account that they will have a time window to cancel and that they can export everything, and these should both be reiterated after they submit the account deletion form, every time they log in after that, and on the account settings page.  It should be possible to cancel deletion or export data directly from those messages.

I would also like a form for users to provide feedback about why they are deleting their account after the deletion form is submitted and on the account settings page.  It should disappear permanently from both places once it is submitted.  The form would be completely optional and open ended, and the wording should be of the "Please help us make our service better" variety.

Permanent deletion? But what about backups?

Ideally, when an account is deleted all data is scrubbed from everywhere--I don't want to have it anymore.  The trouble is that the data will continue to exist and can be restored from any database dumps I have lying around.  I'd like it to be purged from those, too, but it's not a great idea to be modifying your backups.

I may need someone more in tune with database administration and automated backups, replication, etc. to help me out on this one; I'm sure it's a solved problem, but I'm not succeeding in finding solutions.  The best one I can think of is to only keep a few days worth of daily backups, and purge the oldest every time a new one is created (and tested for integrity, etc.)