Movin' to Mobility--what's your take?

[Dorsey]

As someone whose existence crosses the web/mobile barrier, I want to add our experience and conclusions to this thread. I have to provide a little background on us and our users (this is NOT an ad) so you'll see how we got to where we are now.

We run a dating site in the U.S. that provides anonymous text and calling among our members. Our market is those who are tired of the same old email-based dating sites with phony pictures and profiles. Our members want to speak with other members quickly and judge for themselves - if the person is real, fine; if not, move on to the next one.

While we have a full-blown web site, we strongly encourage the use of mobile devices (phones, mostly) for hooking up while in bars and other social venues. Given the limited display area and restrictive interaction for forms and such, to say nothing of the wide range of capabilities, we decided early on to develop two parallel sites with identical functionality; one in HTML the other WML. When we began over a year ago, we hoped to "build once and deploy many times" via CSS, but that just wasn't feasible. I challenge anyone to simply change style sheets and make their site continue to work as well as the non-mobile version when viewed in a cell phone browser. As pointed out by some here, you quickly find that you have to split forms, restrict menu options, limit links, and on and on to accomodate limited browser features. We're not talking PDAs here, but lowest common denominator devices. It is not a mechanical (i.e., CSS) translation; it requires re-thinking the way the user interacts with the device, just as you gave careful thought to the web site.

If you need to make your site available to those with sophisticated mobile devices, especially if you can guarantee that your users all have the same device, by all means use CSS, but understand that even then, it's not a magic bullet that will solve all your problems.

If anyone wants to see what we've got, go to www.zogo.com. Oh yes, you can use a web browser or cell phone equally well.

[MBScott]

How do you figure out where to send which user? I mean, if I go to zogo.com with a web browser, it displays. But if I go to zogo.com with my cell, how do you figure out which type of display to use?

The problem I'm running into is that some cell browsers have an OS installed, and want html pages. Other cell browsers only want wml.

So, how do you direct where the user goes?

Missy

[phpster]

We too are looking at mobile apps. I have had some success with changing our forms out to xml and using js to format it on a pocket pc 2003 ... our big issues revolve around working out how to separate our forms into smaller sections since some of our pages are around 100K and our forms are generated dynamically based on the user designed forms.

We are continuing on the course looking at windows mobile 2005(though that platform seems very unstable right now no matter the device).

[NikLP]

So, how do you direct where the user goes?

Missy, I don't know much about 'old skool' browsers, but most these days will be looking for html, hopefully. If you're using ASP.Net 2 nd VS2005, your problems should be easily rectified, as this system has built in browser "morphing" (for want of a better phrase, or actually being able to remember the real one...).

You can easily set that up so that the web app will display different versions of the output code/css etc for various browsers. You can "define" browsers (it recognises common ones by default) by analysing the Agent string from the HTTP headers that IIS receives (IIRC, off the top of my head).

If you're leaning more towards the PHP methodology, you want to be sniffing the Agent string manually I guess, or using some fancy class to do it . I don't know about Java, and I'm not touching Rails with a pole!

To be honest, that's the limit of my knowledge - I've investigated in brief the possibilities, but never implemented anything, as I've always hoped that browser developers would catch up, and I'd never have to develop anything large enough to require two versions!

[vgarcia]

^^ The user agent header is easily faked and shouldn't be relied upon to serve varying content unless you have no other choice. Even then I would be worried.

Use the HTTP Accept header if you can.

[wwb_99]

For redirecting users, I actually let users redirect themselves using items that are hidden by normal CSS but show for mobile users.

I really find browser detection to be a bad game. HTTP_ACCEPT does not work so well for mobile devices given that they also accept text/html, etc. Using UA strings is folly because they are changing so rapidly that one will end up spending lots of qt tweaking the settings to bounce people to the right place.

While the adaptable rendering featured by .NET is slick, I still think it falls into that same trap every other technical trick used to serve the same pages to mobile and standard browsers does: you really need to have a fundamentally different application for mobile users. Now, this should not necessarily effect the core logic and middle tiers of an application, which is where most of the smarts should lie anyhow.

[Dan Schulz]

Yeah, take what you learned about the browser wars and browser detection and apply it to mobile apps. Detect OBJECT support, not browser support (though this may be harder on mobile user agents than traditional Web browsers).

[MBScott]

oboy.

