I Just Need Someone to Make Me a Website!

Web Design, Web Development Comments Off

“Hey man, I have this awesome new idea for a company!!! Its gonna be like a Facebook/Twitter/MySpace/Google/Etrade/etc. only better. I just need someone to to make a website for me, you know, cause I don’t know too much about computers. Anyways, I know you’re good with programming and stuff, so you in?”

Anyone who has ever worked as a developer has undoubtedly had more than a few such proposals thrown their way by friends, family or even random strangers they talk to on the internet. Their idea will totally revolutionize the way we do things on the internet, but is so simple that making it should be a snap. Unfortunately, these people are not only ignorant about the technology, but most of the time lack any knowledge of the field in which they plan on making said riches. I myself have a monthly ceremony where one of my friends or acquaintances sits me down and very excitedly explains to me their great new idea, how it will make millions by selling it to Google (it’s always Google for some reason) and how they just need me to write the code “real quick.” The most recent such proposals included a stock trading site and a Pandora like site that “does not suck.” After listening to their proposals, I usually spend an hour trying to explain to them why its not going to happen before completely giving up and telling them I am simply too busy to be part of their new capitalizing venture. Lately I have been getting hit with an increased number of these proposals so I thought I might take a couple of minutes and quickly jot down a few facts all you eager entrepreneurs should know about programming and the web.

How Websites Make Money

Before I go go though the list of reasons you probably should not be starting a website business, let me go over one other very important concept: revenue generation. Unless you’re making a site about your cat, the goal of your site is to make money. If you are not actually selling a product, like shoes or tennis balls or frozen lumpia, there are a few ways that online businesses can generate money. First, and what seems to be most popular, is to give away your products and services for free but gather user information and sell it to companies for advertising purposes. Facebook, Twitter and Google all operate on this business model. In point of fact, you are actually the product they are selling, and their services are just how they get you to voluntarily participate. Another popular type of business plan is to sell subscriptions. Sites like Pandora, Netflix and Flickr provide premium services for a nominal monthly or yearly fee. This type of business plan is also very popular, and profitable, for the sites dealing with, lets just say adult entertainment. Other sites generate revenue by charging “as you use” fees. Craigslist is a perfect example of this as they only charge you a fee if you post a job ad, otherwise their site is completely free.

No successful website ever is built on the notion of being bought out. Sure, one of your long term goals can be to sell a product to competitors, but why would a competitor buy a business whose profit plan is to be bought out? Web companies buy other companies for two reasons. One is to absorb the established user base and the other is to acquire technologies that will be cheaper than licensing or redeveloping. Both of these have only one goal: to increase the traffic and overall user base of their site.

The most important part in generating online profit is having a large user base, so unless you have millions of users or a some amazing new algorithm that millions of users will want to use, you’re not getting bought out. In other words, the only sites that get bought out are sites that have already succeeded on their own.

If you want to start a site that will compete with another established site the most important thing to know is what you will do different. Recreating a service that already exists (and if you’re not good with computers will be much worse) will not attract any users to switch over. A new competing site has to be different enough to carve out its own niche before it has any chance of succeeding. For this you need to invest lots and lots of money.

Websites Are Not Cheap

Web businesses have always been more popular because of their low cost overhead. You don’t need a store front, you don’t need sales people, and most times you don’t even have a product you need to store and sell. Most of the technologies you will use are open source and won’t cost you a dime to use. Hell, you don’t even need an office. You can work from home or the ever popular coffee shop. All these things are great, but websites have a lot of other operating costs that people seem to overlook. The domain name registration, DNS hosting, server hardware (or cloud/co-location/hosting fees), bandwidth and the most important of all the people you have to pay to develop and maintain the site. The more popular the site gets, the more expensive it gets and the costs go up very very quickly.

Things whose costs are negligible, or even free, when first starting out can cost a lot of money as soon as you start getting decent traffic. DNS hosting, for example is usually included in the yearly $20 fee you pay for your domain name, but when your site starts attracting users, it can cost you thousands of dollars per month. If you don’t have the cash to keep a site running when it gets popular it will quickly lose its user base and you will be done.

