I recently had a discussion with a customer annoyed that it’s hard to edit the home page contents in Zen Cart. Not surprising. It’s a cart, not a full-service WYSIWYG website system. Given the hammer he has, the home page became a nail.

While it often makes sense to make a shopping cart, or a blog, the central aspect of your site, you do have to recognize the tradeoffs.
(more…)

At Web-Op, we’ve been doing sites for local real estate agents for years. In many ways, it’s still a market which is fairly weak in the SEO space. Many firms rely on cheap ‘iframe’ display of listings, so they end up with a site that Google sees as having no real content.

However, even innovations in data import technology, like TransparentRETS and dsIDXPress, allowing you to import MLS data in bulk onto a familiar, easy-to-install backend, are not a cure-all for top rankings. (more…)

Yes, I’m being deliberately inflammatory. The media seems to imagine it’s the salvation of the newspaper, and some brilliant shift in the Internet to accomodate it. Sorry, but what it is is a shiny, locked in gimmick.

Apple has steadfastly avoided the Netbook trend– the sub-$400, 7″-12″ laptop which now represents a significant amount of all PC sales. No surprise– a $399 iNetbook would cannibalize sales of their $1,000 and up machines.

Instead, the iPad runs a limited system most reminiscent of an iPhone scaled up to twice its original size. Among the major limits: limited developer access, crippled multitasking, and the same interface conventions.

Limited Developer Access doesn’t sound like a big fear. Get anything you want from the App Store. It’s all pre-vetted and safe too! Consumers initially like the concept of a ’safe’ source for software. Apple drools over a cut of every sale. But what happens when there isn’t the App you want, because of Apple’s policies? We’ve seen it plenty of times on the iPhone platform already– Google Voice was delayed and hobbled, turn-by-turn navigation arrived late to the party. Unfortunately, the truly breakthrough products– from the open-architecture PC to Facebook– have benefitted from an ecosystem which allowed someone to bring out the “out of left field” application.

Why does multitasking matter? The more hardware resources you have– whether it’s screen pixels, processor cycles, or memory– the less likely you’ll need them all the time. Moreover, the more convinient it can be to have something else in the space. If you have a big monitor, you probably don’t keep one window full screen all day– so it becomes worthwhile to have media players, IM clients, and such which can fill in the extra space. A device like the iPad will be fundamentally limited if you have to stop and go to a different program every 5 minutes.

Finally, the interface conventions. Once you get to an 8″ or 10″ screen, you’re making excuses if you can’t have a decent keyboard. In such a situation, it seems like you’re really just trying to keep the device a toy– if people can’t write a document on a touch-screen, they’ll buy that $1,000 MacBook.

All in sum, it means Apple delivered a compromise device– built more around their desires and product-segmentation aims than a real consumer desire. It also means thaat it’s unlikely to become a true “platform” the way the iPhone and iPod systems did.

For the person who wants a full-scale device, the Asus EEE Tablet can do anything the iPad can and a thousand things more. For the customers who want a little less, single-purpose devices like the Kindle offer a experience built around a single need. The eBook sales logic for the iPad seems a little weak when you realize the Kindle offers 10 times the battery life and a text-friendly screen.

Finally, how does it fold back into the whole web thing? Simple: The “Our Company is an App” thing will not scale past a certain point. Yeah, when it’s a mobile phone, fine, but when you’re looking at bigger screens, bigger memories, and bigger expectations, you’d better return to the basics of the Web:

* There won’t be one master device to emulate the behavior of. The iPhone apps which follow Apple’s style guide are fine. But a website designed to match the feel of OSX looks out of place on Windows XP. It’s true even on “midsize” devices like netbooks and tablets, which may run the iPhone OS, Windows XP, Vista, or 7, Linux, or potentially even Android.

* Users will expect an experience on their terms. Their MP3s are running in the background, so don’t load music. They may be leaving an instant messenger or video open, so don’t hog every pixel on a display.

* Compatibilty is still king. Yeah, it works in Mobile Safari on the iPad, but for the people who bought someone else’s tablet and are running Firefox or, help us all, IE8?

* There’s no master storefront to get on everyone’s desktop. even if you make apps for the main mobile and “pad” systems, it won’t reach a lot of people, and especially the desktop. Instead, appeal to normal search behavior and live inside their browser. Or do you prefer deliberately reaching only a small percent of the market?

I’ve noticed an alarming trend recently:

You’ve picked an industry. You want a website. But you have no meaningful value to add.
(more…)

