by John W. Long on August 27, 2010
I gave a talk last night at the local Refresh chapter here in Raleigh. It was a great time. People asked good questions and I fielded their questions as best I could.
Here’s the gist of the talk:
With modern development tools it’s far too easy to build too much software too fast without spending adequate time developing your customer base. Successful products solve a real needs. No matter how good your idea is, you need to spend time talking to the people who will actually use (and buy) your product. But it’s not enough just to talk to them. You need to have something to talk about.
This is where rapid prototyping can really help. Rapid prototyping allows you to show something to your customers early in your development cycle so that you can begin getting the feedback that will be crucial to the success of your project.
For Web applications, there are at least five different tools that you can use to “prototype” your project and get feedback early:
- Whiteboards
- Wireframes
- Hi-fi mockups
- HTML prototypes
- Functional prototypes
We discussed the pros and cons of each approach and then talked about what makes for good customer development.
Good customer development involves four things:
- An idea
- An assertion
- An experiment
- Customer feedback
You start with your idea. This is the big overarching idea for your product. I want to build a product that revolutionizes X by doing Y better than anyone else. You then make an assertion about your idea. In order to do this, I believe that we must do Z really well. You then design an experiment in order to validate your assertion. Finally you take that experiment to your customers and get their feedback on it.
The important thing here is that you are boiling your idea down into something practical. For example, when 37signals created Basecamp (a popular project management system) they felt that the entire thing would fail if they didn’t make it easy to communicate about a project (their assertion). So they set about building the messages section of Basecamp first (this was even before they had done anything with to-do lists or milestones).
Identify the heart of your application and start there. A good way of identifying the heart of your application is to ask the question: What’s the most important part of the application to get right to test our core idea?
As soon as you have something to show off (a prototype of some kind), you should begin getting feedback from potential customers. You will want to ask questions like: What do you think about how this works? Should we remove anything? How can we make this better? And of course, the big one: Would you actually pay money for this? How much?
Based on what you learn from your customers you’ll need to revisit your idea. Does anything need to change there? Does anything about our revolutionary idea need to change? After reevaluating your idea, you should make new assertions and build new experiments around those assertions. This is a cycle, from idea to customer feedback, and back again.
A couple of notes. If you show something to a potential customer and they give you negative feedback that is an extremely good thing. Experiments are successful whenever they generate feedback (good or bad). Take what you learn and integrate it into your development process. Don’t be afraid to throw stuff away. One of the primary goals of a good customer development cycle is to maximize learning. After all we are trying to build a successful product here. We want to know early on if people like what we are building and if they will actually use it.
Of course, there is a lot that could be said here to balance and expand upon the ideas presented here. It is important to stay true to your vision for the product — to stick to your guns so-to-speak. But it’s also important to validate those ideas with serious customer development.
Learn More
by John W. Long on July 19, 2010
Josh French and I have just committed a series of changes to Radiant that will change the way page children are created (you must be running on edge to see the changes). Instead of creating a child page immediately, the “Add Child” button will now present you with a list of page types. The goal of this change is to move the selection of page type to page creation. This change is essential for a number of other ideas that we are considering.
One benefit of this approach is that it allows a custom page type to change the way a page is initialized. For example, a page type could determine the initial values of fields or page parts.
In the future, this could also allow custom page types to easily make modifications to the page editing interface. So a Blog Post page type could add a dropdown to select the post author, or even list the comments on the post. Or an Event page type could add fields for the location and date.
We are looking for feedback on this change from the Radiant community. Add your thoughts in the comments below.
by John W. Long on June 7, 2010
I talked briefly about racking up your Serve projects in my previous article. But apart from the benefit of being able to deploy Serve on Passenger or Mongrel, why is Rack integration cool?
One benefit is that you get access to all kinds of middleware. Middleware is a software module that extends your server or web application with additional functionality. It’s called middleware because it sits between your application and the web server software. When a request for a file or resource comes into the server it first travels through each layer of middleware before reaching your application. Your application then sends a response back which again travels each layer of middleware before being served up to the user. As the request and response travel through each layer of middleware, the middleware can make changes to or even serve up something totally different. This is useful for adding features like logging, custom error handling, or gzip compression.
I my original article I showed you how to use Rack::ShowStatus and Rack::ShowExceptions to get handy error messages for your project. Today, I’d like to show you how to add Compass integration.
Never heard of Compass? Compass is a fancy new CSS framework built on Sass and it’s awesome. Among other things it provides a number of handy CSS3 modules that allow you to easily use a number of advanced CSS features. Without Compass and Sass this kind of stuff becomes pretty labor intensive to write.
Now Serve comes with built in support for serving Sass files, but it doesn’t know anything about Compass. To use Serve with Compass you will need to add the following lines to your config.ru file:
require 'sass/plugin/rack'
require 'compass'
Compass.add_project_configuration(root + '/compass.config')
Compass.configure_sass_plugin!
use Sass::Plugin::Rack
The first two lines are necessary so that the Sass Rack middleware is installed and the Compass framework is loaded. The next two lines tell Compass where your configuration file is located (in this case I’ve put it in the project root) and configure Sass using the configuration values stored there. The last line loads the Sass plugin as middleware.
Your compass.config should look something like this:
http_path = "/"
css_dir = "public/stylesheets"
sass_dir = "public/stylesheets/sass"
images_dir = "images"
javascripts_dir = "javascripts"
relative_assets = false
Your actual values will vary depending on how you are using Compass, but the key variables for the purposes of this tutorial are css_dir and sass_dir. In this case I’ve chosen to have the plugin generate my CSS in the public/stylesheets directory and store my Sass (much like Rails does) in the public/stylesheets/sass directory.
If you’ve separated your dynamic and static assets into the views and public directories (like I suggested in my previous article) you will notice that I’ve chosen to put my Sass and CSS in the directory for static assets (public). This is because the Sass plugin is designed to generate your CSS when the first request is made to your Serve application. Generated files are nice in production environments because they can be served directly by the Web server instead of by your application. This is in contrast to the way that Sass files are normally used with a Serve project. Normally, you would put your Sass files in views/stylesheets and they would be processed by the Serve Rack adapter on each request.
Here’s a Gist of the source code for this entire tutorial along with a couple of other goodies. Enjoy!
Hat tip to Chris Eppstein for his help with this.
by John W. Long on May 26, 2010
Serve is a rapid prototyping framework that I have been building for Web applications. It is specifically designed to make it easy to prototype Rails applications, but it can easily be used to prototype applications for any other framework. I’ve talked about the benefits of using Serve before, so I won’t cover that here, but if you are interested in learning more about Serve read, Serve: A Rapid Prototyping Framework for Designers.
Yesterday I released Serve 0.11.2 which adds built-in support for Rack. Rack allows a Ruby application to be deployed in any number of environments (Mongrel, CGI, Passenger, etc.). The good news for Serve users is that you can now deploy Serve projects much like any other Rails application.
Today, I’d like to talk about setting up your Serve project for deployment on Passenger (a.k.a. mod_rails). Passenger is an Apache/Nginx module that allows you easily deploy Rack-based applications in production environments. The benefit for Serve users is that with Rack and Passenger, Serve is much easier to deploy on a modern Web server. This will allow you to put your prototype project on a Web server that is easily accessible by your clients. Or, if you are on a Mac and you prefer to stay away from the command line, you can use Passenger and the Passenger Preference Pane to handle your Serve projects.
I’m not going to cover the setting up Passenger in this tutorial. That is already well documented on the Passenger web site. Instead I’m going to talk about how to convert your Serve project so that it works well with Passenger.
Passenger requires that Rack applications have a certain structure for performance and security reasons.
The Basics
We learn from the Passenger User Guide that Rack applications must have three things:
- A
tmp directory
- A
public directory
- A
config.ru file
The tmp directory is used by Passenger for the restart.txt file. You can notify Passenger that your Rack application should be restarted by updating the Last-Modified timestamp on the restart.txt file. The public directory is needed for static assets like images, javascripts, and stylesheets — in this case anything that is not processed by Serve directly. The config.ru file is a Ruby-based configuration file for Rack.
I’m going to suggest that we add one more directory:
In the views directory we’ll put all of the ERB, HAML, and special Serve files that are necessary for the prototype. Anything that does not need to be processed by Serve should go in the public directory. This includes all images, javascripts, etc. CSS files should also go in the public directory, but SASS or SCSS files should go in the views directory.
To create these directories and files, you can execute the following commands from the command line in the root of your project:
$ mkdir tmp
$ touch tmp/restart.txt
$ mkdir public
$ mkdir views
$ touch config.ru
Now move all of your existing Serve files into the views directory (ERB, HAML, SASS, Redirects, etc…). Be sure to preserve the existing directory structure. If you have a view_helpers.rb file that should also go in the root of views directory.
Once that is complete, move images, javascripts, and other static assets into the public directory. Again, be sure to preserve the existing directory structure. (If a file was in images/icons it should now be in public/images/icons.)
Rack Configuration
Now open up config.ru in your favorite text editor and insert the following code:
gem 'activesupport', '2.3.5'
gem 'serve'
require 'serve'
require 'serve/rack'
use Rack::ShowStatus
use Rack::ShowExceptions
root = File.dirname(__FILE__)
if ENV['SERVER_SOFTWARE'] =~ /passenger/i
run Serve::RackAdapter.new(root + '/views')
else
run Rack::Cascade.new([
Serve::RackAdapter.new(root + '/views'),
Rack::Directory.new(root + '/public')
])
end
Advanced users may want to modify this a bit to include other middleware or applications, but this configuration should suffice for the basic Serve project. I’ve included the Rack::ShowStatus and Rack::ShowExceptions middleware to provide pretty 404s, messages, and error handling. To turn off either of these features just comment out the appropriate line. Rack::Cascade and Rack::Directory are used to handle files in the public directory if Passenger is not used. This is useful if you are using Rack from the command line via the rackup command.
So that’s it! Everything you need to know to rackup a Serve project on Passenger.
by John W. Long on May 15, 2010
Last week I helped my friends at Terralien launch fullstackiphone.com. Full-Stack iPhone is a long-standing service from Terralien under a new name. Terralien has been doing iPhone interfaces for Web applications for some time now so we thought it would be appropriate to begin promoting the service in a more public way.
Terralien can deliver a lot of value to potential clients. Nathaniel Talbott has done a great job assembling a hand-picked team of top-notch developers and designers that are passionate about building successful businesses. If you are looking for a team that can build an iPhone application with an incredible Web-based backend, be sure to check us out.
by John W. Long on April 30, 2010
Page layouts are one of the most powerful features of Radiant. Layouts allow you to encapsulate much of the common HTML of a website into a template of sorts that is filled in with the information unique to each page.
Today, I’d like to share a couple of tips and tricks for making the best use of this powerful feature. These aren’t hard and fast rules, just a couple of the best practices that I’ve picked up over the years as I’ve worked with Radiant.
Use One Layout If Possible
Radiant allows you to create as many layouts as you want for your website. At first glance you may be tempted to create multiple layouts for your site that have a one-to-one relationship with the type of page you are creating. For instance, you may want to have a layout for your home page, one for your portfolio, one for your blog, etc. Resist this urge if you can. Depending on how your HTML and CSS are written, you may be able to get away with just one layout — even if the page that you are working on has a vastly different look and feel. The trick is to use conditional tags to switch parts of the layout on and off depending on the page.
Why is this helpful? It keeps all of the common code in one place and allows you to keep things DRY. It also minimizes user error and ensures that each page has the proper design, because a content editor never has to worry about selecting the proper layout. You set the layout once on the root page, and all the other pages inherit it.
Use Conditional Tags To Build Flexible Layouts
Radiant provides a number of conditional tags that make it easy to build smart layouts. Use them.
The most commonly used is tag is probably if_url (and its sister unless_url). This tag allows you to test the URL of the current page and show or hide content based on the condition. You can do an exact match on the URL by using the equals attribute, but I mostly use the matches attribute because it allows me to use regular expressions to match an array of URLs.
For instance, on WiseheartDesign.com I insert code for comments using the if_url tag with the matches attribute like this:
<r:if_url matches="^/articles/.+">
...code to display comments here...
</r:if_url>
If you are not familiar with regular expressions, this may look a little convoluted, but it is really quite simple. It basically reads, if the URL starts with “/articles/” and is followed by at least one character, then insert the following code. That last part is necessary so that the articles index page (which has the URL of “/articles/”), is not matched by the expression.
As you can see, the if_url tag is quite powerful for adding conditions to your layouts, but it has one significant weakness. Since it relies on the URL of the page, if you change the URL scheme for your website, you will need to remember to come back and update your layout. If your layouts are riddled with calls to if_url this may prove to be a bit of a headache.
Another tag that may be useful here is the if_content tag. You can use the if_content tag to test if a page has certain parts (or the unless_content tag to test that it does not). With clever naming of page parts you can get a lot of mileage out of this simple tag.
For instance, suppose you have two basic page designs for your web site. One is a standard two-column design with content and sidebar. Another is a simple single column design with no sidebar. By testing for the existence of the sidebar, you can actually handle both cases with a single layout:
<r:if_content part="sidebar">
<div id="content"><r:content /></div>
<div id="sidebar"><r:content part="sidebar" /></div>
</r:if_content>
<r:unless_content part="sidebar">
<div id="content" class="no_sidebar"><r:content /></div>
</r:unless_content>
The code above checks for the existence of the “sidebar” part. If it exists it renders two divs, one for the content and one for the sidebar. If the “sidebar” part does not exist, only the content div is rendered – this time with the “no_sidebar” class so that the single column version can be styled differently.
With a little a little imagination, I’m sure that you can see how the same technique can be used to achieve one-column, two-column, and three-column designs – all within the context of a single Radiant layout.
Use Snippets To Simplify Complex Layouts
Radiant snippets are designed to make it easy to share share common code between layouts and/or pages, but they are also useful for other purposes. The more complicated your layouts become the more you will find it makes sense to extract meaningful parts into Radiant snippets.
One purpose is to isolate complex or verbose code. For instance, you may want to put your Google Analytics code in a snippet. You will probably only enter this code once during the lifetime of your site, and there is no reason that it should clutter up your layout code.
Another purpose is to make content more accessible. I often put my navigation code in a snippet because as I update a site it is easier to maintain in isolation.
by John W. Long on April 8, 2010
Today I would like to announce the release of ToggleJS – a LowPro and Prototype-based solution for unobtrusively toggling elements with effects. ToggleJS makes it easy to create an advanced section on a form that slides out when the “Advanced” link is clicked, or to show more options when a certain check box is checked. And it does all of this with beautiful effects (complements of script.aculo.us).
View the online demo.
The way ToggleJS works is you select an element to be the “Trigger” element that will cause another another element revealed. You can chose a link, a checkbox, a select box, or a group of radio buttons as your trigger. You then add a rel attribute to the element that identifies an ID or group of IDs for the elements that should be revealed.
Using a Link as a Trigger
For example, the following code will create an advanced section that will only be revealed when the “Advanced” link is clicked:
<p><a class="toggle" href="#advanced" rel="toggle[advanced]">Advanced</a></p>
<div id="advanced">
... advanced options here ...
</div>
Note that I’ve set the rel attribute to “toggle[advanced]”. This is a special syntax that identifies the list of IDs that should be toggled when the trigger is clicked. (IDs appear between the brackets. To toggle multiple IDs separate them with commas.) In this case we are telling ToggleJS that the “Advanced” link is a trigger for the “advanced” div. By convention, toggle triggers are also identified with the “toggle” class (this is configurable). Also note that ToggleJS will take care of hiding the “advanced” div when the page loads.
A Checkbox Trigger
To create a checkbox toggle trigger, the syntax is almost identical:
<p>
<input type="checkbox" class="toggle" name="remind" id="remind" value="1" rel="toggle[remind_on]" />
<label for="remind">Remind me</label>
<span id="remind_on">on <input type="text" name="date" /></span>
</p>
In the example above, if the user checks the “Remind me” checkbox a date field will appear where they can enter a date for the reminder. ToggleJS is smart enough to recognize whether the checkbox is checked on page load and will hide or show the related element as needed.
Selects and Options
The code necessary to make this work with a select box is a little different. Instead of setting the rel attribute on the select box, you should set it on each of the options:
<select class="toggle">
<option>- none -</option>
<option value="1" rel="toggle[one]">One</option>
<option value="2" rel="toggle[two]">Two</option>
<option value="1,2" rel="toggle[one,two]">One and Two</option>
</select>
<div id="one">1</div>
<div id="two">2</div>
In this example, the select box is used to toggle the visibility of divs “one” and “two”, based on selection. Note that the last option, “One and Two”, displays both divs by specifying both IDs in the rel attribute.
Radio Buttons
The fourth and final way that you can use ToggleJS, is with a group of radio buttons. The code is actually strikingly similar to the code used for the select boxes:
<div class="radio_group toggle">
<p>
<input type="radio" name="numbers" id="numbers_none"/>
<label for="numbers_none">None</label>
</p>
<p>
<input type="radio" name="numbers" id="numbers_one" value="1" rel="toggle[one]" />
<label for="numbers_one">One</label>
</p>
<p>
<input type="radio" name="numbers" id="numbers_two" value="2" rel="toggle[two]" />
<label for="numbers_two">Two</label>
</p>
<p>
<input type="radio" name="numbers" id="numbers_three" value="1,2" rel="toggle[one,two]" />
<label for="numbers_three">One and Two</label>
</p>
</div>
<div id="one">1</div>
<div id="two">2</div>
The Wiring
Apart from the standard script tags for LowPro and Prototype, you will also need to wire in the appropriate LowPro behaviors. If you are building a Rails application, I’d recommend that you put this in “application.js”:
Event.addBehavior({
'a.toggle': Toggle.LinkBehavior(),
'input[type=checkbox].toggle': Toggle.CheckboxBehavior(),
'div.radio_group.toggle': Toggle.RadioGroupBehavior(),
'select.toggle': Toggle.SelectBehavior()
});
What this code does is associate the LowPro behaviors with the correct elements based on CSS selectors. You can customize the rules above if you want to use different class names or if you would like to tweak the behaviors with custom options.
For example, you can create an inverted toggle checbox by adding the following line to the Event.addBehavior call:
'a.inverted_toggle': Toggle.LinkBehavior({inverted: true}),
An inverted toggle link would hide the associated div the first time it was clicked instead of showing it.
You can also customize the effect used and handle custom before and after toggle events for the Toggle.LinkBehavior. For full details on the different options that you can pass the LowPro behaviors, consult the inline documentation.
There are also two configuration variables that can be used to customize the default settings for all toggle behaviors:
Toggle.DefaultEffect = 'appear'; # a string; the default is 'slide'
Toggle.DefaultEffectDuration = 0.5; # in seconds; the default is 0.25
Conclusion
ToggleJS removes the need to write custom code to toggle the visibility of other elements for many of the common use cases. And it does all of this in a clean unobtrusive way. You can learn more about ToggleJS, over at the GitHub project or view the online demo here.
Before closing, I’d like to thank the kind folks at MemberHub who sponsored the initial development of ToggleJS and have allowed me to release it as open source. MemberHub is a group communications platform for churches and other organizations.
by John W. Long on March 11, 2010
Over the years we have had many requests on the Radiant CMS Mailing List to add better support for conditional tags of some kind. Right now we have an array of tags for making conditional statements that are included in the standard distribution. The following is an incomplete list:
<r:if_children> <r:unless_children>
<r:if_content> <r:unless_content>
<r:if_url> <r:unless_url>
<r:if_ancestor_or_self> <r:unless_ancestor_or_self>
<r:if_self> <r:unless_self>
<r:if_parent> <r:unless_parent>
<r:if_dev> <r:unless_dev>
When Radiant was first released, we only had if_content and the rest were added as the need arose. We have considered adding generic support for conditionals, but every proposal thus far seems to require additional syntax of some kind. Chris Parish took a stab at adding generic support for conditionals at one point. His extension allows a user to type expressions like:
<r:if cond="breadcrumb matches /your regexp/">
or even,
<r:if cond="parts includes-any ['body', 'other part']">
To date we have avoided adding something like this to the core because of quibbles over the precise syntax. We also value the rigidity that the Radius attribute syntax provides. To be effective with tags in Radiant, a designer only has to understand tags, attributes, and nesting. Adding another strange comparison syntax on top of this seems needlessly complex.
Towards A Generic Syntax for Conditionals
While thinking about some of this today, it occurred to me that there might be a reasonable compromise that preserves HTML-like, attribute-oriented syntax while allowing a high degree of flexibility.
So without further ado, I would like to propose that we add generic support for conditionals to Radiant with the following basic syntax:
<r:if property="name" matches="regexp">
or unless,
<r:unless property="name" matches="regexp">
Above, the property attribute indicates a property on a page that a conditional operates on. (I will talk about properties in detail in a minute.) The matches attribute indicates that the property should match the given regular expression if the tag is going to expand. Additional attributes would include equals, nequals (for not equals), and nmatches (for not matches).
Now what exactly are properties? Properties would be a new first class concept in Radiant. There would be properties for all of the default page attributes (title, slug, url, etc.), but you would also be able to define your own properties with a class method on Page. So subclasses of Page could define their own properties or extensions could add properties to Page to declare properties that are accessible to all pages.
To declare a property you would define it within the class definition of a page like this:
property 'name'
By default, with no additional parameters this would assume that the property ‘name’ is a reference to the ActiveRecord attribute ‘name’. But you could also pass a block to calculate properties on the fly:
property 'full_url' do
'http://wiseheartdesign.com' + url
end
This would allow you to create constructs like:
property 'author.name' do
author.name
end
Of course, some additional sugar would make this much easier:
property 'author', :method => 'author', :attributes => [:name, :email, :website]
This would declare three properties, ‘author.name’, ‘author.email’, and ‘author.website’.
Once properties are declared you could access them within tag definitions like this:
tag 'if' do |tag|
page = tag.locals.page
property = tag.attr['property']
value = page.properties[property]
equals = tag.attr['equals']
tag.expand if value == equals
end
The bracket syntax would give tag authors easy access to properties on a page and make properties a first class concept in Radiant that extension authors can take to another level.
A Generic Case Statement
I would also suggest that there is room for a third type of conditional statement. We already have if and unless, why not case?
<r:case property="author.name">
<r:when equals="John">Lead Designer</r:when>
<r:when equals="Sean">Lead Developer</r:when>
<r:else>Core Developer</r:else>
</r:case>
And yes did you see that? case, when, and else allow us to avoid if, then, and else – another one of the commonly suggested features. We can keep it clean with single tags for if and unless, and allow case, when, and else for complex conditionals.
Suggestions, Addendums, Thoughts?
So there you have it. My proposal for adding a generic syntax for Radiant conditionals to the standard tag library. Any thoughts or comments from the Radiant community? Is this a can of worms or a powerful, much needed addition? Put your thoughts in the comments below.
by John W. Long on March 2, 2010
With all the buzz on the Web today about the necessity of good design for success, there has been very little discussion about matching the right designer to the right project. The way the word “designer” is used today is a bit ambiguous. It can refer to any one of a broad range of professions. From usability experts, to illustrators, to HTML and CSS specialists, to typographers, to user experience people.
To make matters worse, this confusion about the word “designer” and what it actually means often leads to hiring decisions that set projects up for failure. Hiring the wrong designer for your project can be akin to asking the wrong type of doctor operate on you. You would never ask a foot doctor to do brain surgery. Or, an eye doctor to remove your appendix. But the same kind of thing happens all the time in the design world and nobody blinks.
The truth is there are many different kinds of designers, and each is good at different things. Yes, some designers are generalists and their value lies in their ability to deliver consistently across multiple disciplines, but generalists rarely deliver the highest quality work.
So how do you find the right designer for your project? Especially if you don’t know a lot about design? Where do you start?
Recognize Different Designers Work Better In Different Mediums
One of the rookie mistakes you want to avoid when choosing a designer for your website is picking a print designer to do a Web designer’s job. There is a huge difference in the skills necessary to pull off a successful website design and the skills necessary to operate well in print. And the opposite is also true!
Since I primarily do Web design for a living I probably wouldn’t be the best person to design an album cover for your new CD or to create a brochure for your business. Could I do it for you? Absolutely! But again, I wouldn’t be the best choice. There are other people who can do this kind of work in less time and with better results than I can currently offer.
Why is this true? Because the medium that you ask an artist to operate in is just as important as the artist you choose. What do I mean by medium? The medium is the method or materials through which a work of art is presented. As this applies to design we generally use terms like print, web, or motion graphics (Flash).
Why is the medium so important? Because the medium that a designer is working in makes a huge difference in the quality of work that he is able to produce. You wouldn’t ask a sculptor to design a skyscraper, or painter to compose a symphony. All of these people can create beautiful things if you put them in their element, but get it wrong and you won’t get good results.
Recognize Designers Have Different Strengths
Along the same lines, the other mistake you want to avoid is selecting a designer that does not have a strong skillset for the types of things that will be necessary to complete your project successfully. Some designers are really good at illustration, use of photos, or color. Some designers are great at branding and logo design. Some at usability or total user experience (UX). Some are amazing at marketing and message.
On the same token, while a designer may be really good at one thing (say illustration), he or she may be terrible at another (say usability).
Why is this? A lot of it is about experience. Some of it, natural gifting. But a huge part of it is related to the designer’s personal passions. Designers tend to do well at the things they enjoy. Or, to enjoy the things that they do well. A good question to ask a potential designer is does your project fall into the category of the things that he or she enjoys? If it does you will probably find them quite knowledgeable about the things that are necessary for your project to be a success.
The last thing you want is to end up paying someone a lot of money to do something that they are not good at. Consider a potential designer’s strengths and weaknesses when matching them up with your project.
Recognize Some Designers Have Different Appeal
Another thing to consider in your search for the right designer for your project is the appeal that their personal style has to your target audience. Some designers are good at tailoring their style to the audience, but others are not. This isn’t necessarily a bad thing. Many designers are very successful at producing a certain look that their clients value. As you are evaluating a designer consider the diversity of his portfolio, or, conversely, the consistency. Is their personal style something that would appeal to your target audience? If the answer is no, move on.
Other Things To Consider
Of course, there are many other things to consider as you look to hire a designer for your own project. How well do they communicate? Do they connect with you personally? How responsible and honest are they? But the points listed above should give you a framework for considering the value that they may be able to deliver in terms of design.
If you can afford it you may want to engage multiple designers. One to work on each of the individual components of the project. For example you could engage one designer to help you develop a good logo and brand for your company (or project), another to work on the marketing and emotional appeal of your website, and another to work on the user experience.
If money is tight, you may want to engage a designer that is more of a generalist rather than a specialist. After all, there are times when it’s just more economical to go to a family doctor instead of a specialist. But know the difference and hire accordingly.
And don’t forget to ask probing questions like the ones mentioned in this article. It is your money, business, and reputation that is on the line.
by John W. Long on February 24, 2010
My good friend and fellow designer Brandon Mathis has put together a wonderful little default avatar package that is available for free on his website.
Brandon and I had the good fortune of being able to work together on MemberHub.com back in 2008. MemberHub’s design needs were growing beyond what I could handle at the time so we needed someone to help us power through many of the features we were working on. An all around great guy and extremely competent designer, Brandon was just the sort of person we were looking for to assist us.
So it was while we were in the midst of things working on MemberHub that Brandon took the time to improve the MemberHub default avatar. The default avatar is the picture that every user gets to represent them if they haven’t uploaded a photo on MemberHub.com. At the time we were using a lame question mark avatar reminiscent of the old Facebook default avatar. We wanted to make the avatar a little more personal. As we looked around for a good free option we discovered to our chagrin that there really weren’t any. We both thought this was a shame, so Brandon spent his own time to create a default avatar set that we could use on MemberHub.com that he could also release for anyone to use.
The result was Fancy Avatars. A default avatar set that can be easily customized to suit your needs. The set includes male and female avatars, and the orignal vector source image (a Fireworks PNG). Fancy Avatars is licensed under a Creative Commons Attribution license so it is free to use on both commercial and personal projects.
Check out the demo page or download the set now.