The cost of the people is the biggest cost you will have to cover. Websites are complicated and it takes people with genuine smarts and talent to create something that works and will generate you money. These kind of people tend to be very smart (and usually already employed) and won’t work for nothing. A decent developer can make anywhere from $60k to $130k at a normal 9-5(ish) job. A start-up usually means 14-18 hour days and working with the insecurity of being fired any moment. The only time developers will ever work for free, or as an investment, is if they’re doing it for themselves. Wanting a programmer to build you a site in exchange for future compensation is the same as asking a construction company to build you a house now, and when the market improves you’ll sell the house and split the profits. It’s not gonna happen.

Websites Are Not Simple

As you may know, websites are actually amazing, incredible yet horribly complicated pieces of technology. It may appear simple enough to us, but billions of dollars and man hours have already gone into figuring out how to build sites that do what you want, do it fast and do it reliably. There are many different aspects of a website: the hardware infrastructure, the data stores, the application itself and the user interface. There are of course non-technical aspects as well, such as marketing, management, etc. but I’ll just focus on the technology right now.

Hardware infrastructure consists of servers and services that run the site. These are simply computers that have to be installed, configured, automated and maintained that will host your website. Starting out, you can pay to have another company handle that for you by hosting the site on a cloud or paying for a server at a data center, but as your site grows, chances are you will need to invest into your own hardware and people to take care of it.

The development of the data stores, web application and user interface all come together to work as your site, but require months, if not years of development to get off the ground and even then require constant work. This too can be outsourced, but its not cheap, and ends up costing a lot more than just hiring developers.

Websites Are Not Static, They Evolve

The first thing I try to explain to my dear friends and acquaintances when confronted with this kind of proposal is that you don’t just build a website and that’s it. A website is never actually done. It is a piece of code that constantly keeps evolving. It has to incorporate new technologies and concepts to meet the exponentially growing standards of its users. I will put it this way: think about what you could do with Facebook 5 years ago, 3 years ago, a year ago and now. Facebook has changed its look dozens of times each time improving its usability and adding new features. Its user base only keeps growing.

Sites also need to keep increasing their response times. Every day the public demands to do more, faster than ever before. I keep getting reminded of a Louis CK bit on the Conan O’Brien’s show (YouTube Link) making fun of how fast our expectations go up.  A website that does not constantly keep up, crashes and burns real quick.

Websites Need Direction

The most important aspect of a website is having direction and passion. The person in charge needs to know everything I have describes so far and much much more in order to know what to build. If you look at the most profitable tech companies of all times: Google, Microsoft, Apple, Facebook, Cisco, IBM, HP, Dell. The one thing all these companies have in common was that they were started by techies who cared about their product more than they cared about their profits. These are the kind of people who had enough passion for the technology to stay up all night writing software, building computers or solving equations just for fun. To have an idea for a website is easy, but to truly deliver it you have to have the passion for the work and brains to pull it off. If you’re coming to me to make it for you, it means you have neither.


Building and maintaining a website is not as simple as it seems. It takes lots of time, money, brains, talent and passion. If you don’t have most of those, go start a banana stand instead.

JavaScript: You’re Doing it Wrong! – The Video

JavaScript, Web Design, Web Development Comments Off

Hi all,

I did a talk recently for my group about some common JavaScript mistakes that I kept seeing over and over again and a bunch of people asked me to web cast it, so I recorded it and, well, here it is. Its not great quality, but its watchable. I also added a link at the bottom for the PPT presentation. When I have a bit more time, I’ll post the slides with explanation here.

Download the PowerPoint presentation.

6 Common CSS Misuses

CSS, Web Design Comments Off

Since the inception of the internet, there has always been a struggle between HTML (Hypertext Markup Language) and CSS (Cascading Style Sheets). Clean and proper HTML is very structured and semantically organized, but not very pretty. Creativity was never part of the HTML specification, which is where CSS comes in. CSS aims to take this structured information and present it more aesthetically and in a more personal way to the user, but designing things that look nice does not always work well with the HTML box model and more often than not CSS is misused to get things to render the way you intended. CSS is flexible enough that you can use and misuse it in a variety of ways and things will probably come out correctly, but it can impact the performance, scalability and flexibility of your site in the long run. Here are 6 most common misuses of CSS that I have found in no particular order and some suggestions how to avoid them.

