18 Questions to Ask Before Adding New Tech to your Web App

Adding a new piece of technology to your web application is not a consideration to take lightly.  There are a lot of factors to consider that can slow down or doom a project if the proper evaluation is not given up front.  In the end, you want the long term benefit to be worth it, but not derail any short term milestones.

And when I say technology, I mean a framework, library, automation tool.  Whatever the type, I use it to encompass anything that you might be considering adding into the technology stack that is new to your web application.  This most often involves something you’ve only read or heard about, or maybe only worked through a tutorial.  This is a case where there is a large unknown component to the technology you want to add.

When evaluating adding any new piece of technology to your web development project, use the criteria below to help you make your decision.

Does the new technology ______:

1. Address some problems in your software architecture

If you have some software design problems that you consistently struggle with given the tools , libraries, frameworks that you currently use, and this new framework will solve that for you then go for it.  If you are just adding this new framework only to learn it, and it doesn’t add value to your product or software process, then go pick something else to learn that does add some value.

2. Allow you to become proficient in a reasonable time

Depending on the time frame that you have within your development cycle, you may not have a lot of time that can be considered R&D time to learn a new framework.  A new framework should not require a year to become proficient at, that is a lifetime in the development world.  This is also another reason why the skill level of you and your team should be considered.  Master some core technologies first before you start learning something new.  You can always get stuff done with the other languages and frameworks that you already know if you have to, then refactor later.

3. Enable you to create software more quickly and with less effort

Anything that improves your efficiency is something to invest time in.  Always strive to do more with less code.

4. Result in software that is more maintainable

If the new framework best practices result in software that is more maintainable, then in the long run that will pay off.  Your product will be easier to add new features to and be able to be picked up by other developers easier.

5. Result in software that can better adapt to changes

If you have a problem with handling growing complexity without big rewrites and lots of bugs introduced, then integrating a piece of technology that adds to that is going to make things better, it’ll add to your problems.  If on the other hand, using the framework allows for better overall design and encourages solid, maybe even SOLID, design principles, then your software project will be better off.

6. Improve the testability of your software

If testable code is important to you, and it should be, then you should always weigh the impact that adding a new framework has on your ability to test.  One clue to look at is also how the framework tests itself?  That can tell you how much importance it places on testability.

7. Have no significant degradation in performance

If your software designs have problems with performance, and it is really important to your product, then a new framework should be providing a lot of benefits without significantly impacting your software’s performance.  Most of the time, because a framework adds flexibility and adds a layer on top of your existing stack, it often will decrease the performance compared to well-designed code in current tool sets.  The opposite would be writing absolutely optimized custom code for every interaction, but that’s a tradeoff with speed of development and maintainability.  I always opt towards speed of development and functionality first, then look at performance later.  If you know ahead of time performance is valued highly in the product, then make sure you at least have a plan to optimize performance if and when issues come up.

8. Encourage good programming practices

A good framework that you add should be using design patterns that encourage you to write good quality code.  The effort to write good code should be no more than writing bad code so you have no reason to not just write good code using best practices at the start.

9. Have good support by its creators

Sometimes the creators are commercial, sometimes it is open source, sometimes it is a combination where it is open source contributors that are employed by a big commercial company.  Either way, I consider support being the same as documentation, so how well does the project itself keep up with changes in its development with the corresponding documentation.  Checking commit history looking for a variety of committers over a long period of time also helps grow confidence in the project that something that changes in the core developer’s lives or career, or the company’s finances, won’t derail the project.

10. Have good support by its users

Where does the user community get support? These are the same channels you will use to learn and help figure out best practices.  Looking on Stack Overflow to see how many questions are being asked and how well they are being answered is a good gauge (lookup questions using Tags).  Also, seeing what conferences exist and what other companies are using the project helps.  Having someone you have a personal relationship with that has experience and that is willing to help answer some questions is also a plus.

11. Have a good chance to be actively maintained during the useful lifetime of your design

