Alternative voices for NVDA!

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!

ARIA, feature detection, and the lowest common denominator

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.

Email contact nicknames

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.

Touchscreens, games, and Fitts' Law

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.

Things in their proper place

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.

Stupid css tricks: line breaks in lists

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!

Reminders, part 4 - deleting accounts

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.)

Reminders, part 3 - registration and login flow

One of the goals of the reminders project is to simplify everything as much as possible.  That includes the login and registration processes and the auxiliary features that go with them like forgotten password resets, other password changes, and email changes as well as the actual reminder creation and completion.  Sometimes it seems like the simplest things are the most complex; I've built login and registration forms before, but when you really get into it there are enough corner cases that it seemed prudent to diagram it all out and make sure I've got everything streamlined in all possible circumstances.

I originally thought of having a single form for either login or registration--if the user existed, they would be logged in, otherwise a new account could be created.  Of course, it's not really a good idea to create a new account if the user just got their username wrong, those people need a message saying that the username they gave doesn't exist.  I've seen applications of this that have a "I'm creating a new account/I'm logging in" toggle, but that seems inelegant and potentially confusing.

An alternative is to use the error message to say "that account doesn't exist, would you like to create it?" and then automatically create it using the entered username and password.  This would still require a separate registration form, or at least the appearance of being a separate form, and this form should likewise redirect the user to log in where appropriate, or perhaps even just log them in without redirecting.  Separating the forms matches the mental model and the convention of there being two separate activities, but the processes need to remain interconnected so it they are still streamlined for those users who have forgotten they have an account or don't pay very much attention to which form they're typing into.

Registration

Flow chart of the registration process (content described in detail below)

The registration form is going to be as simple as possible--an email address which will be used as a username, a password, and perhaps an "I'm over 13" checkbox as legally required.  The email address should be unique per user, so if it's in use that user probably already has an account.  Email verification is already necessary since the system may send out emails, so it should not be possible to use someone else's email address.

The simplest case is that the user comes to the registration form, enters an email that has never been used before and a good password, their account is created and a "verify your email" message is sent to that email address, and they are taken straight into creating reminders and asked to verify their email address later.  Creating a reminder should also give them a warning about unverified email addresses.

The next use case is basically the same, but the user has entered a very common password like "1234".  I believe that web developers have the responsibility to educate (but unobtrusively!) when users do something that may harm themselves, but also to allow them to do it if they really want to.  To that end, I'm adding an additional registration step that warns the user that their password is one of the N most common, and could be guessed by a hacker in <10 seconds, for example.  At that point the user can choose to use it anyway or pick a new one, at which point registration continues as before.  This step would also be part of any process that involves changing a password.

It is also possible that the email address the user gives is already in use.  Probably this is because they already have an account; if so, the user may also have given the password that belongs to that account, and can just be logged in according to the normal login process below.  Otherwise, they will receive an error message that the email address given is in use and a link to log in, which will pre-fill the email address.

It is also possible that someone else registered the account, but in that case they would not have been able to verify the email address.  Users can still log into an un-verified account, and they can have the password reset (described further below), so the legitimate owner of an email address should be able to gain control of an account registered to it.  The simplest flow I have for that case is 1. try to create an account; 2. try to log in; 3. reset password.  It's a little awkward to go through step 2 for an account the user never registered themselves, but for the most part step 2 is appropriate and it won't be appropriate to include a password reset link directly on the failed registration form.  It may also be awkward to take over an account that someone else registered and added their own reminders to, but I'm not sure how to do that aside from requiring verification first, which is awkward for new users and affects a lot more people.

Being able to take over an account that is associated with your own email address is a good thing in the case mentioned above, but it could also be a bad thing if someone puts in an email address they do not use, it expires, and someone else takes it.  Like anything else that uses email password resets, it will have to be the responsibility of the user to maintain a current email address on their account.  If they really do use the account, logging in with an old email may serve as a reminder to update it, otherwise they may have to have a human verify that they own the account and change the email, and enough information needs to be logged that someone could do that.

Logging in

Flow chart of the login process (described in detail in text)

What happens when a user logs in depends on where they are logging in from.  I'm still planning on having a desktop widget to show current tasks, so logging in on the widget will take take the user to the current tasks--even if it's empty--with a welcome back message that disappears after a moment on top.  On the web, successfully logging in will take the user to a list of all their reminders with the tasks that come up soonest on top.

