News Flash

Great article by @NeutronUK on how to create a print stylesheet using Firebug and the Web Developer Toolbar - http://cot.ag/bOQiVM

Tagged: Mobile

30 September 2008

It is said that you are more likely to leave your wallet behind than your cellphone when leaving the house. Most people are within 15 feet of their phone at any time, even when they are sleeping. One person in seven has been dumped by phone and the incidence of firing by phone is growing.

The phone is so omnipresent it is becoming set to take over as the task-oriented access point for the Web, while the PC, the TV, and other large screen access points will continue to be the choice for video streaming, browsing, and other activities involving heavy graphics or complicated interfaces. It is unlikely that the phone will take over as the online word processor any time soon.

Moving functionality onto the phone: spending

If you are more likely to have your phone with you than your purse, it starts to make sense for the phone to take over some of the functions that you need all the time. It is no surprise that payment is moving on to the phone.

Take your credit card, for example. What is a credit card, really, but a bunch of information held in a form that is awkward to replicate? In effect, it’s an account number combined with an ID. Any modern cellphone has more storage capacity than a hundred credit cards require, so why not move it onto the phone and have it with you the whole time?

However, managing your finances on your phone with a full-scale accounting application might not be convenient; you would really need a bigger screen than is really comfortable to carry around with you. So we have our first driver towards convergence right here. Moving a credit card to the phone and administrating your finances across a variety of web channels not only makes sense, but there are a lot of other advantages to it which we will discuss later.

Traveling

First let’s look at how another card with a magnetic strip has evolved. The humble tube ticket used to be the standard way of getting about in London; now 80% or more of eligible journeys are made using contactless Oyster cards. Contactless cards are quicker and more convenient than putting a card into a slot. So if we are going to move the credit card onto the phone then let it be as a contactless card. And if we have a contactless card, it might as well be our Oyster card as well. That way the Oyster can be “topped up” from the account attached to the credit card and save us a bit more bother. In the world of developing technology, convenience should be king. It is no surprise to find that the Oyster card is administrated over a web interface, so perhaps we should integrate that with our accounting package so that we can see our debits coming out of the bank account, and then drill down into the journeys.

Just making the phone into a ticket is limiting its usefulness, though. If you are connected to the network, the phone could know where you are and alert you just before you reached your stop. This would be handy for those people who tend to fall asleep and go straight past their stop. Also, it could spot if you are going the wrong way (oops, wrong platform and wrong train!). Clearly this could also work if we spread the ticket to cover “over-ground” rail and bus. It could do these tasks already, but it needs to know where you are going. If our application were tied to your calendar, then it would already know where you are going. If you had not put the trip into the calendar, then the phone could check while buying your ticket. It could even set an “out of office” autoreply on your email, add a calendar entry in to let people know where you are, and add the trip to your expenses claim form. Directing you to the right platform, the right train and then letting you know in time to gather your things together before you got there would be easy, too. Even more useful, for those unfamiliar with the tube system, would be help to find your way around the labyrinthine tunnels.

Identification

While we are at it, are there any other contactless cards we could add to our phone? Well, here at dunnhumby there is our security pass. Now, a phone can’t replace all the functionality of my pass because having a photo visible is clearly an important security element. The phone could do the door-opening part of its work, though. I’m less likely to be left behind than the standard pass, so let’s look at how it could work if I remembered my phone but forgot my standard pass.

If I left my pass behind I could swipe my phone at a kiosk at reception. The kiosk could then print out a photo of me, from my badge record, to hang around my neck. Clearly I need to show that I really am me, so I would be asked for a password and a few other details before being given the temporary pass. Now the kiosk could ask for those details, but so could the phone. The phone is, after all, a computer.

We could also look at putting a biometric check on the phone. These are available on laptops, so why not phones? It isn’t 100% secure, but it is better than we have now. Now the phone has an advantage over the kiosk as a place to check my biometric data, because it is somewhere I am more comfortable with the verification information being stored. It also prevents data redundancy, as I only need to have my personal details in one place rather than several. If we are doing security checks with the phone then we want to ensure that loss of the phone does not let it out into the world. What we really need to do is to make this another joint application, with the phone accessing a secure hybrid online interface and backup system on the Web. Clearly this will need the best security we can find, but if it has that then we can start tying the security aspects up with that credit card we were talking about earlier.

Security