This is something that depends on your product life cycle, if you most likely redesign your product every 3 years, then only has to exist for that long.  If you have to distribute software for a hospital, useful lifetime might be 10 years, so are you confident the new piece of technology will be maintained, updated, and still valid that far in the future?

12. Currently in a state where it is complete and functional

If still in a state of flux, with lots of API changes, or bugs being introduced, it’s not worth using it in your product because you will be constantly working around bugs or wasting time debugging.  Unless you like that sort of thing.  Harder to do if you are working on a product because you are contributing to someone else’s code.

13. Change not too quickly

Will new releases be completely breaking old ones.  If a project is iterating quickly, and your software relies on stable code with infrequent releases, this may not fit into your project well.

14. Allow you to collaborate more easily with other people

If the framework you are adding is not very popular, or not well documented, then if you work on a team with others, it may be frustrating for them to work alongside you.  Also may be hard to find contractors who know the framework.  Ideally you should have the ability to share components you made with the public, or to get them on github or other sources.

15. Minimize complexity added to environment setup for developers and production servers

Does the framework add any complicated steps to the build or test process that will not be able to be automated.  Also, consider the impact on developers setting up a local environment, which is important to truly distributed collaborative work.  Sometimes unavoidable depending on role of the framework.

16. Cost should not be prohibitive

Sometimes the costs are direct, like you have to pay for a license.  Sometimes the costs are secondary, for example, what if a new framework requires a lot more memory usage on your web server, so you have to upgrade your server’s RAM costing you X/month.

17. Have only reasonable requirements to be brought into your product

If a framework has a lot of requirements, need to evaluate their impact too.  Might not be a big deal if you never directly use the required projects and they are abstracted when you use the framework.  But maybe some of them are exposed and new things you have to learn.  

18. Have a software license compatible with your product

Have a commercial product?  Make sure the license allows you to sell online, distribute, or sell a subscription to your product, whichever applies depends of course on your monetization strategy.

Jeremy Zerr
Why You Should Use AngularJS in your Next Web Application

Adding a new javascript framework like AngularJS to your web app requires some careful evaluation.  Most projects already are using jQuery, maybe jQuery UI, and potentially other javascript libraries to handle other functionality not covered by jQuery or even jQuery plugins for UI elements like charts, multi-selects, infinite scrollers, sliders, etc.  Any javascript framework has a tough task to find a space to fill with developers.

Your decision might consider the additional lines of code added, worrying about if this may slow down your javascript execution, or page load times.  You know you will also have a huge initial learning phase where you discover how to use, then try to learn best practices as you start to play around with implementing your app.  Maybe you are concerned that it is just a fad framework too, there are other options for similar Javascript frameworks like Backbone.jsKnockout.js.

For most, I bet the initial learning phase and temporary slowdown in development is the primary hurdle.  This can slow down a project that could be quickly done with existing technology.  The long term benefit has to be there in order to spend your time learning and figuring out best practices, and ultimately the new piece of technology must be solving a problem in your software architecture to justify the time.

I found when researching AngularJS and going through the process of implementing an app with it, that it was going to be a great tool in making web applications.  For a big list of criteria I recommend to evaluate when considering adding a new component to your web application, check out my article here titled 18 Questions to Ask Before Adding New Tech to your Web App.  Here are some of the criteria from that list and how my evaluation of AngularJS went.  It's my opinion that there is a significant hole in front-end web development that AngularJS fills.

1. Address some problems in your software architecture

When writing web applications, I have objects in the server-side code that often times aren’t represented as objects in the client-side code.  For simple apps, this might be OK, but when it gets complicated, it can be a big help to mirror these objects on both sides.  Also leads to a terminology issue, a Person object on the server can’t truly be talked about as a Person on the client side because it doesn’t look or feel the same way.  Doesn’t have the same methods, isn’t represented as code, sometimes is stuffed into hidden inputs or in data attributes.

