James,

I totally and 100% agree with you.

I try and encourage all clients to support all the top browsers, the problem
we're seeing is their isn't always a strong ROI in delivering multiple
experiences. Clients often have very high expectations of the experience however
rarely the budget to see it through on all the "Class A" devices.

The sentiment we are seeing in the marketplace is best summarized by Joe
Hewitt's tweet:
"I want desperately to be a web developer again, but if I have to wait until
2020 for browsers to do what Cocoa can do in 2010, I won't wait."

-Brian


--- In mobile-web@yahoogroups.com, "James Pearce" <jamesgpearce@...> wrote:
>
> > iPod touch is often consuming more traffic that all Android devices combined
(which is why I frequently call BS on the recent "Android Explosion" as reported
by the stats firms. I just don't see it as a viable market for most companies
yet once you look at their data)
>
> I don't disagree with the general hypothesis, but I think it's important for
newcomers to the mobile web not to confuse A) raw market penetration, B) web
usage (or often, the very different web+app ad traffic), and hence C) design
targets.
>
> All three are causally interlinked in a multi-dimensional rabbits-and-foxes
sort of way
>
> i.e if no one develops sites that work on platform X, then users of platform X
won't use the web, ad campaigns that target platform X will have their budgets
cut - and then the AdMob stats (which are apparently taken as gospel by just
about everyone) skew down.
>
> On the other hand... imagine if the jQuery mobile team, say, king-made a
particular obscure browser by ensuring brilliant UI support for it. a sites
using that library will suddenly become compelling for those users - who as a
result should use it more often. If that site was something as large as, say,
Facebook... then the effect on the feedback loop from that simple stance would
be significant.
>
> Personally, I'm on a crusade against mobile web sites with blue pinstripe
backgrounds - little will encourage an Android user to return to a site less
than a tawdry effort to pastiche an entirely different phone's OS ;-)
>
> James
>
> James Pearce
> http://tripleodeon.com &c
>

 

The basic question is: for which browsers do you develop?

A few extra questions:

- Why exactly this browser set? I assume you pay attention to browser
quality and (sales) market share, but are there any other reasons?

--- In mobile-web@yahoogroups.com, "bfling" <bfling@...> wrote:
> ...
> pinchzoom.com  //  we make amazing mobile experiences

Shouldn't that be "we make amazing iOS-only experiences"?

More seriously, though, *of course* customers are looking to invest on  "iPhone
websites" -- that's what all the marketing buzz is telling them to invest on. It
does betray the reality of the user base, though. If you do not develop for 80%
of mobile devices, of course none of those 80% are going to register on your
radar.

Hmm … it seems IE mobile in fact does support conditional comments, see
http://www.brucelawson.co.uk/2008/ie-6-mobile-standards-compliance-tests/ - the
article is a bit outdated (as is IE mobile ;)

I do not know how it will be with Windows Phone 7's IE when released. I think
the older ones can easily be recognized as irrelevant (as ppk mentioned), as I
remember having always replaced them with some Opera Mini/Mobile. I think I'm
going to dust off some of the old HTCs at home as well as a relatively new one
here in the office and do some testing. I just hope there is a recognizable
difference between the IE mobile and desktop versions.

>
> From my experience, IE mobile does NOT support conditional comments, but I
> haven't tried with different doctypes yet. I remember (that project was two
> years ago, though) that different doctypes did have an effect in IE mobile...
>
> Regards
> Michael
>
>
> > Does anybody know as what / how the 'new' IE Mobile identifies itself - to
be
> > used within conditional comments. Or shall we really(?) expect it as
> > 'irrelevant'?
> > I read it basically will be built upon IE6-(shriek)-'s rendering engine -
but
> > it eventually will be in the game as windows phone 7 appears.
> > 
>

> > pinchzoom.com  //  we make amazing mobile experiences
> Shouldn't that be "we make amazing iOS-only experiences"?

It certainly does feel like it most days. ;)

