1.) Pricing Terms

Obviously, one of the primary purposes of a contract is to spell out the pricing terms – and this is the area of the contract the client is likely to be most interested in. The way this section is structured will depend a great deal upon your pricing model. As I argued previously, a hybrid pricing model is probably the way to go, but this may depend on your company or it may differ on a project-by-project basis. If you do use a hybrid model (offering a quote that may be different than the actual price), make sure you clearly specify that the quote provided is provisional and may be subject to change. If you are using a fixed quote model, then you will have to make sure that you include a very detailed and accurate description of the project deliverables (see point 3).

2.) Payment Terms

You may include these details in the section on general pricing, but specifying payment terms is very important in a design contract. First of all, you will want to make sure that at least some money is paid up-front (generally 25-50%). Indicate that work will begin after this money is received, so that they actually have some motivation to cut the first check.

Secondly, tie each subsequent payment to a clear deliverable or to a specific time period. If they want monthly payments, this should be easy to specify in a contract. But if they pay you along the way based on the stage of the project, you will want to be very specific about what this entails. Is the design complete once everyone is completely happy with the design, or once the second-stage design comp has been delivered? Don’t tie a payment down to anything vague and unspecified.

As far as invoice term goes, in my experience you can expect companies to take as long as you give them to pay the invoice (or longer). I’m consistently amazed by how long it takes a larger company to cut and deliver a check for $1,000 to a small design firm. I’m not sure there is a good answer to this – requiring the check in less than 30 days is generally outside of industry standards and probably won’t actually result in a quicker payday anyways. My advice is simply to assume that you will have to wait approximately 30 days to receive a check for any work, and try to account for this fact as you manage your company and adjust your cash flow expectations accordingly. If anyone has any advice on getting companies to pay their invoices promptly, please let me know!

3.) Project Workflow

It’s a good idea to write the basic workflow you expect for the project into your contract. Specify the different stages you’ll go through as the project progresses and when the client will need to approve the work done. This way, the contract is not just legal jargon, but actually a useful document for both client and designer to help direct the project’s process and guide expectations.

We break our project workflow down into the following components:

1. Research
2. Information Architecture
3. Wireframes
4. Design Compositions
5. Page Creation
6. Website Launch
7. Post-Launch Research
8. Website Finalization

In fact, we have developed two standard contracts; one for smaller website projects that involve a simpler workflow, and one for big projects that require some intensive research before and after the development process.

4.) Timeline Expectations

Along with the budget, the project timeline is one of the most critical elements to many clients. You should definitely mention that timelines may frequently change, and that any estimate you offer is a good faith best judgment – but not infallible. This is also a good opportunity to hammer home the point that the client has responsibilities too – such as getting you content – and if they fall behind then so will you. Fight the temptation to offer a best-case scenario timeline, because we all know that true projects never follow the best-case scenario.

5.) Maintenance Agreement

Some clients seem to expect free maintenance for life, but as a designer you know that this is not feasible. Clearly specify what counts as maintenance vs. simply fixing problems as part of the initial contract. At the Wojo Group, we generally include customized maintenance agreements outside of the bounds of the standard contract.

6.) Limited Liability and Indemnification

This is the part of the contract where you try to protect yourself from some really nasty legal problems. Basically, clauses on limited liability and indemnification should indicate that you will not be held responsible for any actions brought against the client as a result of the website, and that the client will reimburse you if you are subjected to such actions.

7.) Arbitration Clause

You’ll want a clause in your contract specifying what happens if claims against you are in excess of the limit for small claims court. In this worst-case scenario, you want to limit your exposure to huge lawsuits and mounting legal fees. Arbitration is the way to go because it keeps the dispute out of the courts. Instead, both parties present their case before one or more ‘arbitrators’, and each party agrees to be bound to the decision made. This avoids the potentially nasty appeal process, leads to lower legal costs, and results in a quicker decision. Hopefully, it will never come to this…but just in case you want to have your bases covered.

8.) Design Credit Agreement

Generally speaking, you want to specify that you have the right to use the project in your portfolio. Also, you might want to have a small design credit inserted into the website, generally placed in the footer. If clients are squeamish about these items, then you can cut them out. However, as a general rule of thumb it is a good idea to keep these options open for you, especially if you are working on a project that will make a great addition to your portfolio.

