Less is More

A guide to simple, pragmatic,

user-centric web development

by Leo Utskot

Where otherwise not noted this work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative
Works 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/us/
or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

1
Contents

Introduction 3
What is Copyle Solutions?

It’s all about the people 4

e Team
e Client
e User

Content is King 7
Information architecture

Function before form 9

Make the choices for the client

Layout 11
Wireframes
Grids are Good

Design 14
Get a personality
Logo, Colors and Fonts
Paper Please
Rules of thumb

Start building 17
Framework
Small team
Quick Beta

Tools of the Trade 18

2
Introduction

is guide was written by Leo Utskot with the help of several colleagues from Copyle
Solutions and other friends in the business. e motivation behind writing this
document stems from years of struggling to find a good method for web development
which balances the need for a concise documentation while still remaining
understandable and manageable for the client. e method is a work in progress 10
years in the making and is based on a number of different methods I have come across
during my career as well as my personal experience. e object of the exercise is to help
others overcome myths and bad advise commonly advocated by people wanting to make
a few extra dollars by complicating the process of web development.

Less is More is not a framework or formal soware development model and I also realize
that this guide probably works better for smaller companies which have less bureaucracy
and hierarchy.

What is Copyle Solutions?

Copyle Solutions in an umbrella name for a small group of companies focused on Free
Soware and includes Copyle in Mexico City and two other Copyle companies in
Oslo and Bergen, Norway. Web projects in all the Copyle companies successfully
employ the Less is More method on a daily basis.

3
It’s all about the people

e success of a web development project largely depends on the understanding of the

roles and personalities of the people involved. is is the single most important lesson of
my professional career and I can not stress it’s importance enough. Fancy computers and
new programming languages can provide a small boost in productivity, but failing to
meet the needs of the end-users, or not understanding the motivation behind you clients
decisions will result in total failure.

According to recent studies1 , about one third of IT project fail to meet their
expectations, oen running over the planned timeframe, not delivering the features as
promised or even resulting in a complete failure. is results is hundreds of millions of
dollars lost for our clients and loss of face for us working in the industry. e fact that
important systems still operate perfectly even though they are written in ancient
languages2 running on 15 year old hardware has made me come to the conclusion that
most of these soware projects fail because of human error, not technological
shortcomings. is guide will therefore focus on human interaction and practical
communication tools which help to get the job done correctly and on time.

e Team
As in sports, each member of the team assigned to a project needs to support the others
in order to win. A typical web development team will consist of a project leader, a
salesperson and one or more of both programmers and Client
designers. ere may be overlapping positions and
specialists involved, but generally speaking the
organization is similar to the diagram to the Leader Salesperson
right.

Programmers Designers

