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

[wwb_99]

One 10,000 lb gorilla we have been starting to tackle is mobile web applications. Now, there are a number of methods to go about this, but there are two basic paths:

1) Use simple HTML and mobile CSS to try and craft the same page to the mobile browser.
2) Build a separate mobile application, generally riding upon the core logic of the main web application.

I think both have merits and should be explored, but we have fallen squarely in school number two. The main reasons for this are:

1) Mobile CSS support is spotty at best.
2) Mobile users needs are different and you really do want to target them with different content and services.
3) The mobile browsing experience is so different that re-crafting even the best-thought-out of pages is very difficult. In many ways it is alot easier to just provide a different version.
4) Really applies to our systems, but I am generally dealing with things well-enough engineered to allow one to put a different UI layer on them without too much additional effort.

So, how are you all building applications in the mobile era? What is the strategy? How are you testing them? And has it been worth the effort?

[vgarcia]

I've used mostly #1 in the past, because I've mostly done mobile versions of text-heavy sites and they honestly didn't have much of a mobile audience to begin with. It's easy to add a mobile stylesheet and it's quick "support".

For a "real" application that had a larger mobile audience I'd use approach number 2. People have far less patience for tasks on a mobile device (for example, I wouldn't be building forms any longer than they absolutely need to be).

[dhtmlgod]

I've only worked on thin-client apps on a mobile platform, never a web-front ended application. But I would probably go for option 2 if I ever had to. 'specially if it's .NET 2

As for testing them, again slightly different but VS.NET has a mobile device emulator built in which isn't too bad. I had the advantage of working for a company that sold PDAs, so I could test anything on a variaty of models once I was happy with the emulator performance.

Worth the effort? For the company I worked for at the time, definetly! They saw a rise in order shipments of around 70% (I developed a stocktracking/barcoding system) so I would say it was worth the effort. But this was a client side app comminicating with some web services...

[Crimson77]

I'm still hoping it will all flop and we won't have to do anything about it. But I doubt I'm that lucky. Yet another task to be learnt.

[telos]

Let's face it, life is mobile. While this mobile mindset is still relatively new, we have to understand that it is not going away. As we get more and more mobile, and increase our thirst for content-on-demand, it is inevitable that users are turning to technologies that can satisfy their ever-increasing demands.

Much of the future of mobile technology is still being shaped and I believe that there will be a ton of changes and improvements in the near future. While I currently do not target mobile users, it is clear that traffic from mobile users will increase.

Honestly though, I think mobile technology will eventually start to (better) support our current languages/methods. I think it is ridiculous to assume that developers and content providers will double their efforts (and money) for all of their projects. I could be wrong though.

And with the rise AJAX, many sites will be rendered useless - unless of course, mobile devices start to support JavaScript, OR, the developer has already doubled their efforts to provide both an AJAX'd and non-AJAX'd versions on their site.

Either way, this will be a good discussion...

[vgarcia]

And with the rise AJAX, many sites will be rendered useless - unless of course, mobile devices start to support JavaScript, OR, the developer has already doubled their efforts to provide both an AJAX'd and non-AJAX'd versions on their site.

Opera's mobile browser can already run lots of AJAX powered sites. That doesn't change the fact that small screens still have to be taken into account. I don't want to sit there with a stylus and enter a paragraph or three of text for example, or scroll through a form that's a mile long on a 240x320 screen.

[wwb_99]

I've used mostly #1 in the past, because I've mostly done mobile versions of text-heavy sites and they honestly didn't have much of a mobile audience to begin with. It's easy to add a mobile stylesheet and it's quick "support".

I have done this a bit. Or, more properly, the html has been setup for accessiblilty, which happens to dovetail nicely with both search engines and mobile devices.

For a "real" application that had a larger mobile audience I'd use approach number 2. People have far less patience for tasks on a mobile device (for example, I wouldn't be building forms any longer than they absolutely need to be).

Quoted for truth.

Honestly though, I think mobile technology will eventually start to (better) support our current languages/methods. I think it is ridiculous to assume that developers and content providers will double their efforts (and money) for all of their projects. I could be wrong though.

