Nobody’s going to discount the growth of mobile. We’ve all got our collections of phones, tablets, and even the occasional netbook. However, a fortune thrown at mobile development will net you no extra revenue if it doesn’t serve a user purpose.

While users on the desktop may be willing to put up with moderately clunky architectures, and sometimes enjoy clever things which achieve more of a branding goal than a direct sale, such extravagances are lost when your hands are cramped around a tiny screen waiting for data to slowly trundle across a 3G (or semi-4G) connection. The medium, in many cases, directs the message.

Is your sales message necessarily long-form? Remember, scrolling is clumsy to the point of awkwardness even on the best smartphones, and NOBODY likes pinching and panning to read a long novel. For example, if you’re trying to show detailed illustrations of spa services and explain the staff’s experience, nobody’s going to sit through it.

A better choice may be to abandon that messaging entirely for mobile users. A quicker hit with a stronger value proposition can work instead– for example, a downloadable coupon.

It’s also important to consider that mobile users may not even be engaging you for a direct buying opportunity. If I open a brick-and-mortar retailer’s mobile site, my likely concern is less about making a purchase online, and more about finding a nearby location. Feel free to remove your shopping cart, return policy, and such, to put that location-finder front and centre.

Maybe you’re not a retailer, so that’s not the obvious answer. In that case, it’s time to reevaluate the reason someone is on your site in a mobile device.

The first likely choice: he’s trying to find your retail partners. The good old “Where to buy” link is vital. However, that can be risky. If your distribution channel isn’t “tight”– knowing not just which distributors you sell to, but even most retailers– you may not have the details on important local vendors, leading the user to give up on your product as unavailable in his neighbourhood.

The manufacturer does, however, tend to have an edge on product information. Frequently, a retailer’s displays are limited to breif summaries of products, and whatever you can read off the box itself. I can recall trying to peck out manufacturers’ websites on a BlackBerry to do feature comparisons in the store– and when I got there, ending up in large, slow-to-load pages which didn’t fit my needs at all. Honestly, if you look at a screenshot like this, you know– if the information you need is even on the page in the first place– you’re going to be pawing all over the screen to try to dig it out. A simple, appropriately scaled product photo and a table of key features, on the other hand, would close the deal your point-of-sale display already opened.

versus
Indeed, this may be a rare truly appropriate use for QR codes– since it clearly ties to a single product’s packaging, a customer could scan and arrive at full details which won’t fit on the back of the box. A further enhancement could even come by tying it to packaging version– using a different code (and thus a different page) for seasonal, region-specific, or bundled products.

People scream blue murder about Amazon using their mobile presence to aid customers in comparison shopping, but customers who are researching their purchases on mobile devices aren’t just doing so to find the lowest price– information matters. Providing those details on a well-thought-out informational mobile site can help your brick-and-mortar partners outcompete Amazon- if the customers can get their questions answered before even seeing the online price, it increases their chance of closing the deal in-store.

Of course, all these paths lead customers to a purchase– even if not directly through your site. There are retailers who have to consider “maybe my product is simply not purchased off a mobile device”, where the value proposition is primarily informational.

Any sort of transportation product fits there– yes, you might be able to build a clunky product to let me buy a bus pass with a credit card number or mobile wallet payment, but I’m probably just wanting to check the time-table.

Other likely “information only” mobile presences include products which could require emergency aid (i. e. treatment if you swallow cleanser) or field service (repairing a damaged automotive component). While it may be depressing to focus on the crisis aspects of your products, being timely and correct may be a great way to earn customer trust.

However, before you get too involved in development from these documents, it makes sense to design and approve the database schema. In particular, it should be walked through the client or their representative to ensure it matches their expectations.

Why does the data structure matter?

First, the right structure often allows for a much wider range of analysis of the data later. If you store when orders are booked, for example, you can easily do reports that crunch the data on that dimension Planning what you might want to do in future maintenance or ongoing releases is valuable, because you can’t take a naive approach and get out without major scars. The obvious naive mindset of “let’s store every detail from user’s IP address to shoe size to screen resolution, in case we want to use them as an axis for reports later” leads to loads of wasted space and inefficient database operations, while “let’s store nothing except the bare minimum, and add stuff as it’s needed” means when you decide you need that value, it takes three months to build the real data in. Also, then you’re trying to update the schema, on a live site, on the fly.

