Results 1 to 5 of 5
May 2, 2009, 05:55 #1
- Join Date
- Oct 2005
- Melbourne, Australia
- 0 Post(s)
- 0 Thread(s)
Everything A Print Designer Needs To Know About Building Web Sites
Notice: This is a discussion thread for comments about the article, WWWDOTME, first published in Issue 249 of Desktop Magazine.
The idea that “building a web site is easy” has existed since the web was invented, thanks to applications like Microsoft FrontPage and Adobe Dreamweaver.
However, as many inexperienced web designers soon discover, creating a one-page homage to your canary Boris (may his soul rest in peace) and building a professional web site are two very different tasks. To build a web site that communicates effectively with its audience, can be updated by the client, and looks visually pleasing, requires a whole range of skills—some of which lie beyond the comfort zone of most designers.
For example, determining what technology is the best fit, what Content Management System to use, where to host the site, how to ensure cross-browser compatibility and how to ensure the site ranks well in search engines are all important. For the uninitiated, these hurdles can become very overwhelming, very quickly.
So what works, and what doesn’t? Well, as you might expect, the answer is always “it depends.” As with any project, important decisions are shaped by the goals of the project, the budget, the timeframe, the experience of the team members, and the personal preferences of those involved.
While it’s true that many technology decisions are often best left to the geeks who speak in 1s and 0s, there are a few universal truths that apply to all web projects. It’s crucial that any designer tackling a web project understands these fundamentals, regardless of whether they cut code, push pixels, or dabble in both.
The Client-side Contest
It’s understandable why we designers love Flash so much—why wouldn’t we? It’s an enormously powerful medium with which we can create eye candy and push the boundaries of interactivity and multimedia. Flash also has an enormous install base, so it conveniently sidesteps the browser-compatibility woes that have plagued CSS-based sites for years. Finally, Flash has that unmistakable “wow” factor that is useful for blowing away clients.
Unfortunately, Flash has a few dirty little secrets. Actually, they’re not little—take a look at the following downsides before you decide to build your next site in Flash:
- Flash sites perform poorly in search engines compared with sites created with HTML. Whilst Google has made advances over the years in indexing content, Google’s engineers still have a long way to go before the bots that crawl the web can understand a Flash file to the degree that can be defined using simple HTML tags.
- Most Flash sites are less accessible to disabled users than their HTML-based counterparts. Sure, there are some basic keyboard navigation features built into every Flash file, but in many browsers, switching between the Flash object and its HTML container is problematic, as is navigating Flash objects with input devices other than a mouse or keyboard. See “What is web accessibility?” (Desktop 235) for more on this topic.
- Flash sites are often less usable than an HTML/CSS equivalent. I’m not talking about that beautiful, intuitive interface you built—key features of the web browser experience go out the window when a site is built in Flash. These include highlighting text for copy and paste, clicking the Back button to go back a page, increasing the font size, and allowing for users to open links in new windows.
- Flash sites can’t be viewed by most mobile users. Even the iPhone—a phenomenally successful product for Apple in Australia and arguably the most advanced handheld device on the market—cannot view Flash files.
Of course, there are many circumstances when it does make sense to use Flash—animated mastheads, embedded movies, and interactive interfaces that break away from the document-based model of the web are all good candidates. However, rarely do those circumstances involve building a site purely in Flash.
The Server-side Showdown
Yet more and more roles demand that designers be comfortable with both graphics and writing code—even if it’s just to update the template of the content management system that powers the site.
Here’s a brief rundown of the most common server-side languages in use on the web and how they stack up.
- CGI-Perl: The programming language Perl has been around for longer than the World Wide Web itself. The language is an ongoing open source project, and any hosting provider you use is guaranteed to have it installed. However, unless you have a good reason for learning Perl, I’d suggest steering clear—it is notorious for being difficult to learn.
- PHP: Like Perl, PHP is also an open source language. However, unlike Perl, PHP has a reputation for attracting beginners, largely because it is very easy to learn and ubiquitous across web hosting providers. The ease of use of PHP is sometimes viewed as a criticism by developers, though, as it provides newcomers with “enough to rope to hang themselves.” However, the popularity of PHP is undeniable. It is also the language of choice for many free content management and blogging systems (which we’ll explore later in this article). The XAMPP package, a single-click install of PHP and other technologies that integrate with PHP, is a great tool for Windows and Mac users.
- ASP.NET: For those clients who are uneasy about trusting open source technologies, Microsoft’s ASP.NET might be a good choice. The Visual Studio development environment is a natural choice for building ASP.NET sites. Visual Studio drastically simplifies the process of building web sites, but this comes at a cost—it is both expensive and resource-hungry (although there is a free “express edition” available). Unfortunately the code that Visual Studio generates is often inefficient and non-standards compliant, and not every web hosting provider provides the facility to host ASP.NET pages.
- Ruby: The Ruby language has been around for over 10 years, but it’s popularity for building web applications is only recent, fuelled largely by a web application framework called Ruby on Rails (or just “Rails” for short). Don’t let the slightly odd name fool you—Rails is a well-thought-out framework that forces developers to follow best practices in terms of file structure, file naming conventions, code reuse and unit testing. There is a steep learning curve required in order to master Rails, but those who persist often become vocal evangelists.
- Flex: Flex refers to a collection of technologies from Adobe for developing Rich Internet Applications—online applications with a much higher degree of interactivity than a standard browser-based web application. In Flex, user interfaces are defined using a markup language called MXML, the interactions on the page are described in ActionScript, and the end product runs as a Flash file. Adobe make the basic Flex Software Developer Kit available to download for free, but if you’re planning on building sites in Flex on a regular basis then it’s worth paying for the Flex Builder Pro editor.
As you can see, the choices of technology for a web project are vast. Whether you’re itching to get your hands dirty, or just want to understand how those propeller-heads in the basement of your office spend their time, making an effort to appreciate the fundamental differences between the languages listed above will make you a better web designer—if only because you’ll be able to better communicate with your technical colleagues.
Dabbling in server-side web development may also improve your client-side coding skills—if more web development projects were approached with a software engineering mindset, rather than a print mindset, then there would be less broken web sites out there.
Content Management Systems: Custom or Package?
In the previous section, I argued that designers should learn a server-side language. Now I’m going to recommend that you don’t use it when building your next web site. It’s confusing, I know—bear with me!
Here’s why you should build your next site using as little custom code as possible: wearing the designer hat and the programmer hat certainly gives you a competitive advantage in the web world, but the reality is that most web sites are fundamentally content sites. For these types of sites, a Content Management System (CMS) will suffice.
One of the most difficult challenges in building a web site is ensuring that the client can update it on their own, long after the project has completed. A CMS is key in achieving this goal. While there will always be clients who are faster learners than others, it’s also true that some CMSes are much easier to learn for non-technical people than others.
True, there are occasions when the site for which you’re designing might require purely custom code, but on these occasions it’s more likely that the development (and design) will be managed in-house rather than by an external agency. If you’re reinventing the wheel for your client, you should be using a CMS.
There are numerous advantages to using a well-established CMS rather than “rolling your own.” These include:
- Security: Using a CMS that is being constantly evolved means that with each upgrade comes improvements in the security of the product. These updates may fix previously undiscovered security flaws; adapt to changes in how browsers operate, or add support for upgraded database versions. Writing custom code for a client that is accessible over the web without investing any time in the future testing and updating that code will risk in the security of you client’s website being compromised.
- Familiarity: There may be no “perfect” CMS, but there are a finite number of them on the market. If by chance your client has used the CMS that you choose for your project before, then the learning curve for updating their site will be much lower. This makes good business sense for them, and makes you look good.
- Maintenance and Support: If the code that powers your client’s web site is completely custom, then your client will be more dependent upon you to make any future tweaks or changes than if you used an established CMS. Whilst on the surface this may seem like a cunning way to lock them in for repeat business, in fact such as approach can be harmful to the your client-vendor relationship—especially if there are occasions when you are unable to accommodate their requests in a timely fashion. It makes much more sense to use a CMS for which a thriving community of developers exists, so that your client has an alternative developer to turn to if necessary.
So if building a site from scratch is a no-no, the question then becomes “Which CMS should I use?” This question has caused heated discussions amongst web developers for years, and is one for which the answer is, again, “It depends.”
Unfortunately, a comprehensive comparison of every available CMS is beyond the scope of this article. There are a huge number of factors to consider. Here’s a sample (this list is merely the tip of the iceberg):
- Does the CMS contain the features necessary for this site?
- Are there any legacy systems with which the CMS needs to interface?
- How big is the development community associated with the CMS?
- Is the client comfortable with using an open source solution?
- What plans are there for expanding the site in the future?
An open source CMS is often perfect for a client whose project budget is limited. Tools such as Drupal, Joomla, eZ Publish and Wordpress are all open source and written in PHP. Each package has its strengths and weaknesses, but all deserve your consideration.
An excellent place to begin researching open source CMSes is opensourcecms.com. The site provides demos of over 100 open source CMSes with which you can experiment without installing anything on your own local machine.
Ranking in Search Engines
OK, so you’ve launched your site and you’re publishing interesting, unique content every day. Visitors should come flocking in droves, right? Well, maybe not. If people can’t find your site, then how would they know that it exists?
If your logfiles are telling you that only two people are visiting your site every day (and you’re one of them), then you may need to put some effort into optimising your site for search engines. Search Engine Optimisation (SEO) is an umbrella term that covers how you code your site, what content you publish, how you phrase that content, what URL structure you use, and how well you rank in search engines for various phrases.
The world of SEO continues to be tarnished by stories of online marketing consultants who “game” Google with unconventional techniques that trick the Google algorithm into listing their website higher in the results pages than it probably deserves to be.
The truth, however, is that SEO is an important aspect of any commercial website, and there are many legitimate techniques that you can, and should, utilise, to ensure that people are able to find your site through a search engine. Whilst it would be impossible to describe how to develop a comprehensive SEO strategy within these pages, if you follow my advice at the start of this chapter to use HTML instead of Flash whenever appropriate, you’ll be well on your way.
One common misconception is that a website’s ranking in a search engine is tied to its PageRank. PageRank is a trademarked term used by Google to determine how much authority a website has. Fundamentally, the way it works is this—the more links to a website, the more important Google considers that site to be, and therefore the higher its PageRank.
Realistically, though, the algorithm that determines a website’s PageRank is a closely guarded secret, and the algorithm itself is constantly changing as the web grows. Additionally, a website’s PageRank is only one factor that influences its position in Google’s search results pages. Finally, its important to remember that Google is but one of many search engines. Google may dominate the current climate, but this may not be the case in the future. Focussing on Google alone would be a short-sighted strategy.
In the end, a site’s PageRank value (or its ranking using any other metric, for that matter) is meaningless if the site ranks well in results pages for Google and other search engines for the phrases that matter to your client. The key to achieving (and maintaining) success is to continually monitor your site’s traffic using an analytics package like Google Analytics. The insight that this data can provide on how visitors use your site and what keywords they type to find it will be invaluable in shaping the site’s SEO strategy.
A Web Site Is A Software Product, Not A Piece Of Paper
Getting on the web has never been easier for end users interested in publishing photos, chatting with friends and dumping random thoughts for the world to savour, but building a professional website is as difficult as it has always been.
It’s therefore critical that web designers take the initiative to understand what goes on “under the hood,” or risk their beautiful mockups not reaching their full potential because of the technology that implements them. By understanding when to choose Flash or HTML, the pros and cons of the various server-side languages, how to select a CMS and what factors affect a page’s ranking in a search engine, designers will be able to offer their clients a more informed service—and a more successful website.
May 2, 2009, 07:40 #2
- Join Date
- Feb 2005
- from Madrid to Heaven
- 211 Post(s)
- 1 Thread(s)
Impressive article Matt. I can only say that I agree with every single word of it... but I loved the setences where it readsSo what works, and what doesn’t? Well, as you might expect, the answer is always “it depends.”
May 2, 2009, 17:25 #3
Nice job, Matt. I can think of a blue zillion forum threads you could link to in the article, as much of what you discuss are hot topics in the forums.
May 3, 2009, 18:09 #4
- Join Date
- Oct 2005
- Melbourne, Australia
- 0 Post(s)
- 0 Thread(s)
Thanks so much guys, glad you liked it.
I wasn't sure whether it was the right level for the SitePoint audience (it was obviously aimed at Desktop's readership, which is more beginner-level when it comes to web stuff.
Perhaps I'll pump it through the sitepoint.com article system after all, with the forum threads that you're referring to, Black Max. Could you do a brain dump of some of the threads you were thinking of?
May 3, 2009, 20:11 #5
I thought the column was a good one. I used to write a beginner-level column for SP years ago, until I realized (tardily) that few SP readers needed that level of discussion. Maybe I'll approach the Desktop folks to bring that series back from the grave...!