I think things like mobile support really make disciplined development and separation of concerns much more important. We have been able to roll out "mobile" versions of some things simply by switching some stuff over to a stripped down template. This was easily done because the back-end objects were just containers for content and had no presentational logic embedded. Now, if you are not doing true 3-layered solutions, this can get trickier or involve much more work mobilizing content.

And with the rise AJAX, many sites will be rendered useless - unless of course, mobile devices start to support JavaScript, OR, the developer has already doubled their efforts to provide both an AJAX'd and non-AJAX'd versions on their site.

Having done a fair amount of surfing on a mobile device that supports scripting (Blackberries of various modern sorts), I would definitely advise not serving the scripted versions. The underpinnings of AJAX have been about since 98 or so (see MS Exchange 5.5 Web Mail, it is the worlds first big "AJAX" application). But a big part of the reason heavy AJAX stuff did not take off until recently is that you actually do need a faster machine and especially more RAM to make it work well. Check out yahoo mail's new version; it brings my fast machine to its knees at times.

How this plays into mobile devices is that they don't have the processing umph desktops do, so getting into an AJAX style UI can be painful for them. Furthermore, most users are paying by the bit, so constant remote-scripting tricks can get real expensive real fast for your users. The other angle is on many mobile devices, one does not have a free-form mouse cursor to click on things. Try surfing some ajax sites using tab, shift-tab and the left mouse button and you will see how infuriating the experience can be in some UI layouts.

[willsmith727]

In this months issue of .net Cameron Moll talks about this. Its a small interview, but worth a read. To me after reading the interview it comes across as if its not of utmost importance right at this minute, but could be soon.

After all, the .mobi domain names were just recently announced, so that could spark something? In the interview i believe, according to Moll, that he says the engine with which mobiles render our web pages is in the process of changing/upgrading. So that might make our lives easier when we start having to design for mobiles.

[Clenard]

I'm still skeptical about .mobi extensions but Mobile is growing rapidly lately. I know alot of people will even make claims that it has to do with .mobi but the fact is - it's not. More people are just finding that their mobile devices are easier and cheaper to use than ever.

I recently got a Treo 650 and find myself online (via Treo) half of the day now, rather than my Laptop. I like it that way too since I get more done in life lol

I definately agree with Mobile CSS Support issues. Right now there's too many different OS's and Browsers on Mobile phones and it will make life alot worse than the current Browser issues we face with IE, FF, Opera, etc.

I'd love to see more tutorials and articles on Mobile Sites, Apps, etc. on Sitepoint

[nukeemusn]

I've seen a lot about mobile web technology lately, but I also have to point out that not much has been said about wheter the technology is APPROPRIATE or not.

As someone else on here pointed out, this is a great article: http://www.alistapart.com/articles/landwarinasia/

I'd say that for most businesses, mobile web apps aren't needed. I personally don't plan on buying someing from, say, Amazon.com using my cell phone. Nor do I expect people to be visiting my web desing business site on their PDA. I, peronally, do very little web surfing aside form some news stories on my cell phone, becuase, frankly, it's a clunky interface to even make phone calls from!

I'm not saying that its an irrelevant issue, I'm just saying that poeple need to consider whether they really NEED it or not. Then figure out HOW to do it.

[kohoutek]

I generally do not design a page to suit screen and mobile at the same time. Designing for screen is a completely different field and holds different information architecture abilities that would not work for mobiles. I design for mobiles separately just as I provide an alternative stylesheet for print.
More work but the only solution in my view as I'm not going to reduce the visual design part of designing a website just to make a 'one-fits-all' site. For some sites this may be good, for most I've not seen this as a good approach.

[Dan Schulz]

It's not that hard to design for mobile using the same (X)HTML content, really. Just make sure that your images are no longer than 200px across. If you have to use a larger image for the traditional screen, you can serve it up with CSS instead.

[Crimson77]

Is there a 'link rel' or import option for serving up mobile content with CSS the same way you can make a print version?

[webfinity]

I haven't tackled it just yet. It is something that I've been wanting to do for a while. I'll keep an eye on this thread.