Second, it allows you to talk through any gaps in the logic. If you just talk about an order in the abstract, you might not notice that two parts of the system talking to the same data structure, and then you need some sort of “status” or “locking” flag to indicate who should be seeing this data.

Third, even developers have bad models. Maybe you envisioned storing price as a single value, but the customer wants a start-up price, a monthly fee, and a discounted promotion-term monthly fee. Better to find that out now, before you build a stack of CRUD (create-read-update-delete) tools around the incorrect data model. A checklist makes these differences in opinion obvious.

Finally, there are frequently data structures which are talked of as a unit, even though they need to be analyzed at a lower level. For example, does your address need to be one line or two, the zip code 5 characters, 6, 9, 10 or more? Finding out the resolution to those ambiguities can also give insight onto the future direction of the site. A US-only site might only need a VARCHAR(5) for zip codes, but if Canada is in the future, a 10-character string avoids a change in mid-stream.

How can you talk about data structure?

The simplest route is just to prepare a checklist of each field in each major table. Discuss what goes in each field, and get a sign-off from the appropriate person. Then there’s a clear opportunity to raise any objections, and to retool with fewer or more columns, before you start plumbing together actual code. It might be feasible to even model the data structure by creating example records, say, on 3×5 cards, and asking “is this enough information to do your job” or “will you be wanting reports on something you don’t see here?”

Although the shiny Apple ad may focus on a billion App Store products, the pervasiveness of the web was a key factor in the success of tablets. Much as in the Netbook craze a few years previous– the form factor all but demands easy access to a broad range electronic content. You going to carry around a stack of discs for your paper-thin tablet?

However, just because your content is safely on a website doesn’t mean it’s perfectly suited for the tablet market. There are a few distinct technical and use-case concerns to be worried about.

First, tablets have some rather limited hardware. Many of them feature relatively low resolutions of 1024×768 or less. Even with a high resolution, their small size may encourage use of a small “effective” resolution– bumping up the text DPI to ensure readability. When even the cheapest desktop PC comes with a 1280 pixel or wider, 96 dpi screen, it often becomes difficult to find a layout which satisfies both user types. Adaptive CSS can play a big role here– as most tablet browsers are capable enough to understand media queries.

The second concern on limited hardware comes from poor input devices. You can’t do pixel-accurate work on a touchscreen. And on-screen keyboards range from appaling to merely awful. While this has led to the assumption “tablets are primarily a content consumption device”, it also means even the little bit of content production required in a normal website– enterring billing information, filling out feedback forms, and such. Sometimes you can cheat– geolocate a user rather than soliciting city and state, or punt info collection to a phone call– but sometimes you have to ask “is it worth it to force a user to go through an extra select box mess to get his birthdate when we’re selling him a pizza?”

Second, some UI conventions we’ve become accustomed to on the desktop are simply gone in tablets. Relying heavily on hover or “mouseover” behaviour will fail, as touchscreens are generally not capable of detecting it. They could, in theory, but nobody’s doing it, and even if they did, there’d be a lot of false positives. The multi-touch nature of a tablet screen can clash with the conventional assumptions of “enter an element/exit an element” that assume a single mouse pointer. In addition, some tablet experiences rely on things like styling a selected link prominently to clearly indicate it was pressed– which could clash with your own styling. In many cases, users prefer a “fake native” look, using toolkits like jQuery Touch to produce buttons and controls that resemble those of native applications, rather than a “custom” or “web-styled look”. It’s a classic extension of one of the most basic principles of usability– you want your program- or site- to resemble what the customer already knows.

Third, rich media support is a guessing game. Want to use Flash Video? Fine on a Motorola Xoom or RIM Playbook, not an iPad. On the other hand, the supposedly “universal” HTML5 video can still be bogged down by differences in codec support. Once that’s resolved, you still have further questions: Should the full-screen experience be optimized for a 7″ widescreen (Samsung Galaxy Tab), a 10″ 4:3 screen (HP TouchPad) or a 10″ widescreen (like some convertible Windows tablets)? Do we design around a user on Wi-Fi backed up with a 5-10Mbps residential cable connection and negligible usage limits, or expensive, 1-2Mbps 3G data?

