Cost Effective Web Development

A presentation at Iceweb in October 2010 in Reykjavík, Iceland by Drew McLellan

Slide 1

Slide 1

10 COST EFFECTIVE WEB DEVELOPMENT TECHNIQUES

Slide 2

Slide 2

OR: HOW CAN I MAKE THE BEST USE OF LIMITED DESIGN AND DEVELOPMENT BUDGETS IN THESE INCREASINGLY CHALLENGING ECONOMIC TIMES? Most of you are building sites that cost your client more money than they should. You’re wasting money. Here’s how you can stop.

Slide 3

Slide 3

SOMEWHERE OUT THERE LIES A WORLD OF

LIMITLESS

BUDGETS Some people are building things without needing to worry about how much time it takes or what it costs. That’s not most of us. Most of us work with constrained budgets. Internal or external clients. Everyone has a limit on either the amount to TIME or the amount of MONEY

Slide 4

Slide 4

WHEN BUDGETS ARE TIGHT EVERYONE

WORKS

HARDER It’s no secret that we’re in a period of global recession. Clients either have smaller budgets, or want more from the same budget as before. Companies who employ web designers and developers have less work, which may mean they’re unable to support as many sta ! . Everyone has to work harder.

Slide 5

Slide 5

FA S T E R CHEAPER BETTER STRONGER WITH FEWER RESOURCES AVAILABLE What we build has to be done faster Spending less To higher standards because the market is more competative and has to last longer. All this will fewer people on your team, or less money to pay for the number of hours you may require as a freelancer. Today I’m going to be looking at some techniques that might help you to design and build faster, cheaper, better and stronger.

Slide 6

Slide 6

SOME TECHNIQUES ARE TECHNICAL BUT MANY ARE ABOUT WORKFLOW Some of those techniques are about the technology we put in place. A lot of what we do on the web is technical and by identifying the costs associate with technology we’re using we can make sure we’re as e " cient as possible. One of the biggest costs in building stu ! for the web is you and me. It’s people’s time. So a lot of the suggestions are about improving workflow. About thinking about our jobs in terms of e " ciency.

Slide 7

Slide 7

I’M DREW MCLELLAN EDGEOFMYSEAT.COM ~ @DREWM I HELP PEOPLE BUILD THINGS ON THE WEB I’m a web developer. I co-run a web development agency called edgeofmyseat.com We help people build things on the web. I’m @drewm on Twitter

Slide 8

Slide 8

HERE’S THE TIPS PRESENTED IN NO PARTICULAR ORDER So these are my tips, in no particular order. Yours may be di ! erent - I encourage you to share them. You might not agree - that’s ok! The important thing is that you think about how your can improve the way you spend your client’s budgets.

Slide 9

Slide 9

1 WRITE A COMPREHENSIVE SPECIFICATION FOR YOUR PROJECT WORKFLOW. When we’re talking about e " ciency in design and development, we need to talk about specifications. Most of us don’t like the concept of having to produce a spec It’s outside of our skills, often.

Slide 10

Slide 10

A GOOD SPEC DOES TWO THINGS LIMITS SCOPE

ENABLES EFFICIENCY But a good spec does two di ! erent things. It limits the scope of the project by defining EXACTLY what the work is, up front. Most of us have to estimate either hours or costs for projects. Having a good description of each aspect of the project enables us to do that accurately. IT’S VITAL to get estimates right, and to: 
 ONLY DO THE WORK YOU ESTIMATED FOR When it comes to actually designing and building it enables you to be more e " cient. Questions answered up front Find common features and design/build once

&

Slide 11

Slide 11

THE EASIEST PLACE TO CONTROL COS T S

  • IS IN - THE SPEC If budgets are tight, the easiest place to control the costs is in the spec. When the spec is still being written and refined, making changes, cutting back features, or juggling where time is best spent. When budget is limited, you need to make sure money is being spent where it matters. At the spec level, changes are almost free. Once you’ve started building, changes are expensive, and it’s money you can’t a ! ord to waste. So what should be in a spec?

Slide 12

Slide 12

DESCRIBE HOW THE SITE WORKS

FROM THE USER’S PERSPECTIVE NOT HOW IT’S IMPLEMENTED A good spec simply describes the site from a user’s point of view. What do they see? What can they do? A picture paints a thousand words, so include sketches of the interface. (where it matters) These aren’t designs. By thinking about what the user can see and do, you’re describing what needs to be designed and built. Include all users - such as sta ! admins, content editors, moderators as well as punters. This helps you make sure you’ve thought of everything, and time to design and build can be estimated accurately.

