Podcast 26: Technical considerations

In this weeks show Paul and Marcus are joined by Chris and Mark to discuss the more technical aspects of launching a new website.


Download this show.

What are the technical considerations you need to take into account before building your new website? Understanding things like the technical constraints faced by your users or inherent in your hosting environment, helps to define the functionality of your site.

Techno buster: RSS

Every site you visit these days seems to have those little orange RSS buttons. But what is RSS, how does it work and why should you consider adding an RSS feed to your site? Listen to this week’s podcast to find out more or check out the following post on web feeds.

Main feature: Technical considerations

In this weeks show we look at three main areas for consideration when developing a new site:

  • The technical constraints faced by users
  • The hosting environment where your website will reside
  • The integration with other business systems

Technical constraints faced by users

Probably the biggest set of technical constraints imposed on us when developing a website comes from our target audience. Factors like; the browsers used, available plugins, screen resolution, JavaScript support and bandwidth, all affect how a site is designed and built. Understanding the technical environment your users work in will dramatically alter the way you approach a web project.

Hosting environment

If you have an existing hosting platform for your site that cannot be altered, this will significantly change how your site is built. Different hosting environments support different sever side languages and databases. Also things like bandwidth capacity and streaming media services can impact whether you are able to provide rich media on your site or not.

Business systems

Integrating your website into existing business systems can be problematic. Whether you are endeavouring to tie your site into stock control / accounting systems, or ensuring it is compatible with legacy databases, backend integration can be a time consuming (and expensive process). However, if it is not properly addressed, poor integration can lead to data inconsistencies and a lot of re-keying of data.

Web resources: Backup and recovery

In response to a listener’s question, the team discuss tactics and tools to handle backup and recovery of websites and data. In particular, two tools were mentioned:

CVS is a file recovery and version control systems that can be used to manage changes to your site. As well as preventing one developer overwriting another’s work, it also allows you to rollback your website to any previous incarnation. However, be warned, this does not handle database recovery.

Although this is not strictly a backup or recovery tool, it is still invaluable if you have a distributed network of developers working on a project. By using peer-to-peer technology, it can ensure that all development files associated with a website are backed up over multiple locations. It has some great project management facilities too.

  • jedatu

    You should consider using http://www.shrinkster.com to shorten the links you read out over the podcast. As long as everyone knows you are using shrinkster, then all they need to remember is the 3 character code at the end.
    Here is a shrinkster link to this post:
    Great podcast guys!

  • http://www.algemeenbekend.nl/ Gerben

    Again, good podcast. Loved the backgroundsound of keyboards and spinning cooler-fans ;-)

  • http://www.macsoftreview.com Phil Palmieri

    In reference to your last podcast about backing up your website i just wanted to
    jump in. ( i know it’s a short book ).
    First, to your business people, always require a CD or other Soft copy of the
    completed project on final payment – you shouldn’t have to figure out how to
    download the site yourself, that what you are paying a web company for.
    Second, to developers. You shouldn’t really (in practice) have to backup your
    production server, your production server in essence is a snapshot of a stable
    release. You should be backing up a version from the dev environment.
    You can do this with a CVS like you mentioned, but in a 1 man shop I build a
    version on my development server, then when i have a release i make a zip of
    that stable version and archive it.
    You should NEVER in a perfect world be touching your production files – if
    something needs to be changed, change it on the DEV Server, then when it works
    move it up. I know this is a hard concept to implement 100% because some
    people want things, and they want them now – and its hard to justify a release
    for a ridiculously simple update. I adopted the habit of if the client must
    have the change now – i make them sign a document stating that they are aware
    it hasn’t been tested etc, etc.. Usually this scares them off. – but if not, i
    am 100% covered.
    If you are looking at hiring a company to do web development, and they do not
    offer an development view (not public) of your projects – run and hide — that
    is usually a good sign of the professionalism of the company. It’s almost the
    Hobby / Professional boundary – along with other things.
    Did i mention not to ever, ever, ever work on the production server? Ok.

  • Ed

    I know in my web standards aware mind that web standards is the way to go for an easily findable site, but then I do a search for “worst Christmas page” on Google, and what comes up first? My award winning bad site, that doesn’t conform to any web standards at all!
    (though do a search for “worst Christmas site” and the podcast page for that episode comes up first, which would be made with web standards.)

  • http://webaxe.blogspot.com/ Dennis Lembree

    Great points, Phil. Also, I believe it’s wise to somewhat regularly burn sites on a CD/DVD or external hard drive in order to archive it somewhere safely.

  • http://xentek.net eric marden

    You may be invested into Groove, but I want to suggest Basecamp – one of the best web applications I’ve used for project managment. It’s built by the same people that developed the Ruby on Rails framework and is an elegant example of usability, productivity and just the right about of AJAX to make the application reallly respond.
    It’s very useful for collaborating with your clients, and I’ve found it very intuitive and easy for them to pick it up.

  • Shammie Jayaransie