> More seriously, though, *of course* customers are looking to invest on 
"iPhone websites" -- that's what all the marketing buzz is telling them to
invest on. It does betray the reality of the user base, though. If you do not
develop for 80% of mobile devices, of course none of those 80% are going to
register on your radar.

I hear your point, but I don't see it as being as clear cut as that. Maybe
smaller companies get swayed by marketing buzz, because they have no data to the
contrary. But the companies we work with have a lot of data from a lot of
different countries. They don't make decisions hastily as it can take them 12-24
months to implement and roll out a mobile solution.

All I can say is that the "reality of the user base" as you mention is rarely in
line with quarterly gross device sales reports. While I'm sure there are plenty
of companies around the world that have a broader mix, I just haven't been
seeing it.

Android is certainly on the rise, but iOS devices continue to make up the lions
share of usage.

-Brian

>
> Yes, IE Mobile will support conditional comments in Windows Phone 7.
>
> We are adding media queries for IE9.

Does that mean you'll switch to IE9 in due time? That would be GREAT news.

ppk

>> > pinchzoom.com  //  we make amazing mobile experiences
>> Shouldn't that be "we make amazing iOS-only experiences"?
>
> It certainly does feel like it most days. ;)
>
>> More seriously, though, *of course* customers are looking to invest on
 "iPhone websites" -- that's what all the marketing buzz is telling them to
invest on. It does betray the reality of the user base, though. If you do not
develop for 80% of mobile devices, of course none of those 80% are going to
register on your radar.
>
> I hear your point, but I don't see it as being as clear cut as that. Maybe
smaller companies get swayed by marketing buzz, because they have no data to the
contrary. But the companies we work with have a lot of data from a lot of
different countries. They don't make decisions hastily as it can take them 12-24
months to implement and roll out a mobile solution.

Yes, that's an important point. Companies who pay for mobile web
development now have fixed their strategy about six to nine months
ago, when everybody was still obsessed by the iPhone and only the
iPhone.

But by the same logic it would mean that companies who start
formulating their (new) mobile strategy now would be more open to
non-iPhone devices. Right? It'll take a while before we notice that
change, but it should occur. Right?

> All I can say is that the "reality of the user base" as you mention is rarely
in line with quarterly gross device sales reports. While I'm sure there are
plenty of companies around the world that have a broader mix, I just haven't
been seeing it.

That's the oddest thing about this conversation. When I posted my
question I expected a few "iPhone only" replies, but also a few
replies that encompassed a broader range of devices. Those latter
replies haven't arrived, though. Does it mean nobody on this list
develops for more than iPhone/Android, or is it just that they haven't
spoken up yet?

> Android is certainly on the rise, but iOS devices continue to make up the
lions share of usage.

Ah well, Android will be the first OS after iOS that will leave its
mark on web development. That much has always been clear.

Anyway, as far as I'm concerned part of the point of this mailing list
is to spread interest in multi-device development. We've got a long
way to go, but I think the outcome is unavoidable in the long run.

ppk

>
> Yes, you can use the term "IEMobile" in your conditional comments to single
out
> IE on Windows Phone 7.
>
> Joe
>

well that's great news


so it seems we could agree on coming down to some outline as this?

- mobile first -
include mobile styles first (may be enhanced using media queries)

- desktop enhancements -
add desktop styles using media queries (as I read it, all browsers including
IE9), enhance for IE <= 8 using conditional comments


I just see two issues remain:

1. How to tell apart IE6 and Window Mobile (pre 7) IE mobile (if necessary) - or
just assume IE6 s being desktop (that is, ignoring the older IE mobiles)?

2. How to tell apart Symbian Webkit as being mobile or desktop, as ppk mentioned
in this thread's initial post?

By the way, has anyone ever tried building a media-query API on the server side?

It might be quite nice to be able to quiz a device database (at the time the
page is generated) with the same properties/query syntax as is normally invoked
on the client.

(Then no-one is even tempted to send unnecessary or unapplied styling across the
æther).