9.) Additional Expenses Agreement

In the course of web design, you may need to make significant expenses for specialized fonts, images, and so forth. Make sure it’s clear that the client will be billed for these items at actual cost, and that they will always be notified before such purchases are made on their behalf.

10.) Cancellation

Neither party should be able to bail on a whim, but if both of you want out, there should be an easy way to mutually cancel the contract. Make sure you specify that you will be paid for all hours of work completed up until the time of cancellation if the client wants out.

11.) Cross-Browser Compatibility

If you’re a web designer, you know there are a seemingly endless number of browsers – especially if you count all of the mobile browsers now available. Despite the abundance of choices, however, there really are only a few browsers that have any significant percentage of the market – Internet Explorer (6, 7, and 8), Firefox, and Safari. Make sure you specify which browsers you plan on building the website for. Sure, you could design the website to be compatible with Netscape 4 – but this will obviously require some serious time commitments and call for a bigger paycheck. If you fail to mention the issue of cross-browser compatibility, then you may have clients coming after you when their website doesn’t load in their favorite antiquated browser.

As a somewhat extreme example, a recent client called us complaining about some fairly bizarre problems, which we couldn’t replicate even in IE 6. We eventually learned that the client was using the AOL browser that comes with the dial-up service. Remember that thing? You never know what browsers or devices people are going to use to view their websites – so make sure you specify up front what browsers will be compatible and include this in your contract.

12.) Client Content

Oftentimes the most challenging part of finishing a website is getting content from the client. Despite breathing down your neck to make progress on the design and programming of their project, you need to engage in medieval torture methods to get any content out of them. Make sure you clearly indicate that any delay in delivery of content from the client will result in timeline delays.

It’s also wise to specify the formats you accept for content. Frankly, we don’t want to get any WMV movie files or publisher documents. In our contract, we specify the acceptable formats for text, graphics, audio, and video content. You may also want to specify that there will be additional fees if they give you print content that you have to type in manually.

13.) Mistakes

To be fair to clients, they should not have to pay for our mistakes. However, in the design industry, ‘mistake’ can be a vague term. Make sure you clearly specify what counts and what doesn’t. You should fix a blatant error for free, but if you produce a perfectly good design composition that the client happens to hate, then you haven’t made a mistake at all and you deserve to be paid for your work.

We also have a section in our contract discussing what happens if a third party is hired to work on the website. You can’t be held responsible for someone else’s mistake, nor expected to fix them for free, so indicate that any repairs or changes you have to make as the result of third-party tinkering will be billable.

14.) Assignment of Project

It’s probably a good idea to mention that you have the right to assign subcontractors to work on portions of the project. To be fair to the client, however, you should guarantee the work of any subcontractors to the extent that you guarantee your own. However, if you get in a jam and need some extra help, you’ll be glad you left this option open.

15.) Referral Program

Word-of-mouth advertising is very important for our company, so we include a referal incentive program written right into the contract. We offer 5% of the referred project’s revenue – but you might want to try something different. Not a necessary element of a contract, but useful nonetheless.

The Search Controller

The Motionspire search controller uses one function and view for returning any content, whether it’s filtered or not, so the pagination only required one copy of the code to be implemented.  I keep a session variable for maintaining the user’s preference for items per page, and if that parameter has been sent to the search function I set the session variable :

if params[:itemsPerPage] then session[:itemsPerPage] = params[:itemsPerPage] end

When I run though the search function, I see if a page parameter has been passed:

if params[:page] then @page = params[:page].to_i else @page = 1 end

After I retrieve the articles pertaining to the search parameters (in this case the results are stored into an array called @videos), I check the :itemsPerPage preference and find the last possible page:

if session[:itemsPerPage] then @per = session[:itemsPerPage].to_i else @per = 24 end

@lastpage = @videos.length/(@per) + 1

if @videos.length%(@per) == 0

    @lastpage = @lastpage - 1

end

I have a default itemsPerPage value of 24 hardcoded, and you can change this for your search.

From here, we simply return the search results for that page, using the current page and the items per page preference:

@videos = @videos[((@page-1)*@per),@per]

For search queries within a large data set, I would recommend using these parameters with the sql query with the ‘ORDER BY’ and ‘LIMIT’ in order to avoid returning extremely large results unnecessarily.