1. Reset All (*)

When designing a website, you want it to look the same for every user, regardless of browser choice. Every browser has its own built in stylesheet for how to render each HTML tag. Unfortunately these stylesheets are almost never identical (especially when dealing with IE) and can lead to strange rendering behavior. To deal with this it is a common practice to use what are generally known as reset classes, but a very common misuse is the dreaded RESET ALL.


* { border: 0; font-size: 1em; margin: 0; outline: 0; padding: 0; }

I cannot stress how wrong this is. DON’T EVER EVER EVER EVER DO THIS! What this simple and seemingly innocuous statement does is give every element a default margin and padding of 0. It is true that we want to reset most elements down to a baseline (be it a 0px or Xpx margin/padding/border etc) but the blanket statement will also reset thing you probably did not intend on resetting and you will be stuck redefining elements in the worst way possible. Example of this would be lists and blockquotes. These tags which we take for granted would all of a sudden lose all spacing and would look like crap.

Instead of creating this headache for yourself, list all the tags you want to be identical and reset them. Here is the definition I use in my work. Feel free to use it yourselves.

html, body, div, span, applet, object, iframe, 
h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, 
abbr, acronym, address, big, cite, code, del, 
dfn, em, font, img, ins, kbd, q, s, samp, 
small, strike, strong, sub, sup, tt, var, 
b, u, i, center, dl, dt, dd, ol, ul, li, 
fieldset, form, label, legend, 
table, caption, tbody, tfoot, thead, tr, th, td 
     { border: 0; font-size: 1em; margin: 0; outline: 0; padding: 0; }

2. Styling ID’s

<div id="header"> ... </div> 
#header { font-size: 2em; height: 100px; padding: 10px; width: 800px; }

While there is technically nothing wrong with applying a style to an ID tag, it does remove any performance benefits that a style sheet provides.Here is what I mean. When your browser requests a website, it downloads both the HTML markup and the CSS stylesheet to your computer. Then as it renders the page (top down mind you) the browser searches the CSS stylesheet by class and loads the style definitions into memory. When a style class is reused, it happens instantly allowing the page to render faster and without additional resources. Unlike classes, ID tags can only be used once per page, meaning that applying a style by ID will never get reused and provides no benefit. If you do want to style just a single element, just add a class to it, and add it as a class style definition. It will render exactly the same, except if at any point in the future you want to add another element with the same properties, you will be able to. Another thing you can do is partition the overall style into subclasses so they are more applicable. Here is an example:

<div id="header" class="bigtext container header"> ... </div>
.bigtext { font-size: 2em; }
.container { padding: 10px; width: 800px; }
.header { height: 100px; }

In this example, I partitioned the the style sheet into 3 classes. One for typography, another as a generic container and the last as specific styles for the header element. Even though this particular element might never repeat, it is conceivable to have multiple elements that require large font text or lots of elements that have a set width and padding as the header element and partitioning it this way will allow for most of those to be reused. Be very careful not to over-partition though by creating overly specific definitions. Read on.

3. Overly Specific Class Definitions

<div>Regular content....</div> 
<div class="red">Sale Sale Sale!!!!</div> 
<div class="red">ERROR!</div> 
.red { color: red; }

One of the greatest benefits that using CSS is being able to change the look and feel of an entire site simply be changing a few parameters without ever touching the HTML. By overly specifying definitions, you completely miss this point. The above example has an error and a Sale statement that both need to be rendered in red as to stand out. If we ever wanted to change the color the sale statement is rendered, we would no longer be able to just change the CSS definition as that would cause all elements with class red to change color, and would also make it nonsensical to have class red render another color. Instead we would have to either edit the HTML and change the class name to ‘blue’, for example.