After all, many of these properties are static for a given device and could
indeed be keyed off, say, user-agent.

As a side effort, this might be a way to rally support around a set of clear,
clean, design-led criteria for categorizing devices.

Just thinking out loud really.

James

James Pearce
http://tripleodeon.com &c


--- In mobile-web@yahoogroups.com, Stephanie Rieger <steph@...> wrote:
>
> Hello,
> In response to
>
> > How to tell apart Symbian Webkit as being mobile or desktop, as ppk
> > mentioned in this thread's initial po
> >
>
> I assume you meant differentiating Nokia/Symbian WebKit from other
> WebKits? This one is actually fairly easy (but of course prone to
> error as these things are).
>
> All S60 Nokia webkit devices share the following text within the UA
> string.
>
> "Nokia"
> "AppleWebKit"
> "Symbian"
>
> Looking for "Symbian" and "AppleWebKit" will usually do the trick.
> There is also a S40 Webkit browser which is best targeted separately
> so using "Symbian" rather than "Nokia" will ensure you don't
> accidentally catch the S40 devices. I just checked the new S^3 devices
> and they also use the full "Symbian" string, so those are safe as well.
>
> There is always the risk of catching the odd Samsung or Sony Ericsson
> Symbian device in there so to be really safe, you could also look for
> "Nokia" (Symbian Foundation doesn't always formally distribute the
> same platform features as Nokia would use so i'm not sure what browser
> other Symbian licensees are using).
>
> All this said, this approach does not distinguish amongst the various
> versions of the Nokia Webkit browser. Note as well that the only
> consistently supported media query on Nokia webkit is device-width and
> all these devices identify as "screen".
>
> Steph
>
> http://yiibu.com
> Yiibu: Lovingly crafted mobile experiences
>
> +44 (0)7957 651 177
> Twitter: stephanierieger

Fortunately, it is possible to distinguish IE6 Mobile from its' desktop
counterparts. Not with conditional comments (it reads those just like the
desktop IE6), but with the CSS "handheld" media type.

However, IE6 Mobile is one of those browsers that parses both screen and
handheld media types. So you have to let it read whatever styles you're feeding
to IE6 on the desktop, but add an @media handheld sheet/block that resets the
desktop styles and then finally sets the styles you actually want it to
display...!

Matthew Babbs.

--- In mobile-web@yahoogroups.com, "andreas.windt" <kontakt@...> wrote:

> so it seems we could agree on coming down to some outline as this?
>
> - mobile first -
> include mobile styles first (may be enhanced using media queries)
>
> - desktop enhancements -
> add desktop styles using media queries (as I read it, all browsers including
IE9), enhance for IE <= 8 using conditional comments
>
>
> I just see two issues remain:
>
> 1. How to tell apart IE6 and Window Mobile (pre 7) IE mobile (if necessary) -
or just assume IE6 s being desktop (that is, ignoring the older IE mobiles)?
>
> 2. How to tell apart Symbian Webkit as being mobile or desktop, as ppk
mentioned in this thread's initial post?
>

Great! I played a bit with it ...

<!-- For Internet Explorer 8 and below, including IE Mobile, use this stylesheet
-->
<!--[if lte IE 8]>
<link rel="stylesheet" href="ccs/preIE9-and-IEMobile.css" type="text/css">
<![endif]-->
<!-- For any other browser -->
<![if gte IE 9]>
<link rel="stylesheet" href="ccs/desktop-and-mobile.css" type="text/css">
<![endif]>

works like a charm.

There seems only one single drawback left, considering mobile devices also
loading the possibly bloated bits of css for the desktop styles.
However, we could decide whether to separate desktop and mobile styles or not,
depending on how 'bloated' they really are and how crucial bandwidth is, i.e:
Non-IEs and IE9:
Include mobile styles, append desktop styles per js (not my favorite choice).
IEs including IEMobile:
Separate by conditional comments, that is trigger by IEMobile, as Joe Marini
mentioned.