Managing this complexity can be very hard.  AngularJS has ng-resource which you use to create services that hook up to REST APIs and return back that object in JSON and you can attach methods to that object so it can be a fully functional object.  It feels more like something familiar to what you are working with on the server side.  All without much work on your end, you have methods like save(), get(), update(), that map to REST API endpoints and are most likely the similar methods you might have in your Data Mapper on the server side.

AngularJS encourages you to also deal with models on the client side just like you have them on the server side, big plus there.

I also don’t feel like the design using jQuery + Mustache is elegant when it comes to having an object that has properties represented in different ways within the web UI.  An example, you have a table of Person objects from the REST API, you have a button for each Person to denote they have “Accepted” an invitation, so when they click, you want the checkbox to change and you want the style on the row to change.  In jQuery, you listen for the checkbox change event, then you toggle the class on the button and the row.  In AngularJS, the model is the source of truth so you build everything from that.

See what I mean by taking a look at this jQuery vs. AngularJS plunker I created and compare the type of code you write.

2. Enable you to create software more quickly and with less effort

AngularJS having the ng-model and ng-class directives alone cover so many of the common operations that we all have been doing in jQuery.  Two-way data binding and saving to the server now takes a small number of lines in AngularJS, but in jQuery would require creating your own object, and several different click and event handlers.  Switching from watching elements and events to watching a model is a big shift in the right direction.

3. Result in software that is more maintainable

AngularJS encourages using the model as the source of truth, which starts to get you to also think object oriented design on the client-side.  This allows you to keep in mind the same object-oriented design principles that in general make software more maintainable compared to procedural.

4. Improve the testability of your software

AngularJS has dependency injection at its core, which makes it easy to test.  Even the documentation on the AngularJS site has testing as a part of every tutorial step, which almost makes it hard NOT to test.

5. Encourage good programming practices

Model as the source of truth, dependency injection, ability to create directives that can decorate elements that lends to reusable and shareable components, REST API connection to your server, lots of benefits from just following AngularJS basic usage.

6. Allow you to collaborate more easily with other people

Using models as the source of truth is something that is familiar with anybody who is doing object-oriented MVC server-side software, so this should make it easy to pick up for most web developers.

Also, being able to create directives in AngularJS and dependency injection makes it easy to create components that can be shared easily between developers and really has excited the developer community.  Lots of existing projects have developed AngularJS directive bridge libraries so you can use their code by tossing an AngularJS directive to decorate an existing element with new functionality.  Like Select2Infinite ScrollerBootstrap, and Angular has its own UI companion suite.  Just check out http://ngmodules.org/.

7. Allow you to become proficient in a reasonable time

It took me around 2 full weeks to feel like I was proficient, where I was starting to pick out and understand best practices and look at some of the finer points of the framework.  Where I started from is that I have a lot of experience developing with Javascript, jQuery, jQuery UI, and also implemented a project using Backbone.js earlier this year which is one of the other Javascript frameworks built to solve a similar type of solution as AngularJS.  I felt like knowing how Backbone.js works helped a lot with picking up AngularJS.

Jeremy ZerrAngularJS, Javascript
AngularJS Directive Best Practices

Using directives in AngularJS is one of the great features added to tie complicated javascript functionality and client-side templating to your HTML app in a way that allows for re-use and maintainable code.

You can think of a directive as an extension of HTML so that you can create your own elements and attributes.

Just like when you use a “<select>” element, you expect to see an element that you can click on and will drop down to have a list of items, and you expect to be able to click one and have that one show up as the “selected” one.  Where a HTML element implies certain functionality, a directive allows us to create our own display elements and/or functionality that can be used as new elements or to extend existing elements.

I’ll use the example of a basketball team where we have many basketball players making up a basketball team.  Wouldn’t it be nice if in your HTML you could write this to display a basketball player in HTML?


As you might expect to see in HTML, this would output a basketball player with a few fields like name, number, position, and some stats like points and assists.  To accomplish this, it would take a combination of several HTML elements, including <div>, <span>, and maybe an <input> if we wanted to change the number of points and assists in a scorebook type of app.

For the code examples shown on this page, I'm using AngularJS 1.2.7, they should all work with 1.2.*.