So now we have a phone/web application that knows how to identify you and can be used in a quick and easy way to give you access to money, travel and work. This is clearly of value, so what happens if you lose it? Well first, it is a phone so you may be able to locate it: you could call it, or get it to use GPS to tell you where it is. But what if it was stolen? You can can easily cancel it through the phone network. But not only that, your new replacement phone can make itself into a clone of your old one as soon as you have verified your identity. So your new phone/card wallet is safer than the old credit cards you used before, immune to shoulder surfing, and tied into the way you run your accounts. With a credit card someone can clone it and access your account, but a phone can change the code it uses with each transaction so even a thief could intercept the code they couldn’t use it.

Given that our phone knows who we are it could also act as a key. Not just at work, but for our homes, too. You could control access to your house remotely to let people in; your house is connected to the phone network after all. If you were organising a party you could make access to your house part of the invitation email as you pick people out of your contacts on your home PC. They would be able to access their email from their phones, effectively making their own phones into “keys” to get in. You could set up visitor phones to have access once for a limited slot (that party invite perhaps), or regularly on certain days (the cleaner) or on a permanent basis (the boyfriend). You could then remove the permission straight away (during an argument in a restaurant, say) and not worry that they will come busting in later (I Will Survive might never have been written if it had been that easy to change your lock!)

Shopping

Mixing phone access with web applications can help enable spending, traveling, working and security; perhaps it can do more than that. It is already tied into the way you budget, so why not set it up so purchases over $20 require a fingerprint? As we put verification on the phone instead of the kiosk it is easy, and it won’t slow things down as you are holding the phone to wave it near the checkout anyway. If it’s a big purchase, say $100, you could set it up to ask for a PIN number too. It’s your phone so you can set the limits to amounts you are comfortable with. All of this adds security, but could also help you stick to a budget.

Let’s go further than that. Why not decide what weight we are happy to carry in a single shopping trip, and say that if you purchase anything over 10kg you will be willing to pay $5 for delivery. Pickers gather a basket for you at your local store, so if it is heavy why not put the basket we have gathered into the same process? Your phone can exchange contact details and pay at the same time. That is all very well if you are buying everything in one store, and we could do it even with an ordinary credit card and epos (electronic point of sale) access to preferences. What happens if you build up to 10kg across a few shops? If your phone keeps track of your purchases it could ask, when you go over the weight limit in one trip, whether you want the latest purchase delivered. Perhaps, as a slightly more costly service, the picker in store could take the basket you picked from all the different shops and get them all delivered? This could combine with your online mapping application to remind you to get delivery when you are in the stores that do delivery, even if that means popping into a nearby store. It would also tie up to your overall shopping trip and maybe your packing list too. Going on holiday? Make the application remind you when you are near any items you need to buy before you go.

If we are putting cards into our application then including contactless loyalty cards clearly makes sense. What are the advantages? Well, the first is that if your loyalty card and your payment mechanism are on the same phone then you can begin to get credit for all those small purchases that were not worth getting your card out for before. Pulling out your phone to pay is even less work than getting your money out of your wallet, particularly if you don’t have to count the money, just wave the phone. Again convenience is king, and adding convenience is actually providing customers with value.

In order to get at the other advantages of the loyalty card being on the phone we should, perhaps, touch briefly on what a loyalty card is:

  • A way for a retailer to say “Thank you for shopping here, do come again”
  • A way for you to tell the retailer which offers will interest you so as to keep the offers you are sent relevant
  • A way for the retailer to understand shopping habits so that they can become the type of shop that you, their customer, wants

In any interaction between a retailer and a customer, both parties must benefit. If this is not the case then the interaction will not happen. When you buy a loaf of bread the retailer gets your money and you get to eat; both sides benefit. The same is true for a loyalty card. By becoming the place you want to shop the retailer becomes more profitable and both parties benefit. In the way I have described the phone developing I have been talking about the benefits to the phone’s owner. Some of them are overwhelming, and will mean that market forces make them happen, but that will not necessarily make them as convenient as I have described. The bank that puts their credit card onto our phones first has an advantage and people will start to switch to them. This, in turn, will pressure all banks to move their credit cards onto our phones.

This won’t work if there is just convenience to the customer without a clear commercial beneficiary. I mentioned the possibility of your phone keeping track of what you bought and arranging for the shopping to be delivered, if necessary. If a shopping trip stays within a single shop then that shop benefits, but if a trip takes the shopper through multiple shops only the customer benefits from the phone doing this work. Equally, where is the advantage to the product manufacturer in making the weights of its products available to millions of phones? Likewise, if credit cards are being added to the phone, who is going to provide the platform that lets you add them in and remove them when it becomes necessary to, for example, change your credit card provider?

