homepage Welcome to WebmasterWorld Guest from 54.166.148.189
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / WebmasterWorld / Accessibility and Usability
Forum Library, Charter, Moderators: ergophobe

Accessibility and Usability Forum

    
Designing for the Mobile User
Considerations and Techniques
trillianjedi




msg:1582806
 6:18 pm on May 30, 2006 (gmt 0)

I knew I was going to end up in this forum sooner or later.... ;)

I've decided to make one of my sites "mobile friendly". I own a Blackberry, so I have a rough idea of what's entailed. Here's the basic design criteria, off the top of my head:-

- 5-10k page size max
- No Javascript
- No images
- No CSS file
- No cookie requirement
- Nav menu at bottom of page
- HTML headers cut to absolute minimum, possibly containing just title and "NOINDEX" tag.

Standard markup basics will be used - H1, 2 and 3 with Paragraph tags only. No stylesheet. My Blackberry marks up pages quite nicely in that way, I've checked.

That would suit me, on the Blackberry. What would suit you on your device?

TJ

 

trillianjedi




msg:1582807
 2:22 pm on May 31, 2006 (gmt 0)

A couple of further thoughts.

I've read the W3C's Device Independance initiative here:-

[w3.org...]

It seems the, somewhat Utopian, ideal is to have just one set of mark up that can be viewed on the widest possible subset of browsers. So no changes - you build pages that from the get go will render equally on mobile or PC based browsers.