Slide 13

Slide 13

CHANGES ARE CHEAP TO M A K E ON PA P E R Don’t be afraid of changing the spec at this stage. Changes are cheap. Changes for the better save you money.

Slide 14

Slide 14

ENABLES EFFICIENCY! DEVELOPMENT

  • CAN BE - PLANNED UP FRONT Once you’re working to a finalised spec, it gives you a world-picture of the project. As a designer you might be designing something like a User Badge. With a spec you can look through and find all places it’s used and make sure your design accommodates it. As a developer, you might be building something like a Pagination class. By having a spec up front, you can find all items that need paging, and make sure your class is flexible enough for all those uses. It enables you to be more e " cient.

Slide 15

Slide 15

  • NO - ALARMS
  • NO - SURPRISES It should basically mean that there are no surprises. Or at least the surprises are minor and easy to deal with. A spec enables you to make sure any additions can be correctly charged for. It helps you make sure that a job continues to be profitable. That helps make sure you’re around to work on the next project.

Slide 16

Slide 16

2 EVALUATE POSSIBLE EXISTING SOLUTIONS TECHNICAL - particularly DEV

Slide 17

Slide 17

DON’T REINVENT

THE WHEEL There are unique projects - but for each one there’s 1000 that are fundamentally the same. Don’t be afraid of using technology you haven’t developed yourself. There are lots of web application frameworks There are lots of content management systems A lot of those are free Some of them are even good. Building on top of an existing platform can save masses of time.

Slide 18

Slide 18

EVALUATE AGAINST

YOUR (NOW SOLID) SPECIFICATION Don’t forget your spec. It’s a great help in evaluating a technical solution. It tells you what any chosen platform needs to be able to deliver.

Slide 19

Slide 19

CONSIDER COMPROMISES: WHERE DOES COST MATTER

MORE

THAN FEATURES? Perhaps you might find a system that will allow you to deliver 90% of your project out of the box. MASSIVE SAVING. It’s a good time to re-evaluate the 10%. Is it an important 10%. Is the cost saving from changing the spec worth it? That will depend on your project. Massively.

Slide 20

Slide 20

USE EXISTING CODE AND BUILD 1 0% ON TOP

  • NOT -

1 0 0%

FROM NOTHING It’s always going to be more cost e " cient if you can then build that 10% yourselves Than to build 100% yourself from scratch.

Slide 21

Slide 21

3 CONSIDER THE COST OF YOUR DESIGN CHOICES MOSTLY TECHNICAL - DESIGN

Slide 22

Slide 22

Slide 23

Slide 23

Slide 24

Slide 24

Slide 25

Slide 25

Slide 26

Slide 26

TO U G H BUT NOT IMPOS SIBLE

Slide 27

Slide 27

IT JUST TAKES TIME

Slide 28

Slide 28

Slide 29

Slide 29

Slide 30

Slide 30

Slide 31

Slide 31

CONSIDER THE DEVELOPMENT

IMPLICATIONS OF EVERY SINGLE DESIGN CHOICE

Slide 32

Slide 32

4 MAKE SURE YOUR DESIGN COVERS ALL STATES THE USER ENCOUNTERS WORKFLOW - DESIGN

Slide 33

Slide 33

GOING

BACK & FORTH

COSTS TIME

Slide 34

Slide 34

  • CONSIDER - LOGGED IN LOGGED OUT

&

Slide 35

Slide 35

  • CONSIDER - EMPTY STATES TO O M U C H DATA

&

Slide 36

Slide 36

  • CONSIDER - WITH JAVASCRIPT WITHOUT

&

Slide 37

Slide 37

  • CONSIDER - ERRORS MESSAGES

&

Slide 38

Slide 38

MAKE SURE EVERYTHING IN THE SPEC IS

DESIGNED

Slide 39

Slide 39

5 DESIGN FOR REUSABILITY TECHNICAL - DESIGN

Slide 40

Slide 40

BUILD A TOOLKIT OF REUSABLE COMPONENTS

Slide 41

Slide 41

DESIGN TO A GRID

Slide 42

Slide 42

EVERY UNIQUE ELEMENT IS A SOURCE OF COST