Finally, there’s a lot of new ground in the tablet experience. Customers are still in their infancy when it comes to location-based services. Going whole-hog on them to provide customized content could impress users– if they get it. If they’re surprised with “Special offers around MESA, AZ” it can be an impediment to the desired use pattern, or worse yet, reaches into that “creepy zone” which sends customers running.

The keys to a successful tablet-friendly site are compromise and extensive testing. You can replace mouseover-powered dropdown menus with click-powered flyouts, or better yet, on-page menus. You can stack different media players and fall-through until they work on most of your target devices, but what you can’t do is build an all-singing, all-dancing PC website and then look surprised when it doesn’t fit on the screen and leaves big “plugin goes here” boxes all over the tablet display.

In addition, it must be remembered that the tablet ecosystem is not a monoculture. People often talk of tablets as “appliances” because they’re somewhat consistent in behaviour, without a wide array of customizations and options– but the differences between them makes it difficult to treat them with the same consistency as, say, toaster ovens or irons.

A staged deployment offers you several benefits at no significant extra costs.

First, you can get something live faster. If you don’t have a corporate presence, or your presence is technically decrepit, it is vital to replace it quickly. Every week you waste is a week your old site is discouraging customers and potentially strangling search engines.

Second, on a related note, it lets you get feedback from users faster. Some people really go the whole nine yards, and hire focus groups to test and prototype their site. But most small businesses start with sites designed based on an estimate of what users need, based on their own customer experience and our analysis. There’s going to be an expectation that things have to change, after you get the third angry “where’s the price list?” email. Rolling out a basic site early allows you to find and correct those mistakes before they’re built into deep links and navigation menus all over the site.

In an ideal world, each phase of development will really be three sub-phases:

• Build the code as specified
• Wait a fortnight to gather real customer experience
• Update the site based on what we learned

Moreover, in many cases, the feedback can help you steer future phases of development. If you find everyone’s looking at the Category A page on the main site, maybe you need a more prominent Category A presence in your shopping cart. Maybe nobody will fill out a contact form asking for Social Security Number, so you’d better not use that to attach all the customer data in your CRM.

Staged deployments also allow you to stagger your own development efforts. It does take a fair amount of your effort to build a site– get all the images you need, review the branding, sign off on content. If you also have to do this for a shopping cart or other major site module, the labor can be tremendous. You often end up involving many different departments, which can result in trampled toes and wasted efforts. Imagine, for example, if everyone in the office goes to try to obtain logo and letterhead at once. Imagine if they submit three different logos.

Hacing a break between modules allows you to organize and plan for the next phase– lining up any assets we’ll need, and reviewing the results of previous changes to make sure nothing needs to be changed based on them. It also simplifies things if you hope to use a seperate chain of command– maybe main corporate signs off on the front page, and then you introduce the retail division with autonomy over every decision made pertaining to the cart.

All too often, development turns into a “the perfect is the enemy of the good” situation. By waiting until you can build a full questionnaire, instead of going live with a contact form, you’re leaving leads on the table. By holding the entire site while you build out a shopping cart, people can’t find out your address and hours of operation. Is it worth it?

One thing we can’t stress enough is not to simply take your existing site and run it through a translator, whether Google Translate or a college intern hired for sub-minimum wage.

A one-to-one translation tends to ignore legitimate technical differences between nations. For example, form validators designed for 5-digit American zip codes will blow up if fed an analogous Brazillian CEP code instead. Phone numbers are often pre-validated too, and can prevent users from proceeding through your sales funnel. You might have a gorgeous looking site up, but zero conversions, and such runaway validators are the cause.

Aside from hard failures, there is also an atmosphere of soft distrust created by a straight transliteration. Maybe your addresses aren’t shown in the way your visitors normally make out an envelope. Or you quote 12-hour time when all the other ads are in 24-hour time. A key part of website development is to build credibility, and it’s the small things which show you have a real local presence and understanding.

Second, don’t ignore the product mix! Carmakers have driven themselves mad for decades over the fact that they can’t just sell the same model in Seoul, Sao Paulo, and Sedona. In the end, they’ve largely given up. Learn from their efforts. Maybe a few of your products have worldwide appeal, but a substantial amount of your success will involve picking products that are truly targeted towards local audiences. Plan ahead and be ready to move “laterally”. Maybe you sell diet supplements in America, but there aren’t enough fat people in China yet to justify the costs. Use your manufacturing contacts to sell an immune-boosting or general health supplement instead. The product mix also goes all the way to packaging, brand names, and sizes– will people in a 10-square-metre Tokyo apartment want to store a drum of 500 pills, or a little packet of 14?