Everyone has a shopping cart on their site. Odds are, it’s been 5 or 10 years since the first time you bought something online. You’d think by now, they would have ironed out the kinks. However, year after year, new website owners continue to make the same mistakes. Before you unpack that ASP.NET Storefront or Zen-Cart archive, why not take a moment to plan a strategy for your cart to search and sell well. (more…)

At Web-Op, we’ve heard some prospective clients look at our bids and announce “We’ll get ourselves a $200 commercial template”.  Wow!  Think of the up-front cost savings!  Of course, that’s ALL you get with a $200 template.

First off, a canned template is likely to need customization immediately to fit your logo and corporate colours, unless your name is “The Lorem Ipsum Corporation”.  The sample images may show your competitor’s products, or nothing useful for your business.  Chalk up 10 to 20 hours of graphic design time, at $50 an hour or more, to fix these problems.  In tne end, the requisite changes may be so severe that your purchase ends up only a “skeleton” of tables and boxes that you can hang appropriate imagery on.

Running Tally:  $700-1200

Now you have a website, but it’s a shell.  That template probably only came with enough text to stretch the boxes on the screen to their intended width, or generic copy.  Someone has to write it, and in addition, someone else should read it.  It’s always worth the expense to have a second set of eyes scanning that content.  You need someone with the guts to say that “Interactive Business Synergy Solutions” is a lot less clear than “Wholesale Janitorial Supply and Uniform Service”.  If you hire professional developers, they’re reading and checking the content as they put it into the new site.  But if you have to stick with in-house staff, it’s worth paying a few users fifty bucks a head to be in a focus group.

Running Tally:  $800-1300, plus the cost of copy

If you knew you had a specific need ahead of time, you might have started with a template designed to work with a back-office system like Drupal or Zen-Cart to do the heavy lifting.  This decision shows some foresight.  You’ll have the facilities to manage an updated news site or a shopping cart.  However, even the easiest to use of these systems requires you to do a significant amount of setup to ensure that when you go live, credit card payments don’t get sent to the Central Bank of Zimbabwe.  An experienced developer may well have done this several times over, so he knows the catches and the correct choices.  You can either spend $300 to eat the first order that went astray or locate a press-release that disappeared, $300 worth of extra time testing and bug-fixing these components ahead of going live, or pay an experienced developer $300 to do things right in the first place.  The choice is yours.

Running Tally:  $1100-1400, plus copy

Finally, all web development contains significant amount of repetitive work.  It could be fixing the bad HTML Microsoft Office dumped into fifty documents.  It could be describing 30 new products for a shopping cart.  But these are hours that you won’t get back with a template.  If you earn a reasonable $20 an hour, expect to spend between $200 and $500 on this, for a small site.

Running Tally:  $1300-1900, plus copy.  You’ve already spent over a thousand dollars more than you originally planned, and the site isn’t live yet.

Finally, spend $1,000 to hire someone to go through your site, add keyword-focused your titles and headers, and remove the boosted Wikipedia article copy to ensure that Google sees the site in a reasonably positive light.  Now, at last, you can go live!  Once you buy hosting and set the site up, of course.  Depending on the type of backend you’re working with, this can easily be a day’s labour.

Running Tally:  $2100-2900 plus copy and hosting.   The site is finally ready to go live, but now every corner you cut to get it even THAT cheap will begin to show.

After a few weeks, you’ll probably find you long for certain features, perhaps ones you wrote off in order to accept the affordable template.  Either you’d better start learning PHP, or you’re going to have to hire a new developer.  Since he’s new to your particular project, it might take 20 hours for him to do what someone who had built the site from zero could do in ten.  So add another $1,350 to cover that extra ten hours of labour.

Final Total:  $3,450-4,250 plus the cost of hosting and acquiring copy.

You chose to accept a wide range of compromises, little if any on-going support, and only minimal expert guidance, and it still ended up costing in the same ballpark as having professionals do it right the first time.

Building your own website should be approached like other do-it-yourself projects.  While many of us can change an oil filter and save $20, or even add a new phone jack to save $75, few of us would try to replace our transmissions or install central heating.  We simply don’t have the skills to do the job.  Producing a quality web page requires at least four distinct skills:  research, programming, graphic design and writing.  Many smaller organizations, and even some larger ones, don’t anticipate that they’re going to have to call in professionals when they reach their limits.  That’s when $200 turns into $3000+.