Here is a link to a plunker showing an example of how to create your own custom directive to do this:

The basketballPlayer directive is associated with a template file that is HTML with some AngularJS template markup within.

Take a look at how I implemented the capability to change the points using an input field.  I can use a directive as an attribute, called ng-model, which is one of the directives provided by AngularJS core. That’s right, many core AngularJS features are directives themselves, a directive can be an element name or an attribute.  This is why understanding directives is one of the most important things to learn and understand when learning AngularJS.

As with any technology, there are many ways to approach a solution, and creating directives is no exception. We have some choices to evaluate, a few things to consider include:

  • Using Attribute vs. Element
  • Using proper HTML5/XHTML5 markup
  • Scope considerations for reusable code

Using the element name


may seem like a really cool feature of AngularJS and a huge readability improvement to someone going through source code.  However, this has no chance of validating as proper HTML5.

Even though it is not proper HTML5, this is the preferred way to use a directive that adds new markup to your app.  Another wise suggestion is to use a prefix (think namespace) for your directives that you use as an element name, which is mainly a future-proofing in case an HTML element comes out that has the same name someday.  Like maybe you were thinking of:


But what if an upcoming version of HTML5 adds a special multiselect tag and all of the sudden your app breaks.  A suggestion is to use:


That way you know for sure it’ll be OK in the future.

But something like:


I’m pretty sure the chance of that being used in a future release of HTML is none.

Having an element name work as a directive is not enabled by default, you need to explicitly allow for it in your javascript code, I keep all my directives in a directives.js file:

