FadeMove = function(element, options) {
    Spry.Effect.Cluster.call(this, options);

    var duration = 1000;
    var toggle = 'false';
    var from = 100;
    var to = 0;
    var fromPos = new Spry.Effect.Utils.Position();
        fromPos.x = 13;
        fromPos.y = 0;
    var toPos = new Spry.Effect.Utils.Position();
        toPos.x = 13;
        toPos.y = -65;
    Spry.Effect.makePositioned(element);
    
    var transition = Spry.fifthTransition;
    
    if (options) {
        if (options.duration != null) duration = options.duration;
        if (options.from != null) from = options.from;
        if (options.to != null) to = options.to;
        if (options.transition != null) transition = options.transition;
    }
            
    var fadeOut = new Spry.Effect.Fade(element, {duration: 500, from: from, to: to, transition: transition, toggle: toggle});
    var moveUp = new Spry.Effect.Move(element, fromPos, toPos,{duration: 800, transition: transition, toggle: toggle});
    
    this.addParallelEffect(fadeOut);
    this.addParallelEffect(moveUp);
};
        
FadeMove.prototype = new Spry.Effect.Cluster();
FadeMove.prototype.constructor = FadeMove;

FadeMove = function(element, options) {
    Spry.Effect.Cluster.call(this, options);
    .............
}
FadeMove.prototype = new Spry.Effect.Cluster();
FadeMove.prototype.constructor = FadeMove;

var duration = 1000;
    var toggle = 'false';
    var from = 100;
    var to = 0;
    if (options) {
        if (options.duration != null) duration = options.duration;
        if (options.from != null) from = options.from;
        if (options.to != null) to = options.to;
        if (options.transition != null) transition = options.transition;
    }

var fadeOut = new Spry.Effect.Fade(element, {duration: 500, from: from, to: to, transition: transition, toggle: toggle});
    var moveUp = new Spry.Effect.Move(element, fromPos, toPos,{duration: 800, transition: transition, toggle: toggle});

this.addParallelEffect(fadeOut);
this.addParallelEffect(moveUp);

One question among a million has plagued humanity for thousands of years, and still remains without an answer.  No, it's not theological, and it has nothing to do with chickens and their alleged eggs.  Rather. it is the question of whether you should bid out your next job based on number of hours or a project basis.

This question is tricky, and I know every designer has a lot of different opinions about the subject.  And in all fairness, all sides probably have a legitimate argument.  So instead of arguing for a particular perspective, I'm going to simply explain my own view.

From the moment I began freelancing, I have always quoted my jobs on a project basis.  Here's a few reasons why:

First, I worked for nearly three years in a law firm where everything was billed by the hour.  While legitimate work was done, a standard practice in legal billing is to assign certain number of minutes (or hours) to certain tasks.  So for example, every phone call is billable for 10 minutes worth of time, even if it's 45 seconds long.

Now in my last post, I argued that a legitimate part of billing your customer is for your expertise, and I am not backing down from this.  However, I think it is extremely easy to cross the line into outright extortion.  As I try to keep my customers first in everything that I do (and I really do...I'm not just saying it!), I want to avoid this kind of practice as much as possible.

Secondly, even if you bill on an hourly basis, I think it is reasonable for a client to require an estimate of the number of hours you expect to work on the project.  As I like to stretch hours of work as much as possible, such a constraint is somewhat...well...constraining, and I'd prefer to have a more open schedule (read on for the reason why...).

Third, I like the project bid-method because when I design, and especially when I am developing a custom app, I REALLY like to experiment with new things.  Now if I come up with something cool that is outside of my client's expectation, I think it is reasonable to work that into the bid.  However, if I am essentially using the client's time to build my own skills, I don't think they should have to pay for that.  So, I prefer the bid method because it allows me the flexibility to stretch myself as a designer and developer without the client's project or pocketbook suffering without justification.

So there's my case for a project-based approach to billing.  Obviously, there are a million ways to approach it, and I'll not question those who pursue other models.  What is important for a designer, however, is that you find a method that works for you.  Whether you are billing on a project basis, or by hour of work, be sure to constantly assess your methodology so that 1.) your customer's expectations and needs are being fulfilled and 2.) that you are being compensated adequately for your work.  If the model you are using causes you to blow out the scope on every project, it's time to find a new model!

More In This Series 

On Becoming a Better Web Designer, 6(a)

On Becoming a Better Web Designer: Default CSS

On Becoming a Better Web Designer, in 4-D!

On Becoming a Better Web Designer, Part Third

On Becoming a Better Web Designer, Part Deux

Okay, I'm going to take a bit of a detour here from the "series-in-a-series" that I've been doing to quickly blog about an invaluable CSS trick that every designer needs to use as often as possible.

So here's the scenario: You have a blog that's going to have pictures in it.  The thing is, you want to be able to float the images either to the right or to the left with some margins applied.  Oh yeah, you also want to have, say, seven different border-color options.  And did I forget to mention that you also want different padding between the image and border?

What to do, what to do?  When I first started, I would have sat down and mapped out a class for each "scenario."  For example, for the left-blue-2px-bordered option, I would have created something like "img.leftbluetwoborder."  While this will, of course, work, it's not usable.  Who can remember "leftbluetwoborder", not to mention the 23 other similarly named classes?  So what's the alternative to this terrible mess?

Enter what I call "class overloading."  What is this?  Simply, it is applying more than one class to whatever you're applying classes to.  So if I have an image with "class='myimage'", with class overloading I could easily do this: "class='myimage left blue two'". 

What have I done?  Well, first off, I've made a darn cool image border.  But more importantly, I've made my classes much more flexible.  No longer does one class have to try to account for all the rules to get a specific desired result.  Rather, with this method, I can group CSS classes to achieve an extremely versatile result with probably less code and much easier-to-remember class names (well, at least I think words like "blue" and "left" are easier to remember than "leftbluetwoborder"...).

But also, this technique reinforces the whole point of CSS, the "cascading" part.  When I limit classes to extremely general functions (like making things blue), I am forced to rely on other elements that do other things (like give padding) to achieve results other than blue.  But again, as each class is taking on a specific, but flexible role, this is good because as I generify (should totally be a word) what CSS classes do, the more powerful they become.  And ultimately, I have to write less code to achieve more efficient results. 

So there you have it.  Start overloading classes and discover just how awesome this invaluable technique can be. 

More In This Series 

On Becoming a Better Web Designer, 6(a)

On Becoming a Better Web Designer: Default CSS

On Becoming a Better Web Designer, in 4-D!

On Becoming a Better Web Designer, Part Third

On Becoming a Better Web Designer, Part Deux