The Helper

First, I created a short helper function that finds the min and max pages, ensuring we don’t show a negative page or a page that doesn’t exist:

def minmaxpage(current,total,option)
    min = current - 2
    if min < 1
        min = 1
        max = 1 + 4
        if max > total then max = total end
    end
    max = min + 4
    if max > total
        max = total
        min = max - 4
        while min < 1
            min = min + 1
        end
    end
    if option == 'min' then return min else return max end
end

The View

For the content from the view, we use the @videos array to present the content for the page.  The only custom coding necessary is in the links for the pages.  For this site, I provide a first and last page link, along with 2 pages on either side of the current page.  You can manipulate this code how you want, but the basic idea will remain the same.

First we grab the min and max page from the helper:

<% min = minmaxpage(@page, @lastpage, 'min') %>

<% max = minmaxpage(@page, @lastpage, 'max') %>

For the code for the page links, we simply check to see if the min page is within two of the current:

<% if min < @page %>

    <%= link_to( "Prev",

        :action => "search",

        :page => (@page - 1) ) %>

<% end %>

<% if min > 1 %>

    <%= link_to( "1",

        :action => "search",

        :page => 1 ) %>

<% end %>

<% x = min %>

Then we loop through the remaining pages, ensuring we don’t go over the max, and make the current page simple text instead of a link:

<% while x <= max %>

    <% if x.to_i == @page.to_i %>

        <span class="current"><%= x %></span>

    <% else %>

        <%= link_to( x.to_s,

            :action => "search",

            :page => x ) %>

    <% end %>

    <% x = x+1 %>

<% end %>

<% if max < @lastpage %>

    <%= link_to( @lastpage.to_s,

        :action => "search",

        :page => @lastpage ) %>

<% end %>

<% if max > @page %>

    <%= link_to( "Next",

        :action => "search",

        :page => (@page + 1) ) %>

<% end %>

The code may look a little long, but the implementation took very little time.  I know exactly what the code is doing and it is very easy to expand this for different situations and code.

There are a lot of solutions for pagination of content, but I found that this simple implementation helped me avoid using plugins and save time.  Let me know if you guys have any questions or comparable solutions.

Things that are enjoyable will be easy to use and efficient.

The ALA article is defending the case that beautiful and aesthetically pleasing UI designs increase functionality because they’re perceived to be easy to use and efficient. What we’ve been practicing here is the theory that you can have an interface be more enjoyable through the implementation of functionality. That is, if a piece of functionality is fun, the user will perceive it as intuitive. Now there are limits to this; you can’t have something that is super fun and not functional what so ever. But, generally speaking, the more fun you can make a user interface to interact with, the more forgiving your users will be of any shortcomings.

Coverflow

Be honest, when coverflow was announced you thought, “Cool, but it’s useless.” Coverflow is one of the biggest successes of “fun” in UI design. It has some great functional uses when browsing folders on your mac full of images, but past that, it’s a stretch to say it’s a great way to browse files. There are far more efficient and more usable ways to browse cover art in iTunes, or to browse visual files on my mac, but I still find myself using coverflow more often than I thought I would. That’s because it’s fun to use. Moving that slider and seeing my files or album covers rotate and move in 3D space is a delight. On the iPhone the fun is amplified by swiping your finger and having it respond in real time.

Time Machine

Apple is the master of adding fun to user interfaces. If you look at why or how their user experience is so successful, 9 times out of 10 you’ll find their solution is just plain more fun than the competitions’. Time Machine is another example of this. Backup software is a fully developed genre, but Apple decided to step in and make a big splash. They made Time Machine completely unlike any other backup software out there. Using 3D and a crazy time portal background that you manipulate with an actual time line makes using backup a joy. In fact, I would argue that it was Apple’s primary focus when designing the UI for Time Machine. It’s like healthy chefs making food that’s good for you actually taste good. Apple made the important, mundane task of backup fun to use.

Adding Fun to Your UI

It’s no doubt that Apple churns out some of the most fun to use software out there, but we can all start doing a better job at making our UIs more enjoyable, particularly on the web.

Sliders

Sliders are a great alternative to the standard form elements like drop down menus or text inputs.

Animated User Feedback