So, who’s going to do all of this work?

Perhaps it would make sense to create a deal similar to that for loyalty cards: customers provide some information about themselves in exchange for having the platform to add and subtract cards and to set limits, alarms, and alerts. Given that loyalty cards are doing some of this kind of work already, it might make sense to extend an on-phone card to include the platform itself. This would allow much closer integration between phone and online applications without the causing the phone to be costing too much in bandwidth. One possible benefit to the loyalty scheme might be the advantage of having control over the branding as settings are changed and alerts read. Given that the platform will require maintenance, and will run within a possession we have already shown is integral to everyday life, there is a need for it to be of the level of quality that only comes at a considerable cost. As customers, we could offer a willingness to receive non-intrusive targeted offers and advertising within the platform interface and additional information about ourselves for targeting those offers in return for the loyalty card company providing the platform. Neither one of these seems too high a cost for the value such a platform would provide for us.

This sort of deal with a loyalty card could have a significant advantage over phone manufacturers producing a home-grown solution: consistency. If convenience is king, then usability is the throne it sits upon. If something is not usable it is not really convenient. Usability comes from things working the way you expect them to without having to think. Given the rate at which we change from one phone to another, following fashions, we do not want to have to learn a new interface every time. We particularly do not want to risk having the way our credit card is protected changing continually. If your favourite loyalty card were the platform it could come with you. It will be a brand to rely upon to back up your phone and not accidentally delete your settings, your identification and half of your life.

Conclusion

Nearly all of the functions to be integrated that I mention here are either in use on phones in other countries or are already in development. For example, contactless capability, referred to as NFC (Near Field Communication) looks like it will be standard for most new UK phones in about 18 months or so; in Japan it is already how everyone uses their phones. This kind of convergence and integration has not really happened yet, but is clearly on the horizon.

So what is the future of web apps? They will tell us who we are, where we are, what we can spend and what we can spend it on. In effect, they can become the ultimate view nannies, always remembering the fact that the user will have set up the guidelines themselves.

The only question is not how far can the future development of web applications take us, but how far do we want it to go?

Continue reading 2
HTML5 Online Conference April 12 2010

14 May 2007

The number of mobile devices loose in the world greatly exceeds the number of desktop (or laptop) computers filling up desk and table space in offices and homes. The number of people who might view your site while clutching a screen measuring anywhere from 100 pixels to 640 pixels in width increases daily. Creating mobile-friendly content is quickly becoming less of an occasional add-on and more of a standard practice.

This article will take a look at how you can create mobile-friendly content, how you can test your work, and offer a few tips for writing CSS for the media type handheld. If you are a Dreamweaver or Flash user, we’ll also take a look at something new from Adobe that will help you test your pages for handheld devices.

Start with the basics

If you begin with standards-based HTML that is formatted with logical, semantic markup, you’re ahead of the game already. A well structured document with clear organization and semantic markup will display cleanly, be usable, and be accessible on any device – mobiles included. Using CSS to separate content from presentation means your content will be accessible, even on the least capable mobile device. Pay attention to other basics as well. For example, good alternative text is an essential for any non-text element in your pages. Make sure that form fields are properly labeled.

Clean, semantic markup is crucial when you consider the variety found in mobile devices. Some phones may only understand WAP. More capable phones may understand WAP2, which opens them up to rendering websites with XHTML and CSS. Some devices may display only monochromatic screen colors, while others may have full color. Some devices support CSS, some do not. Some only understand HTML 3.2, while others understand XHTML. Some devices undertand tables, floats, frames, JavaScript, and dynamic menus, but many do not. Most devices don’t support cookies. Devices at the high end of the mobile market such as BlackBerry, Palm, or the upcoming iPhone are highly capable and support nearly as much as a standard computer.

All those possibilities are enough to make you long for the days when the browser wars meant coding for Internet Explorer 4 or Netscape Navigator 4! But we have two things now that we didn’t have in the bad old days: a large body of knowledge about how to write standards-based HTML and XHTML using semantic markup and about how to separate content from presentation with CSS. If you stick to best practices in those two areas, the need to worry about every single rendering possibility from mobile devices diminishes and you can develop with confidence.

Testing your site

None of the free or fee-based testing options can equal the testing results you get with an actual device. I recommend testing with real mobile devices much as possible, but I know it isn’t feasible to run out and buy every single mobile device. There are some fairly reliable ways to test your site without going to that extreme. Some of the testing techniques are free, some are not. First, let’s look at the free options.

