Tag Archive for 'error'

That fragile thing we call the Internet

Sure, it can withstand a nuclear war, and we've got some records, but how much of our beloved Internet is a database error away from being lost?

Reading Robin Wauter's tweet and the heart-wrenching paragraph that is all that's left of one man's four years of blogging, it made me think again how little time most of us devote to backing things up.

How would you feel if you lost all your blog posts?

So here's what I propose: an annual Backup Your Blog Day. Maybe on April 1st ('cos only fools don't back up!) Or... (date suggestions?)

There's apparently already a monthly 13th Blog Backup Day. (And, ideally, you'd be doing automated backups every day or week but we don't live in an ideal world so I'll take pragmatic over ideal any day!)

We need twitter avatar badges and blog chicklets. Who's up for designing them? And it would rock to have a Wordpress plugin that reminds you to make a manual backup of your blog.

Thoughts?

MacPython re-install gotcha

The comprehensive uninstallation directions for MacPython comprise the single sentence: "To uninstall MacPython, you can simply remove these three things." The three things refer to the MacPython 2.5 application folder (/Applications/MacPython), the framework (/Library/Frameworks/Python.framework), and (I'm assuming) the symlink in /usr/local/bin.

Unfortunately, what it doesn't tell you is that unless you also remove all files with names starting with Python under /Library/Receipts, the installer won't let you reinstall MacPython (it checks these to see what is already installed). Instead the installer tells you that a newer version is installed, marks the files "skip", and fails with "nothing to install".

I spent a good few hours until I realized this so I hope this helps someone else keep their hair.

Mozy’s not all that

Mozy Error

I've been a paid-up subscriber of the much-hyped Mozy remote backup system for about a year now. The only problem is that I haven't really used it in that time and I emailed them a few days ago to ask them to cancel my account (and I haven't heard back yet). The reason: I haven't successfully backed up once on my Mac.

When you first run Mozy, you select the folders you want to back up and Mozy starts backing them up. This first backup can take a long time if you have lots of files. We're talking days here.

That's fine except there's a catch: You can't interrupt the backup.

Update: Keith Peters reports that you can actually interrupt the backup and provides a screen-grab to prove it. That being the case, this must be one of the worst UI cock-ups in history because, for all intents and purposes, it looks to the user as if the backup failed and is starting over.

If you're on a desktop machine that you leave on all the time, that shouldn't be an issue. But my primary machine is my notebook and I'm rarely in the same spot for a couple of hours let alone a couple of days.

So Mozy has never backed up my Mac successfully.

Every now and then I see the error dialog above to remind me that I'm paying for something that I'm not using.

This is such a fundamental flaw that I don't know how Mozy gets the glowing reviews that it does. Perhaps most of the reviewers use it to back up just two or three files for testing and leave it at that.

I might give Mozy another try at some point if they implement a system where you can actually resume interrupted backups.(And if anyone from Mozy is reading this, could you please get back to me about canceling my account?)

Update: After Keith's advice, I let the Mozy app run its course and it has finally managed its first successful backup. I'm going to give it another chance. But please, guys, fix that horribly misleading UI!

Better form validation in Flex

Flex comes with a built-in form validation system that unfortunately uses mystery meat tooltips to display component validation errors.

To see what I mean, take a look at the example I wrote a while back in the Validating Data Quick Start.

Mystery Meat Error Messages

If you tab around that example, you may notice that you are probably doing something wrong (as indicated by the red borders around the form items that begin to appear) but you have no idea what you're doing wrong. In order to find out, you have to mouse over the form field. Only then does a tooltip appear to tell you what the problem is.

Needless to say, having the user switch input devices and exert additional effort in order to see a form validation error does not make for good ergonomics or usability.

A better alternative is to actually display the error message beside the control.

You can, of course, do this simply by having the error message in a label.

For example:

<mx:FormItem label="Your name">
    <mx:HBox>
        <mx:TextInput id="yourName" change="validateNotEmptyTextInput(yourName);" focusOut="validateNotEmptyTextInput(yourName);"/>
        <mx:Label id="yourNameError" visible="false" text="Your name cannot be empty."/>
    </mx:HBox>
</mx:FormItem>

The validateNotEmptyTextInput() method, in this example, is not a Flex Validator (as used in my Validation Quick Start), but a simple method.

For example:

private function validateNotEmptyTextInput(target:TextInput):void
{
    (this[target.name+"Error"] as Label).visible = (target.text == "");
}

In the above example, I'm using a pragmatic naming convention to create a generic validation method that works with TextInput components. Nothing too spectacular visually, but usability-wise already better than the default Flex behavior.

Creating an error Label for each component, though, is not very practical. We can overcome this limitation and add a little visual flare by using the Flex error tooltip instead of a label.

Kyle Quevillon has a post in which he details how to use the Flex Tooltip Manager to create Error Tooltips. Referring to Kyle's post, we can alter the validateNotEmptyTextInput() method as follows:

// If the TextInput is empty, display an error message.
if (target.text == "")
{
    // Has the error message ToolTip already been created?
    // (A reference to created ToolTip instances is saved in a hash called errorMessageToolTips.)
    var toolTipExists:Boolean = errorMessageToolTips.hasOwnProperty(target.name);
 
    if (toolTipExists)
    {
        // Error message ToolTip has already been created, just show it.
        (errorMessages[target.name] as ToolTip).visible = true;
    }
    else
    {
        // Create the ToolTip instance.
        var pt:Point = new Point(target.x, target.y);
        pt = target.contentToGlobal(pt);
        var errorTip:ToolTip = ToolTipManager.createToolTip(errorMessages[target.name] + " cannot be empty", pt.x + target.width + 5, pt.y) as ToolTip;
        errorTip.setStyle("styleName", "errorTip");
 
        // Save a reference to the error message ToolTip in a hash for later use.
        errorMessages[target.name] = errorTip;
    }
}
else
{
    // TextInput is valid. Hide the error message if one exists.
    if (toolTipExists)
    {
        (errorMessageToolTips[target.name] as ToolTip).visible = false;
    }
}
 

Where errorMessages is a hash of personalized messages:

errorMessages =
{
    yourName: "Your name",
    yourEmail: "Your email",
    phone: "The phone number"
}

Thus, we no longer need the Label component but there is a catch: we still need the HBox (or a container of some sort) if the TextInput is in a FormItem. Otherwise, contentToGlobal() returns an incorrect value when trying to position the error message.

So the new FormItem looks something like this:

<mx:FormItem label="Your name">
    <mx:HBox>
        <mx:TextInput id="yourName" change="validateNotEmptyTextInput(yourName);" focusOut="validateNotEmptyTextInput(yourName);"/>
    </mx:HBox>
</mx:FormItem>

And the resulting validation errors both look nice and are functional.

Better Flex Validation Errors

(In the above example, I modified the errorTip style to make the message boxes slightly shorter than usual by setting the paddingTop and paddingBottom properties to 2.)

To summarize, I'm not a big fan of the mystery meat validation error tooltips in Flex. Displaying validation errors on the form itself leads to better usability as users do not have to exert additional effort to find out what they did incorrectly.

Update: Someone has filed a bug about this very issue in the public Flex Bug and Issue Management System. I've left a comment on the bug and linked it to this post.






Bad Behavior has blocked 0 access attempts in the last 7 days.