Giving feedback to the user for their interactions is critical to good UX, but you can take it further. It is now easier than ever to surprise and delight users with javascript frameworks like jQuery and Scriptaculous.

Drag & Drop

Another great way to spice up a UI is to give it more drag and drop functionality.

These are just a few ideas of what you can do to make your user experience a little more fun for your users. Some of the best solutions involve innovative interactions like the swiping to unlock an iPhone, the motion sensor controls of the Nintendo Wii, or that first time you realized you could pan around Google Maps without reloading the page. Of course, you can’t always have an amazing breakthrough in user experience, but if you make it one of your goals to let your users have fun, you’ll find that their emotions will be more positive and thus their user experience will be as well.

Getting on the Same Page

One of the biggest advantages of using contracts is it allows you and your client to get a clearer idea of what the project entails. It can be used to clearly define payment terms, the project timeline, and the expected project deliverables. Our contract actually walks through and describes in clear terms our web design process. There is no need to view contracts as a necessary evil full of legal jargon. Instead, view the contract as a tool that helps both parties stay on track.

Avoiding Scope Creep

‘Scope creep’ is the project management buzzword that describes the phenomenon of ever-growing project demands. A client starts off wanting a simple website with a shopping cart, and before you know it they’re requesting live chat features, a discussion forum, and user profiles. Scope creep can also take a more subtle, more sinister form. It may involve really little things like constant requests to upload a bit of content or a suggestion that involves making one more page for the site. But, even these minor additions to the project can add up and kill your time if you aren’t careful. If you have a well-written contract and design proposal, then both you and the client can clearly see the scope of the project as originally agreed upon.

Scope creep is not necessarily bad in and of itself, as long as you have a way to deal with it fairly. After all, it’s unlikely that the client is going to know exactly what they want right when they first begin the project, and they are likely to learn things along the way that might require a shift in strategy. It is not realistic to stick rigidly to an original agreement, because things change and evolve over time. But, a contract can help you to fairly and reasonably manage a change in scope. Make sure that your contract contains provisions that lay out the costs associated with any expansion of the workload or significant change in direction that may occur during the course of the project. If managed correctly, ’scope creep’ can actually be a good thing – allowing you to get paid for doing more work on a project you are already working on.

Provide Legal Protection

Unfortunately, we live in a litigious society, so the risks of some sort of legal action are higher than ever. Do you want to appear in court without a signed contract to defend your position? On the other hand, if you are trying to collect money on a completed project, do you want to be in small-claims court without a signed agreement in hand? Obviously, we all would like to avoid this type of nasty confrontation, but even if you would never take it this far, there is no guarantee that your client will return the favor. Protect yourself with a contract. As long as you follow your end of the deal, a signed contract will come to your defense.

Even if you never actually go to court, the mere existence of a contract can really help you out. Clients who are tempted to bail will be a bit more hesitant when they realize that they made a legal agreement.

Note that a contract also provides the client with legal protection. A contract should also ensure that you, as the designer, don’t bail on your client or treat them unfairly. Be sure to explain this benefit to the client when asking them to sign a contract. Many people tend to be suspicious of contracts and suspect foul play whenever they are used. This is a false conception, though, because a contract actually protects both parties.

Weeding Out the Bad Apples

Frankly, requiring a contract is a good way to filter potentially terrible client relationships. If a client is unwilling to sign a contract, this is a sign of trouble ahead. Rather than lamenting the loss of a project, celebrate the fact that you may have dodged a bullet.

One of the biggest lessons our company has learned over the years is that we don’t want every single client we can get. Just like clients are looking for a good fit with a design company, you should look for a good fit with a particular client and project. Perhaps you’re desperately strapped for cash, and this advice sounds a bit idealistic. However, the headaches, lost time, and frustration that comes with a bad client relationship are not worth it, and often aren’t profitable in the end anyways. It definitely won’t be profitable if they bail on you mid-project or refuse to pay. But if they sign a contract, it indicates that they take the project seriously and probably at least intend to pay you.

Why Not Have a Contract?