Here's the lowdown, so far: The target audience we're going for will have sophisticated equipment (I mean the data files we need to send them would be for gps-enabled phones and dashboard devices) and so we're probably looking mostly at a Windows OS and decent graphics.

I just cannot wrap my mind around HOW to accurately find out screen size and send them to the right place. The only time I ever do any browser detection is to serve up an IE vs Firefox CSS.



Missy

[Dan Schulz]

Stick to a general width of about 200px and you should be fine.

As far as detecting mobile support (if you use WAP) that I'm not sure of. I just prefer to create once, deploy everywhere.

[brandaggio]

Do you want to fill out a 100-question quiz on a mobile phone or PDA? Do you want to read paragraphs about last night's baseball game when on a 320x240 screen, or do you just want scores and highlights presented in an easy-to-digest manner while you're on the move?

It sounds like this could be an argument for handheld CSS and graceful degradation (hide stuff, show stuff, make the layout simpler etc.). I realize that support is spotty, but the reality is handhelds will get bigger, richer displays and be able to handle the format of regular pages far better. This, it seems, will be ubiquitous in 1-2 years.

I definately see both sides of the argument. We have providers who have an interest in things being somewhat fractured (read .mobi) and developers who have an interest in standardization. Either way, creating CSS just for handhelds or using different markup would require some creative thinking.

I imagine that in reality there are situations where handheld CSS would be more than adequate (in a lot of cases - if done right) but that a platform/hardware specific app might also be required for a particular client need (like for some internal inventory app for which the client already has somewhat older Palms to use - or for an app that will be used in a particular way - like something the Fedex guy might use on the road). The situation/requirements should determine the approach - doesn't seem like there is any hard and fast rule that says one way is inherently better for all uses.

[Tijmen]

As far as detecting mobile support (if you use WAP) that I'm not sure of. I just prefer to create once, deploy everywhere.

This should be usefull for doing that, wurfl.

the WURFL file contains information regarding wireless devices' configurations, capabilities and features. The main scope of this file is to collect as many information as we can about all the existing wireless devices that access WAP pages

[Dan Schulz]

Learn something new every day .

[cereal_girl]

So, even if you've decided which design approach you're going to take, there are still some hurdles to tackle.
The big one for me at the moment is testing. Even if i put something together targeting the mobilw audience, I honestly have no idea how it's working in the big wide world - there's just too many variables in devices/ support, and I'm not aware of any great testing tools/platforms yet.
Do you folks have anything up your sleeves to handle that?

[brandaggio]

So, even if you've decided which design approach you're going to take, there are still some hurdles to tackle.
The big one for me at the moment is testing. Even if i put something together targeting the mobilw audience, I honestly have no idea how it's working in the big wide world - there's just too many variables in devices/ support, and I'm not aware of any great testing tools/platforms yet.
Do you folks have anything up your sleeves to handle that?

If you read through this thread thoroughly you will find a number of links to articles and tools to help you create, serve and troubleshoot mobile content. The thread is not that long - just start at the beginning - we have been having a fairly thoughtful conversation, covering all sides as best we can.

Have you decided as to whether or not you are going to use a handheld stylesheet to serve to mobiles or a whole seperate site/codebase? Perhaps I/we can make a better suggestion based on what approach you would like to take - reading through the thread might help you decide.

[cereal_girl]

Sorry...
Personally, I think there's a lot to be said for unique content and stylesheet for handhelds. Mobile users simply have different needs.
Anyways, I've tried a few different approaches, but haven't nailed down anything that really works for me. So far, my efforts have been pretty feeble, but I''ve been wanting to deal with that "10,000 lb gorilla"
Testing has been the biggest issue. I'm not confident that Opera and FF small screen are giving an adequate picture of how my pages are going to perform in the real world...
I guess I just wondered if there were just some other indispensable tools out there that I didn't know about.

[MBScott]

I'm with you, cereal girl! Someone else said (and it is someone around here whose opinion I usually listen to) that he prefers to create once and deploy everywhere.

When the client started this website, there was no such animal as WAP! I mean, I might prefer that, but the client prefers that his site work on each device.

And it's not a DESIGN issue, totally. I wouldn't care if it were totally text, if it would work. There are other issues:

-in search results, it would be annoying to display only 5 results in a page on a PC screen. But 5 results on a handheld is almost too many. I could have the user choose how many results he wants displayed, but we're trying to do this so that it's EASY for the user, not where they have to decide (and push tiny buttons) everything.

