Whether you’re a solo freelancer or the head of a huge web design agency (or somewhere in between), your website often serves as the first point of contact with a potential new client. Displaying an impressive portfolio of work along with a few client testimonials is a great start. But the final piece is key: Your contact form, or as many call it, the "Request a Quote" form, also known as Request for Quotation (RFQ) form or Request for Proposal (RFP) form.

Converting new visitors to sales leads (and ultimately to paying clients) is how we sustain ourselves in this business of web design. With a carefully designed "Request a Quote" form, we can get this process off on the right foot.

In this article, I will discuss some of the factors to consider when designing this key feature of your website. Along the way, we will look at the "Request a Quote" form of different web design shops to get some ideas brewing.
Asking the Right Questions

When it comes to designing a "Request a Quote" form for your web design business, there are no right or wrong questions to ask. It all depends on your specific needs, style, and the way you conduct business. That said, here are some typical pieces of information that you may find useful when designing your "Request a Quote" form. The following discusses some ideas for form fields in your web form.
Contact Information

This one’s obvious. But don’t go overboard. An email address is essential (make it required). Phone/Skype ID, maybe (but make it optional). Street address? I’d skip that for now until you decide to take on the project and draw up the contract. Also, ask for the URL of their existing website if they have one (make this field optional); the vast majority of web design projects are website redesign projects.
Tell Us About Yourself

Determine some information about the people you’ll be working with. Find out what industry they’re in, who their competitors are, who their customers are, where they’re based at, etc.
Specific Needs

This may be up to you to recommend, but some clients may already know what they’re looking for. Perhaps a dropdown menu or checkboxes on things they’re looking to get done (which also shows the things you’re capable of doing). Give them a way to specify which of your services they’re interested in. For example, they may be interested in logo design, getting a CMS set up, and so on.
Timelines

Do they have a specific deadline they need to meet? How much time do they have for this project?
Upload a Document

I haven’t found many sites that include this as a form field, but I decided this would be a helpful thing to add on my own "Request a Quote" form so that requestors can include Word documents or images with their form submission. Additionally, some clients may already have their project requirements written out in a document; this gives them the option to attach it to their quote request.

The Budget

Whether or not to talk about budget so early in the process is a tricky question. The initial reaction for any savvy negotiator is to shy away from revealing their "number" too soon. But in the web design industry, the budget question is a real concern for everyone involved.

The cost of web design varies wildly across the spectrum. You can get a template-based design for under $100, hire a mid-range design shop for a few thousand, or go the large agency route where budgets go from tens to hundreds of thousands of dollars. This is why I feel it’s important to include the budget question in your "Request a Quote" form. Get some ballpark numbers out in the open early in the process to make sure you and your potential client aren’t wasting each other’s valuable time.
Considering User Experience

Designing for a particular user experience is always important in any web design project. Designing your "Request a Quote" form is no different. A key factor to consider here is how much time and effort will you require of your visitors who wish to request a quote.

I prefer the "quick and simple" approach where I gather just a few — but very important — pieces of information, just to get the ball rolling. These can be basic, open-ended questions about their business, their goals, and their budget. Once I receive this initial request, we schedule a time to chat where I aim to flesh out all of the details I’ll need in order to devise an accurate proposal for them.

The Foundation Six website features a short form, asking only the essential questions.

Keeping the "Request a Quote" form quick and simple avoids overwhelming the would-be client and makes them feel comfortable and productive. These are positive emotions for our potential client to come away with after their first interaction with us (even if this interaction happens over the web). This in turn makes them more likely to end up hiring us for their project.
Copy, Personality, and Responsive Web Forms

Your "Request a Quote" form is the very first step in a personal relationship between you and your potential client. Infusing your own personality into your form can make it feel warm and inviting.

It’s a good idea to keep all of the copy throughout your site consistent and authentic. This extends to your contact page and even within your "Request a Quote" form itself. A few well-crafted pieces of copy can help the visitor along as they progress through the contact form.

Here are a few web forms with great personality.
Bold Perspective

The agency has a conversational approach which emulates the sense of engaging in a dialogue.

Awesome*

The design has a clearly broken-down interface for specifying the client’s exact needs.

CasJam Media

I designed my form to have short pieces of hints and text as users focus on each form field.

Request a Quote Form vs. Project Worksheet

Sometimes, the "Request a Quote" form is blended (or replaced) with a project worksheet. What’s the difference, you ask?