What are the main reasons for operating without a contract? Perhaps the biggest concern is that clients won’t like them, since they may view it with suspicion. This is particularly true for smaller clients – many big ones have a lawyer on staff to look it over (and big companies expect to deal with contracts). However, as I’ve explained before, a refusal to sign a contract is a strong indication of a potential trouble client. Also, if a client seems uncomfortable about signing, take the opportunity to explain the benefits of the contract. A good contract will actually protect them as well, and it will allow both of you to get a clear idea of what the project entails.

Another objection to contracts may be that they are too time consuming. Drafting up a contract for each client is a laborious task – and this time could be better spent doing actual design work. However, in reality, you can probably make a contract template that applies to most projects, and vary it slightly for each client as needed. And with plenty of online resources to help you, writing a good design contract shouldn’t be all that difficult. In part two of this article, I’ll go over some tips on what to actually include in a design contract and provide some more resources to make the whole process a lot easier.

<script type="text/javascript" src="http://www.thewojogroup.com/flipEm.js" ></script>

**Make sure to test this on your site, some flash objects or other plugins may not work properly

Enjoy!

When I’m programming, I need 8 different tabs open with every reference site I can get for a particular language.  I google function names constantly, most of my debugging time is spent with dumb syntax errors, and I’m never going to be able to use Regular Expressions off the top of my head.

So what can mediocre programmers like myself do? Develop. I’m going to go over a few tips for good application development, and how to use development methods that can improve your programming, even if you lack superstar skills.

Project Management

There are too many different project management philosophies to mention here, and many of them are developed by very experienced and knowledgeable professionals in the industry.  However, project management and planning remain to be the biggest downfall for most programmers.  Many of these methods are made to apply to development teams, but you can abstract a lot of the ideas to individual projects.  Try to check out a few papers or books on the topic during your free time.

1/3 Rule

For most projects, I try to stick with the 1/3 rule:  spend (approximately) 1/3 of your time on planning, 1/3 on coding, and 1/3 on testing.  Many programmers expect to spend the majority of the project timeline writing code, and believe that good code will drive the project.  However, I have found that most worthwhile final products are created from development timelines that have actual coding as a minority.  This 1/3 flow can often take iterations for different portions of a project, where you plan, code, and test small portions and move on to the next section.  But you will often find dedicating time to plan properly will cut down on actual coding, and proper testing will save you time in the long run.

Start with Your User

I am a big fan of top-down development.  There are a lot of different theories about development strategies and methods, but I have found that for real world applications, the single most important aspect of any program is the interface.

With that in mind, I start my planning with laying out the interface.  Implementation of this idea can vary depending on the project.  For example, you may start with wireframes and a user flow for a web application.  For something like simpleCart(js), I started by listing every way in which the user would interact with the code, including function calls, div classes, and html layout for cart items. When you start your project by building out the interface first, you are ensuring that your program will adhere to the end-user functionality of the project.

Compartmentalize Functionality

It doesn’t matter whether you are a big believer in MVC (I am) or like procedural or object-oriented (I’m a OOP guy); you will find yourself improving your code by creating structure first, and then implementing code.  It is often beneficial to create functions (or objects) that relate to real-world goals or problems.  If you say to yourself, “I am going to need to store the current user preferences in a cookie,” you might want to create a function for exactly that.

By focusing on individual problems, it becomes much easier to create efficient code for that particular purpose.  In turn, you often write better code.  It also becomes much easier to debug; if you are having a problem storing to a cookie, you simply look at your ’store to cookie’ function.  Documentation also becomes extremely easy, as the purpose of your code becomes evident simply by looking at the function name.  I know this may be second nature to many developers, but it can’t hurt to mention it.

Abstract Data Storage

I’ve found that many projects outlast hardware, hosting, or storage implementations.  You may move your code to another server, decide to implement a different database system, or find that you outgrow your storage and need to keep data in more than one place.  In any of these cases, abstracting data storage and retrieval functions from the rest of your code will benefit you immensely.  Data storage is often the last part I consider for my project.  I often do most of my developing with two empty functions: load() and store(). They are usually the last thing I implement, as, in most situations, they are the least important to the functionality of your end-user.  It also becomes extremely easy to maintain consistency of your core functionality when switching to a new data implementation by simply altering these functions.

Conclusion

These are all very high level concepts, and it may or may not be clear how to actually implement some of them in your projects.  The overriding theme that I hope you can take away from this article is that every program looks the same from 10,000 feet.  Most great applications are built with the end-user in mind, and great development isn’t necessarily dependent on great code.  Please let me know if you guys have any other tips.

