So, I wanted to share with you my experiences in preparing for launching a web design business. I’m doing this for two reasons: first is to share what I know in the hope that you might grab a nugget or two of learning and secondly (more selfishly on my part), if I share my adventure, it will motivate me even more to do everything by the numbers. If I’m going to give you, dear reader, valuable information for your adventures into freelance, I’m going to damn well be sure about the information and not lead you (and myself) astray.

Deciding to go freelance

So, in the midst of everything, I had to ask myself some hard questions. I mean, the really though questions you ask when you’re about to really shake up your existence:

• Am I crazy??!?
• Do I have the qualifications to freelance for a living?
• Do I have the level of commitment to do this?
• What will make me different from the rest of the pack?
• Do I have the where-with-all to start a business?

I know dozens of people who get the itch now and again. They get fed up with the daily grind and become attracted to the “greener” pasture that is self-employment. Many of them will try it out (hey, I’ve done this already at least once) only to find out that they enjoyed the process about as much as novacaine-less dental surgery. That was enough to get many of them back into the rat race and look at those entrepreneurial souls out there with the same kind of look you give to your addled old aunt who doesn’t quite remember who you are, but still pinches your cheek with a plier-like grip.

So, am I crazy? Well yeah, that’s besides the point. The question is, am I crazy enough to do this? And that would be yes also. Why? Well Sally, let me tell you. I have a plan and a passion for what I do. I really enjoy this web design stuff and I’m really go at it. I eat and sleep web design. I even arrange my fruit loops into interesting layouts and show them to my friends saying “Now that’s gonna be a cool looking website!”

Now, about my qualifications. Do I know what I need to know to do the work? Yes, and no. Here’s what I mean: Do I know how to design some wicked pretty sites? Yes. Can I write code that will make all who’s-who of web design jealous at my mad skillz? Heck yeah! Do I know how to write a GUI interface to a mass spectrometer in TI Basic? No. I don’t. Nor do I ever want to. If I have a client who really really wants me to add a TI Basic interface to his mass spectrometer and they’re a good client. Then by golly I’m going to ask my friends who know TI Basic to help me out. I don’t have any problems asking for help now and then.

Rule 1 of Freelancing: Don’t be afraid to ask help from people you trust and pay them for it.

Now you must be asking, that’s fine, but are you committed to seeing this through? This was the toughest question to ask. I mean, it’s good in theory to say I’m now a freelancer, but then you have to say a freelancer all the time. Unless you are getting business on the side to suppliment your income as Head Barista at the local caffeine palace, you need to come to grips with the fact that you’re about to start a business and you’re livelihood will depend on how committed you are to freelancing. There’s no half way here.

Rule 2 of Freelancing: Remember you are a freelancer 24 hours a day / 7 days a week.

Ok, good. I’ve got skills, I’ve got committment, I’ve got a case of Excedrine and my very own kitten-hanging-in-a-tree poster on the wall. So, what’s going to make me special enough to have client prospects enter the squared circle in a no-holds-barred Battle Royale in the hopes of having me as their designer? Now there’s a good question. The ultimate answer to that question is simple: my reputation. Now of course, when you’re just starting out, there’s not much in the reputation piggy bank to start with, but there are ways to build your reputation. Most important of which is to do the job, get happy clients and share what you know with everyone you can. Become part of your community, whichever that is. Be an active member of that community. Networking is gold!

Rule 3 of Freelancing: Start building a positive reputation now!

Rule 4 of Freelancing: Don’t be afraid to share what you know. Be part of the community!

Finally, do I have the where-with-all to make the move to self-employment? The question is: Can you financially handle the move to running a business and do you have the discipline to run a business? I mean, freelancing isn’t 100% doing web design and waiting for the money to start overflowing your bank vault. There’s a mundane side to freelance. Expect to have a third of your time (or more) just doing the day to day activities any business owner performs. You still have to manage your bookkeeping, answer emails, write proposals, meet with prospects and pay the bills. So, do I have the where-with-all to do everything involved in running a business? Yes. I do.

Rule 5 for Freelancing: Being a freelancer means you are running a business and you are doing everything that entails.

So, think about it. Do you want to freelance? Can you postively answer these questions and be confident in your decision? Then welcome to the wonderful world of freelancing! We have cookies!