--- In mobile-web@yahoogroups.com, Matthew Babbs <matt.babbs@...> wrote:
>
>  Okay, having thought this over a bit, I think we can solve the problem
> with just two stylesheets - and without any browser downloading more
> than one!
>
> The key is in the conditional comments:
>
> - stylesheet CC'd for IE<9 -
>     Desktop styles, plus any fixes for IE<9 desktop versions
>     @media handheld block (reset & basic styles for IE6 Mobile)
>
> - stylesheet CC'd for IE9+, Windows Phone 7, and everything not IE -
>     Basic styles
>     @media query for mobile (extra styles for mobile)
>     @media query for desktop (extra styles for desktop)
>     Other media queries/blocks, as required
>
> The conditional comments force IE6 Mobile to download the first
> stylesheet, where it parses the desktop styles, then styles to reset
> those, and lastly the mobile styles we actually want it to display.
>
> The second stylesheet works as PPK originally proposed, with Symbian,
> Windows Phone 7 and other basic mobile browsers seeing only the default,
> 'mobile first' styles. Modern browsers (whether mobile or desktop)
> should see the styles behind the @media query designed to select them.
>
> Matthew Babbs.
>

 

Great! I played a bit with it ...

<!-- For Internet Explorer 8 and below, including IE Mobile, use this stylesheet -->
<!--[if lte IE 8]>
<link rel="stylesheet" href="ccs/preIE9-and-IEMobile.css" type="text/css">
<![endif]-->
<!-- For any other browser -->
<![if gte IE 9]>
<link rel="stylesheet" href="ccs/desktop-and-mobile.css" type="text/css">
<![endif]>

works like a charm.

There seems only one single drawback left, considering mobile devices also loading the possibly bloated bits of css for the desktop styles.
However, we could decide whether to separate desktop and mobile styles or not, depending on how 'bloated' they really are and how crucial bandwidth is, i.e:
Non-IEs and IE9:
Include mobile styles, append desktop styles per js (not my favorite choice).
IEs including IEMobile:
Separate by conditional comments, that is trigger by IEMobile, as Joe Marini mentioned.

--- In mobile-web@yahoogroups.com, Matthew Babbs <matt.babbs@...> wrote:
>
> Okay, having thought this over a bit, I think we can solve the problem
> with just two stylesheets - and without any browser downloading more
> than one!
>
> The key is in the conditional comments:
>
> - stylesheet CC'd for IE<9 -
> Desktop styles, plus any fixes for IE<9 desktop versions
> @media handheld block (reset & basic styles for IE6 Mobile)
>
> - stylesheet CC'd for IE9+, Windows Phone 7, and everything not IE -
> Basic styles
> @media query for mobile (extra styles for mobile)
> @media query for desktop (extra styles for desktop)
> Other media queries/blocks, as required
>
> The conditional comments force IE6 Mobile to download the first
> stylesheet, where it parses the desktop styles, then styles to reset
> those, and lastly the mobile styles we actually want it to display.
>
> The second stylesheet works as PPK originally proposed, with Symbian,
> Windows Phone 7 and other basic mobile browsers seeing only the default,
> 'mobile first' styles. Modern browsers (whether mobile or desktop)
> should see the styles behind the @media query designed to select them.
>
> Matthew Babbs.
>

As the matter of fact, we have just started to work on a solution for that.
All this client side magic sounds fine, and don't misunderstand, I am all for
client side stuff on the mobile web, but to my experience, it is not enough. The
client magic need a little help from the server side to speed things up and
reduce data traffic and so on.
I'll let you know how we are doing.