Many login forms make no distinction between username and password errors, they merely tell you that the combination of them is wrong.  I've heard security cited as the reason for this--if it tells you that a username doesn't exist, then an automatic script can move onto the next username and try to crack that one's password.  Personally, I think there are better methods of protecting users' accounts, and it's a better experience for the user if they know which field is wrong, so this login form will distinguish the two types of error.

If the email address the user provides does not exist, they will be told that the email does not exist and asked if they want to make a new account.  If the user decides not to create a new account, they can enter a different email address and try logging in again.

Clicking a create account link could automatically generate an account with the password already provided, but I want to be sure that those users know they're creating an account and to be sure what their passwords are before continuing.  Submitting the registration form takes the user into the registration process described in the previous section.

If the email address is in the system but the password is not correct, the user will be told that the entered password is incorrect and asked if they would like to have their password reset.

Forgotten passwords

Flow chart for resetting passwords (described in detail in text)

Resetting a user's password involves first sending a password reset link to a user's email, which they then must click on in a certain period of time to get the form to change their password.  In the simplest scenario, the user finds the page from the login form, enters the email of an existing account, goes straight to their email and clicks the reset link, enters a good password, and is logged in.

Hopefully users won't click through to this page if they don't have an account, but they might still not know what email they used.  If the email address is wrong, users are given an error and asked if they want to create an account just like the login, but I anticipate that fewer users will use it from this page.

Password reset links will have an expiration period for greater account security.  If a user uses the link after that period of time they will be given a message telling them that it has expired and a new link has been emailed to them.  Otherwise, the user will get a form with a password field, which will have the same password quality check as the signup form.

As mentioned before, it is possible to get into a state where you cannot reset your own password because you no longer have the email address associated with it.  Those users will probably need to talk to someone to get their account back, but I have not yet decided where that fits into this flow.  Perhaps it will just be in some informational text on the password reset page and on a separate support page.

Password changes

Flow chart of changing a password (described in detail in text)

The normal password change process will be accessed by logged-in users, and requires the previous password instead of the user's email address.  Like other methods of setting passwords, it will tell ask the user if they want to change a weak password but will not require them to.

Changing a password this way will also send the user an email, but if they actually did change their password they will not need to do anything with it.  The email merely serves to warn users that their password is changed in case it was updated by someone else, and will allow them to set it back to what it was without having to know the new password.

Email changes

Flow chart of changing an email address (described in detail in text)

Changing email addresses is a little more complicated because it must be confirmed at both email addresses to prevent spam and account theft and because email is used to log in.

The basic email change form is simple, it just takes a new email address and responds with a confirmation message and sends two emails.  The email to the old address is merely an alert like the password change message, it just gives the user a chance to set it back to what it was in the event that someone tried to set it for them.  For the most part it can be ignored.

The email to the new address does require the user to confirm that this is their new address, both to prevent email to someone who doesn't want it and to make sure the email is correct so the user actually gets their reminders.  If the new email is never confirmed, the system continues to use the old email.

I'm not quite sure how to handle unconfirmed email addresses when logging in.  I think that maybe the login form should not accept the new email address until it is confirmed in case it belongs to someone else, but on the other hand unconfirmed email addresses are accepted for new accounts.

Regardless of whether or not the form allows the user to log in with the new email address, if the user has the password correct it should tell the user that they must confirm their new email address, and that the official address associated with the account will continue to be the old one until they confirm the new one.  There should also be a link to re-send the confirmation email in case the old one has gotten lost or deleted.

It also ought to be possible to continue logging in with the old address until the new one is confirmed, since the new one really isn't official yet.  Once the email is confirmed it's probably ok for it to be impossible to log in with the old one.

What's next?

The next step is probably to make a site map with all of these auxiliary pages to make sure I don't miss any, and wireframe or diagram any that I haven't done yet like account deletion.  After that I can start on higher fidelity and full-page wireframes for the website and widget versions, and then maybe I can start on building things.

How (not to) write an alert message

If your alert message needs instructions, you're doing something wrong.

Confusing dialog message headed by "Don't click "OK" if your system is running fine"

This is what you get when you ignore the poor usability warning signs.

Reminders, part 2 - wireframes

The heart and soul of the reminder application is going to be creating reminders and viewing a list of current reminders. There will also have to be some auxiliary features like viewing all (not just current) reminders, editing reminders, and deleting reminders. This will all also be hosted on a server, and that means accounts--signing up, logging in, forgotten passwords, and deleting accounts.