If you frequently visit personal or non-commercial websites, you’ve probably noticed the small badges at their footers announcing “W3C valid HTML / XHTML / CSS”. Some web developers strongly argue the merits of standard-compliant design, as though it has value in and of itself, and some people seeking a new site will boldly insist that it complies with official standards. However, people chasing the conformance badge often lose track of the real objectives of web design: developing useful, attractive tools with the audience in mind.

Standards can be limiting.

At first, this argument sounds like a whine, issued by developers who can’t be bothered to find ways to work within the new standards. I’m sure many designers were heartbroken when the <marquee> tag didn’t quite make the cut. However, in certain cases, the standards actually DO only provide a subset of the functions developers need, and little recourse. An excellent example of this problem is with the XHTML STRICT spec– the “target” option on links has been removed. You can, therefore, no longer specify a link to open in a new window without either requiring a client-side script, or breaking the spec. Since many sites make use of this feature for user benefit, the standard actually moved the state of the art backwards.

Standards often get misinterpreted

In some situations, the W3C has supplied sample implementations which should clarify how standards are supposed to be implemented. A good example of this is “Amaya“, the obscure browser which serves as a model of how recent HTML specs should work. Sample code is, in theory, the best specification, because it eliminates any ambiguity left in a written guideline. However, not only are many specs without sample implementations, those that do have them are often ignored. This often leads to inconsistent interpretations of the specification, and poor cross-browser compatibility.

An example: Although all major web browsers “support” the CSS standard, only Opera 9 navigates the ACID2 “torture test” page as its designer intended. If your developers write code to the actual CSS spec, they’ll find it looks bizarre in real browsers.

Standards can represent a cop-out for real testing.

A poor designer may try to use the excuse “It’s standard HTML/XHTML/CSS” if you have trouble rendering under a specific browser. He’s blaming the browser because HE chose to ignore compatibility with the real world. This is an unacceptable excuse at any time; the first lesson of web design is that no mainstream browser implements the standards 1000% accurately. Would you trust a car that was built with every part in tolerance, but never test-driven?

Know your audience: Sometimes, standards just don’t work.

The best of modern browsers (IE7, Opera 9, Firefox) generally come within shouting distance of supporting the W3C standards. If you don’t “game” the standards or make excessively complex designs, compatibility is generally good. However, the rules are completely thrown out the window when those aren’t your target market. Internet appliances (WebTV and similar), mobile phones and PDAs, and even just users stuck on specific older browsers can torpedo standards-compliant code instantly. Advanced markup simply goes over their heads, or worse, is interpreted in ways ranging from comical to unusable.

Much like newspapers are written to the lowest reading level of their target audience, so webpages must be written to accomodate the buggiest and most primitive browsers they will encounter. If that means IE-specific tags and browser-detection code to keep order, so be it.

Like the United Nations

I have no problems with the standards-setting bodies themselves. They remind me of the United Nations: well-intentioned, but with little actual enforcement power.

Their lack of power comes from two sources:

First, since HTML and CSS have reached an adequate level for most design needs, there’s little that can be offered in new standards to make them worth embracing. There is very little you can render in XHTML that you couldn’t render in HTML 4.0, so why bother changing existing designs and habits to meet XHTML standards unless you have a very specific need?

Second, the real standards are, perfectly honestly, the behaviours of Internet Explorer 6 and 7 and Firefox 1.5 and 2.0. For an eye-opening experience, try surfing with Amaya (mentioned above), and see how many successful commercial sites have chosen to appeal to the real standard, and not the official demonstration of how HTML and CSS are supposed to behave.

What can make standards matter?

Right now, standards-compliance tends to earn you nothing except a feeling of superiority and likely several more billable hours for fixing the tags that actually work in browsers but cause the validator to puke. Instead, standards need to present a clear value-add to the developer and user. If new standards allow developers to easily add desirable effects you couldn’t do before, then browsers will clamor to embrace them and the standards will succeed. May I suggest:

• A tag structure for the definition of nested, collapsible or drop-down menus.
• The ability to have multiple languages or character-encodings in a page, and let the browser display only the relevant ones
• An embedded font system.

People will embrace those standards, because they fit clear design needs, while things like “Now your webpage is valid XML too!” didn’t.

By Brendan Dekker

If you’re the type of person that gets confused with words like aesthetics, visual tension, fluidity, dominance, and balance then this article is for you. In many industries (and the web industry in particular), it is extremely important that a designer and a client can communicate their thoughts and ideas in a very efficient manner. It is often difficult for a designer to grasp a business concept, as well as for a businessman to understand the importance of good design. This is a gap that must be closed for a project to be executed efficiently.