In my opinion, requesting a quote is a preliminary stage of the process that seeks to just get a feel for whether or not the parties are the right fit for one another.

A project worksheet, on the other hand, tackles more specific, targeted questions about the project — many of which are relevant only after the contract is signed and the project is underway.

Here are a few examples of the project worksheet being incorporated into a web designer’s site.
Bold Perspective

Bold Perspective has a conversational and responsive interface that takes the visitor down several paths depending on their specific needs. It’s a very creative approach and actually fun to fill out!

Solid Giant

The web design studio of Josh Starr goes with a PDF questionnaire that gets down the important questions. He’s set up the PDF to include text input fields so it works very much like a web form.

Brian Hoff

Graphic and web designer Brian Hoff offers two different project worksheets: one for brand design work, and the other for web design work. Both project worksheets go in-depth with targeted and constructive questions. I especially like his question in the web design worksheet that reads, "Imagine your website 1 year from now. Complete the sentence: I know the website worked because…" That’s how you ensure a successful project right from the very beginning.

Resources for Designing Quote Request Forms

Here are a few tools which may prove useful to you as you design your "Request a Quote" form:
FormStack — allows you to quickly create any type of web form with their easy to use drag-and-drop form builder
Gravity Forms — If you have a WordPress site, I highly recommend this premium forms plugin
Best Practices for Hints and Validation in Web Forms – Some ideas for error-checking and data validation of your "Request a Quote" form
25 Stylish Examples of Web Forms — Here is a collection of web form designs for inspiration
Wrapping Up

In the end, it’s up to you how you wish to design your "Request a Quote" form. It’s an important part of not only your website, but also your business as a whole. It deserves careful consideration, testing, reassessing and tweaking until it does what it’s intended to do: Win you more business and have happier clients.

In ASP.NET MVC 3 Preview 1, we introduced some syntactic sugar for creating and accessing view data using new dynamic properties.
Within a controller action, the ViewModel property of Controller allows setting and accessing view data via property accessors that are resolved dynamically at runtime. From within a view, the View property provides the same thing (see the addendum at the bottom of this post for why these property names do not match).
Disclaimer

This blog post talks about ASP.NET MVC 3 Preview 1, which is a pre-release version. Specific technical details may change before the final release of MVC 3. This release is designed to elicit feedback on features with enough time to make meaningful changes before MVC 3 ships, so please comment on this blog post if you have comments.

Let’s take a look at the old way and the new way of doing this:
The old way

The following is some controller code that adds a string to the view data.
public ActionResult Index() {
ViewData["Message"] = "Some Message";
return View();
}

The following is code within a view that accesses the view data we supplied in the controller action.

<%: ViewData["Message"] %>

The new way

This time around, we use the ViewModel property which is typed as dynamic. We use it like we would any property.
public ActionResult Index() {
ViewModel.Message = "Some Message";
return View();
}

And we reference it in a Razor view. Note that this also works in a WebForms View too.

@View.Message

Note that View.Message is equivalent to View["Message"].
Going beyond properties

However, what might not be clear to everyone is that you can also store and call methods using the same approach. Just for fun, I wrote an example of doing this.

In the controller, I defined a lambda expression that takes in an index and two strings. It returns the first string if the index is even, and the second string if the index is odd. It’s very simple.

The next thing I do is assign that lambda to the Cycle property of ViewModel, which is created on the spot since ViewModel is dynamic.
public ActionResult Index() {
ViewModel.Message = "Welcome to ASP.NET MVC!";

Func cycleMethod =
(index, even, odd) => index % 2 == 0 ? even : odd;
ViewModel.Cycle = cycleMethod;

return View();
}

Now, I can dynamically call that method from my view.

@for (var i = 0; i < 10; i++) {



}

@i

As a fan of dynamic languages, I find this technique to be pretty slick. :)

The point of this blog post was to show that this is possible, but it raises the question, “why would anyone want to do this over writing a custom helper method?”

Very good question! Right now, it’s mostly a curiosity to me, but I can imagine cases where this might come in handy. However, if you re-use such view functionality or really need Intellisense, I’d highly recommend making it a helper method. I think this approach works well for rapid prototyping and maybe for one time use helper functions.

Perhaps you’ll find even better uses I didn’t think of at all.
Addendum: The Property name mismatch

Earlier in this post I mentioned the mismatch between property names, ViewModel vs View. I also talked about this in a video I recorded for MvcConf on MVC 3 Preview 1. Originally, we wanted to pick a nice terse name for this property so when referencing it in the view, there is minimal noise. We liked the property View for this purpose and implemented it for our view page first.