Opera provides two good testing tools. Using the standard Opera browser, select View > Small Screen to see your page rendered in an approximation of what a mobile screen might display. The Opera web developer bar has a button called Display that allows you to toggle CSS on or off when viewing a page using small screen view. Here you see two Opera small screen views of my blog, Web Teacher, first with CSS, then without.

Opera's small screen rendering with CSS Opera's small screen rendering with no CSS

As you can see, Opera renders the images in small screen view. (We’ll talk more about images later.) Note that the small screen view renders the content in source order, that is, the order in which the elements appear in the HTML. Elements are clearly distinguishable from a semantic viewpoint: headings, links, paragraphs, blockquotes. The organizational and semantic underpinnings hold up so that the content is readable and useable. This is especially easy to see in the second screen shot, with the CSS toggled off. Keep in mind that neither of the displays in the previous two screen captures are influenced by a handheld CSS media type stylesheet. When a heldheld CSS stylesheet is present, Opera’s small screen view will take it into account. More about this in a bit.

Opera provides a free browser that can be downloaded and installed on handheld devices. It’s called Opera Mini. (You can purchase Opera Mobile for even more capability.) Both are available at opera.com. Since Opera is in the business of providing browsers for mobiles, the company made a helpful online mobile simulator at operamini.com/demo. Here, you can load a page into the Mini Demo and operate it with mouse or keyboard as if it were a real mobile phone. The screen capture shows that the Mini Demo renders images and CSS. Again, there is no handheld CSS media type stylesheet affecting this rendering.

The Opera Mini simulator

Another free way to test your site for clear structure, organization, and proper semantics is with Firefox’s Web Developer extension. Use this tool to disable images, JavaScript, and CSS and you’ll have a good idea about whether your content is going to make sense and be navigable in one of older and less capable mobile phones.

Here’s a Firefox screen capture. For this, the Web Developer Toolbar was used to disable all CSS, all JavaScript, and all images.

Firefox with CSS, JS, and images disabled

Viewing the page without images and with no functioning JavaScipt is very useful in terms of testing for older mobile devices. Keep in mind that some of the less capable mobile devices don’t render tables. None of them understand frames. Seeing your site this way really drives home the importance of standards-driven, semantic markup.

Using specific emulators

Some of the phone and PDA manufacturers have emulators on their sites that you can download and use for testing. Depending on your target audience, testing on a specific emulator might be helpful. If you are interested in specific device or manufacturer, check their site for developer resources. (For example, Sony Ericsson’s Developer World, Nokia has a developer forum with an XHTML section,

Testing CSS Handheld media stylesheets

An important tool in the Firefox Web Developer Toolbar is CSS > View CSS by Media Type > Handheld. If you look at Web Teacher in a standard monitor, you see that it is a simple two column layout using a left float for the content div and a large margin-left to create the sidebar as a second column. I’ll add a stylesheet for handheld media to the testing mix. It contains only two rules — to reset the sizes of the content div and sidebar div and to remove the float. Here’s the entire stylesheet:


#content {
	float: none;
	width: 95%;
}
#sidebar {
	width: 90%;
	margin-left: 5%;
}

The link to this stylesheet was added to the document head after the all media stylesheet, so as to be last in the cascade. I’ll use a link element for this. For those mobiles that do understand CSS, using link is more reliable than using @import for bringing in styles, although some of the more capable devices understand @import. Here’s the link element:


Media types are mutually exclusive. A user agent can only support one media type when rendering a document. If I want to retain any of my existing styles in a handheld display, I need to take one more step, and that is to list all the media types I want my existing styles to apply to in a comma separated list. I change the link element for my existing stylesheet, which is called 2col.css to include this media attribute: media="handheld,all". The two link elements are now:



The styles and the color scheme I have in 2col.css should also apply to handheld renderings, but the two column layout will be removed by the mobile.css rules.

Testing with the Firefox Web Developer Toolbar menu CSS > View CSS by Media Type > Handheld should now show handheld media results, and it does.

The first screen capture shows the two column layout, as it normally displays with the all media stylesheet. The second shows Firefox using the handheld media view.

Firefox rendering the all media styles

Firefox renders handheld media

From the second screen capture, you can see that Firefox has expanded the content div to 95%, according to the mobile.css rules. If you scrolled down the page past the content div, you would find the sidebar div now displays at 90% width after the content div. Note in the second screen capture, that styles from 2col.css such as the presentation of the list under the title image and the background gradient behind the headings are retained because of the handheld media designation in that stylesheet.