It must first be established that the client/designer relationship be founded in TRUST, each one knowing undoubtedly that the other is good at what they do. Contrary to popular belief, a designer’s job is not merely to make something look nice… that job belongs to an artist. A designer’s efforts attempt to merge functionality and ease of use with style and attractiveness, as well as to do so in a way that fits with your company’s image. This is not an easy task. At the same time, it becomes the clients responsibly to communicate to the designer their wants, needs, and initial ideas (if they have any) BEFORE the design process has begun. There is nothing more inefficient than a client telling a designer what they want AFTER the efforts have been made to create a good design.

The next step is communication throughout the design process. If your designer starts rambling off an assortment of terms that don’t make sense to you, stop them. The designer’s job is not to confuse the client. Don’t be afraid to ask questions to find out what something means. After all, the designer is working for you. In contrast to this, always remember that you trust your designer. Why would you have hired them in the first place if you didn’t? If efforts are made to communicate ideas throughout the process in an organized manner, the result will effectively be a happy client. If a “happy client” is something you’d like to be, it is important to remember three key terms… trust, organization, and communication.

You’re probably thinking about your new website in terms of what it will be and do.  It’s equally important to consider it in terms of what it won’t be and shouldn’t be.

Imagine delivering sales presentations as epic poems, and telling your spouse about your love for her with a PowerPoint presentation.  Obviously, it won’t work well.  The web’s exactly like any other medium– ideally suited for certain tasks, clunky for others, and downright silly for some.  If you go into the web development process with a clear understanding of what websites aren’t good replacements for, you’ll make choices which produce a better website.
Websites are NOT desktop applications.
If you’re looking at developing a website as a replacement for software that once ran on your internal network or PCs, you may come in dreaming that your new website will be essentially the same environment, only living in a Firefox or IE window.  This mindset, carried too far, can result in significant added complexity, and potentially limit the benefits you’re getting by moving to the web.  It often means ignoring the things which make the Web a usable place.

First, users have far more control over the flow of a website session than if you work with a desktop application.    Although you can provide navigation, the odds are fairly strong that users will instead click the “back” and “forward” buttons to make their way through a multiple stage process.  Some users tend to open new browser windows at certain steps in the procedure.  This becomes dangerous when you use frames or AJAX technology to provide a site where parts of the site stay in place as you change others.  If you click “Back” on the browser instead of the site’s own “Go Back” control, you may find yourself returned to the beginning of a multi-stage task, or worse yet, stranded with no easy route back to the start or where you were before.

The news isn’t all bad there:  you can often design to exploit this situation.  A user who can open a new browser window is less likely to become stranded because they can’t get the information needed to proceed, and some tasks obviously make sense to present as “click the back button and try again”.

Second, websites should be “self-contained” when possible.  Even if you can’t have the databases and the code on the same machine, you can at least strive to move the whole assembly onto remote hosting.  Many desktop applications, especially for a business’s internal use, rely on a server for the office.  Every PC in the office draws information from that.  If you follow the same model for your website, you end up still having to take care of the office server, AND constantly monitor its connectivity to the website.

Finally, performance characteristics are going to be different on the Web.  Desktop applications are frequently processor- or disc-limited, but graphics are essentially free.  In comparison, web servers generally have adequate processor and disc resources, which are constrained by fairly limited transfer performance to the user.  You might find you get better responsiveness by devoting more time to processing data, if it can avoid the transfer of unnecessary large images or intermediate tables.

-Websites are NOT PDF files.  You all know PDF files– those little “land mines” of the web, which unexpectedly spawn a slow-to-load plugin and a 5Mb download.  Their saving grace is that they generally look the same on every computer you view them on.   If a 1040 has to look a certain way, fine, use a PDF.  If the document is really destined for printing, then it’s okay to force specific font sizes and page layouts that look good when printed.  There are, however, just as many situations– such as product specifications and data sheets– where the target is the screen– and site owners seem incapable of converting these documents to true Web documents.

Replacing a bloated PDF with a comparable set of HTML and images often results in faster loading, improved browser compatibility and stability (with no external plugin required, browser crashes and hangs are much less common), and less clumsy navigation (PDFs tend to throw off the “back” button’s behaviour)