Finally, plan payment early. We see a lot of websites– even within America– trip and stumble when it comes time to set up payment processing. It’s time- and labour-consuming to set up, and it often triggers other design choices, like what shopping cart to use. On an international site, the issue is doubly important: many American credit card processors won’t accept transactions in foreign currencies, and even if they did, it might incur extra fees, a sure way to dissuade customers. It becomes very important to also research alternative means of payment favoured in the target country. For example, the bank-to-bank transfer that’s complicated and expensive in the US is simple and extremely cheap in parts of Europe and Asia, so accepting a wire isn’t such a big deal. Other countries have developed ‘pay at a local store’ services to accept cash payment when credit card penetration is low. You have to ask: do we need to cater to the demographics which use these services? Will it get us more business, or save us costs?

At Web-Op, we’re helping companies cross international barriers. Whether it’s an American seller trying to get in on the “Rise of the Rest”, or a Chinese manufacturer eager to build a global brand, we can help.

A real doozy is the “can’t we edit…?” line of discussion. Whenever you build a database-driven system, like a CRM system, or even a sophisticated order-tracking or shopping cart system, people decide they want to be able to edit the enterred data.

Now, there’s nothing inherently wrong with allowing you to edit PARTS of your data. The trick is to abstract it– rather than editing data with no constraints, you provide the functions to perform legitimate business operations. For example, it makes sense to have an “update customer address” tool, or a “delete product from order and adjust price tool.” The dangerous aspect comes when you want to start editing any field on a record free-form.

• First, it’s a red carpet to data sabotage. Subtly change a few addresses on your corporate mailing list files, and all of a sudden, you’re sending white-papers to people living at the bus station. The real danger is that it’s subtle. If someone blows away your database in a fell swoop, well, you can identify it immediately and reach for backups. But if you contaminate a record or two a day, by the time anyone notices something’s wrong, the data’s a complete mess.

  A second dangerous angle is the use of editing tools to cover tracks. Say you print those invoices and send them to customers. You send out a $400 one, then edit the job back to $40. Pocket $360, and the database won’t notice the fraud because its numbers match the contents of the till.

• Second, it completely bypasses connections inherent in the data. Say that you store Parts, Labour, and Tax columns in your invoice system. If you are forced to edit that data through a “reprice” tool, it will be consistent. Tax can be correctly re-calculated if you change Parts or Labour. But if you provide a simple box for each field, the connection can be lost, and then the revenuers start coming and asking why the net tax on the invoices is 1.6% instead of 8.1%.
• Finally, editing tools are often an excuse, or a means, to bypass your company procedures. “Oh, we need to make an exception in the system… we’ll use the dumb editing tool because the smart system won’t let us make an exception.” If you’re trying to make exceptions all the time, your rules are likely faulty, or you’re giving your ataffers a lot of leeway. Either way, it’s not a well-run ship.

I suspect this mindset comes from the fact that customers are used to “non-programmed” ways to run their business. Using a flat Excel spreadsheet or pencil-and-paper files doesn’t enforce any discipline. Want to delete your recievables for July and put a graphic of a unicorn in? Excel won’t complain! It doesn’t care! But I care. If you edit your database into oblivion, it will take far more effort to make it right than just letting the system enforce its rules.

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.

Many canned back-end systems are designed for easy template-driven management of specific info. A cart “sees” data as products and orders. A real-estate system “sees” listings and neighborhoods. As a result, it’s simple to expand a cart from 3 items to 4. To streamline those tasks, you give up power when it comes to adding, say, a streaming video showcase and downloadable press releases- it doesn’t fit the back-end metaphor.

So why not use a non-specialized system like Mambo or Joomla instead? Because you don’t want to try to emulate that special ‘streamlined’ functionality. It might be coaxed into doing property listings or products, but it’s hardly the most efficient way, and leaves you more prone to errors and inconsistencies when the paradigm isn’t built into the software. Such an incomplete vision often means empty templates and incomplete entries, as there aren’t the needed sanity checks you’d see in a system built for the task.