--- In mobile-web@yahoogroups.com, "James Pearce" <jamesgpearce@...> wrote:
>
> By the way, has anyone ever tried building a media-query API on the server
side?
>
> It might be quite nice to be able to quiz a device database (at the time the
page is generated) with the same properties/query syntax as is normally invoked
on the client.
>
> (Then no-one is even tempted to send unnecessary or unapplied styling across
the æther).
>
> After all, many of these properties are static for a given device and could
indeed be keyed off, say, user-agent.
>
> As a side effort, this might be a way to rally support around a set of clear,
clean, design-led criteria for categorizing devices.
>
> Just thinking out loud really.
>
> James
>
> James Pearce
> http://tripleodeon.com &c
>
>
> --- In mobile-web@yahoogroups.com, Stephanie Rieger <steph@> wrote:
> >
> > Hello,
> > In response to
> >
> > > How to tell apart Symbian Webkit as being mobile or desktop, as ppk
> > > mentioned in this thread's initial po
> > >
> >
> > I assume you meant differentiating Nokia/Symbian WebKit from other
> > WebKits? This one is actually fairly easy (but of course prone to
> > error as these things are).
> >
> > All S60 Nokia webkit devices share the following text within the UA
> > string.
> >
> > "Nokia"
> > "AppleWebKit"
> > "Symbian"
> >
> > Looking for "Symbian" and "AppleWebKit" will usually do the trick.
> > There is also a S40 Webkit browser which is best targeted separately
> > so using "Symbian" rather than "Nokia" will ensure you don't
> > accidentally catch the S40 devices. I just checked the new S^3 devices
> > and they also use the full "Symbian" string, so those are safe as well.
> >
> > There is always the risk of catching the odd Samsung or Sony Ericsson
> > Symbian device in there so to be really safe, you could also look for
> > "Nokia" (Symbian Foundation doesn't always formally distribute the
> > same platform features as Nokia would use so i'm not sure what browser
> > other Symbian licensees are using).
> >
> > All this said, this approach does not distinguish amongst the various
> > versions of the Nokia Webkit browser. Note as well that the only
> > consistently supported media query on Nokia webkit is device-width and
> > all these devices identify as "screen".
> >
> > Steph
> >
> > http://yiibu.com
> > Yiibu: Lovingly crafted mobile experiences
> >
> > +44 (0)7957 651 177
> > Twitter: stephanierieger
>

The second conditional comment needs to select Windows Phone 7 as well as IE9.
I'm leaning towards the following syntax:
  <!--[if (gte IE 9)|IEMobile|!(IE)]><!--> <link rel="stylesheet"
href="everyone-else.css"> <!--<![endif]-->
(As a side benefit, it also validates.)

I agree it's not ideal for browsers to have to download styles they're not going
to display, but there's a limit to what we can do, client-side. PPK's original
proposal follows the current orthodoxy that it's better to sacrifice download
sizes in order to reduce http requests, and my version keeps to that. Of course,
if the extra styles weight a lot you may need to reconsider, but it's probably a
case-by-case thing.

Eg we have to balance:
* Size of downloads
* Number of http requests
* Number of CSS files to maintain

One of the really clever things about PPK's idea is that the browsers which like
to use *both* handheld and screen media types only have to apply one set of
styles, as they don't see the stuff hidden behind media queries. It's all too
easy to lose that by trying to reduce the wasted downloads - for example if we
have a separate file with @media handheld, browsers which like to use *both*
handheld and screen media types will go and download the advanced stylesheet
too, leaving them with the same size download but an extra http request.

That's not a nice thing to do to either the Symbian browsers that started this
discussion, or to IE6 Mobile. ;)

So to avoid that would need some server-side solution.

Matthew Babbs

--- In mobile-web@yahoogroups.com, "Andreas Windt" <kontakt@...> wrote:
>
> Great! I played a bit with it ...
>
> <!-- For Internet Explorer 8 and below, including IE Mobile, use this
stylesheet -->
> <!--[if lte IE 8]>
> <link rel="stylesheet" href="ccs/preIE9-and-IEMobile.css" type="text/css">
> <![endif]-->
> <!-- For any other browser -->
> <![if gte IE 9]>
> <link rel="stylesheet" href="ccs/desktop-and-mobile.css" type="text/css">
> <![endif]>
>
> works like a charm.
>
> There seems only one single drawback left, considering mobile devices also
loading the possibly bloated bits of css for the desktop styles.
> However, we could decide whether to separate desktop and mobile styles or not,
depending on how 'bloated' they really are and how crucial bandwidth is, i.e:
> Non-IEs and IE9:
> Include mobile styles, append desktop styles per js (not my favorite choice).
> IEs including IEMobile:
> Separate by conditional comments, that is trigger by IEMobile, as Joe Marini
mentioned.
>