1 e Standish Group CHAOS Report (http://www.projectsmart.co.uk/docs/chaos-report.pdf ), as well as studies by Gartner and KPMG all
have similar finding. Some put the figure higher, but the conclusion is the same, IT project failure rates are staggeringly hight compared to other
industries.

2 COBALT. Fortran, etc

4
If you don’t have these roles clearly defined or are missing one of the roles by for example
having the salesperson share the role of the leader then I suggest correcting this before
starting the project. is has to do with issues of loyalty and motivation explained below
and not with workload or how many hours you can bill.

e salesperson is primarily motivated by selling more projects to the client by assuring

that he is happy with the work. A salesperson will always try to get more work done, in
less time in order to please his customer. From the client’s perspective the salesperson is
the “good guy” while the rest of the team oen feel the opposite.

On the other hand the project leader needs to balance the promises made to the client
with the well-being of his team. I have seen the result of this not being done and I assure
you that mutiny can be a very ugly thing. From the client’s perspective the leader is oen
the “bad guy”, reluctant to made changes or compromises to the plan since he is acting as
the captain and protector of his team.

Accepting, understanding and utilizing these trait is one of the easiest ways of keeping
the client and the team happy, which will ultimately result in more sales and a better
product. To give a concrete example imagine that Juan (leader) and Pedro (sales) go to a
meeting where the client asks for a fairly logical and simple feature. e best strategy
will be that Juan is against the change to avoid having to move the plan and press his
team to work faster. However, Pedro’s attitude should be that of diplomacy, focused on
charging more, asking for more time or giving the feature as a favor if it’s convenient. In
any case, if managed correctly everyone will be happy; the client will be content with the
deal, the leader will have protected his team and the salesperson has either made a new
sale or will have a favor to his advantage for later use.

e Client
In, web development as in all other industries, the client is God. e problem is that in
this case God oen doesn’t quite know what he wants and you most likely need to help
him understand new technology and concepts. I describe communication tools which
can help us with this issue in the rest of the book, but it’s important to first understand
the objective of the project for the client. As soon as you have that objective, be it selling
a new product or saving money by automating a process, many decisions become
obvious. Instead of just following orders you can help your clients by making suggestions

5
and recommendations. It may sound a bit like a scene from Office Space3 , but I even
recommend to reduce the objective to a single sentence, print it out and hang it on the
wall there the entire team can always see it.

Another important point is that the client oen has a lot riding on the project and may
even lose his job over it. Clients oen need frequent feedback and may get nervous at
the end of the project. Make sure you don’t elevate their expectations at the start of the
project so that you don’t make this worse. By 50% into the project you should at least
have something “clickable” for him to see. Weekly status meetings or a simple e-mail
with the summary of the progress and problems of the project is always a good idea.
Don’t exaggerate problems, but don’t avoid talking about them either. When bringing
bad news to the table, have the salesperson present to make sure he can help calm down
the client.

e User
Even if it is the client who decides, the decisions should always be made with the end
user in mind. During the project always try to talk and listen to them. If the project is to
make a public website then be sure to understand the type of user which will most likely
to use it. What kind of computer and connection do they have? What other sites do
they use and how do these sites work?

If the project is to be used by a select group of users then make sure to actually talk to
them. Arranging a formal focus group where the users take time to explain how they
work and have the chance to answer questions is ideal and costs very little. If this is not
possible, at least avoid accepting specifications without verifying it informally via an e-
mail of phone conversation with the end user, who oen does not see a business process
in the same way as his boss does.

During the testing phase it becomes even more important to involve actual users. As
soon as possible get a beta version of the system out the door and into the hands of real
users. Programmers make the worst testers since their minds are hardwired to think in a
logical fashion, a programmer will never input a letter in an input field which is
expecting a number and know very well that they should be patient while waiting for a

3 Brilliant movie all IT people should see: http://www.imdb.com/title/tt0151804/

6
reload and will not hit the stop/reload button. Real users will oen find bugs by doing
totally unexpected things.

Content is King
Content is what makes up the “meat” of the system and doesn’t have to be in the form of
an article or news item. Content is any information that comes in or out of the system
and it’s important to begin defining a web development by looking at content. Too
many websites are created based on a preconception of how the design should look, at
the cost of usability. In the case of an online magazine check how big the articles are and
how many pictures they plan to use in each one before deciding on the number of
columns in the design and how much space should be dedicated to banners. Or, in a
system to manage a human resource database start by getting an example of the current
report before choosing a chart library. It’s also important to always ask for physical
examples of any printed output.

Information architecture
Aer you’ve seen all the content, structure it to make sure you’re not leaving holes and to
help the client get an overview of the project scope. By holes I mean that for example in
a business process you need to avoid dead ends where the user is stuck and can’t
complete their task. Make sure there are helpful messages and ways of correcting human
error throughout the system. On a NAVEGACIÓN NIVEL 1 NIVEL 2

website which provides information Quienes somos

Quienes somos
(contenido normal)

make a tree structure and check that it’s Anúnciate

Anúnciate
(contenido normal)

balanced according to priorities. If you Suscríbete

Suscríbete
(formato de contacto)
Confirmación

want to sell a product don’t put more Contáctanos

Contáctanos
(contenido normal)

information about the company than Noticias

Última noticia
(contenido normal)
Otra noticia
(contenido normal)

information about the product. Términos legales

Términos legales
(contenido normal)

Revista
Publicación Ficha Ficha comercial

I also recommend spending time on the Publicidad

Libro
(portada, descripción) (PDF)

Tarifario
(PDF)

presentation of the information Spread

ARQUITECTURA (varios)
www.editorialmapas.com
architecture. Avoid simply making an a
series of different sized squares with Example of a tree structure
overlapping arrows in Visio. If you are not good
at making things presentable, get a designer to clean up a hand-drawn sketch.

7
Avoid UML like the plague. I have never seen an actual client understand it and I have
come to the conclusion that updating hundreds of little stick-figure drawings every time
there is a change is a great waste of time. A client will always study with more attention
one or two professionally produced diagrams than a hundred UML files. is goes
against what most universities and large consultant companies teach, but in my
experience they don’t help make better sites. ey may however make more money for
the companies hired to develop.

e very best examples I’ve seen of good diagrams come from XPLANE Corp4 :

Copyright held by XPLANE Corp. From: http://www.xplane.com/#/publications/

Some of our examples can also be found on the Copyle Solutions website and you are
welcome to download and modify them for use in your own projects.

As a practical tip there is no soware as flexible and easy to use as a pencil and a few
sheets of paper. I normally begin designing on paper so that I can get a clear visual
representation of the layout and then I create the digital version when I’m certain where
all the pieces fit in. Avoid fancy 3D effects, they are nothing more than gimmicks

4 www.xplane.com

8
created to sell the latest office soware and provide no additional information to the
viewer. Limit yourself to a few basic colors and shapes and stick with the style
throughout the entire project. Make sure you leave white spaces in the diagrams in order
to avoid cluttering and interrupting the logical narrative.

A wonderful book to read on the subject is Visual Explanations: Images and Quantities,
Evidence and Narrative5 by Edward Tue6. I recommend reading everything you can
find by Mr. Tue as he is one of the true masters of the field. His website
edwardtue.com also contains examples and a lively forum where people discuss how to
better represent ideas and information using visuals.

Function before form

Now that you have understood the objective of the projected, gathered and studied all
of the content creating a clean and concise diagram of the information you are ready to
begin talking about how the system should function. is is a logical continuation of
organizing the input/output elements and must again come before you begin defining
how the final product should look. is step has proved to be the most complicated to
standardize because the functions in a CRM7 system are so different than that of a
product website. Almost all information can at the end be described as a series of
interrelated tables and fields, but I have yet to find something similar for the functions.
UML fans will at this point be screaming about how their method resolves this
problem, but I remain unconvinced that my clients will understand the UML system. I
have tried huge logic charts and stacks of wireframes, but none has been as good as my
current motto: “Just describe it”. I think the soware industry sometimes believes itself
so complex that we begin to forget about the most basic tools of communication, the
written word.

My opinion is that the best method for defining functionalities is to simply describe
how the system will work in pain, unambiguous narratives. Avoid being creative and
always use the same words to describe the same elements even if it becomes slightly

5 http://www.edwardtue.com/tue/books_visex

6 http://en.wikipedia.org/wiki/Edward_Tue

7 Client Relationship Management

9
boring (we are not trying to beat Harry Potter in readability). A typical example could
be:

“If the Contact Us button is clicked the user will be presented with a form containing
the following fields: Name, E-mail, Subject and Comment as well as a Send button. All
fields must be filled out and the E-mails format will be validated. en the Send button
is clicked the user will be presented with a confirmation message.”

It’s simple, easy to write, easy to understand and avoids a million details that your client
could not care less about.

Make the choices for the client

With respect to the example given above what happens if there is a problem and the
message can not be sent? How big should the Name field be? ese are valid questions
which should be answered, but they are not questions that a client needs to think about.
We, as web developers need to always assume that things may go wrong and we should
always create clear and concise error messages for all occasions. e size of the field
should be long enough to include most common names and a good suggestion is to
simply look at what Amazon or Google uses (they have armies of people researching
these things and they sites seem to be working OK). Keep in mind that most clients are
quite happy to deal with less decisions and will appreciate that you make them for them
as long as you make good choices. is sounds much harder than it is and in my
experience it takes less time to do a little best-practice research or a few experiments than
it does to review a 100 page, minutely detailed document with the client and his
advisors. e web has been around long enough so that many functionalities have been
solved in standardized ways. is does not mean that you can never invent something
new or improve an existing solution, but you as the web developer are the expert and are
the most qualified to do so.

Again, spend time on the document, make sure it is well written and without errors. If a
small diagram can help you explain something feel free to include it, but make it as short
as possible. Our typical functionality documents are 10-20 pages long and seem to work
very well for most clients. ey can be read in 30 minutes and can quickly be modified
as needed. Anything requiring larger documents should probably be divided into sub-
projects.

10
Layout

Defining how the information should be laid out across the screen is not only fun, but it
is typically the first step where the designers become involved. A layout is also the first
document which lets the programmers actually begin to wrote code, even if it is just
style sheets and html. Focus should again be on the end-users and the content, but you
can begin to allow the esthetics to play a part in the discussions as well.

Wireframes
Wireframes are the basic communication tools used to define layouts. Wireframes
should be as plain as possible and should not include graphic element other then
perhaps the logo. It is important to let the client see and understand the structure of the
pages without getting bogged down in whether or not the colors are bright enough or
the font is legible. is is of course more true in some projects than other. Again my
personal preference is to start by using pencil and pen to sketch the wireframes before
using a graphic application to polish them. I also recommend avoiding spreadsheet
programs and word processors to create the wireframes, ideally one should use a vector
based drawing program such as Illustrator, Freehand or Omnigraffle to avoid
frustrations with the limitations of the soware.

11
I’m sure excellent examples can be found online, but in this case I’ll use a Copyle
example to illustrate a wireframe. More can be found on the Copyle Industries website.

is particular wireframe was used during Sitio de Travesias

Wireframe
Contenido Generico v1.0

the project to create a website for the Inicio | Colaboradores | Contacto

Full 468x60 px Buscar Ir

Mexican Travesias travel magazine

Buscador Avanzado

Crónicas Reportes Escapada Compras Comida Arte Guía Rápida Rutas Concierge Portadas

Yukón y Alaska a Relacionado

currently online at revistatravesias.com. 1 #65

fond
Por: Megan Son
Foto: Laurent Granier
4
Título de liga

Nombre de galería
5
Si el escrito Jack London Imágen de artículo Nombre de video

Although the design phase moved some y decentas de miles de

otros aventureros
salieron en estampida
Algo del comentario

Tags: alaska, yukon, oro, jack

2 ¿Qué hay de nuevo? hacia estos remotos y london, trineos, frio, bosque
gélidos territorios...

of the elements around, the basic layout Título de artículo

Lorem ipsum dolor sit
amet consectateur Full 468x60 px
Suscripción
Nombre
nonummy lorenzino.
Interdum volgus vidett.
6

of the content and especially the priorities Título de artículo

Lorem ipsum dolor sit
amet consectateur
Lorem ipsum dolor sit amet consectateur nonummy
lorenzino. Interdum volgus videt, est ubi peccat. Si
veteres ita miratur laudatque poetas, ut nihil anteferat,
Email

Contáctame
nonummy lorenzino. nihil illis comparet, errat. Si quaedam nimis antique, si
Interdum volgus vidett. peraque dure dicere credit eos.Lorem ipsum dolor sit Foro
Travesias TV
of each element has not changed from the Título de artículo
Lorem ipsum dolor sit
amet consectateur
amet consectateur nonummy lorenzino. dicere credit
eos.Lorem ipsum dolor sit amet consectateur nonummy
lorenzino. Interdum volgus videt, est ubi peccat.

nonummy lorenzino. Si veteres ita miratur laudatque poetas, ut nihil Imagen 7

Interdum volgus vidett.

wireframe. Small red arrows are used to 3

Este fin de semana
anteferat, nihil illis comparet, errat. Lorem ipsum dolor
sit amet consectateur nonummy lorenzino. Interdum
volgus videt, est ubi peccat. Si veteres ita miratur
laudatque poetas, ut nihil anteferat, nihil illis comparet,
• CATEGORÏA - FECHA errat. Si quaedam nimis antique, si peraque dure dicere

point to specific items which are detailed Título de Evento

• CATEGORÏA - FECHA
Título de Evento
• CATEGORÏA - FECHA
credit eos.Lorem ipsum dolor sit
amet consectateur nonummy
lorenzino. dicere credit
Título de Evento eos.Lorem ipsum dolor sit amet
• CATEGORÏA - FECHA consectateur nonummy
Half Skyscraper
in the yellow area at the bottom and Título de Evento
lorenzino. Interdum volgus
videt, est ubi peccat. ipsum
dolor sit amet consectateur
160x300 px

nonummy lorenzino.
Título de imágen

almost everything else is done on black

NOTAS

and white. 1.
2.
3.
Número y portada de revisa que el usuario actualmente está viendo
Últimas 3 notas de ¿Qué hay de nuevo?
Listado de eventos para este fin de semana con Categoría del evento, fecha y el título del evento
Imágen
4. Los nombres son ligas a otros contenidos de los mismos autores.
5. Contenidos relacionado con iconos para mostrar que tipo de contenido es.
6. Formato de captura para suscriptores potenciales
7. Espacio para destacar información sobre Travesias TV
Banner

Grids are Good

Now that you have a good communication tools for the layout all you need is to know
which layout to use. e title of this section, “Grids are Good”, is borrowed from a
presentation with the same title by Khoi Vinh8 from subtraction.com. I’ve always used
grids to create layouts, but I’ve never seen it explained as clearly as in Mr. Vinh
presentation9 and I recommend that you all download and read it.

e basic concept is simple. e human vision is very good at lining up things on a

vertical or horizontal grid. If you need proof of this just look around at pictures hanging
on the walls. When you find one that looks crooked try to measure the deviation. Most
likely you are not only correct in that the picture is not perfectly straight, but the
variation is oen under one degree from perfect. In addition to this superpower, the
human vision can also see when things are spaced evenly which is why many graphics
applications have a special “distribute evenly” function built into them.

8 http://en.wikipedia.org/wiki/Khoi_Vinh

9 http://www.subtraction.com/pics/0703/grids_are_good.pdf

12
e essential problem to be solved when creating a layout is where to put each element.
If we start out by assuming that they should be aligned along a grid then the problem
becomes much easier to solve and much more pleasing to the eye. I can hear the
designers screaming about loss of creativity, but aligning elements along a grid does not
imply boring, it just gives us a good starting point. Not all elements have to line up
perfectly and the grid doesn’t have to be uniform in any way. As Mr. Vinh comments in
his presentation the ideal grid is 12 spaces wide since it can be subdivided in very many
ways (2x6, 4x3, 2-3-3-4, etc).

Start doing the grid by finding the largest fixed element (a big ugly banner for example)
and work from there. You’ll soon discover that element magically find their place. Also
make sure that you leave lots of margins in the grid to make sure that elements don’t
fight for pixels and everything has enough air around them to not feel crowded. If this
sounds very unscientific, go find a designer.

13
Design

Design is of course a subjective issue and depends a lot on the client’s taste. However
there are certain tips that can not only improve the web experience but also help
communication with the client. For further reading a lot of people will suggest reading
Jakob Nielsen10, but I personally feel that his line of thinking is too fixed on the
mechanical and not on the emotional side of using the web. Just as with cars it’s not only
about a clean dashboard and ergonomic seats, people want it to look and feel good as
well.

Get a personality
e first step in the design process should always be to find a personality for the project.
It doesn’t have to be very creative or complex personality, but something to guide the
rest of the process. As always, the personality should be based on the needs of the end-
user. If it’s a public site, look at who the audience is and what design they are used to
seeing. Use a best-practice study to see what the competition is doing and take a look at
other marketing material from the same client, even if it isn’t directly related. Get the
client to describe the design he is looking for with emotional words or even unrelated
things (Example: If your website was a movie, what would the poster look like?).

Hopefully you will end up with something that describes a general design style and will
define if the background should be light or dark, if the icons should be comic or serious
and if you are looking for interesting or straight to the point. “Light, serious and straight
to the point” is a perfect description of a website.

Logo, Colors and Fonts

Aer getting a personality the designers should try to hold back their creative energies
and define a logo (even if it’s just the online version of another logo), the palette of
colors and the fonts to be used in the design. is may sound a bit restrictive, but these
elements reflect so much personality that I feel it’s better to get them defined before
doing the rest of the elements.

10 http://en.wikipedia.org/wiki/Jakob_Nielsen

14
Even when you have the layout, logo, colors and fonts defined there are an infinite
amount of choices and variations available and it’s much easier to make incremental
adjustments when some factors are fixed.

is is a good example of and online identity guidelines document made by David
Almeralla11 from Atomo Interactive in Mexico:

%&'($I0&7:$;&#9$&2#1-&-8$+0&2#)&1#,

!"#$ !"#$%&'($)*+*
!"#$%&'($)*+*$&,$-"#$.*,-$/012(.#1-()$#)#.#1-$*/$*0'$3'(124$5-
,"*0)2$(66#('$&1$($6'*.&1#1-$)*7(-&*1$*1$())$7*..01&7(-&*1,4$!"#
%&'($)*+*$7(11*-$3#$'#6)(7#2$38$($,-(12('2$-86#/(7#4$5-$,"*0)2
()9(8,$3#$'#6'*207#2$/'*.$*'&+&1()$('-9*':$(12$,"*0)2$1#;#'$3#
'#30&)-<$'#2'(91<$'#=7'#(-#2$*'$2&,-*'-#24
$AB$..
)*+*$,&-#
!"#$ %&1&.0.$,&>#
4?@$&17"<$AB$..$9&2#$/*'$6'&1-$(12$A@C$6&D#),$9&2#$/*'$9#3

)*+*$./0123&*4$5*4#3