[Dan Schulz]

Is there a 'link rel' or import option for serving up mobile content with CSS the same way you can make a print version?

The link would be the same as if you were using a stylesheet for the computer screen, but you'd use media="handheld" instead of media="screen"

[Crimson77]

The link would be the same as if you were using a stylesheet for the computer screen, but you'd use media="handheld" instead of media="screen"

Thanks for that. Will this work with all handheld devices? or are there some that don't recognize the link?

[Dan Schulz]

Sorry, I'm not qualfiied to answer that question. Not yet anyway. My own personal gut feeling tells me though that some will, and some won't. The only thing to do is to try.

FireFox's Web Developer Toolbar has a "small screen" mode you can use; Opera does this natively, and for actual handheld devices, you can get emulators here:
http://developer.openwave.com/dvl/to...ator/index.htm
http://www.forum.nokia.com/info/sw.n...olkit_4.1.html

[bcr]

I'm still hoping it will all flop and we won't have to do anything about it. But I doubt I'm that lucky. Yet another task to be learnt.

Haha, that's pretty much how I feel too. Unfortunately, I think it's going to get more and more common. I'd imagine in places like Japan it's already a normal thing to do.

[vgarcia]

Thanks for that. Will this work with all handheld devices? or are there some that don't recognize the link?

Some will totally ignore the CSS. Some will apply handheld. Some will apply screen styles (like older pocket IE, not sure about the newest versions). Mobile browsers are a big minefield sometimes.

[wwb_99]

^^^This man speaks the truth. The best quote I have heard about mobile browser support issues is that it makes the browser wars of the late 90s look fun and easy.

We finally settled on a tactic of serving very simple html and letting the devices deal with the rest. This would work reasonably well on everything from my trusty old Nokia 6010 to newer blackberries, and actually produced reasonably usable pages.

There are other issues, like differing screen resolutions which also make this interesting.

I've seen a lot about mobile web technology lately, but I also have to point out that not much has been said about wheter the technology is APPROPRIATE or not.

As someone else on here pointed out, this is a great article: http://www.alistapart.com/articles/landwarinasia/

I'd say that for most businesses, mobile web apps aren't needed. I personally don't plan on buying someing from, say, Amazon.com using my cell phone. Nor do I expect people to be visiting my web desing business site on their PDA. I, peronally, do very little web surfing aside form some news stories on my cell phone, becuase, frankly, it's a clunky interface to even make phone calls from!

I'm not saying that its an irrelevant issue, I'm just saying that poeple need to consider whether they really NEED it or not. Then figure out HOW to do it.

Very, very valid points. We make two sorts of mobile sites:

a) We run a major conference, so we thought it would be neat to have a mobile site for use while at the conference. Especially considering most of our attendees have higher-end blackberries and such so mobile web works easily for them.

b) Intranet-style mobile applications for staff. Conveniently we are pretty standardized on blackberry 7250s and 90s which behave very similarly in terms of browser behavior.

In any case, I would add one more question to your last paragraph: figure out what parts of the application have a mobile use. For example, the mobile conference site just served:

1) Exhibitor list (find people on the floor)
2) Hotel list (find people to drink with)
3) Stripped down schedule
4) Session list
5) Speaker list

We did not bother porting the other ~100 pages of content over to the mobile app as it was not worth the trouble.

PS: Missed this one:

I'm still hoping it will all flop and we won't have to do anything about it. But I doubt I'm that lucky. Yet another task to be learnt.

This is very unlikely. If anything it will become more prevalent as mobile devices and connectivity improve and people become more accustomed to reading from the small screen.

Still, it really does reinforce that content is king. No one I have ever spoken with has cared how our mobile apps look so long as they worked and were snappy on their device and connection.

[MBScott]

I have only one client whose content is appropriate to mobile, and he let me know just yesterday that he's ready to go! Fortunately, he understands that the entire site is NOT necessary or needed for his mobile audience, so we'll go with option 2, just to serve up the data that his users would need.