Even those site owners who avoid using PDFs directly often want to turn their web site into the functional equivalent of a PDF file– they’ll attempt to force the use of certain fonts, colours, and in some cases even browsers in an attempt to control the presentation of the page.  While a reasonable amount of corporate style is entirely acceptable, and can improve your image online, you can’t hold a lot of hope for everyone seeing your site exactly the same.  Eventually you will have a user on a mobile phone, or a person with fonts enlarged to accomodate weak eyes, and your vision will collapse.  In that situation, the best approach is to plan to let it collapse gracefully– ensure the navigation and content can still be read even under adverse conditions.

-Websites are NOT TV commercials.

I’m sure you’ve went to more than one website which had a huge Flash introduction, followed by two screens of text which add up to maybe three paragraphs.  This is the web’s answer to a 30-second TV spot.

Think about what you can’t do in a 30-second TV spot– these sites have the same problem.
-You can’t sell effectively to multiple audiences.
-You can’t provide detailed specifications.
-You can’t build a community or resource that people will come back to.  How often do you watch old commercials for their informative value?

Some people might hope to use websites primarily to build brand awareness, or as a teaser, by which to “force” your potential customers into contacting you for more information.   Both of those assumptions are naive.

First, it’s only practical to build brand awareness alone when you’ve got a huge audience.  This is the mindset behind Super Bowl ads– if you’re lucky, enough people will remember you’re the belching hamster company and see what you’re about.  An ad on the Super Bowl reaches 60% of the TV audience at the time.  Even the most popular websites– Google and Yahoo– reach 30% or less of the web-user population on a given day, according to traffic-analysis firm Alexa.  For a more typical example, the site rated as the 37,249th most popular site on May 8th, 2007 only reached about 11 out of every million web users that day.

Second, users resent being steered into making contact with you.  Bandwidth and storage have never been cheaper, so there’s very little excuse not to provide detailed information on your website.  If everything is a “call us for more details” message, many users will bounce.  They’ll either be concerned that the company isn’t professional or capable enough to adequately fill out its own website, or suspicious that they’ll have to sit through solicitations once they make contact with you.

-Websites are not TV itself either.

People have been trying to turn the web into TV at least since Internet Explorer 4 and its “Channel Bar”.  It’s a terrible metaphor.  The Web offers so much more than TV.

-Television tends to offer a selection of content that’s a mile wide but six inches deep, while the Internet is both wide and deep.  If I want more information on a subject once a show has ended, the show itself rarely provides me with options.  A well-planned website will provide both its own resources and links to quality sites, allowing me to go as far as I want in the topic.

-There are no “Channels” on the Internet.  If I turn on a TV station, particularly a cable one, they’re going to stick fairly close to their target subject matter.  It’s not like they’re suddenly going to make pastry on the Cartoon Network.  This is perfect for a passive medium– the program changes every 30 minutes for you, but doesn’t wander far from home.

The Internet is more active.  You choose both when to leave one site and where you’re going next.  Therefore, the click of a link corresponds to BOTH the click of a remote (switching to an entirely new line of content) and a change of show (switching to new content on the same theme)  If you start organizing your site content into “channels”, it tends to encourage to restrictions on navigation, trying to ensure that the user doesn’t jump into a different “channel” too easily.

A “channel” mindset may also result in dividing content in ways that don’t match up with user’s expectations, just to fit into the existing set of channels, or an imposing proliferation of channels.

A good example of this is the otherwise excellent Craigslist.  They organized their classified ads into types of merchandise.  These are classic channels– once you get in one, the navigation doesn’t provide an obvious way to jump into another.  As a result, if you’re looking for an item which doesn’t fit clearly into one of the categories, it’s common to make several wrong guesses before finding the “right” category.  Furthermore, once you find the “right” category, you’ll probably miss any ads which were placed in the “wrong” category.

If content has to be divided, there are some interesting approaches which can help to lessen these problems:

-Wider categories reduce the ambiguity about where the desired content will be found.
-A site could present a category and still have links to its conceptual “neighbours”.  Alternatively, the default view could include the neighbouring categories to ensure overlapping content is made available.
-Heirarchical categories (like many online shops) avoid the risk of a menu with 500 categories.
-Tags instead of fixed categories allow users to arrange the content in ways that make sense to them.

The key to successful web development is to recognize and cooperate with the foibles and strengths of the medium.  If you choose to design by metaphor, ensure that you’re not becoming caught up in the parts of the metaphor which won’t work on the web.

In the next few months, we’ll be bringing you:

• Search Engine Optimization tactics
• Web design hints
• Tricks to stay one step ahead of your audience
• Ping-pong Scores

Check back frequently.