Sometimes the alternative to insufficient control is overkill. Some packages try to do it all. Magento offers a fairly sophisticated page editor. Add the right modules, and WordPress will make tea and biscuits. These packages, however, often end up being complicated to operate. Metaphors mash poorly when you need to read blog posts as property listings, or generic pages as a live catalog. Moreover, you end up fighting the divided needs– templates ideal for a cart are suboptimal for corporate information pages, or you have to suppress blog links on your main page.

For many users, the right answer is a hybrid system. Multiple tools for different jobs. Static pages or a non-specific CMS for their main content, but harness a specialized tool for the big “moving parts” of the site– the cart, the blog, the searchable inventory. In such a way, you minimize the time spent dealing with the specialized product’s limits, and still enjoy its strengths.

Many of our larger projects work so at Web-Op. For example, Belleza Olive Oil can use the full power of a cart to sell their wares, but never show the cart’s ugly category or home pages. Static pages ensure they get the image they want with no compromises.

Of course, it’s got its costs– more development time, and sometimes more of a learning curve, but it’s often worth it to ensure you’re not trying to drive nails with a spoon.

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. It’s all about the brains on top of local data.

Realistically, if someone wants to just see or search the MLS, odds are, they’ll do it somewhere else. However, a savvy agent can help ‘steer’ a customer by providing pre-made landing pages and searches which provide real value. If you can promote foreclosed properties less than five years old as suitable for those who don’t want the full renovation hassle, it moves from a simple canned search to a start for customer interest. Or add useful resource guides. Surely, it’s not a crime to tell out-of-towners if the utility on the east side of town is 10 percent more expensive, or the month to move to saddle the current owner with the property taxes.

Building your site on processed and analyzed content also helps you hedge your bets. While the real estate industry has done a good job monopolizing property listings, there’s a danger at hand. Their costly, complex data license rules have left the door open for other firms able to offer a better deal for non-agency firms interested in the data. Why wouldn’t, say, Google like to add a ‘homes for sale near…’ box to their Maps service?

One of the most likely changes I see in the future is a truly national service. It’s an obvious road to entry for a new alternative data source– No more patchworks of local MLS boards, and websites that abruptly cut off at an arbitrary boundary. There are also likely to be means for ‘for sale by owner’ vendors to get their properties in the system and cut a listing agency out entirely, and add non-conventional homes– manufactured homes sans land, timeshare rentals, and such.

In such an environment, your local knowledge and customized content becomes even more important– after all, who’s likely to have a better listing interface, you or a firm like Google with an endless development budget? The listings alone are a commodity– only the value-add matters.

It’s a bit of doom-saying, I admit, but having to treat listings as a commodity can only be good news for real estate agents who play the SEO game smart– depending on becoming a resource with real content. It will cause the ‘I posted listings, it’s enough’ competition to sink.

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?

A frequent theme for these titles was, about 80 percent of the way through the game, your character’s love interest ceases to be an adorable 20-pixel-high maiden, and turns into a screen-filling ball of evil spells and tumors which must be dispatched to move forward.

What does it have to do with the Internet?  A lot.

Often times, you’re the one responsible for your beloved website turning into a similar screen-filling ball of evil.

The tumors tend to come from poorly imagined scope.  What started as a dispatch system for employees grew a login for external contractors.  Then direct sales emerges.  Finance demands to be grafted in.  Within a few years, the original software is barely there beneath the addons.

Now, it’s normal for software to evolve and grow.  However, if allowed to grow randomly, you find yourself wrestling with limitations which made sense in one context, as they become unwieldly.  Perhaps, for example, your order system was product-based.  Each order has one item, one payment method, etc.  Works great until you realize people want to add a split payment.  Or two items on one order.  Soon, you’re making dozens of exceptions to keep the monster alive.

When do you draw the line?

Can you now succinctly define what you need– in terms of data storage or workflow — and does it differ largely from the decisions you made when the site began?

• Are you doing the same job multiple times to keep different parts of the site in synch?
• Have you passed on desirable enhancements to the site since they can’t fit the established layout and data structure?
• Are everyday operations done primarily as “special cases” bolted on later?
• Have you been forced to “hunt down” specialized hosting or developers to keep the site operational?  PHP 4 is dead, yet many people are tied to apps which bomb in 5 or 6.

Slaying the beast can be hard.  You have to fight your locked-in work processes.  But sometimes you can’t move on until you do.