!"#$ E1$#D7)0,&*1$>*1#$&,$-"#$3)(1:$,6(7#$*'$.('+&1$,0''*012&1+$*0'
)*+*4$FD7)0,&*1$>*1#,$+&;#$*0'$)*+*$3'#(-"&1+$,6(7#$/*'$.(D&.0.
;&,&3&)&-84

$$$$G$!"#$)*+*$.0,-$,-(12$7)#('$*/$(18$*-"#'$#)#.#1-,4
$$$$G$H'#(-#$(1$#D7)0,&*1$>*1#<$#I0()$-*$-"#$"#&+"-$*/$-"#$)#--#'$
J%J$&1$%5KE<$*1$())$,&2#,$('*012$-"#$)*+*4
$$$$G$L*$*-"#'$+'(6"&7$*'$-#D-$,"*0)2$(66#('$9&-"&1$-"#$#D7)0,&*1$
>*1#4

)*+*$6*1*'3
M"#1#;#'$6*,,&3)#<$*0'$)*+*$,"*0)2$3#$6'#,#1-#2$&1$%&'($N)0#
7%,$>?@6 7%,$A>B6
OP%Q$R?BHS$(12$T'#8$OP%Q$UR@HS$*1$9"&-#<$9&-"$)#+&3&)&-8$(12
7)('&-8$-"#$/&',-$6'&*'&-&#,4

!"#$ 7'#8#''#9$!'#(:;#4:$(49$<=:&*43
!"#$6'#/#''#2$)*+*$-'#(-.#1-$&,$%&'($N)0#$OP%Q$R?BHS$(12$T'#8
OP%Q$UR@HS$*1$9"&-#4
!"#$ E$9"&-#$)*+*$'#;#',#2$*0-$*/$(1*-"#'$7*)*'$*'$6"*-*+'(6"$&,
(77#6-(3)#4$V*9#;#'<$-"#$+0&2&1+$6'&17&6)#,$*/$)#+&3&)&-8<$7*1-'(,-
!"#$ (12$7)('&-8$.0,-$3#$(66)&#2$&1$())$7(,#,4

Identity guideline for Mira Companies

Not licensed under the Creative Commons license, all rights reserved.
Paper Please
is article talk a lot about the developers using paper and pencil, but during the design
process I also try to use these tools together with the client. e formal term is “Paper

11 dalmeralla.blogspot.com

15
Prototyping” and wikipedia has an article12 about it. e basic idea is to bring paper and
pencils to a workshop type meeting where the designer(s) can sketch in front of the
client in order to allow instant feedbacks from everyone including the client. I’ve not
always been able to use this technique, but when I have, it’s been quite effective. A good
suggestion is to print out a empty browser window beforehand so everyone remembers
to obey the general shape (hint: it’s not vertical).

Rules of thumb
• e standard size of a monitor is today 1024x768 pixels. e browsers windows is
slightly smaller due to the scrollbar and toolbar. Even if the html is done properly and
can scale, there is an ideal size for any design.

• People do not like waiting for things to load so avoid large files as much as possible.

• Text is less legible if the contrast between the background and the font is low. Avoid
invisible text please!

• e menu should generally be placed at the top horizontally or to the le vertically.
Being creative with the placement of the menu can cause confusion.

• Make sure to let the client see the design on a computer screen, preferably in a few
different resolutions. It may look very pretty printed out and foam-boarded, but that
does not represent actual use of the design.

• Generally speaking, programmers are the worst designers in the world. (e opposite
can probably also be said)

12 http://en.wikipedia.org/wiki/Paper_prototyping

16
Start building

Now you can finally start building. Hopefully no more than one third of the project’s
time has been used before you get to this point and hopefully you will not have to make
too many changes to all of documents you have produced. However, please do not
assume that you can focus 100% of your energy on the programming and creation of
design elements during the rest of the project. Murphy’s Law13 does exist and the client
can always change his mind. Also, as web developers we oen learn something new
during the project and you should not be afraid of change. Plan for this and deadlines
will be much less painful for everyone involved.

We’ll assume everyone knows the importance of backups, good hardware and
infrastructure and we’ll focus on how the actual building should be done when there are
no emergencies.

Framework
e importance of a framework can not be understated. e selection of which
framework to use is widely overstated. In other words, use whatever works for you, but
make sure that everyone on the project understands it well and uses it always.
Programmers like to try whatever is new, but before using a new framework test it well
and make sure it has an online following.

Small team
Less is also more when talking about the size of the team of web developers. Adding
people, especially programmers, during a project is oen a waste of time due to the time
needed to bring them up to date. Even large sites with hundreds of pages worth of
content can be handled by the minimum team of 4 people. If the team is any larger try
to make sure the members have worked together before and make sure they use
collaboration tools like a versioning system and a wiki to keep track of what the others
are doing. is is a general rule and there are exceptions.

Quick Beta
Get a beta out of the door as soon as possible. is is a good rule to be learnt from
Google. Even if you know there are bugs or uncompleted parts of the system it is

13 http://en.wikipedia.org/wiki/Murphy's_law

17
generally better for everyone to let either the client or actual users see the work in
process. Showing something clickable will provide you with free testing and almost
always improve the relationship with the client since he will oen be anxious to see
something working. In Copyle a product is typically in beta for the final 20% of the
time it takes to complete. Content is oen inserted during the beta phase and for
business logic system reports are oen created at the very end in order to have real data
to verify with.

Tools of the Trade

ese are my basic tools of the trade. Copyle is in no way affiliated with this soware
and we’re sure there are other options which are just as good, but this is what I use.

Whiteboards, paper and pencil

Nothing is more flexible in a meeting than a great big whiteboards. If you buy them they
can cost a few hundred dollars, but you can also use big panes of glass with white paint
on the back. As an added bonus they also work well as projection backgrounds.

I’m a paper and pencil kind of guy, even before the Moleskine14 fad. Many people prefer
to use electronic tools and although they have lots of advantages paper never runs out of
batteries, a notebook is generally smaller and quieter than a laptop during meetings and
drawing a diagram doesn’t require switching applications.

Plain text editor

It seems that the people who make word processors forget that 95% of the time we
simply want to write. Many people in Copyle have Unix backgrounds and spend a lot
of time in pain text editors . Generally speaking, it’s easier to focus on the content of
documents and then worry about how it looks. ey are also faster to start up and the
ones included with the operating system support spell checkers.

Omnigraffle

14 http://www.moleskine.com/

18
Omnigraffle15 from the Omni group is unfortunately only available in OS X and is not
Free Soware. However I have yet to find a better soware to create diagrams and
wireframes.

Basecamp / Activecollab

Basecamp16 is a hosted application made by 37Signals who also wore Getting Real, one
the inspirations for this guide. ActiveCollab17 was a replication of BaseCamp written in
PHP and released under the GPL. You can still get ahold of the 0.7.1 version18 and
install it on your LAMP19 server without having to spend a dollar.

Both applications are great web-tools for helping you organize and plan projects. Project
members, tasks, milestones and files can all be controlled and in addition to facilitation
the team’s internal communication it’s also a great thing to show the clients.

Wiki

I honestly don’t understand how a company can survive without a Wiki. ere are
currently hundreds of Wiki systems, from Wikipedias MediaWiki20 soware to hosted
applications. At Copyle we use our Wiki as a intranet for all our information. Details
about servers, phone numbers for clients and project notes are all stored in the on-line,
searchable and infinitely expandable system. WikiMedia is Free Soware and easy to
install on you LAMP server.

15 http://www.omnigroup.com/applications/omnigraffle/

16 http://www.basecamphq.com/

17 http://www.activecollab.com/

18 http://www.activecollab.com/files/0.7.1/activeCollab.tar.gz

19 http://en.wikipedia.org/wiki/LAMP_(soware_bundle)

20 http://www.mediawiki.org/

19