So far I've put together some wireframes for reminder lists and creating a new reminder, and some task flows for logging in, signing up, and resetting a password.  I'll save the login and registration flowcharts for the next post and just talk about the reminder lists and creating a new reminder here.

Reminder lists

Task list.  Basically the same for current and all tasks.  Tasks with the earliest "due date" appear at the top, color (& text) indicates age.

The current reminders list and the all reminders list should be about the same, with the exception, of course, that all reminders shows things you'll have to do some time in the future and things you've already done or recently deleted, and current reminders should be only things you currently have to do.

Current reminders may be completely empty most of the time--that's totally fine, especially with the desktop widgets, where it shouldn't take up any more space than absolutely necessary.  To that end, I've also made the longer description collapsible--it may not even be necessary to have the longer description, just a name, which would simplify this and the creation form nicely.  Most of the time there should just be unobtrusive buttons to create a new reminder or view all of them, making it much more obvious when one does actually appear.

When a task is visible, it should be possible to mark it as done, edit it, and delete it.  It should also show how urgent it is--for many of these sorts of tasks it doesn't matter if they don't get done right away, but bad things may happen if one waits too long to do them.  The time window probably depends on the task, and I've made it possible to set it in the "new reminder" form as you'll see below, but it might be better to simplify the form and just assume some standard period of time that people think works for most things.  It'll take a bit of research to see which is better, and if there is a standard timeframe what it should be.

One of the things I like to keep in mind when designing things is that everything should be reversible.  There are all sorts of studies that show that people just click through confirmation dialogs without thinking about them, which means stopping a user before they do something irreversible just doesn't work.  I've tried to set up this interface so that there are no irreversible tasks, anything that can be done can be undone.  Editing of course just takes another edit.  Marking things as finished and deleting them should make them disappear from the current tasks list, but they should stick around for a few moments and slowly fade out of sight so the user has time to undo the action if it was an accident.  They'll also appear in the All Reminders view, though deleted reminders should probably disappear from there too after a few days to get out of the way.

Creating and editing reminders

The form for creating a reminder.  Users can say what it is, when they need to do it relative to now, how long they should take to do it, whether/how often it repeats, and if they want email alerts.

The reminder creation form is a little longer than I originally intended; as mentioned above, it's possible that I can just get rid of the long description and the "When do you want to have it done by?" questions, reducing it down to just 4 questions.  One of my goals here is to make this as quick and painless as possible.  Having sensible defaults can help with this too, but that'll take some time seeing what people tend to actually put in the form.  And there may not be a sensible default for everyone, so there might have to be something in the backend that senses how people are actually using it and adapts.

All in all I think the form is pretty straight-forward.  The questions are pretty much how I intend to phrase them; I was going for a direct, conversational style and trying to avoid the short, jargony, disconected phrases that event schedulers often use.

I've made all of the dates relative, and I hope having the number selector followed by a drop-down of days/weeks/months/years embedded in a sentence will make sense.

One thing in particular to point out is the email section.  I mentioned in the previous post that emails are not ideal for task reminders, and I'd prefer to make something ambient; however, it's possible that something ambient isn't sufficiently noticeable, and anyway I'm not going to be able to support every platform that way.  I'm one lone developer, and I may be able to get something functional on Windows and Mac but I don't really intend to support each of the multiple desktop widget packages available on Linux, each with it's own custom python api.  So I've tried to address the previous concern with emails--that they get deleted or disappear under other things before I've done the task--by adding repeated emails.  Users will be able to click a link from the email to mark the task as completed.

The other thing to mention is that it should be easy for users to turn off all of those emails all at once without going through all of their tasks.  But if they do that and forget, they may be confused or angry when they don't receive an email from a new task added afterwards.  I've added a warning message there, and perhaps there should also be one on the task lists if there are tasks that send emails and emails are turned off.

After a task is created, the user should probably be taken back to the current tasks list.  But the task almost certainly won't be visible there yet, so it may be a little disconcerting to the user that they don't see it.  There will probably need to be a confirmation message of some sort displayed at the top of the form that gets out of the way after a few moments, probably with the name of the task and "in 6 months" or whenever it needs to be done.

What needs to be done

I've already diagrammed the login process that I want, and I'll talk about that a bit in the next post.  I'd like to wireframe that process, and also document the process for marking tasks finished via email, unsubscribing from all emails via the emails and via account preferences pages, and deleting accounts.

After that I'd like to build something interactive incorporating the feedback I'll hopefully have gotten from what I've posted so far, solicit more feedback on the whole process from that, and then maybe start building the real thing.