Instead try to create a set of classes that are both descriptive and reusable. In the above example we have 3 types of text that would exist on the site: regular contextual text, highlighted text and error text. We can then create several reusable classes to work:

<div>Regular content....</div> 
<div class="highlight">Sale Sale Sale!!!!</div> 
<div class="error">ERROR!</div> 
.highlight { color: red; } 
.error { color: red; }

By using this method, we are not tying the class names to the values that are set and while still having reusable classes.

4. Misuse of !important directive

.foo { padding: 0px !important; }

CSS is a very hierarchical language. It is written so that definitions that come last overrule those that come before. Perfect example:

<div class="red blue">Foobar</div> 
.red { color: red; } 
.blue { color: blue; }

In the above example the text Foobar will render blue, but if we switch the order of the CSS class definitions as so:

<div class="red blue">Foobar</div> 
.blue { color: blue; } 
.red { color: red; }

then the text will render red. The only exception to this rule is the !important directive. Using this directive means that nothing can overrule this definition. If we make the red class !important, than the text will always render red. Only way to overrule it at that point is to make the overruling properties important. That is where the problem comes up. Once you start using the !important directive, sooner or later you are going to be using them to over rule each other and then you got a huge mess. The other problem with them is that if you have the same class defined in different places (a common practice when splitting typesetting and layout) having one somewhere can lead to many frustrations and countless hours trying to figure out why things are not working as expected.

<div class="red blue green yellow orange purple">
 I will always be dark blue.
.red { color: red; }
.blue { color: DarkBlue !important; }
.green { color: green; }
.yellow { color: yellow; }
.orange { color: orange; }
.blue { color: LightBlue; }
.purple { color: purple; }

As you can see from that example, it does not matter how many classes have been implemented and assigned and in which order. It does not even matter that we overrode that class name itself. I view the !important directive as a hack instead of a feature. If you are using it, then you are hacking around something that should have been designed differently. I have never had a case where I absolutely had to use this directive and re-arranging elements and classes could not be done. Well, there was one case where a 3rd party plugin was breaking my layout by breaking a few of these rules so I had to use it to override it.

5. Problem with catch-all definitions

.header * { line-height: 1.5em; } 
.footer div { font-family: Arial; }

Catch-All tag definitions are really powerful for setting a baseline style in your design and the fact that you can chain them provides even more flexibility, but they can be dangerous. Styling a tags this way will apply that style to EVERY instance of said tags. It is the catch all we talked about earlier and sometimes it can lead to writing more code to handle the problems when proper planning could have helped. More often than not, I have seen this used as a way to override the typesetting in a child element, except 3 lines down there is another child element overriding that one. For example:

<div class="header"> 
 <h1 class="original">OTHER INFO</h1> 
h1 { color: black; font-size: 2em; } 
.header h1 { color: red; font-size: 3em; } 
.header h1.original { color: black; font-size: 2em; }

What we get then is repeating classes and code that really don’t need to be there. Instead of being lazy, just create one baseline and use classes to override properties you want to override. Example:

<div class="header"> 
 <h1 class="title">TITLE</h1> 
 <h1>OTHER INFO</h1> 
h1 { color: black; font-size: 2em; } 
.title { color: red; font-size: 3em; }

By just changing how I organized my classes I was able to get rid of one class definition and now don’t have to worry about if the title class will affect anything else it should not.

6. Inline Styling

The last, and one we are all guilty of is using that tempting inline style tag. Sometimes its just easier and faster to add the little style tag to your element than open your stylesheet, find the appropriate place, name it the appropriate name, etc. After all its just one little element.

<div style="padding: 10px;">I will always be 10px!</div>

I have done this. We have all done this. Hell, I still tend to do it every once in a while. Even though there is technically nothing wrong with adding a style, it does break pretty much every benefit that style provides. It is the equivalent of styling an ID tag, styling too specifically and inline styles override almost any stylesheet definition.

If you are working with multiple developers, or at some point expect to hand over the code to someone new, having a mix of stylesheet and inline style will cause a massive loss of time and energy. Just say no and do it properly.

Powered by WordPress | Theme by Bojan Beran Feedburner Posts RSS