But when we went to port this property over to the Controller, we realized it wouldn’t work. Anyone care to guess why? Yep, that’s right. Controller already has a method named View so it can’t also have a property named the same thing. So we called it ViewModel for the time being and figured we’d change it once we came up with a better name.

So far, we haven’t come up with a better name that’s both short and descriptive. And before you suggest it, the acronym of “View Data” is not an option.

If you have a better name, do suggest it. :)
Addendum 2: Unit Testing

Someone on Twitter asked me how you would unit test this action method. Here’s an example of a unit tests that shows you can simply call this dynamic method directly from within a unit test (see the act section below).
[TestMethod]
public void CanCallCycle() {
// arrange
var controller = new HomeController();
controller.Index();

// act
string even = controller.ViewModel.Cycle(0, "even", "odd");

// assert
Assert.AreEqual("even", even);
}

I’ve been working on a lovely little prototype recently but ran into a problem where my code receives a collection of attributes and needs to change them in some way and then pass the changed collection along to another method that consumes the collection.
I want to avoid changing the attributes directly, because when you use reflection to retrieve attributes, those attributes may be cached by the framework. So changing an attribute is not a safe operation as you may be changing the attribute for everyone else who tries to retrieve them.

What I really wanted to do is create a copy of all these attributes, and pass the collection of copied attributes along. But how do I do that?
CustomAttributeData

Brad Wilson and David Ebbo to the rescue! In a game of geek telephone, David told Brad a while back, who then recently told me, about a little class in the framework called CustomAttributeData.

This class takes advantage of a feature of the framework known as a Reflection-Only context. This allows you to examine an assembly without instantiating any of its types. This is useful, for example, if you need to examine an assembly compiled against a different version of the framework or a different platform.
Copying an Attribute

As you’ll find out, it’s also useful when you need to copy an attribute. This might raise the question in your head, “if you have an existing attribute instance, why can’t you just copy it?” The problem is that a given attribute might not have a default constructor. So then you’re left with the challenge of figuring out how to populate the parameters of a constructor from an existing instance of an attribute. Let’s look at a sample attribute.
[AttributeUsage(AttributeTargets.All, AllowMultiple = true)]
public class SomethingAttribute : Attribute {
public SomethingAttribute(string readOnlyProperty) {
ReadOnlyProperty = readOnlyProperty;
}
public string ReadOnlyProperty { get; private set; }
public string NamedProperty { get; set; }
public string NamedField;
}

And here’s an example of this attribute applied to a class a couple of times.
[Something("ROVal1", NamedProperty = "NVal1", NamedField = "Val1")]
[Something("ROVal2", NamedProperty = "NVal2", NamedField = "Val2")]
public class Character {
}

Given an instance of this attribute, I might be able to figure out how the constructor argument should be populated by assuming a convention of using the property with the same name as the argument. But what if the attribute had a constructor argument that had no corresponding property? Keep in mind, I want this to work with arbitrary attributes, not just ones that I wrote.
CustomAttributeData saves the day!

This is where CustomAttributeData comes into play. An instance of this class tells you everything you need to know about the attribute and how to construct it. It provides access to the constructor, the constructor parameters, and the named parameters used to declare the attribute.

Let’s look at a method that will create an attribute instance given an instance of CustomAttributeData.
public static Attribute CreateAttribute(this CustomAttributeData data)
{
var arguments = from arg in data.ConstructorArguments
select arg.Value;

var attribute = data.Constructor.Invoke(arguments.ToArray())
as Attribute;

foreach (var namedArgument in data.NamedArguments) {
var propertyInfo = namedArgument.MemberInfo as PropertyInfo;
if (propertyInfo != null) {
propertyInfo.SetValue(attribute, namedArgument.TypedValue.Value, null);
}
else {
var fieldInfo = namedArgument.MemberInfo as FieldInfo;
if (fieldInfo != null) {
fieldInfo.SetValue(attribute, namedArgument.TypedValue.Value);
}
}
}

return attribute;
}

The code sample demonstrates how we use the information within the CustomAttributeData instance to figure out how to create an instance of the attribute described by the data.

So how did we get the CustomAttributeData instance in the first place? That’s pretty easy, we called the CustomAttributeData.GetCustomAttributes() method. With these pieces in hand, it’s pretty straightforward now to copy the attributes on a type or member. Here’s a set of extension methods I wrote to do just that.
public static IEnumerable GetCustomAttributesCopy(this Type type) {
return CustomAttributeData.GetCustomAttributes(type).CreateAttributes();
}