Build as little as possible to start.

If you build a massive app with 300 features, then your users may be stuck using what you’ve given them. However, if you launch your app or new feature with the bare minimum, then your users will use what you’ve given them and tell you what direction to go to make improvements. A great analogy brought up by Daniel Burka of digg is the story of an MIT architect. This architect built a building and instead of sidewalks outside it they just covered everything in grass. Then they came back a year later and got on the roof. They took a picture of all the wear and tear on the grass made by the foot paths of all the people going to and from the building and covered them with cement to make the sidewalks. Let your users pick the direction of your app.

The future of web applications is people.

This was a point brought up many times by multiple speakers. It revolves around the idea that we’ve started and built the web first, then we added people. We are going to focus greater attention on how to build the web more around people and less around technology. Facebook Connect is a huge example that seemed to be everywhere at fowa, including a presentation by Dave Morin on the topic. Facebook Connect is just an example of the broader concept – if you build an app that brings about a lot of new tools and tech for users than you need to learn how to make those tools and tech revolve around people, not their function. Build your apps around people, not just good function.

Be a skeptic.

Don’t ever think that because this tip helped person A it’s going to help you. Don’t listen to how this new tool coming out can really help person B and assume it can help you. Really, really think about the hundreds of tiny factors that made it work for them. Through that search you’ll find out what might work for you and you’ll see it’s nearly always somewhat different. Moral of the story, facebook connect is awesome but I don’t care (though lots of other people probably do). Atlas from 280 north brought a tear to my eye it’s so good, but I don’t think it’s going to work out for me as well as he made it seem it would. Percentage coupons work for 37signals but why on earth should I think it will give me the same results? Be careful of anecdotal tips, find out what works for you.

Twitter, WTF?

Seriously it’s gotten out of control. When I heard, “for the first time ever you can tweet to space” I thought, really? Is that surprising? Is twitter that old that we really view that as a breakthrough? I heard twitter said at fowa as much as I used to hear “web 2.0″ thrown around. Don’t get us wrong, we’re not knocking it. We even have our own twitter page to prove it.  However, we did see 10+ people within twelve feet of us using twitter at once (in fact, we started tweeting just to see how many screens we could see our tweet on). Google is not the Internet. Neither is twitter- and don’t forget that.

Recognize the value of what you are creating.

One of the first things mentioned at the conference by the opening speaker Jason Fried (of 37signals) was that web developers need to start charging more. Many of us feel that we have to develop an awesome web app and provide it for free to get anyone to even pay attention. Jason argued that it hurts the industry. Rather than succumb to this temptation, we need to develop sustainable business models. If we create something that is truly of value, there is nothing wrong in charging a fair price for that value. Free is dying, start making money.

Give people a reason to love you.

Consumers have more power than ever before. Not only do they have a growing number of choices, they have more information (and more potential influence over others) than in the past. If people are going to stick with you, they have to have a good reason to. And this comes back to truly caring about your customers. As Gary Vaynerchuk put so eloquently, “You want a marketing strategy? CARE!!!”

Design matters. A lot.

I tend to be a functionality guy. But the importance of compelling design was a theme that ran consistently throughout the conference. Delicious Library was offered as a telling example; this program made millions by taking something that could already be done (making a catalog with Excel) and giving it an attractive and fun interface. Even though functionality is important, at the end of the day we enjoy using things that are well-designed. Make your apps fun to use and good to look at, people lust for movie stars, not old fat balding men.

Overall Future of Web Apps Miami 09 was an excellent experience and we wouldn’t hesitate for a second to go back again. Great job to all the folks at Carsonified.

For those of you who are a less of a geek than I, FOWA is the Future of Web Apps Conference. It is one of many wonderful events that Carsonified puts on every year.  We will have the pleasure of spending 3 days in downtown Miami, attending workshops, presentations, parties, and fraternizing with the ‘web-developers A-list’.

We are going to try to keep all of you updated from the conference this year, using this crazy thing called ‘Twitter’.  So, check out twitter.com/thewojogroup next week (Feb 22-24) for updates, pictures, and stories from FOWA Miami 2009.  

And for those of you lucky enough to be going to FOWA also, we’ll see you there!