var myDirectives = angular.module('myDirectives', []);
myDirectives.directive('basketballPlayer', function() {
  return {
    restrict: 'AE',
    templateUrl: 'bball-player-template.html'

The restrict property has an A for Attribute, and an E for Element.  The default, if you don’t specify a restrict property, is A, which means it’s only enabled for Attributes.

Notice the name of the directive is “basketballPlayer” but I called the element “<basketball-player>”.  This is an automatic conversion from camel case to lower case with dashes splitting words, it’s an AngularJS thing that you can’t control.  There are lots of possible options that it gets converted into that are valid that allow you to use it in several ways, some help you out with HTML validation.

If you are concerned about HTML validation, you can write it also as an attribute:

<div data-basketball-player>

If you are not familiar with the special attribute prefix of “data-“, this is a special name and is allowed within HTML, any attributes with a prefix of “data-“ are ignored and allowed to be custom attributes.  The attribute-based syntax is equivalent to <basketball-player>.

This format is valid HTML5, but if you want to step up to XHTML5 we’re not quite OK yet.  Attributes are required to have a value in XHTML5, so most correctly:

<div data-basketball-player="argument">

Even if you don’t have an argument, it’s appropriate to give it a value, recall from plain old HTML:

  <option value="1" selected>My selected option</option>
  <option value="2">Not selected option</option>

Notice the selected doesn’t have an = sign behind it.  This is called Attribute Minification.
This is allowed in HTML5, but is not proper XHTML5.  So again, this is up to you and how strict you want to be.  The proper XHTML5 form for this select element is:

  <option value="1" selected="selected">My selected option</option>
  <option value="2">Not selected option</option>

While I like being strict, I think it’s silly to write selected=“selected” so I opt for not following XHTML5 if that choice is up to me.

Within AngularJS, when you create a directive, it requires a small amount of javascript and a corresponding template.  You can determine whether the directive name you have chosen is allowed to be included in the code as an element or as an attribute, or both.  The default is to only allow it as an attribute.  This is the way I prefer, I like being able to run my HTML code through a validator and have it pass.  This is determined by the restrict property of the directive as mentioned earlier in this article.

The AngularJS docs suggest that you use an element when you are creating a component that is in control of the template.  Typical situation for this is in some domain-specific code.  They suggest you use an attribute when you are decorating an existing element.

In the real world, when looking at documentation online, and help from Stack Overflow and other sites, you will almost always see developers using the most condensed form, using element names and attribute minification.  Some of this is because they are trying to communicate a solution in the simplest manner, but I also suspect this is what most are using within their apps.

In my own code, I like using HTML5 validation because it helps me check out all my HTML to make sure I didn’t miss a close or open tag, but I don’t typically go so far as requiring XHTML5 validation.

Scope considerations for reusable code

You have the option with a directive to isolate the scope, which means to access any variables inside your directive’s template, you need to pass it into the template, using an attribute.

Here is an example of the same code from above in a new plunker showing isolate scope:

Notice that the directive now includes an additional attribute:

<basketball-player player="basketballPlayer"></basketball-player>

And the directive code says to grab a player directive:

myDirectives.directive('basketballPlayer', function() {
  return {
    restrict: 'AE',
    scope: {
      player: '='
    templateUrl: 'bball-player-template.html'

The = sign says to also assign player attribute to the variable of the same name so inside the template, you use player as the variable name, as you can see in the bball-player-template.html file:

<div class="basketball-player">
  <div>Name: {{player.name}}</div>
  <div>Number: {{player.number}}</div>
  <div>Position: {{player.position}}</div>
  <div>Points: <input type="text" ng-model="player.points"/></div>
  <div>Assists: <input type="text" ng-model="player.assists"/></div>

If you need to have some two-way data binding inside of your directive, then there are some situations when you cannot isolate scope.  You can isolate scope and still two-way data-bind when you are only binding to objects, but not primitives.  It’s tricky, so keep it in mind as you design your app.

Isolating scope is a really good thing, much cleaner, and leads to decoupled code, passing in the objects you need from the outside and nothing more.  So if you do need to two-way data-bind inside your directive, consider tossing your variables into an object and passing that to your directive so you can still isolate scope.

For some good reading about isolate scope and how it all works along with no scope isolation and the transclude option, check out this stack overflow question:
Confused about Angularjs transcluded and isolate scopes & bindings

AngularJS Directive Best Practice Guidelines

  1. Use your directive as an element name instead of attribute when you are in control of the template
  2. Use your directive as an attribute instead of element name when you are adding functionality to an existing element
  3. If you do use a directive as an element, add a prefix to all elements to avoid naming conflicts with future HTML5 and possible integrations with other libraries.
  4. If HTML5 validation is a requirement, you’ll be forced to use all directives as attributes with a prefix of “data-“.
  5. If XHTML5 validation is a requirement, same rules as HTML5 validation except need to add “=“ and a value onto the end of attributes.
  6. Use isolate scope where possible, but do not feel defeated if you can’t isolate the scope because of the need to two-way data-bind to an outside scope.
Google Chart Tools Presentation

Here is a link and embed of a presentation I gave to the Boise Google Developers Group a couple weeks ago.  I presented about Google Chart Tools, which is a web data visualization package provided by Google to use.  It is a Javascript API to create interactive, nice looking charts to dress up a data-driven website.  I have used Google Chart Tools in several projects for clients and myself, and find them to be easy to use and stable.

Knowing that any solution to a problem first needs a problem, I begin the presentation with a list of the requirements that a particular project for a client had regarding Data, Tools, and Development environment.  I then proceed through the many web-based data visualization solutions out there and show why Google Chart Tools fit my requirements best.  Then, I have a quick, general overview of the Google Chart Tools features then leave the rest of the details for you to explore on the site which includes a Code Playground and Chart Gallery.

Link: http://prezi.com/hacdlbxeoroe/choosing-a-web-data-visualization-solution...

23 Questions your Web Project Requirements Should Answer

When you are writing your requirements for your next web project, here are some handy questions to ask yourself to make sure that you are doing an effecitve job.  Being a web developer myself, I've seen a lot of variety of requirements from different clients.  From no requirements, to well thought-out and concise requirements.  Realize, that projects with no requirements always end up with requirements by the time we are done discussing your project, so just do them ahead of time.  Specifically, by a list of requirements, I mean written down, clear requirements about the web site and the environment the web site will operate in.

When a potential client comes to me with well written requirements, I know that this web project isn't some random idea that a person isn't serious about.  Also tells me that you have a clue about web sites and running a project, which in my experience always leads to a better relationship and better outcome.  I am a lot more likely to take your project if we can communicate, and the requirements and our initial interview is often all I have to go by.

Why are writing requirements important?

Writing good requirements are most people's least favorite thing to do, but are important in so many ways.

  • Clearly set expectations
  • Allows your web developer to accurately estimate time (so you stay on budget)
  • Makes any requirements meetings before the project starts more efficient (nobody likes to waste time)
  • Your potential web developer will know you are serious and is more likely to take your project
  • Less communication needed during the completion of the project (no wasted time)

All of the tips I'm offering to you are part of my initial interview process that I go through with potential clients and their projects.  This is BEFORE the project is started.  So if these questions are answered in the requirements before we initially talk, the initial interview goes smooth and we can talk about more exciting stuff, like brainstorming the ways your web project can help you in ways you never thought of.

You'll also find that these tips center around figuring out how your web project fits into your business.  This is something your web developer needs to understand.  If I work on your project, I must understand your business so I can make appropriate decisions as I develop the site.  I also can then recommend small, little things that might make a big difference in how your users interact with the site.

Does your pizza delivery guy need to know about pizza?

You wouldn't send a pizza delivery guy out without understanding pizza.  He wouldn't realize that it needs to be delivered hot as a priority, and he wouldn't understand that people might want sprinkle cheese and pepper with their pizza.  He might even flip the pizza box over and ruin all that cheesy deliciousness if he doesn't know what a pizza is.  So in the same way, please make sure your web developer can understand your business before letting them loose on your project.

So here are the questions to ask yourself when writing requirements for your web project.

1. What is the business purpose of your site, how does it fit into your overall business model?

Without knowing the purpose and how it fits in, what will drive the little details of where things are placed, and how things are done.  Don't have your pizza delivery guy know nothing about the pizza.

2. What goals do you have for visitors of your site?

Do you want people visiting your site buy something?  Share something?  Signup for something?  This is really important for layout of your web pages, and how the site is designed to funnel people towards those goals.  Just reading an article is rarely the goal, you want people to form a connection with you, so make it easy for them to do so.

In addition, knowing the goals allows us to put the proper analytics in place to make sure we are tracking those goals.

3. How will your customers reach your site?

Search, Ads, Social media?  Sure, you say all of them right, but what is the reality?  Do you know where they are coming from now if you have an existing site?

4. What geographic location of people does your site serve?

If you are only targeting local people, then the web site should reflect that and it should be obvious to visitors of your site that you are a local company.  Also helps to figure out what your methods to reach out to people should be.  Its easier for local businesses to focus efforts on a small area, than a bigger area like the whole US.

5. What are some examples of similar sites that you like?

This doesn't mean: What site should I copy?  As unique of an idea as you have, there are almost always people who have done similar things, reinventing the wheel is not good.  Even if its bits and pieces from several different sites, this is a tremendous help for a designer to get what color schemes you like, and what navigation you like.

It's also important to know what you don't like.  If you don't like big image sliders at the top of the home page of sites, please tell somebody.  Save everybody some time.

6. How will the web site be hosted?  What are the capabilities?

If you already have a hosting solution, or know what you are going with, this is very important to know.  Why?  What are the hosts capabilities?  The site that is designed must fit into these parameters.  Also, right along with this is what are your backup requirements for your files and database.  Designing these into a system can take some time, so include it in your requriements.  You have thought about backups, right?

7. How many people will have logins to the site?

Its just an estimate.  Also, how many of those people will be members of your organization, and how many will be customers?  Its important for the web developer to have an idea of the type of internal security that is needed, and what roles will be necessary to protect content from internal vs. external vs. anonymous users.

8. What user authentication methods will you use?

When users register, do you want to just user regular old user/password that is saved in your own site's database?  Or do you want to allow Login with Google, Facebook, OpenID?  Or is this an internal site that you want to use an existing login system like LDAP?

9. How many users will be allowed to contribute content and what kind of technical ability do they have?

Designing a rich text editor for a single person with lots of technical experience is a lot easier than designing one that will be stripped down so that a non-technical person can't make posts that look bad.  A technical user can be trusted with a lot more control over the way the content looks and is formatted.

10. What kind of content will people add?

That helps determine the work required to theme the individual page templates.  Typically, individual content types will have their own template, which just means the layout of the individual fields within each content type might be different enough to have its own special HTML/CSS page layout.

Knowing the different type of content also helps to imply what other kind of views might be needed.  Such as, if you have an Event type of content, then it implies you will have a calendar view, and possibly an upcoming events view.  This is another really important part to have for estimating time properly.

11. What roles will users be able to have?

This mainly has to do with security, but also usability.  This is what user groups the users fall into, those user groups can have permissions extended to them.

The security part is to make sure that only certain types of users can add an Event, but that other users cannot.  Maybe you have certain users that are superusers and can edit or delete any existing Event content.

For usability, if a person cannot edit an Event, then they should not see an "edit" link.  Its important in the usability of a site to only have the valid actions presented to a user.

12. How will users interact with the content?

Do you want users to be able to comment on particular types of content?  Do you want them to share on social media using share buttons?  Which social media outlets?  Just putting them all on there is pointless, too many options leads to indecision, narrow down the most important sources and include those.  Can always change later.

13. Any restrictions on technology or licensing used?

An example of this would be no Flash used for videos.  This is probably more important for internally developed software, but it needs to be discussed.  Its a given that the license will be need to be compatible with your intended delivery method, as there are different restrictions if you are selling the software, or just using it internally.

14. What devices do you want to target?

This is where designing for the small screens on mobile devices comes in.  Its also good to prioritize the screens you design for, whether it is PC, tablet, mobile.  All comes down to effort required and you can save money on your project if you can keep the design flexible (buzzword: responsive) enough to work on all devices with a single theme layout.

15. Do you want a single site for mobile?

When it comes to mobile design, there are a couple broad options: single site that does all sizes of devices, or a mobile-only device.  The trend, and the better way in my opinion, is to go with the single site that is flexible to shift with screen size.

16. Do you have any graphics or color scheme that will be provided?

Already have a logo?  Already have a vast library of stock images that will be used?  It's important to mention this so your graphic designer knows what they have to work with.  If your brand has a specific color scheme,  mention that it needs to be adhered to.

17. What are the metrics for success?

This is related to what goals you have for embarking on this web project, but list out what a successful web project completion would mean to your core metrics.  Increased visits?  Increased shares?  More sales or signups?  This helps communicate what is truly most important to you so expectations are clear.

A big part of this is also knowing what those metrics are currently.  Or if you don't have an existing site, what you estimate them to be.  Use of analytics in a web project is a MUST, you need to be able to track your progress, at least to ensure that your web project doesn't cause you to take a step backwards when completed.

18. What are your frustrations with your current site?

You have built up experience using your current site, or even other similar sites, so communicate those frustrations.  They will be #1 on your developer's list of things to take care of on the new project.

19. What do you want to keep the same as the old site?

This is important too, if you like something, its important to understand why you like it so that if possible, it can be incorporated into the new site.  At the very least, a similar feature can be implemented to give you the same benefits.

20. What methods will you use to drive traffic?

If you drive traffic through advertisements, it may mean that you will want to be able to create landing pages easily and track the metrics.  If you are collecting signups on your landing pages, will possibly want to tightly integrate if you are having to make new signup forms often.

21. How will you send email from the site?

Will you have the capability of sending email from your web hosting company, or will you be using a 3rd party like MailChimp to collect signups and send followup emails.

22. Are you taking payments on your site?

Who is your payment gateway and processor?  What kind of products or services are you selling?  This also helps to understand costs incurred with PCI compliance and other taxation factors.

23. Do you need an SSL certificate?

Are you wanting to protect a shopping cart, or the admin area, or both?

Jeremy Zerr