-right now, the search function is handled by a third party (client's choice, not mine).

-some handhelds want html (fine), some want wml (fine, too). I don't mind deploying both, but I can't find a way to accurately detect which device wants which language.

-I'm with cereal girl, too... testing is nearly impossible, even just for the smallest thing. The tests we've done have failed... clients handheld (which wants html) tried to download a wml file (meaning the redirection didn't work) and my handheld (which wants wml) got redirected incorrectly too. That would be 0% for language detection.

Grrrrr.

Missy

[brandaggio]

Someone else said (and it is someone around here whose opinion I usually listen to) that he prefers to create once and deploy everywhere.

And it's not a DESIGN issue, totally. I wouldn't care if it were totally text, if it would work. There are other issues:

Take a look at the code in this chapter - it should help give you a handle on reasonable approach to serve your pre-exisiting HTML to handhelds that support it (most new handhelds can render HTML with little trouble), but tailored slightly for smaller screens via a handheld stylesheet. Hopefully it won't be as hard as it has been with some solid examples to deconstruct.

[MBScott]

John said:

serve your pre-exisiting HTML to handhelds that support it (most new handhelds can render HTML with little trouble),

right... this is easy. What isn't easy is that not all handhelds can render html. What is difficult is finding out from the device what it wants and will render.

Missy

[brandaggio]

John said:

right... this is easy. What isn't easy is that not all handhelds can render html. What is difficult is finding out from the device what it wants and will render.

Missy

I made the same suggestion Dan did (just with some illustrative code) which you seemed to be very receptive to when coming from him (I am sorry I don't have a banner next to my name but perhaps someday I will be so endowed) - not knowing how far along you were (and noting you were willing to make some cosmetic compromises) I offered some working code examples that seem to do what you seemed to think was a good idea.

Of course all of these different devices are hard to target - it is not that dissimilar to deciding on what browsers (and platforms for that matter) to support for any website (in particular those with a wide audience). Time is money - make the compromises where you see fit - it is neither practical nor possible to target every handheld device available and get your site/pages to render identically. Life and work are full of compromises - this is another situation that requires some.

[Dan Schulz]

Hey John, I didn't even want the banner. Fortunately the time has nearly come to give it a new home .

[brandaggio]

Hey John, I didn't even want the banner. Fortunately the time has nearly come to give it a new home .

Dan you deserve it - and you know I genuinely feel that way. I believe strongly in letting people know they are doing good work - not enough positive reinforcement going around if you ask me. Unfortunately, it seems to somehow lessen the credibility of those in a thread that don't have one as people tend to gloss over what you say.

[cereal_girl]

Well, I can see Dan's point. Almost every web project involves making some sort of compromise.
I have a strong focus on accessibility though, so I'm never quite comfortable with a compromise that means my site is going to be totally unavailable to a number of users.
Is there no alternative? How many clients are left out by the styled html approach? .2%, 2% or 20% - really, this the question to ask when making such compromises.
And one that I haven't the faintest idea how to answer - hence my own confusion in which approach to take... that's where I was hoping you folks could help.

[Dan Schulz]

I think the question in your case will be what types of handheld devices will your client's visitors be using? The answer to this question will determine whether you can go with a handheld stylesheet, or will have to go with the (IMHO) obsolete WAP/WML option.

[cereal_girl]

So I guess this is starting to look like a familiar road...
In the early days of CSS (when browser technologies were all over the map) we were sometimes forced to make a bit of a choice - ultimately, it took a decision on the part of developers to adhere to certain standards (ie: sometimes optimizing semantics rather than presentation) to bring about a move towards consistency on the part of the companies making the technology.
It sounds like this might be the same crap, even if it is a different pile.
if WAP/WML doesn't cut the mustard anymore (and I would agree that it certainlty doesn't stand alone) then I guess I have to start asking myself if it's time to make the move to the preferred, more standard technique (html/stylesheets (?) XML(?) (???), serving up handheld-tailored content) with the understanding, that, in time, it will reach a larger audience.
And that the change won't happen until we make it happen...
I guess I'm not sure we're really at that point yet?
(And it still leaves me with questions about effective implementation)

[Dan Schulz]

With mobile user agents, it will really depend on what your target audience is.

If the people you expect to be using your mobile site have the latest and greatest in technology, and can actualy support HTML/CSS, then go for it. If instead they're using old clunkers that need a lot of hand-holding, go with the WAP/WML route.