Slide 43

Slide 43

  • A FEW - VERSATILE TEMPLATES IS BETTER THAN DOZENS

Slide 44

Slide 44

Slide 45

Slide 45

6 REMEMBER: BROADBAND IS NOT A SILVER BULLET DIVERSION :)

Slide 46

Slide 46

Slide 47

Slide 47

DESIGNING FOR BROADBAND PUTS

EXTRA LOAD ON YOUR SERVERS

Slide 48

Slide 48

  • BANDWIDTH IS - EXPENSIVE CONSIDER YOUR

RUNNING COSTS

Slide 49

Slide 49

JUST BECAUSE IT’S DIGITAL DOESN’T MEAN IT’S

FREE

Slide 50

Slide 50

7 PREPARE YOUR DESIGN FILES READY TO SEND ACROSS TO YOUR DEVELOPER WORKFLOW - DESIGN TO DEV

Slide 51

Slide 51

MAKE IT EASY FOR YOUR DEVELOPER

  • TO - GET IT RIGHT

Slide 52

Slide 52

MISTAKES

  • & - ADJUSTMENTS ARE EXPENSIVE

Slide 53

Slide 53

GOING BACK AND FORTH COSTS TIME

Slide 54

Slide 54

NAME AND GROUP

  • YOUR LAYERS -

Slide 55

Slide 55

PROVIDE FLAT VERSIONS OF EACH STATE FOR REFERENCE

Slide 56

Slide 56

HAND OVER A COLOUR GUIDE

Slide 57

Slide 57

EXPLAIN YOUR GRID

  • DEVELOPERS WILL LOVE YOU -

Slide 58

Slide 58

8 BUILD YOUR SITE FOR CHEAP MAINTENANCE TECHNICAL - DESIGN AND DEV

Slide 59

Slide 59

ONCE A SITE IS BUILT IT HAS TO BE MAINTAINED

Slide 60

Slide 60

CONTENT CHANGES STRUCTURE CHANGES USEAGE CHANGES

Slide 61

Slide 61

DESIGN & BUILD FOR FLEXIBILITY

Slide 62

Slide 62

  • AVOID - LABOUR-INTENSIVE TECHNIQUES SUCH AS TEXT AS IMAGES

Slide 63

Slide 63

DON’T DESIGN

EACH SECTION

  • IN A - DIFFERENT COLOUR

Slide 64

Slide 64

CONSIDER HOW EACH ELEMENT RESPONDS TO CHANGE AND THE TIME IT WILL TAKE TO ADAPT IT

Slide 65

Slide 65

9 BUILD YOUR SITE FOR LOW COST QUALITY ASSURANCE (THAT’S TESTING!) WORKFLOW

Slide 66

Slide 66

EVERY ELEMENT OF A SITE NEEDS TO BE TESTED

Slide 67

Slide 67

  • MULTIPLE - BROWSERS
  • MULTIPLE -

PLATFORMS

Slide 68

Slide 68

LOGGED IN

  • OR - LOGGED OUT

Slide 69

Slide 69

JAVASCRIPT ON OR OFF

Slide 70

Slide 70

FLASH

INSTALLED OR NOT

Slide 71

Slide 71

THERE ARE TWO OUTCOMES: TESTING GETS EXPENSIVE

  • OR - QUALITY SUFFERS

Slide 72

Slide 72

CONSIDER THE TESTING OVERHEAD OF EVERYTHING YOU ADD

Slide 73

Slide 73

10 BUILD ON THE SHOULDERS OF GIANTS USE EXISTING APIS OUTSOURCE AS MUCH AS POSSIBLE TECHNICAL

Slide 74

Slide 74

THE WEB IS A COLLECTION OF SMALL PIECES LOOSELY JOINED

Slide 75

Slide 75

BE A SMALL PIECE

Slide 76

Slide 76

AMAZON S3 FEEDBURNER YOUTUBE / VIMEO FLICKR GOOGLE MAPS YAHOO! SEARCH

Slide 77

Slide 77

APIS

Slide 78

Slide 78

THE BEST WAY TO SAVE MONEY LET SOMEONE ELSE SPEND THEIRS

Slide 79

Slide 79

THANK YOU ANY QUESTIONS?

Slide 80

Slide 80

SLIDES ALLINTHEHEAD.COM/PRESENTATIONS FOLLOW ME: @DREWM