public static IEnumerable GetCustomAttributesCopy(
this Assembly assembly) {
return CustomAttributeData.GetCustomAttributes(assembly).CreateAttributes();
}

public static IEnumerable GetCustomAttributesCopy(
this MemberInfo memberInfo) {
return CustomAttributeData.GetCustomAttributes(memberInfo).CreateAttributes();
}

public static IEnumerable CreateAttributes(
this IEnumerable attributesData) {
return from attributeData in attributesData
select attributeData.CreateAttribute();
}

And here’s a bit of code I wrote in a console application to demonstrate the usage.
foreach (var instance in typeof(Character).GetCustomAttributesCopy()) {
var somethingAttribute = instance as SomethingAttribute;
Console.WriteLine("ReadOnlyProperty: " + somethingAttribute.ReadOnlyProperty);
Console.WriteLine("NamedProperty: " + somethingAttribute.NamedProperty);
Console.WriteLine("NamedField: " + somethingAttribute.NamedField);
}

And there you have it, I can grab the attributes from a type and produce a copy of those attributes.

With this out of the way, I can hopefully continue with my original prototype which led me down this rabbit hole in the first place. It always seems to happen this way, where I start a blog post, only to start writing a blog post to support that blog post, and then a blog post to support that one. Much like a dream within a dream within a dream. ;)

One nice new feature introduced in C# 4 is support for named and optional arguments. While these two features are often discussed together, they really are orthogonal concepts.

Let’s look at a quick example of these two concepts at work. Suppose we have a class with one method having the following signature.
// v1
public static void Redirect(string url, string protocol = "http");

This hypothetical library contains a single method that takes in two parameters, a required string url and an optional string protocol.

The following shows the six possible ways this method can be called.
HttpHelpers.Redirect("http://haacked.com/");
HttpHelpers.Redirect(url: "http://haacked.com/");
HttpHelpers.Redirect("http://haacked.com/", "https");
HttpHelpers.Redirect("http://haacked.com/", protocol: "https");
HttpHelpers.Redirect(url: "http://haacked.com/", protocol: "https");
HttpHelpers.Redirect(protocol: "https", url: "http://haacked.com/");

Notice that whether or not a parameter is optional, you can choose to refer to the parameter by name or not. In the last case, notice that the parameters are specified out of order. In this case, using named parameters is required.
The Next Version

One apparent benefit of using optional parameters is that you can reduce the number of overloads your API has. However, relying on optional parameters does have its quirks you need to be aware of when it comes to versioning.

Let’s suppose we’re ready to make version two of our awesome HttpHelpers library and we add an optional parameter to the existing method.
// v2
public static void Redirect(string url, string protocol = "http",
bool permanent = false);

What happens when we try to execute the client without recompiling the client application?

We get a the following exception message.
Unhandled Exception: System.MissingMethodException: Method not found:
'Void HttpLib.HttpHelpers.Redirect(System.String, System.String)'....

Whoops! By changing the method signature, we caused a runtime breaking change to occur. That’s not good.

Let’s try to avoid a runtime breaking change by adding an overload instead of changing the existing method.
// v2.1
public static void Redirect(string url, string protocol = "http");
public static void Redirect(string url, string protocol = "http",
bool permanent = false);

Now, when we run our client application, it works fine. It’s still calling the two parameter version of the method. Adding overloads is never a runtime breaking change.

But let’s suppose we’re now ready to update the client application and we attempt to recompile it. Uh oh!
The call is ambiguous between the following methods or properties:
'HttpLib.HttpHelpers.Redirect(string, string)' and
'HttpLib.HttpHelpers.Redirect(string, string, bool)'

While adding an overload is not a runtime breaking change, it can result in a compile time breaking change. Doh!

Talk about a catch-22! If we add an overload, we break in one way. If we instead add an argument to the existing method, we’re broken in another way.
Why Is This Happening?

When I first heard about optional parameter support, I falsely assumed it was implemented as a feature of the CLR which might allow dynamic dispatch to the method. This was perhaps very naive of me.

My co-worker Levi (no blog still) broke it down for me as follows. Keep in mind, he’s glossing over a lot of details, but at a high level, this is roughly what’s going on.