Our stumbling block right now is, how to make his data searchable. Right now, we're using a third party app to search content for users to find the data files they want. Is this going to be portable to a wireless app? I guess we'll find out.

My initial reaction to his request to make the site wap was one of panic, but the more I've looked into it, the easier it is going to be! (YEA)

You guys will have to keep your fingers crossed for me on this one, but I'll let you know how it goes!

Missy

[deathshadow]

As the technologies have moved out of the dark ages, the very need for things like mobile CSS and WAP starts to be called into question - The current generation of handhelds are leveraging more horsepower than desktop systems of just five years ago - Even the crappy sub $200 Palms are pushing out 300 to 400mhz ARM processors, with the mainstream units from HP pushing past 500mhz. Combine this with several future techs like multi-display and the more capable 'thin' browsers like Opera Mini or Opera Mobile - and one really begins to question the NEED for a 'reduced' version of a website, when the newer units can handle the full blown HTML/CSS quite well...

One look at the Nintendo DS shows that - as does IE6 under Windows mobile '03.

It's not there yet - but in just a few years I think you'll see the need for coding two versions of a site just to support mobiles going the way of the dodo...

I'm really hoping it does - there's no reason for a modern handheld to not be able to do things I used to do on a 386/40.

[NikLP]

Personally, I reckon rebuilding a site purely to serve mobile content is total overkill unless there are very good reasons, i.e. specific applications. (e.g. Orb)

The real core problem here isn't Javascript support, or development platforms, or even time/effort, but CSS support in mobile browsers. Realistically, I feel we should be putting pressure on developers of these browsers to move closer to standards support, and certainly employing support of the "media=handheld" directive. That's the real killer, IMO.

Certainly some support can be given to the idea of re-deploying a portion of a site, based on need, in certain circumstances. However, just because mobile users only "need" a specific portion of the site, doesn't mean the remainder of the content should be excluded from their browsing experience, surely?

I realise that with each site there are varying reasons for choosing each development solution. My suggestion to the lazy and/or hopeful is to use the handheld media directive and see what happens next. If the important bits of the site break, you could fix them accordingly where possible, and let the rest be a little wonky. It's the content that's important - if that's working how it needs to, then the rest is irrelevant (to a point) as mobile web users are pretty much used to half of web pages breaking in their browsers.

I, for one, am rather sick of being told I can't access certain pages because the browser I'm using on my mobile isn't supported, as someone has decided to "go mobile" in certain parts of the site, but disallow mobile access to other areas. Other times the browser doesn't support even the simplest CSS instructions, which is rather frustrating. This is an issue for browser developers though, not web developers - we aren't the ones who should be fighting the "browser wars"!

The whole point of web standards was "design once, develop once, deploy once". Unless I missed something...? If that means three stylesheets, that's one thing. A whole new interface, and associated .aspx (sic) files etc and multiple development threads is totally another. Ajax shouldn't even enter the equation! Accessibility should be inherently part of anything considered to be "web standardised" and all interactive content should degrade gracefully, regardless of development or browser platform.

I'll no doubt get some flak for this but hey...

[vgarcia]

As the technologies have moved out of the dark ages, the very need for things like mobile CSS and WAP starts to be called into question - The current generation of handhelds are leveraging more horsepower than desktop systems of just five years ago - Even the crappy sub $200 Palms are pushing out 300 to 400mhz ARM processors, with the mainstream units from HP pushing past 500mhz. Combine this with several future techs like multi-display and the more capable 'thin' browsers like Opera Mini or Opera Mobile - and one really begins to question the NEED for a 'reduced' version of a website, when the newer units can handle the full blown HTML/CSS quite well...

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?

Hardware and software really aren't the problem with mobile interfaces. It's mostly a usability problem when you try to get your PDA to do stuff meant for a desktop computer.

[wwb_99]

Vinnie speaks the truth. While, from a technical standpoint, it would be nice to have the concept of write once-display anywhere work, it really does not make sense. You use your mobile browser in different times and spaces and ways than your desktop browser. It should be treated much differently from a usability/content creation standpoint. One actually probably wants a wholly different site from a mobile standpoint.