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 soware 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 Soware 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, oen 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 soware 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 right. Programmers
Leader
Salesperson
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 oen 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 oen 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 oen 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 oen has a lot riding on the project and may even lose his job over it. Clients oen 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 email of phone conversation with the end user, who oen 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 oen 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 Aer 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 make a tree structure and check that it’s balanced according to priorities. If you want to sell a product don’t put more information about the company than information about the product. I also recommend spending time on the
Quienes somos
Quienes somos (contenido normal)
Anúnciate
Anúnciate (contenido normal)
Suscríbete
Suscríbete (formato de contacto)
Contáctanos
Contáctanos (contenido normal)
Noticias
Última noticia (contenido normal)
Términos legales
Términos legales (contenido normal)
Revista Publicación Publicidad Libro
Ficha (portada, descripción)
Otra noticia (contenido normal)
Ficha comercial (PDF) Tarifario (PDF)
presentation of the information architecture. Avoid simply making an a series of different sized squares with
Confirmación
ARQUITECTURA www.editorialmapas.com
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
Spread (varios)
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 soware 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 soware 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 Tue6. I recommend reading everything you can find by Mr. Tue as he is one of the true masters of the field. His website edwardtue.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 soware 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.edwardtue.com/tue/books_visex 6 http://en.wikipedia.org/wiki/Edward_Tue 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 subprojects.
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 soware.
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
Mexican Travesias travel magazine
Buscar
Ir
Buscador Avanzado
Crónicas
Reportes
Escapada
Compras
Comida
Yukón y Alaska a fond
currently online at revistatravesias.com.
1
Although the design phase moved some of the elements around, the basic layout
2
#65
¿Qué hay de nuevo?
Por: Megan Son Foto: Laurent Granier
of the content and especially the priorities
Título de artículo Lorem ipsum dolor sit amet consectateur nonummy lorenzino. Interdum volgus vidett.
of each element has not changed from the
Título de artículo Lorem ipsum dolor sit amet consectateur nonummy lorenzino. Interdum volgus vidett.
wireframe. Small red arrows are used to point to specific items which are detailed
3
Este fin de semana • CATEGORÏA - FECHA Título de Evento • CATEGORÏA - FECHA Título de Evento • CATEGORÏA - FECHA Título de Evento • CATEGORÏA - FECHA Título de Evento
in the yellow area at the bottom and
Guía Rápida
Rutas
Concierge
Portadas
Relacionado Título de liga
4
Nombre de galería
Si el escrito Jack London y decentas de miles de otros aventureros salieron en estampida hacia estos remotos y gélidos territorios...
Título de artículo Lorem ipsum dolor sit amet consectateur nonummy lorenzino. Interdum volgus vidett.
Arte
Imágen de artículo
5
Nombre de video Algo del comentario
Tags: alaska, yukon, oro, jack london, trineos, frio, bosque
Suscripción Full 468x60 px 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, errat. Si quaedam nimis antique, si peraque dure dicere credit eos.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. dicere credit eos.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. Interdum volgus videt, est ubi peccat.
Nombre
Contáctame
Travesias TV
Si veteres ita miratur laudatque poetas, ut nihil 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, errat. Si quaedam nimis antique, si peraque dure dicere
Título de imágen
6
Email
credit eos.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. dicere credit eos.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. Interdum volgus videt, est ubi peccat. ipsum dolor sit amet consectateur nonummy lorenzino.
Foro
Imagen
7
Half Skyscraper 160x300 px
almost everything else is done on black NOTAS
and white.
1. 2. 3. 4. 5. 6. 7.
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 Los nombres son ligas a otros contenidos de los mismos autores. Contenidos relacionado con iconos para mostrar que tipo de contenido es. Formato de captura para suscriptores potenciales Espacio para destacar información sobre Travesias TV
Imágen
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 oen 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 enduser. 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 Aer 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:$; $&2#1-&-8$+0&2#)&1#,
!"#$ $AB$..
!"#$
!"#$
!"#$%&'($)*+* !"#$%&'($)*+*$&,$-"#$.*,-$/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 )*+*$,&-# %&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
7%,$>?@6
7%,$A>B6
!"#$ !"#$ !"#$
)*+*$6*1*'3 M"#1#;#'$6*,,&3)#<$*0'$)*+*$,"*0)2$3#$6'#,#1-#2$&1$%&'($N)0# 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)$&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 oen 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 oen 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 oen 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 oen inserted during the beta phase and for business logic system reports are oen 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 soware 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 Soware. However I have yet to find a better soware 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 soware 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 Soware 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_(soware_bundle) 20 http://www.mediawiki.org/
19