When optional parameters are in use, the C# compiler follows a simple algorithm to determine which overload of a method you actually meant to call. It considers as a candidate *every* overload of the method, then one by one it eliminates overloads that can’t possibly work for the particular parameters you’re passing in.

Consider these overloads:
public static void Blah(int i);
public static void Blah(int i, int j = 5);
public static void Blah(string i = "Hello");

Suppose you make the following method call: Blah(0).

The last candidate is eliminated since the parameter types are incorrect, which leaves us with the first two.
public static void Blah(int i);
public static void Blah(int i, int j = 5);
public static void Blah(string i = "Hello");

At this point, the compiler needs to perform a conflict resolution. The conflict resolution is very simple: if one of the candidates has the same number of parameters as the call site, it wins. Otherwise the compiler bombs with an error.

In the case of Blah(0), the first overload is chosen since the number of parameters is exactly one.
public static void Blah(int i); //WINNER!!!
public static void Blah(int i, int j = 5);
public static void Blah(string i = "Hello");

This allows you to take an existing method that doesn’t have optional parameters and add overloads that have optional parameters without breaking anybody (except in Visual Basic which has a slightly different algorithm).

But what happens if you need to version an API that already has optional parameters? Consider this example:
public static void Helper(int i = 2, int j = 3); // v1
public static void Helper(int i = 2, int j = 3, int k = 4); // added in v2

And say that the call site is Helper(j: 10). Both candidates still exist after the elimination process, but since neither candidate has exactly one argument, the compiler will not prefer one over another. This leads to the compilation error we saw earlier about the call being ambiguous.
Conclusion

The reason that optional parameters were introduced to C# 4 in the first place was to support COM interop. That’s it. And now, we’re learning about the full implications of this fact.

If you have a method with optional parameters, you can never add an overload with additional optional parameters out of fear of causing a compile-time breaking change. And you can never remove an existing overload, as this has always been a runtime breaking change.

You pretty much need to treat it like an interface. Your only recourse in this case is to write a new method with a new name.

So be aware of this if you plan to use optional arguments in your APIs.

UPDATE: By the way, you can add overloads that have additional required parameters. So in this way, you are in the same boat as before. However, this can lead to other subtle versioning issues as my follow-up post describes.

In my last blog post, I covered some challenges with versioning methods that differ only by optional parameters. If you haven’t read it, go read it. If I do say so myself, it’s kind of interesting. ;) In this post, I want to cover another very subtle versioning issue with using optional parameters.

At the very end of that last post, I made the following comment.

By the way, you can add overloads that have additional required parameters. So in this way, you are in the same boat as before.

However, this can lead to subtle bugs. Let’s walk through a scenario. Imagine that some class library has the following method in version 1.0.
public static void Foo(string s1, string s2, string s3 = "v1") {
Console.WriteLine("version 1");
}

And you have a client application which calls this method like so:
ClassName.Foo("one", "two");

That’s just fine right. You don’t need to supply a value for the argument s3 because its optional. Everything is hunky dory!

But now, the class library author decides to release version 2 of the library and adds the following overload.
public static void Foo(string s1, string s3 = "v2") {
Console.WriteLine("version 2");
}

public static void Foo(string s1, string s2, string s3 = "v1") {
Console.WriteLine("version 1");
}

Notice that they’ve added an overload that only has two parameters. It differs from the existing method by one required parameter, which is allowed.

As I mentioned before, you’re always allowed to add overloads and maintain binary compatibility. So if you don’t recompile your client application and upgrade the class library, you’ll still get the following output when you run the application.
version 1

But what happens when you recompile your client application against version 2 of the class library and run it again with no source code changes. The output becomes:
version 2

Wow, that’s pretty subtle.

It may not seem so bad in this contrived example, but lets contemplate a real world scenario. Let’s suppose there’s a very commonly used utility method in the .NET Framework that follows this pattern in .NET 4. And in the next version of the framework, a new overload is added with one less required parameter.

Suddenly, when you recompile your application, every call to the one method is now calling the new one.

Now, I’m not one to be alarmist. Realistically, this is probably very unlikely in the .NET Framework because of stringent backwards compatibility requirements. Very likely, if such a method overload was introduced, calling it would be backwards compatible with calling the original.

But the same discipline might not apply to every library that you depend on today. It’s not hard to imagine that such a subtle versioning issue might crop up in a commonly used 3rd party open source library and it would be very hard for you to even know it exists without testing your application very thoroughly.

The moral of the story is, you do write unit tests dontcha? Well dontcha?! If not, now’s a good time to start.