You need a web project built…and you need to select a platform on which to base your new development project, and a partner to build it. So how do you do it? What are the key factors in the selection of the right platform? Is there a “right” platform? What are PHP, .NET, XML and all of these other acronyms anyway? These are all good questions and ones that need to be considered before making that all important decision.

We’ve always taken the stance that we should treat every project as a new challenge and base the decision on a number of factors including the timeline, budget, available resources, likely future direction and others. In some cases, clients rely on us to select the platform, in others, they choose the direction. In either case, the factors to decide are not always the same for both the developer and for the client.

As a client, you need to decide what are the key factors for you. Some of them will no doubt include:

• budget - If I select platform A, will it be cheaper than platform B in development and maintenance costs
• available resources - in the case of the client, not what’s available at the chosen developer’s shop, but the ability to find people outside of that shop should the need arise
• longevity - is this platform new, old, maintained and advancing, or is it dead and with no future plans
• performance - is the selection of a particular platform going to impact the speed and reliability at which the application delivers information and services to its clients
• source - is this an open source project, a proprietary technology, or something else?

The last one is often one that requires further explanation. While it may be out of scope of this posting to discuss the concept of Open Source, these types of platforms are generally free and take advantage of a large pool of developers that participate in the development of the platform for the greater good of all involved. While many are strongly in favour of developing using Open Source tools, we have delivered successful projects and products in both worlds and have experienced victories and challenges in both cases.

As a client, in general, you need to make sure that you are getting the job done with a set of tools and technologies that are proven, have potential to gain advantage from future upgrades, and that there are people out there to help you should the developer become unavailable.

In addition, some platforms have great strengths that truly only begin to surface when the development project is large and/or long-term. Spending more on the initial development can be a worthwhile investment in these cases, and a wasteful spend in cases where the project is simple in nature.

What about the all important “scalability” factor? I find that clients are often in need of a solid dose of reality here. In many cases, the chance for a true problem of scale is extremely low. Does that mean one should ignore the issue? Of course not, we feel that one should prepare for an eventual problem of scale, but should not sacrifice short-term efficiencies and extend the budget for what “might” happen. We all want to believe that our application will be extremely popular and lead to great success; however, one should consider how to measure success so that a proper decision can be made on how much effort to devote initially to this issue. In many cases, one can deal with the problem later once the application has been proven and begins to show the potential to become a “scale” issue (often more money is available through greater revenue or investment at this point).

So where does that leave you as the client in search of answers and a development partner? In any business relationship, you need to work with someone you trust. As in all relationships however, you cannot trust blindly. Make sure you challenge your development partner on their recommended choice (or yours!) and make sure you are comfortable with the answers they are giving you. Each development shop will have their preferred ways and means of developing websites, but the developer needs to make sure they properly explain the pros and cons of each possible alternative so that you the client can be confident you are going in the right direction.

This might be a bit heavy for only being the second post on our newly created blog but since everyone else and their lemur have already weighed in on the subject, I thought I’d step up as well.

First, some background for anyone that isn’t aware. Microsoft announced how IE8 would attempt to avoid the problems caused by the launch of IE7 which coincided with the publication of two articles on A List Apart: Aaron Gustafson’s explanation of the idea and Eric Meyer’s discussion of his personal reaction. Subsequently, some people’s heads exploded. I strongly suggest you read the articles (and their ensuing comments) to get appraised of the situation before continuing on here.

There seems to be a lot of backlash to the idea and yet I don’t find myself that upset or opposed. I can’t really figure out who it is that is so negatively affected. In order to make sure I wasn’t just missing something, I started to look at the stakeholders in this decision and how they would be impacted.

Read the rest of this entry »

We’ve been building websites here at MARSWorks Inc. for many years and have faced many challenges. We’ve often struggled to decide whether or not we’d become more of a FLASH shop or stick to our current style which can best be described as “build anything and in any platform”. We’ve always believed in the philosophy of determining the situation our client and the web audience is in, and then determine the best possible tools and technologies to apply to that situation. Often, the choice of a platform or tool like FLASH poses many challenges in making the site truly accessible, or friendly to Search Engines, or people without the ability to download the FLASH plugin.

In the development of our latest website, a long overdue revamp of our corporate online presence at MARSWorks.com we decided to embark on the challenge of building a website that could use the rich and animated features of FLASH, but also be readable to those without FLASH and be fully readable to search engines or other indexing tools.

Although we’re only at the beginning of this process, we have finally managed to make this a reality, and in the process learn a great deal about trying to have the best of both worlds on a site. The site uses a single set of content data to populate both the xHTML and FLASH versions, and we do our best to detect the version of FLASH and then display the site in the proper format for each visitor.

What’s next? We’re next going to work on making sure we have proper support and display for various mobile platforms, including of course the iPhone from Apple and some popular Blackberry versions.