A web application framework, according to Wikipedia,  “is a software framework that is designed to support the development of dynamic websites, Web applications and Web services. The framework aims to alleviate the overhead associated with common activities used in Web development.”

If you expand that definition to include both client-side (CSS and JavaScript for the browser) as well as server-side (for the web server using a language like php, python or ruby), then you have the making of a development platform for creating just about anything on the web.

So, today I wanted to share my justifications for using frameworks and what that means to site owners, designers and developers alike. There are many considerations when you’re shopping around for frameworks and understanding the business implications can help you decide.

For the site owner.

So, if your site is being redesigned or re-architected or if you are having new development work done, then here are some good reasons for having your web team adopt frameworks:

• Much of the foundation work is done. The main benefit to using any kind of development framework is that most of the foundational programming is done already. For example, a PHP framework like Zend Framework has all the basic database, file access, authentication functions built-in and includes some nifty functions for PDF, Mail, RSS and Web Services support. These features can be fairly simple to have implemented by programmers who are well versed. The benefit here is that your team doesn’t have to reinvent these features and focus on your site specific features.
• Good frameworks are rigorously tested. You can rest assured that the framework code works well. Additionally, good frameworks have a strong development team and any bugs found along the way are pretty well squashed quickly.
• Frameworks help with “What-if-my-developer-got-hit-by-a-bus” syndrome. A well supported framework will have a following of designer/developers that support it. They adopted that framework for their work and they can usually pick up a project with less ramp up time.
• Frameworks can help you add more features for the same price. With a good framework, you can have your team implement/enhance features that might not be in the budget without it. Many popular frameworks have a community of developers who routinely create plug-ins and new modules which might enhance an existing feature or add one that doesn’t exist.

As a site owner, you’ll also have to consider the downside of implementing a framework for your project. Here are a few things to consider:

• Retrofitting a website with a framework is hard. If you have an investment of code which you decide to restructure to use the new framework (or worse yet, a hybrid of the two), you’ll have a prescription for sleepless nights. Some frameworks support refactoring better than others. Also, you need to weigh the cost of recoding against the benefit. Rewriting code can be a big expense if not planned well.
• Learning curve for in-house staff can be high. Many frameworks have a very specific way of coding in them. Some of which are quite inflexible in the approach to building applications. For example the Agavi PHP Framework uses a very specific notion of what an MVC (model-view-controller) is. If your staff isn’t used to this type of development, then they’ll have to take time ramping up before they can get productive. So, there are start up costs involved in moving your team to a new framework.

For the designer/developer.

If you’re a designer/developer considering the switch to a new framework, then you need to also consider the following:

• Will the framework be around for the long haul? You certainly don’t want to invest your time and effort (and maybe even money) in a framework only to have it disappear. Granted, all your existing sites will still work, but the chances you’ll have support or code fixes (without going in and doing it yourself) will be slim.
• Is the framework conducive to how you do your work? In other words, how much will you have to change your daily workflow to accommodate the framework? More on this later.
• Will you be more marketable if you learn this framework? A popular framework creates a demand for programmers who specialize in it. Think about it, there’s a world of demand for developers of a particular framework. (Ruby on Rails anyone?) So, making the investment in learning a framework might open the door for new opportunities.
• Does the framework make programming more fun? A lot of my coder friends wholeheartedly adopted frameworks like Ruby on Rails and jQuery (for JavaScript) because, in their opinion, it makes coding fun! Hey, how cool is that?

How to choose a good framework.

Whether you’re a site owner or a coder, the selection process is similar. Consider these tips when choosing a framework:

• Understand how you (or your web team) codes. What kind of coder are you? Which tools do you use when you are coding? For example, I consider myself a no-frills coder. I prefer short and simple frameworks without a ton of extra features. Frameworks like the YUI framework for what I do is just overly complex. Accessing many of the features requires a lot of code and understanding a pretty large number of functions. On the flipside, if you want the kitchen sink of JavaScript frameworks, YUI is one to seriously consider, there’s a ton of modules and widgets included.
• Make sure there is a large community (of developers and testers) behind the framework. You want to ensure your framework continues to evolve and stay popular. The Ohloh website is a great place to see how popular a framework (or other open source project) and how well supported it is by the developer community. This is THE place to start when you are looking for a framework to hang your hat on. Ohloh will even let you evaluate projects by frequency of updates, code/comment ratio and longevity of the project.
• How large/friendly is the community surrounding the framework? Face it, you’re going to need help from time to time and the internet can be the best place to find it. Consider whether or not the community is friendly to those using the framework, especially newbies. Some frameworks have built a bad reputation for not being very tolerant to new users. This, in turn, sours their opinion of the framework and causes them to switch to another framework.
• Consider the quality of documentation/tutorials. Having a good set of learning resources is really important when making your choice. Bad or incomplete documentation/tutorials will cause a framework to lose popularity.

Doing your homework will help keep you from wasting a lot of time when evaluation a framework.

About my search process.

Over the next few weeks, I’m going to evaluate a number of PHP, JavaScript and CSS frameworks to hang my technical hat on. Here’s my unscientific criteria for making my choice:

1. Does the framework provide the basic functionality I need? I, for the most part, don’t need a ton of widgets or prebuilt functions, but I do have a specific set of needs based on my workload and knowledge.
2. How far can I get in a week? Overall, how productive am I with the framework? I want to know how easy the framework is to do a real life example. My evaluation process will involve choosing one PHP, one JavaScript and one CSS framework and seeing how far I can get with a minimum of hairpulling on my part. I want to see if the framework will increase my productivity in the long run.
3. Does the framework support the way I code? I’m pretty set in my ways as a developer, and I want a framework to compliment my workflow, not bash heads with it.
4. How good is the documentation and how active is the community? It’s a natural part of learning the framework my own.
5. How complete is the featureset? How customizable it? Does the framework have everything that I’ll need to develop the kinds of sites I need to create? If not, how easy is it to modify the framework to round out the features I need?
6. Am I having fun with the framework? It might sound corny, but I really like coding. I got into the business to have fun and feel passionate. I want to know that the framework I use helps me keep the passion alive.

Here are the frameworks that I’ll be evaluation:

PHP: CakePHP, Codeigniter, Symfony and Zend Framework

JavaScript: jQuery/JQuery UI, MooTools, YUI and Prototype/Scriptaculous

CSS: Blueprint, 960 Layout, YUI CSS and my homegrown CSS framework.

As I evaluate each framework, I’ll be posting my findings and how they compare with eachother. I invite everyone to share with me your criteria and experiences.

Now she’s the down-and-out kid. The designers who embraced her in her youth are now turning their collective noses and embracing DIV and SPAN, leaving her out in some cheap motel with a 2 dollar bottle of whiskey, half a pack of cigarettes and distant memories. “I was supposed to hold columnar data,” she keeps muttering to herself.

Ok, here’s the reality. Tables are good, they work and they are useful for good and proper representation of data. Tables are important and deep down are good natured and you can trust her with your little puppy. Over the years, designers abused tables for many reasons: namely because most designers think in grids (especially if you’re a print designer) and tables worked well in browsers. CSS support was sketchy at best and well you could do a lot with tables.

Fast forward today and designers are doing the doing the same thing with DIVs and SPANs.

In a recent article in Digital Web Magazine titled Everything You Know About CSS is Wrong, Rachel Andrew covers the table, table-row, table-cell, etc. display support now available in IE 8 beta. As mentioned in her article you can essentially turn a series of nested tags into a table-style layout using these values for the display CSS attribute. Thus you get all the table-based layout goodness without using any table tags.

Here’s an example, consider the following markup:

<div id="wrapper">
    <div class="row">
        <div class="cell">Column 1 content</div>
        <div class="cell">Column 2 content</div>
        <div class="cell">Column 3 content</div>
    </div>
    <div class="row">
        <div class="cell">Column 4 content</div>
        <div class="cell">Column 5 content</div>
        <div class="cell">Column 6 content</div>
    </div>
</div>

Now, let’s style it with the following CSS:

<style type="text/css">
#wrapper { display : table; border-spacing: 5px; }
.row { display : table-row; height: 125px; }
.cell { display : table-cell; border: 1px solid black; background-color: #ffd; }
</style>

Will yield the following result:

This is the resulting visual for the CSS Table using DIVs.

You can see how table-like the output is. The “table cells” here are rendered the same way the browser would render for a table. All the divs with display : table-cell inherit the same height from the row. For a simple layout where you as a designer need columns to have the same height, this is a pretty cool solution.

Now, if you’re a designer whose been in the trenches for more than a couple of years, you’re looking at this and crying as you reach for the emergency bottle of Wild Turkey. You spent many agonizing months trying to switch your thinking to Web Standards based layout and learning how to lay things out the “right way.” You’re probably mourning all the cool multi-dimensional nested tables which were more complex than getting a stable nuclear fusion with 2 silver spoons, copper wire and a zippo lighter. But hey! It rendered in IE!

Ok, here’s the bottom line.

Tables are for tables, table layouts are for… well … tables! Saying otherwise is sending a dangerous mixed signal to designers to go back to the bad habits of the past. Add to that the fact that CSS Table layouts using DIVs, don’t work in IE 7 nor IE 6. Mix in the fact that there’s no CSS equivalent to ROWSPAN and COLSPAN. Sprinkle in a ton of extraneous DIVs and SPANs just to get this kinda layout working and you have a pretty vile Table Layout soup. CSS or no CSS, I don’t like the smell of this.

Give me clean, semantic markup, broad CSS support and javascript to fill in the design gaps and I’m happy.

Rachael, everything I know about practical web design is right!

The premise behind this book is pretty simple. I’ll be putting together a series of web design/development projects and walking you through each one of them from conceptual start through to basic code and delivery. The difference here is that I’ll be starting with a tight budget of $365 for all the tools that we’ll need to build professionally design websites and applications. And that’s including web hosting and software.

Why $365? That part’s simple. To many would-be web jocks out there, a barrier to getting started is cost. Many people think that you have to drop thousands on software, hardware and hosting to be able to be a professional web designer/developer. I’m setting out to disprove that.

Personally, I think the market is rich with low cost alternative to the likes of Photoshop, Illustrator and Dreamweaver. Don’t get me wrong, I like Adobe and I’ve invested hundreds of dollars in them (and I am about to shell out more for upgrades to CS4), but for those of you just starting out, I’m telling you right now, spending hundreds of dollars isn’t necessary.

Before we get started: PC vs. Mac

Before we start another Windows vs. Mac flame war, I’m going to tell you one important fact. Having a Mac isn’t going to make you a better designer and having a Windows PC isn’t going to make you a better programmer. Marketing gimmicks aside, you can do just as good a job on a Windows PC as you can do on a Mac and vice versa. One of my aims is to choose the best tool for each platform.

I’ll be using a Mac (my platform of choice) for the examples in this book, but everything I do will work on both platforms equally.

I want to hear from you.

I want this project to be all about you and I want your feedback. Let me know if this has real impact and give me suggestions on how to make this information better. It’s as easy as replying to these posts.

Who is this book for?

This book is intended for anyone with interest in the wonder of designing and building for the web. My intent is not to teach you the basics. I’m not gonna even try. There are other good sources in print and on the web for learning HTML, CSS, JavaScript and Server-side languages like PHP or Ruby. I will, however, show you by example how to build various types or projects and share with you my process for completing a project from start to finish.

If you are a Web Designer…

… with a bit of experience, then I hope you’ll take away at least some insight as to how build professional sites and manage the projects using a variety of techniques and processes that have worked for me over the years. As a professional, I’m always on the look out for these nuggets of wisdom and I want to share my nuggets with you.

If you are just starting out…

… in the business of web design, I want you to use the information I’m presenting to learn good habits and skills. While I from time to time will get pretty down-and-dirty technical, there are concepts here which will make sense to designers of all skill levels. I want to help ignite your passion for learning and hopefully give you ideas on how you can take your skillset to the next level.

If you are a site owner…

… who wants to see the process of building professional websites from the vantage point of the web professional, then you’ll find some worthwhile info here. While my focus is the application of the web design/development process, I’ll be sharing some key concepts and buzz words which should help bridge the communications gap between you and your in-house/freelance web professional. Whether you’re looking to staff up for an upcoming project or you just want to see what goes on for yourself. My hope is that you’ll get more of an insight to the process we go through to build engaging web sites.

Coming soon to a browser near you.

In the next few weeks, we’ll discuss the tools we need to set up shop as a designer/developer. We’ll also talk about some key decisions to make before we can start taking on any projects.

So stay tuned…

Ok, the fact is I can’t remember everything! Ok, there I said it. I admitted it.

Now, if you’re a true blue code jockey, you already know what I’m about to say. Ok, hang in there Chucky baby, this is gonna get good!

Let me explain. I personally own 3 computers, a Mac Pro, a MacBook Pro and a Modbook (oh yeah baby!). When I’m working, I use my machines for different things and they serve a purpose at diffent points during my projects (and that doesn’t include the iMac I have at the office). One of my biggest challenges these days is making sure that I keep track of what I’m working on as I move from machine to machine in this ceremonial dance I call work. One slip up and I’ve lost hours of work because I forgot to transfer the right files from one machine to the other.

Add to that the fact that I can collaborate with other designers/developers during a project and you have the fixin’s for a nasty project management stew.

So, what’s the solution? That’s right sparky, subversion (you probably cheated and looked at the title of this post).

Subversion is one of the leading Verson Control Systems in the world today, maybe the universe. It is essentially a tool to allow you to keep a centralized repository of computer files that you would use for a particular project. It supports the notion of versioning which is way of backing up your work and keeping track of each version of a project file you might be working on.

Subversion is great for collaborating as well. Members of your project team can “check out” a copy of the project files and can submit changes to those files. Subversion manages those edits and keeps a copy of all the old versions of your files.

When a teammate on your project “checks in” a file to submit the changes they made to the central repository, they are required to add comments about what kinds of changes they made to the file. This feature is probably one of the most useful in a team environment. You can scan through the history of a file and see what changes were made to a particular file (as long as your teammates weren’t lazy and labeled everything as “oh, was just fixing this before lunch at Taco Pete’s”).

Another valuable feature of subversion is the idea of branching projects. Say you’ve finished up an identity package for a client of yours and now you’re ready to work on a package for one of their subsidiaries. That project will probably start as an offshoot of the first project with some additions and changes to produce the second package. In subversion you can create a new “branch” for the new project and carry over all or some of the files from the original project and they are both treated as independent projects. You can merge the branch back into the main project (called the trunk) if you wanted to consolidate the files for both projects.

See, you need it. You want it! You gotta have this! Right? Good!

Ok, let’s start off with the good news: Subversion is free. Yes! Open source goodness can be found here. You can download the main command line interface from the Subversion site. There are a number of graphical subversion apps around for both Windows and Mac. The best of the bunch for Windows is TortoiseSVN. It’s a great piece of software that integrates nicely with Windows Explorer. On the Mac site, I currently use ZigVersion. It has a very mac-like interface and makes it easy to use subversion on the Mac. One that’s been getting a lot of press lately is Versions with a beautiful interface that makes using subversion feel natural on a Mac.

Now for the bad news. Only a handful of web hosts will allow you to setup a subversion repository. It seems really hard to find on your basic web hosting account. One host that does support Subversion is Dreamhost.com where you are allowed to build subversion repositories using your hosting account space.

A completely online solution I came across this weekend is called Beanstalk which specializes “Hassle Free Subversion Hosting.” It is a total online solution for keeping track of your subversoin repositories. You can sign up for a free account that gives you 20MB of storage for your files. Their paid accounts come with a 30-day free trial period.

Another cool feature according to their website is the integration with Twitter, BaseCamp (an online project management tool) and Lighthouse (an online issue tracking system). Everything you need to manage your projects from start to support. Did you hear that Sparky?

Here’s the deal. If you’re a professional coder, you’re probably using some sort of version control system, you know the warm, happy feeling you get when you commit your code to the trunk. Boy, that’s happy.

If you’re a designer or anyone that generates a lot of files during your day-to-day work, then you need to start using subversion. There’s a certain sense of freedom to be had when you don’t have to worry where the latest and greatest project files. Now that’s cool.

As a somewhat jaded consumer of the web, I tend to have little patience for sites that have little substance beyond all that window dressing. There is a place for sites that entertain, but I’ve got stuff that needs to get done during the day and I want what I came to the site for. Fast, easy to find, easy to consume content. That’s it. No more and certainly by golly, no less.

So after reading an excellent article by Aaron Walter on A List Apart titled “Findability, Orphan of the Web Design Industry”. I decided to publish some tips on how to write for usability and findability on the web. The points I’ll make are pretty common sense, but can act as a checklist for your writing:

• Users instinctively scan the page for visual cues. No one reads every word on every page of a website, especially when they are looking for something specific. Instead, they look for things that will help them find what they are looking for. Headings, bold text, images, icons and navigation items. The search feature of a website is also important in the navigation of a website and shouldn’t be neglected. Organize your content into bite-sized pieces and add headings to them. Bold any key phrases in your content that enhances the meaning of your passage.
• Users will at most read the first paragraph of a section before deciding to move on. If a user thinks they are getting close to the information they want, they will decide whether to stay where they are by reading the first few sentences of that section of your web page. Many successful websites take the journalism approach to writing content. Take the bulk of your content (80%) and summarize it in the first paragraph or two of your copy. Following that, write the rest of your content in descending order of relevance.
• Users prefer Prose over Poetry. Many writers put on their writing hats when they get ready to draft web copy. Users are not reading a business website for entertainment. They are looking for information, quickly and simply. They want to be spoken to in their language and directly, not to have to digest the meaning of what the see on a web page. Write directly and succinctly. Users want you to get to the point, so do it. Steve Krug, an expert in the field of website usability, recommends everyone should “write your content, reduce it by 50% and then reduce it by 50% again.” The rule here is to get your meaning across in the shortest way possible. Use an active voice as much as possible and avoid unnecessary modifiers (“Starbucks serves an inspiring beverage which brings tears of joy streaming down my face.” vs. “Starbucks makes a great cup of coffee which makes me happy.”).
• Avoid unnecessary jargon. Peppering your content with overly complicated jargon presents another obstacle to understanding. That’s not to say that jargon should never be used, it is quite necessary. The idea here is to use it where necessary and maybe include a glossary somewhere on the site that helps explain the term to the layperson.
• Bullets are good. When being presented with a multi-faceted concept, a bulleted list (or any kind of list for that matter) will help the reader scan the information more quickly. Having to wade through lists of information in paragraph form creates an unnecessary obstacle to findability. Use lists when possible. Lists increase people’s ability to scan the content. Also, the act of making lists forces you to keep your thoughts organized and to the point.
• Exploration should be encouraged. Once a user has what they want, they have an important decision to make: what do I do next? A site that encourages exploration gives the visitor more of what they want, that valuable nugget of information. Additionally, the longer users visit a site, the more confidence they have in the site’s owner, the more likely they will come back (user confidence is directly proportional to profit). Encourage exploration. If you refer to a topic that is covered somewhere else on the website, be sure to provide a link to that page. You may want to add a list of related links at the bottom of your content page. Make it a point to help your visitors succeed.

Remember, the more you empower your visitors to succeed, the more confident they are in the fact that you can deliver the goods. Good content writing helps create that confidence.

Granted, typography is an important thing with our new site, absolutely, but good typography is not enough. You need a solid information hierarchy. Let’s take the following example:

This might be the kind of information you might have if you were going to review a book. If you look carefully, you can figure out the relevant information. You need to think about it a bit, but you can get it. From the type point of view, the font is large enough and there’s ample line spacing. Good? We can make it better.

The idea behind information hierarchy is to create contrast between the bits of information so that they are: A) differentiated and B) easy to pick out when you have repetition. Ask yourself the question: what bits of information are the most important? In the above example, definitely the title of the book and the written review. The author is next and the ISBN numbers are less important. So, to create the hierarchy, we change the type treatments for the different data elements. The title and review are most important and get the boldest treatment. The author is next and the ISBN numbers last (but not least).

So let’s look at the same information with a hierarchy:

Here we increased the understanding (and therefore the usability) by using design elements to create a hierarchy. More specifically, we used color and size to let the viewer know that the two most important parts of this bit of data are the title of the book and the review. The rest is still there, but not quite as important (the font is smaller and the color is light gray which makes it seem less important). When you use this scheme consistently throughout data, you’ll create a repetition in the presentation which increases usability in the long run.