Does it mean nobody on this list
develops for more than iPhone/Android, or is it just that they haven't
spoken up yet?

Hi, first of all I'm new to the forum so "Hello everybody".

Second, I've been taken with setting up a mobile channel stragetgy for my org
and wanted to get some advice as to how to build one on 'Progressive
Enhancement' principles.

From all the research I've trawled through, it seems to me the mobile market is
terrifyingly fragmented especially in terms of App development. And with the
rate at which market share is changing, I don't want to go building Apps that
only work on one platform, only to see that platform die a death in 6 months.

Help anyone?

Andy

p.s. I'm not a programmer... but if the answer is in 'techie' so be it!

--- In mobile-web@yahoogroups.com, "Andy" <andy.nash@...> wrote:
> Second, I've been taken with setting up a mobile channel stragetgy for my org
and wanted to get some advice as to how to build one on 'Progressive
Enhancement' principles.

Hi Andy,

Joe's advice is very good.  I'd add that right now, mobile website creation is
rather technical.  If your strengths are in other areas, and you aren't
interested in learning to program yourself, you may be best served by getting
help.  Ideally there will be someone in your org with a strong web design
background; if not, you may need to get outside assistance.

If you do have access to a programmer, but they don't have mobile web
experience, you can give them the book "Programming the Mobile Web" by
Maximiliano Firtman.  It's a thick book, because the mobile web is a thick
topic.  But it's an excellent choice because it goes into the detailed mechanics
of progressive enhancement.

For outside help, it depends on your needs and budget.  There are full-service
web design firms, of course. You might also be served by using a mobile website
tool or service, which can be much cheaper: try searching for "mobile website
builder".

Hope this helps - good luck.

Aaron Maxwell
Founder, Mobile Web Up
amax@...

Just for the sake of completeness, I should also add that if you have an
existing content management system for your web content, there are many ways to
quickly mobilize that content though the use of plugins, themes etc.

For example, if you are running WordPress, you might like to check out the
WordPress Mobile Pack:

http://wordpress.org/extend/plugins/wordpress-mobile-pack/

(in which I have a vested interest, so of course I think it's great! - but there
are others, and also for other CMS platforms; hopefully you get the idea)


James

James Pearce
http://tripleodeon.com &c


--- In mobile-web@yahoogroups.com, "amax_mobilewebup" <amax@...> wrote:
>
> --- In mobile-web@yahoogroups.com, "Andy" <andy.nash@> wrote:
> > Second, I've been taken with setting up a mobile channel stragetgy for my
org and wanted to get some advice as to how to build one on 'Progressive
Enhancement' principles.
>
> Hi Andy,
>
> Joe's advice is very good.  I'd add that right now, mobile website creation is
rather technical.  If your strengths are in other areas, and you aren't
interested in learning to program yourself, you may be best served by getting
help.  Ideally there will be someone in your org with a strong web design
background; if not, you may need to get outside assistance.
>
> If you do have access to a programmer, but they don't have mobile web
experience, you can give them the book "Programming the Mobile Web" by
Maximiliano Firtman.  It's a thick book, because the mobile web is a thick
topic.  But it's an excellent choice because it goes into the detailed mechanics
of progressive enhancement.
>
> For outside help, it depends on your needs and budget.  There are full-service
web design firms, of course. You might also be served by using a mobile website
tool or service, which can be much cheaper: try searching for "mobile website
builder".
>
> Hope this helps - good luck.
>
> Aaron Maxwell
> Founder, Mobile Web Up
> amax@...
>