The Developer’s Guide to Internet Marketing

Featured

Ian Lurie Dec 3 2008

I’m a developer. There, I’ve said it. I’m out of the closet.
It’s a little known fact, but I’ve been coding web applications since 1995. I used the very first version of ColdFusion (on 1,000 floppy disks), learned PHP while building Prius Mileage and have even (gasp) muddled through Ruby. While object-oriented programming still makes my medulla ache, my geek credentials are intact.
I learned internet marketing as a long-suffering copywriter and a developer at the same time.

So, here are my tips for developers trying to function in the marketing world:
First, marketers never make sense. Don’t even try to understand their talk about personas and keywords and the long tail. They’re from Laterra, you’re from Arbre. Instead, focus on the things that you can influence:

  1. Build for speed. A faster site means happier customers and higher search engine rankings. So pay attention to performance-boosters like caching, GZIP compression and stored procedures.
  2. Minimize inline scripting. Don’t put javascript inline in your code. Put it in separate .js include files. That lets visiting web browsers cache the javascript and speeds site performance. On a busy site it adds up fast.
  3. Minimize inline CSS. See #2, above.
  4. Follow the design. Your code may make Linus Torvalds weep with joy, but if you force customers to log in every time they want to buy something, your site’s doomed. Listen to those annoying usability people. They know a thing or two.
  5. Demand a mockup. Before you start coding, someone should give you a screen-by-screen XHTML mockup of how the application should look. All you should have to do is connect that mockup to your application. If it’s not built that way you’re asking for trouble, because you’re being forced to design the interface. Imagine the designers being forced to write code. Make you shudder? Then you get my point.
  6. Build strong validation. Make sure you practice really good contingency design. If someone fails to complete a form, give them clear instructions on what to do next, and don’t wipe the form. Please. For God’s sake. Read Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points (VOICES) to learn more.
  7. Code for standards. See all that pretty code in the XHTML mockup? That’s there for a reason. Don’t just drag-and-drop .NET controls and replace the good code with total crap.
  8. Use a framework. I don’t care which one, just use it. And don’t let the marketing team bully you into hacking together some Frankenstein monster to save a day. Later coders will thank you. So will you if you have to modify your application a year later.
  9. Keep URLs short. Shorter URLs make linking easier and mean that search engines will have an easier time crawling and ranking the site. If you don’t have to have the category ID in every URL, then don’t.
  10. Keep URLs friendly. URLs should make sense to the reader. So ‘mysite.com/skates’ is better than ‘mysite.com/asdf.asp?sessionid=1231asdf’. This is not because of search engines. Search engines are fine with dynamic URLs. Rather, the friendly URLs improve clickability. More folks will click on ‘skates’ than ’1231asdf’.
  11. Don’t worry about friendly URLs. HAHAHAH fooled ya. Not really, actually. But if your site already uses dynamic URLs and has been indexed by search engines, think carefully before you go and change ‘em. The price you’ll pay in lost rankings and busted links may not be worth it.
  12. No session IDs in URLs. If you put session IDs in URLs I will personally hit you with a desk. You need a session ID if someone logs in, starts checkout or does something similar. Otherwise, leave ‘em out. And even if you do need those IDs, there’s this newfangled thing called a cookie. Use it.
  13. No https unless you need it. Don’t put every page of a site behind an SSL certificate. Use SSL when folks are exchanging information with the server. Don’t argue. I’m an old, cranky prima donna and I’ll kick your behind, sonny.
  14. Avoid duplication. Never build a cart, CMS or other tool that puts identical content at more than one URL. It’s annoying to the users and confusing to search engines.
  15. Use consistent canonicalization. The home page lives at www.mydomain.com. Not www.mydomain.com/home/cgi-bin/store/secure/index.htm. Seriously, don’t make me come over there. I’ve got lots of frequent flier miles.
  16. Build for analytics. Find out what analytics package your client is using. Include the appropriate code from the start. Building a store? Put the e-commerce tracking code in now, not later. They’ll love you for it. If they don’t, call me and I’ll blow you kisses.
  17. Test. A long time ago, in a legendary land, developers tested their code before they chucked it over the wall. Servers didn’t crash on grand opening day. CEOs didn’t eat handfuls of TUMs. You should aspire to reach that state of geeky nirvana.
  18. Stick around. When you finish that last line of code, plan to be available for last-minute changes and emergencies for a while. No matter how well you do, your client or the public will find some way to screw up the works. So don’t head for Maui just yet.
  19. Communicate. Want to really mess with the client’s head? Call them up and say “Hey, can you have a look at the home page. I want to make sure this is how you wanted it to work.” After they pick themselves up off the floor, they’ll try to figure out how they can keep you around for the next decade.
  20. Code for reuse. This should be obvious. But write all your code so you can re-use it later. It helps everyone and makes your job easier over time.
  21. Beware AJAX. Download a copy of Lynx, or Firefox and the Web Developer’s Toolbar. Check your new site with javascript turned off. Can you still get around? Can you still read all the text? Use AJAX to do everything and the answer will be ‘no’. That means mobile users, search engines and anyone else whose browser doesn’t support javascript will see a big fat nothing when they visit the site.
  22. Build for maintenance. Like it or not, your client is going to want to add a press release, change a title tag or modify something else someday. When they do, do you want to have to personally make the change for them? Didn’t think so. Make sure they can edit metadata, page copy and whatever else they might change in the life of the site.
  23. Build for structured content. If the site uses a content management system or an online store, make sure your client will be able to independently edit various structural elements on the page: The title tag, description tag, headline and content should all be separately editable. Don’t dump the product name into the title tag, or the article into the description tag.
  24. Search engines matter. A lot. 75% of everything that happens online starts at a search engine. So don’t roll your eyes when someone asks you to make something search-friendly.