You may not want to retain any of your all media styles in the handheld CSS rules, as in this example. Keeping the background images, for example, results in longer page load times. Since many wireless mobile devices load very slowly, you want to really simplify things for handhelds. In that case, simply leave the handheld media attribute out of your main stylesheet. I’ll give you more tips for simplifying things for handheld media shortly.

Testing with subscription services or with software

The testing tools I just mentioned are all free. There are other options that are not free, but you might find them helpful and worth the expense. Browser Cam, where you can test your sites in all sorts of browsers, has added a testing area called Device Cam. Here you can test a page in a smattering of Windows Mobile-based PDAs and several BlackBerry versions. Here’s a screen capture of the test page in a Device Cam rendering of a BlackBerry. Note the strong resemblance to what you saw previously in Opera’s small screen view when the CSS was toggled off.

Device Cam capture of a BlackBerry test

A brand new option for owners of Adobe’s latest CS3 software is Adobe’s Device Central. Device Central uses skins for dozens of mobile devices to display your content in various ways. Here’s a rendering of the test page in a Nokia 7390 skin.

Device Central rendering with a Nokia skin

Device Central can load a live URL or a file from many of the Adobe CS3 applications. It responds to the presence of a stylesheet of the handheld media type when the page is rendered using Opera’s small screen view. Using the Opera small screen view is an option with each of the skins in Device Central. Deselecting the option to view the rendering with Opera’s small screen view in Device Central rendered this page as two columns, in spite of the presence of the handheld stylesheet rules meant to eliminate that.

Tips for handheld CSS

Handheld media stylesheets can be more extensive than the two rule example I showed you previously. A few more rules would certainly benefit Web Teacher, but keep in mind that handheld stylesheets should be as small and compact as possible because of download time.

What can you do to simplify your site and make it more usable in mobiles? First, eliminate some of these problematic items from mobile display.

  • Eliminate floats and frames
  • Eliminate columns – one column with the content first is the best option
  • Eliminate scripted effects such as popups or pop out menus in favor of plain old HTML and simple text menus
  • Eliminate decorative images that slow down the loading process. Use display:none to remove anything that isn’t absolutely necessary, such as links to external resources. Remember, however, that devices that don’t understand CSS won’t do anything with display: none. Any essential images need to be reworked for the small screen and the width and height attributes need to be included in the HTML.
  • Eliminate nested tables and layout tables. If you have tabular data, consider finding a way to present it in a linearized alternate display.

Once you’ve simplified through elimination, start building the rules you need to add. Consider these ideas.

  • If you’re not already using relative measures, switch to ems or percentages rather than pixels
  • Reduce margins, paddings and borders to suit the small screen
  • Use smaller font sizes for headings and paragraph text
  • If you have a long navigation list at the start of the page, add a skip to main content link, or move the links to the end of document flow. Keep the number of clicks required to get to content as minimal as humanly possible. Without a mouse or keyboard, most mobile users have to click laboriously through any top navigation.
  • Make sure your color combinations provide good contrast between foreground and background colors, particularly for devices with fewer color options.

Tips for bloggers

Some blogging software provides the opportunity to format a single blog posting with several different templates, one of which can be meant for mobile users. This specially formatted and simplified material is posted to a unique URL on your site, perhaps something like mobile.mysite.com. If you’re a blogger, check your software to see if you have this capability with your blog. One important consideration for the mobile users of your blog is to keep the number of blog postings per page to a minimum for faster downloads.

In summary, making your site mobile friendly can be boiled down to a few concepts. Use validated, standards-based HTML or XHTML, ensure meaningful semantic markup with presentation removed to a stylesheet, and add handheld media rules as needed.

Continue reading 23

Sign Up to our Newsletter

Enter your e-mail address below to receive regular updates on web design, web development and web business. Subscribe today and receive a free 44 page PDF "Designing Web User Interfaces" by Ryan Singer of 37signals.

Subscribe to the Think Vitamin articles RSS feed

Future of Web Apps Dublin May 14 2010

News

Twitter

Follow us on Twitter

Subscribe

Article Subscribers

Feedburner blog subscriber indicator

News Subscribers

Feedburner blog subscriber indicator

Subscribe by Email

You can receive Think Vitamin updates via email. Just pop your email address in the box below and click the arrows.

Subscribe by RSS

You can also receive new Think Vitamin posts via your RSS feed reader

Subscribe RSS Think Vitamin is a proud member of the Smashing Network

Ads Via The Deck