Is User-Agent based delivery something that's frowned upon in this context? Does the fact that my pages don't render especially well (they're not bad, just could be better) on mobile devices indicate a deeper design problem?

I have also now found the @media CSS directive (HTML 4.0) and media="handheld" references:-

[w3.org...]

I haven't seen this before and I'm curious as to the best way to use these directives and references to best effect. Anyone doing anything with this?

Thanks,

TJ

encyclo




msg:1582808
 1:08 am on Jun 2, 2006 (gmt 0)

There are three basic approaches to dealing with mobile phone/PDA users:

1. Let the markup handle it

The first approach is the W3C way, using semantic markup and table-free designs meaning that you are already sending lean and meaningful markup to all devices. The HTML stays the same throughout, whether you are viewing on a regular monitor or a phone screen. The @handheld CSS rules come into the equation here.

The advantages are that you are making your site device independent, vastly simplifying your management and leveraging web standards to deliver your content to the widest possible audience.

The downsides are that phone/PDA support for CSS, in particular handheld stylesheets, is patchy (with many simply applying screen rules, often badly), and that if you don't differentiate then you may be serving inappropriate content (large graphics, extra text...) instead of a simplified page, reducing your site's usability.

  • Reference: W3C Device Independence Activity [w3.org]

    2. Let the browser handle it

    In particular, we are talking about modern phone browsers such as Opera [opera.com]. Opera is a leader in this area, and that browser uses small-screen rendering technology to intelligently modify page layouts to display them logically within the narrow confines of a phone screen. This means that you can continue using tables, fixed widths, etc. and the browser will override when needed and do a great job of reworking your site built for 800x600 screens.

    The advantages are again that you need to do very little - just let the technology do the work. Same downsides as the standard markup approach - the browser can only do so much to make your site mobile-friendly, and you are relinquishing any control over how your site will function on a small screen.

  • Reference: Opera's Small-Screen Rendering [opera.com]

    3. Let the server handle it

    This approach is more complex, but can produce good results. It depends on browser sniffing and server-generated output, serving simplified markup and reduced content specifically designed for small screen situations. This can be a redirect to a mobile-content subdomain or domain or user-agent based page generation.

    The advantages are that if you can accurately detect phone/PDA users you can tailor the output specifically for them, with lower page weight, reduced clutter and fewer images.

    The downsides include the complexity of the user agent identification process (browser sniffing is fallible), and it requires active long-term management to cater for new phone and browser releases. Also if you use a separate URL structure, it can create a duplicate of your primary site unless you are careful to disallow indexing of the mobile-specific content.


    Ideally, you will consider a combination of methods - your site should be using mobile-friendly markup which can be used not just by regular browsers and phones, but screenreaders and other devices too. You can test your sites in Opera - just press Shift+F11 in your regular Opera browser. You can also look at detecting common phone user agent strings of IP addresses for phone proxies and tailor your content output from your database to get a better result for those visitors.

    What approaches have others used for dealing with phone users? Is anyone testing their sites on small screens?

  • trillianjedi




    msg:1582809
     1:23 pm on Jun 2, 2006 (gmt 0)

    Thanks encyclo.


    1. Let the markup handle it

    The downsides are that phone/PDA support for CSS.... is patchy

    How about a combination of tactics?

    Ensure the original markup renders OK on a variety of devices without the CSS file, then use a user-agent based delivery system to deliver pages without the CSS file in the header, if that user is on a mobile device?

    2. Let the browser handle it

    downsides.......relinquishing any control over how your site will function on a small screen.

    I think that downside rules this out. It's preferable to retain that control as it's impractical to test a site design on every single browser you can lay your hands on, so without knowing what it'll look like, it's probably better to be able to rely on "vanilla" markup. The "just keep it simple" approach.

    Is it safe enough to assume that non-styled markup will render reasonably well on a mobile screen?

    Let's take some example code (I'm particularly interested in hearing from any mobile users for whom this would render badly):-


    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <html>
    <head>
    <title>Mobile Test Page</title>
    </head>
    <h1>An example of "vanilla" markup</h1>
    <h2>What does it look like?</h2>
    <p>It is hoped that this page would render well on pretty much any browser ever built. If it doesn't, I think it would be fair to blame your browser, not my markup.</p>
    </html>

    3. Let the server handle it

    The downsides include the complexity of the user agent identification process (browser sniffing is fallible), and it requires active long-term management

    Is it possible to simplify the user-agent ID process by looking for basic Mozilla etc variants and assuming they're not mobile devices?

    Also if you use a separate URL structure, it can create a duplicate of your primary site unless you are careful to disallow indexing of the mobile-specific content.

    Most sites I've looked at have a separate URL structure (mobile.example.com or wap.example.com etc). It seems a good idea. Duplicate content issues should be easily dealt with by either putting noindex tags in the page or using example.com/mobile/ and banning bots from the sub-directory from within robots.txt (although interesting thread about google indexing anyway over here [webmasterworld.com]) .

    Ideally, you will consider a combination of methods

    I'm seeing this as the way forward. My current gut-instinct preference is to use very very standard (what I've been calling "vanilla") markup and just not serving the CSS file to mobile users.

    TJ

    I'm going to re-iterate your questions so they don't get lost and add one of my own:-


  • What approaches have others used for dealing with phone users?

  • Is anyone testing their sites on small screens?

  • Are there any phones out there that render this kind of "vanilla" markup badly (standard H1 size overly huge etc)?
  • DoingItWell




    msg:1582810
     11:58 am on Jun 5, 2006 (gmt 0)

    trillianjedi, te paragraph below the h2 tag is VERY long in a mobile context. Consider using a screen with 100x160 pixel - it's not vey much, and that line is gigantic. No formatting problems, but a problem because screen area is a "big" issue.

    I'm a co-founder of a discussion group about WAP from back when we had "our own markup", and WML/XHTML/HTML convergence is not a new topic. The first made-for-mobile site/service I set up was for a travel destination website. I figured: what are mobiles good for? Calling phone numbers. I made a WAP site that contained tourism sites, restaurants, hotels, alarm calls, credit card theft reporting numbers etc. with links that you can click directly on the WAP page, and your mobile dials the number of the place you're interested in.

    When you go for full convergence and use HTML/XHTML then you lose that kind of functionality. Most mobile developers send content based on for one thing the UA reported, and have several differently sized images depending on the receiving model. Convergence is great - if you don't lose functionality. Another of the founders of the discussion group resigned from the W3 workgroup because he was frustrated by the lack of understanding of the level of adaptation that is necessary in the real world for mobiles.

    PDA's are another thing. I just visited this thread unsig my iPaq, and it looked quite good. Hadn't considered visiting WW like that before, but I will now. :-)

    Erku




    msg:1582811
     2:35 pm on Jun 7, 2006 (gmt 0)

    I have tried to shy away on mobiles because you can't monetize on them.

    How can you display ads?

    mattglet




    msg:1582812
     2:47 pm on Jun 7, 2006 (gmt 0)

    I have tried to shy away on mobiles because you can't monetize on them.

    How can you display ads?

    Not everything on the internet is dependant on ads for revenue, much to some people's utter disbelief.

    Informational sites, or even (properly done) ecommerce sites are perfect candidates for conversion to mobile devices. If you are away at a relative's house for an extended vacation and need to order something from the internet, you can do so on your mobile and have it shipped to you. Just one of many many examples.

    mrMister




    msg:1582813
     3:00 pm on Jun 7, 2006 (gmt 0)

    I have tried to shy away on mobiles because you can't monetize on them.

    How can you display ads?

    Think of it as an investment for the future.

    If you can get a stranglehold on your niche now then you'll be in a perfect position to profit from it when the technology improves and the gold rush starts.

    Amazon was founded in 1994. It took them a long time to start making a profit.

    encyclo




    msg:1582814
     3:18 pm on Jun 7, 2006 (gmt 0)

    Many modern mobile browsers are starting to support Javascript etc. - ad placement and format is just another part of the equation when considering how to present your content. How about Google's AdLinks for an example?

    DoingItWell makes an important point - the small screen is not just an issue when it comes to layout, but also to the kind of content and the length of pages required for an optimal mobile experience. Just as you can't transpose a magazine or newspaper format to the web, if you simply use your standard pages then you are not adapting to the medium. So is brevity as important as simplicity?

    ebound




    msg:1582815
     3:34 pm on Jun 7, 2006 (gmt 0)

    Is there a common naming convention that is being used to brand mobile access to your websites?

    example:
    mobile.widgets.com
    widgets.com/mobile

    Any others? Which is best? Opinions?

    cabbagehead




    msg:1582816
     8:31 pm on Jun 7, 2006 (gmt 0)

    I would personally see the mobile app as a seperate application module. Thus I think it would be appropriate to use a seperate namespace: mobile.xyz.com

    asomervell




    msg:1582817
     11:11 pm on Jun 7, 2006 (gmt 0)

    I've set up m.domain.co.nz and am using it as my beta, I'll use the "M" Brand on the site to push online users to it

    There's an awesome PHP class that knows what all 800+ mobile variations are and their limitations, lets you query whether the user can accept certain things so you can build a combination of markup and server side differences.... cant remember what its called tho

    rushglen




    msg:1582818
     2:19 pm on Jun 8, 2006 (gmt 0)

    Mobile UserAgent classes (php):

    [phpclasses.org...]

    br4inwash3r




    msg:1582819
     9:48 pm on Jun 9, 2006 (gmt 0)

    I've just had a small chat with a fellow developer yesterday. he specialize in developing mobile content. there's two things that he emphasize when publishing for mobile devices. "think about semantics and use proper mark-up".

    and about this...

    Nav menu at bottom of page

    he also sez you should put your navigation links on top of the page. but put a "skip to content" link somewhere near it ( e.g. the webstandards.org site ). hehe, now I understand what those links are used for.

    Ulkari




    msg:1582820
     9:51 am on Jun 13, 2006 (gmt 0)

    The .mobi TLD has been created just for that.

    [mtld.mobi...]

    This is where the future is. Backed by Google, Microsoft, Nokia, Samsung, Ericsson, Vodafone and a bunch of others.

    trillianjedi




    msg:1582821
     9:55 am on Jun 13, 2006 (gmt 0)

    he also sez you should put your navigation links on top of the page.

    That's interesting. I can only speak on the basis of personal preference, which is to have them at the bottom.

    I guess it depends a lot on the content and how easy it is to get to.

    I like the anchor idea - skip to content, though.

    The .mobi TLD has been created just for that.

    If you have a registered trademark name, registration for .mobi opened yesterday (12th June) - general registration starts 21st August 2006.

    Global Options:
     top home search open messages active posts  
     

    Home / Forums Index / WebmasterWorld / Accessibility and Usability
    rss feed

    All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
    Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
    WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
    © Webmaster World 1996-2014 all rights reserved