Follow these tips and congratulations! You’re on the marketing team. Martinis at noon…

tags : conversation marketingtools

related articles

9 Comments

  1. Cool tips Ian, I started as a developer too, except in 1995 I’m still mugging in secondary school ;)

  2. Judith

    Lol @ “make Linus Torvalds weep with joy” … It sure will…. Really nice article though… Thumbs up!

  3. Awesome post and very insightful. The breakdown in communication between web developers and internet marketers (if not one in the same) always comes down to points like these.
    As an in-house SEO, i constantly wind up in development squabbles…and i’ve seen the eye-roll one too many times from programmers. Any tips on speaking to programmers “on their level” so they’ll stop doubting the effectiveness of ethical internet marketing fundamentals?

  4. Here’s a tip for developers to become more marketing like : get your backside off the chair and go actually speak to some real people in the flesh, face to face about their issues.
    I mean go talk to them solidly for 3 days; that’s if you can manage to take those ipod earplugs out.
    If you get that far, all you have to say to these people is “what bugs you about xyz/client/product/website”
    Then the floodgates and solutions come pouring out.
    Ian, I like you and your stuff. Love your copywriting ebook which we bought. But the above is drivel. Sorry mate.
    F.

  5. Ryan

    Ian,
    Excellent blog. I wanted to clarify one thing in your document. With respect to your items 1-3, pulling the code out of the page and putting it into a separate file is always a good practice, BUT……..
    I recently ran into a site that had no less than 20 different CSS files and 10 different .js files being loaded at the begging of the page. Since everything was off the page and the files css and js files wwere small, it took a few hours to realize that the number of connections (number of external files) was causing part of the problem. We combined the code from a number of files and the page loaded much faster.
    Keep this in mind. Everything is good in moderation.

  6. Ian

    @Ryan Good point. If we give good advice chances are someone will take it to an extreme and OD on Vitamin C :)

  7. I like that you mention AJAX. Like Flash a few years back it is the next new sexy thing. Compliance issues aside, it just makes simple coding impossible. I flinch whenever I see it.

  8. It is certainly a real grind. It is very difficult. A lot of long nights have been spent with my coffee and little results. I am super frustrated right now and i have placed over 5000 craigslist ads and made a mere trickle of income.

  9. Alex

    I knew there was something you were not telling us, Ian… Spot on, I’ll start following everything you said, starting from rule #5 Demand a mockup. Thank you, very informative.

Comments are closed.