Hello,

So we have a hybrid iOS app which consumes some web content via UIWebView. In
this scenario, we like to suppress certain UI elements when loaded in UIWebView
(global header/footer etc.).

I know there're a few different ways to tackle this: customise UIWebView
user-agent header; client-side UA string detection etc. but those are all a bit
messy.

Our web content is served underneath some server side device detection using
WURFL, so ideally I'd like to use that.

One tricky aspect is that iPhone Safari browser and iPhone UIWebView have very
similar UA strings.

Here's an example (excerpt from WURFL DB)...

iPhone iOS5 Safari browser
<device id="apple_iphone_ver5" user_agent="Mozilla/5.0 (iPhone; CPU iPhone OS
5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1
Mobile/9A334 Safari/7534.48.3" fall_back="apple_iphone_ver4"
actual_device_root="true">

iPhone iOS5 UIWebView
<device id="apple_iphone_ver5_0" user_agent="Mozilla/5.0 (iPhone; CPU iPhone OS
5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A334"
fall_back="apple_iphone_ver4_3_3">

From what I understand of iPhone UA, the absence of "safari" in the UA string
indicates UIWebView. Under the hood, it's obviously the same rendering engine,
in this case, AppleWebKit 534.

I feel like I've missed something though... Analysing Apple device ids in WURFL,
the pattern doesn't seem to hold true.

So, my questions:
- Does WURFL have different records for both Safari and UIWebView for a given
OS? If so, how can I tell?
- Is it true that abscence of "safari" in the UA means it's UIWebView? And if
so, am I better just doing client-side string matching if that's the case?

Apologies for the complex nature of the question...

Complicating the matter is the fact that the UA string for a web view can be set
programmatically. There is no guarantee it's going to contain anything
resembling a standard UA string!

E.g., at Tapulous, we add information to it so our web views can have a better
idea of the host environment, but a contractor misunderstood and set the string
to *only* that information, breaking functionality that relied on some of the
traditional keywords.

Moral of the story, if you aren't in control of the UA string for the web view,
don't count on it containing anything useful.

Regards,
-Andrew

--- In mobile-web@yahoogroups.com, Steve Kamerman <stevekamerman@...> wrote:
>
> Hi Jonny,
>
> Due to the way User Agent matching is performed in WURFL, we have made no
> distinction between the standard UA and the UIWebView UA, thus, I would not
> draw conclusions about the pattern of the existence of Safari in the WURFL
> data.  It sounds like you are right on with the Safari keyword.  I would
> take a sample from a few devices - I can test an iPod 3rd Gen (iOS 4.3),
> iPhone 4S, and iPad 1 (both iOS 5.x) if you have an easy way for me to make
> a request from a UIWebView component on my devices.  You are welcome to
> visit http://db.scientiamobile.com/h from a UIWebView and I'll post back
> with the resulting headers (just type "uiwebview" or something in one of
> the fields and submit it) if you'd like.  Assuming the absence of "Safari"
> does indeed mean it's in a UIWebView, I would check the UA for "Safari"
> server side at detection time so you can keep all the detection logic in
> the same place.
>
> Steve Kamerman
>
> On Thu, Jan 5, 2012 at 9:02 PM, jonnyschneider_aus <
> schneider.jonny@...> wrote:
>
> > **
> >
> >
> > Hello,
> >
> > So we have a hybrid iOS app which consumes some web content via UIWebView.
> > In this scenario, we like to suppress certain UI elements when loaded in
> > UIWebView (global header/footer etc.).
> >
> > I know there're a few different ways to tackle this: customise UIWebView
> > user-agent header; client-side UA string detection etc. but those are all a
> > bit messy.
> >
> > Our web content is served underneath some server side device detection
> > using WURFL, so ideally I'd like to use that.
> >
> > One tricky aspect is that iPhone Safari browser and iPhone UIWebView have
> > very similar UA strings.
> >
> > Here's an example (excerpt from WURFL DB)...
> >
> > iPhone iOS5 Safari browser
> > <device id="apple_iphone_ver5" user_agent="Mozilla/5.0 (iPhone; CPU iPhone
> > OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1
> > Mobile/9A334 Safari/7534.48.3" fall_back="apple_iphone_ver4"
> > actual_device_root="true">
> >
> > iPhone iOS5 UIWebView
> > <device id="apple_iphone_ver5_0" user_agent="Mozilla/5.0 (iPhone; CPU
> > iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko)
> > Mobile/9A334" fall_back="apple_iphone_ver4_3_3">
> >
> > From what I understand of iPhone UA, the absence of "safari" in the UA
> > string indicates UIWebView. Under the hood, it's obviously the same
> > rendering engine, in this case, AppleWebKit 534.
> >
> > I feel like I've missed something though... Analysing Apple device ids in
> > WURFL, the pattern doesn't seem to hold true.
> >
> > So, my questions:
> > - Does WURFL have different records for both Safari and UIWebView for a
> > given OS? If so, how can I tell?
> > - Is it true that abscence of "safari" in the UA means it's UIWebView? And
> > if so, am I better just doing client-side string matching if that's the
> > case?
> >
> > Apologies for the complex nature of the question...
> >
> >
> >
>

I know you asked for server-side detection so this may be irrelevant, but I
found an interesting tidbit that when running in a UIWebView,
document.location.host isn't set.  So I have JavaScript code like this that I
use to see if I'm in a UIWebView:

inWebView = (!document.location.host);



--- In mobile-web@yahoogroups.com, "Andrew Hedges" <andrew@...> wrote:
>
> Complicating the matter is the fact that the UA string for a web view can be
set programmatically. There is no guarantee it's going to contain anything
resembling a standard UA string!
>
> E.g., at Tapulous, we add information to it so our web views can have a better
idea of the host environment, but a contractor misunderstood and set the string
to *only* that information, breaking functionality that relied on some of the
traditional keywords.
>
> Moral of the story, if you aren't in control of the UA string for the web
view, don't count on it containing anything useful.
>
> Regards,
> -Andrew
>
> --- In mobile-web@yahoogroups.com, Steve Kamerman <stevekamerman@> wrote:
> >
> > Hi Jonny,
> >
> > Due to the way User Agent matching is performed in WURFL, we have made no
> > distinction between the standard UA and the UIWebView UA, thus, I would not
> > draw conclusions about the pattern of the existence of Safari in the WURFL
> > data.  It sounds like you are right on with the Safari keyword.  I would
> > take a sample from a few devices - I can test an iPod 3rd Gen (iOS 4.3),
> > iPhone 4S, and iPad 1 (both iOS 5.x) if you have an easy way for me to make
> > a request from a UIWebView component on my devices.  You are welcome to
> > visit http://db.scientiamobile.com/h from a UIWebView and I'll post back
> > with the resulting headers (just type "uiwebview" or something in one of
> > the fields and submit it) if you'd like.  Assuming the absence of "Safari"
> > does indeed mean it's in a UIWebView, I would check the UA for "Safari"
> > server side at detection time so you can keep all the detection logic in
> > the same place.
> >
> > Steve Kamerman
> >
> > On Thu, Jan 5, 2012 at 9:02 PM, jonnyschneider_aus <
> > schneider.jonny@> wrote:
> >
> > > **
> > >
> > >
> > > Hello,
> > >
> > > So we have a hybrid iOS app which consumes some web content via UIWebView.
> > > In this scenario, we like to suppress certain UI elements when loaded in
> > > UIWebView (global header/footer etc.).
> > >
> > > I know there're a few different ways to tackle this: customise UIWebView
> > > user-agent header; client-side UA string detection etc. but those are all
a
> > > bit messy.
> > >
> > > Our web content is served underneath some server side device detection
> > > using WURFL, so ideally I'd like to use that.
> > >
> > > One tricky aspect is that iPhone Safari browser and iPhone UIWebView have
> > > very similar UA strings.
> > >
> > > Here's an example (excerpt from WURFL DB)...
> > >
> > > iPhone iOS5 Safari browser
> > > <device id="apple_iphone_ver5" user_agent="Mozilla/5.0 (iPhone; CPU iPhone
> > > OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1
> > > Mobile/9A334 Safari/7534.48.3" fall_back="apple_iphone_ver4"
> > > actual_device_root="true">
> > >
> > > iPhone iOS5 UIWebView
> > > <device id="apple_iphone_ver5_0" user_agent="Mozilla/5.0 (iPhone; CPU
> > > iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko)
> > > Mobile/9A334" fall_back="apple_iphone_ver4_3_3">
> > >
> > > From what I understand of iPhone UA, the absence of "safari" in the UA
> > > string indicates UIWebView. Under the hood, it's obviously the same
> > > rendering engine, in this case, AppleWebKit 534.
> > >
> > > I feel like I've missed something though... Analysing Apple device ids in
> > > WURFL, the pattern doesn't seem to hold true.
> > >
> > > So, my questions:
> > > - Does WURFL have different records for both Safari and UIWebView for a
> > > given OS? If so, how can I tell?
> > > - Is it true that abscence of "safari" in the UA means it's UIWebView? And
> > > if so, am I better just doing client-side string matching if that's the
> > > case?
> > >
> > > Apologies for the complex nature of the question...
> > >
> > >
> > >
> >
>

 

I know you asked for server-side detection so this may be irrelevant, but I found an interesting tidbit that when running in a UIWebView, document.location.host isn't set. So I have JavaScript code like this that I use to see if I'm in a UIWebView:

inWebView = (!document.location.host);

--- In mobile-web@yahoogroups.com, "Andrew Hedges" <andrew@...> wrote:
>
> Complicating the matter is the fact that the UA string for a web view can be set programmatically. There is no guarantee it's going to contain anything resembling a standard UA string!
>
> E.g., at Tapulous, we add information to it so our web views can have a better idea of the host environment, but a contractor misunderstood and set the string to *only* that information, breaking functionality that relied on some of the traditional keywords.
>
> Moral of the story, if you aren't in control of the UA string for the web view, don't count on it containing anything useful.
>
> Regards,
> -Andrew
>
> --- In mobile-web@yahoogroups.com, Steve Kamerman <stevekamerman@> wrote:
> >
> > Hi Jonny,
> >
> > Due to the way User Agent matching is performed in WURFL, we have made no
> > distinction between the standard UA and the UIWebView UA, thus, I would not
> > draw conclusions about the pattern of the existence of Safari in the WURFL
> > data. It sounds like you are right on with the Safari keyword. I would
> > take a sample from a few devices - I can test an iPod 3rd Gen (iOS 4.3),
> > iPhone 4S, and iPad 1 (both iOS 5.x) if you have an easy way for me to make
> > a request from a UIWebView component on my devices. You are welcome to
> > visit http://db.scientiamobile.com/h from a UIWebView and I'll post back
> > with the resulting headers (just type "uiwebview" or something in one of
> > the fields and submit it) if you'd like. Assuming the absence of "Safari"
> > does indeed mean it's in a UIWebView, I would check the UA for "Safari"
> > server side at detection time so you can keep all the detection logic in
> > the same place.
> >
> > Steve Kamerman
> >
> > On Thu, Jan 5, 2012 at 9:02 PM, jonnyschneider_aus <
> > schneider.jonny@> wrote:
> >
> > > **
> > >
> > >
> > > Hello,
> > >
> > > So we have a hybrid iOS app which consumes some web content via UIWebView.
> > > In this scenario, we like to suppress certain UI elements when loaded in
> > > UIWebView (global header/footer etc.).
> > >
> > > I know there're a few different ways to tackle this: customise UIWebView
> > > user-agent header; client-side UA string detection etc. but those are all a
> > > bit messy.
> > >
> > > Our web content is served underneath some server side device detection
> > > using WURFL, so ideally I'd like to use that.
> > >
> > > One tricky aspect is that iPhone Safari browser and iPhone UIWebView have
> > > very similar UA strings.
> > >
> > > Here's an example (excerpt from WURFL DB)...
> > >
> > > iPhone iOS5 Safari browser
> > > <device id="apple_iphone_ver5" user_agent="Mozilla/5.0 (iPhone; CPU iPhone
> > > OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1
> > > Mobile/9A334 Safari/7534.48.3" fall_back="apple_iphone_ver4"
> > > actual_device_root="true">
> > >
> > > iPhone iOS5 UIWebView
> > > <device id="apple_iphone_ver5_0" user_agent="Mozilla/5.0 (iPhone; CPU
> > > iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko)
> > > Mobile/9A334" fall_back="apple_iphone_ver4_3_3">
> > >
> > > From what I understand of iPhone UA, the absence of "safari" in the UA
> > > string indicates UIWebView. Under the hood, it's obviously the same
> > > rendering engine, in this case, AppleWebKit 534.
> > >
> > > I feel like I've missed something though... Analysing Apple device ids in
> > > WURFL, the pattern doesn't seem to hold true.
> > >
> > > So, my questions:
> > > - Does WURFL have different records for both Safari and UIWebView for a
> > > given OS? If so, how can I tell?
> > > - Is it true that abscence of "safari" in the UA means it's UIWebView? And
> > > if so, am I better just doing client-side string matching if that's the
> > > case?
> > >
> > > Apologies for the complex nature of the question...
> > >
> > >
> > >
> >
>

Kevin,

In your case, was the page returned from a web server or was it a local file on
the device? Local files would be fetched using the file:// protocol, which
leaves document.location.host as an empty string (which makes sense since there
is no hostname set).

Regards,
-Andrew

--- In mobile-web@yahoogroups.com, "KevinL" <kevin@...> wrote:
>
> I know you asked for server-side detection so this may be irrelevant, but I
found an interesting tidbit that when running in a UIWebView,
document.location.host isn't set.  So I have JavaScript code like this that I
use to see if I'm in a UIWebView:
>
> inWebView = (!document.location.host);
>
>
>
> --- In mobile-web@yahoogroups.com, "Andrew Hedges" <andrew@> wrote:
> >
> > Complicating the matter is the fact that the UA string for a web view can be
set programmatically. There is no guarantee it's going to contain anything
resembling a standard UA string!
> >
> > E.g., at Tapulous, we add information to it so our web views can have a
better idea of the host environment, but a contractor misunderstood and set the
string to *only* that information, breaking functionality that relied on some of
the traditional keywords.
> >
> > Moral of the story, if you aren't in control of the UA string for the web
view, don't count on it containing anything useful.
> >
> > Regards,
> > -Andrew
> >
> > --- In mobile-web@yahoogroups.com, Steve Kamerman <stevekamerman@> wrote:
> > >
> > > Hi Jonny,
> > >
> > > Due to the way User Agent matching is performed in WURFL, we have made no
> > > distinction between the standard UA and the UIWebView UA, thus, I would
not
> > > draw conclusions about the pattern of the existence of Safari in the WURFL
> > > data.  It sounds like you are right on with the Safari keyword.  I would
> > > take a sample from a few devices - I can test an iPod 3rd Gen (iOS 4.3),
> > > iPhone 4S, and iPad 1 (both iOS 5.x) if you have an easy way for me to
make
> > > a request from a UIWebView component on my devices.  You are welcome to
> > > visit http://db.scientiamobile.com/h from a UIWebView and I'll post back
> > > with the resulting headers (just type "uiwebview" or something in one of
> > > the fields and submit it) if you'd like.  Assuming the absence of "Safari"
> > > does indeed mean it's in a UIWebView, I would check the UA for "Safari"
> > > server side at detection time so you can keep all the detection logic in
> > > the same place.
> > >
> > > Steve Kamerman
> > >
> > > On Thu, Jan 5, 2012 at 9:02 PM, jonnyschneider_aus <
> > > schneider.jonny@> wrote:
> > >
> > > > **
> > > >
> > > >
> > > > Hello,
> > > >
> > > > So we have a hybrid iOS app which consumes some web content via
UIWebView.
> > > > In this scenario, we like to suppress certain UI elements when loaded in
> > > > UIWebView (global header/footer etc.).
> > > >
> > > > I know there're a few different ways to tackle this: customise UIWebView
> > > > user-agent header; client-side UA string detection etc. but those are
all a
> > > > bit messy.
> > > >
> > > > Our web content is served underneath some server side device detection
> > > > using WURFL, so ideally I'd like to use that.
> > > >
> > > > One tricky aspect is that iPhone Safari browser and iPhone UIWebView
have
> > > > very similar UA strings.
> > > >
> > > > Here's an example (excerpt from WURFL DB)...
> > > >
> > > > iPhone iOS5 Safari browser
> > > > <device id="apple_iphone_ver5" user_agent="Mozilla/5.0 (iPhone; CPU
iPhone
> > > > OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1
> > > > Mobile/9A334 Safari/7534.48.3" fall_back="apple_iphone_ver4"
> > > > actual_device_root="true">
> > > >
> > > > iPhone iOS5 UIWebView
> > > > <device id="apple_iphone_ver5_0" user_agent="Mozilla/5.0 (iPhone; CPU
> > > > iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko)
> > > > Mobile/9A334" fall_back="apple_iphone_ver4_3_3">
> > > >
> > > > From what I understand of iPhone UA, the absence of "safari" in the UA
> > > > string indicates UIWebView. Under the hood, it's obviously the same
> > > > rendering engine, in this case, AppleWebKit 534.
> > > >
> > > > I feel like I've missed something though... Analysing Apple device ids
in
> > > > WURFL, the pattern doesn't seem to hold true.
> > > >
> > > > So, my questions:
> > > > - Does WURFL have different records for both Safari and UIWebView for a
> > > > given OS? If so, how can I tell?
> > > > - Is it true that abscence of "safari" in the UA means it's UIWebView?
And
> > > > if so, am I better just doing client-side string matching if that's the
> > > > case?
> > > >
> > > > Apologies for the complex nature of the question...
> > > >
> > > >
> > > >
> > >
> >
>

Thanks everybody for your responses, very helpful.

I do have control over UIWebView in the native app, and did consider modifying
the user agent there, but our experience has been that this can be a bit flakey,
especially on older OS levels that we support.

It's likely that we'll use something else in a custom HTTP header instead, and
pick that up on client-side.

I would like to keep all of the detection logic server side, as suggested, but
that's actually more trouble than it's worth - mostly because of bureaucratic
business processes that get in the way.

Thanks again for all your help.


--- In mobile-web@yahoogroups.com, "jonnyschneider_aus" <schneider.jonny@...>
wrote:
>
> Hello,
>
> So we have a hybrid iOS app which consumes some web content via UIWebView. In
this scenario, we like to suppress certain UI elements when loaded in UIWebView
(global header/footer etc.).
>
> I know there're a few different ways to tackle this: customise UIWebView
user-agent header; client-side UA string detection etc. but those are all a bit
messy.
>
> Our web content is served underneath some server side device detection using
WURFL, so ideally I'd like to use that.
>
> One tricky aspect is that iPhone Safari browser and iPhone UIWebView have very
similar UA strings.
>
> Here's an example (excerpt from WURFL DB)...
>
> iPhone iOS5 Safari browser
> <device id="apple_iphone_ver5" user_agent="Mozilla/5.0 (iPhone; CPU iPhone OS
5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1
Mobile/9A334 Safari/7534.48.3" fall_back="apple_iphone_ver4"
actual_device_root="true">
>
> iPhone iOS5 UIWebView
> <device id="apple_iphone_ver5_0" user_agent="Mozilla/5.0 (iPhone; CPU iPhone
OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A334"
fall_back="apple_iphone_ver4_3_3">
>
> From what I understand of iPhone UA, the absence of "safari" in the UA string
indicates UIWebView. Under the hood, it's obviously the same rendering engine,
in this case, AppleWebKit 534.
>
> I feel like I've missed something though... Analysing Apple device ids in
WURFL, the pattern doesn't seem to hold true.
>
> So, my questions:
> - Does WURFL have different records for both Safari and UIWebView for a given
OS? If so, how can I tell?
> - Is it true that abscence of "safari" in the UA means it's UIWebView? And if
so, am I better just doing client-side string matching if that's the case?
>
> Apologies for the complex nature of the question...
>

A credible website design and development is must for a potential business process that looks forward to grow and stay competitive. But what makes your website such a winning tool for your business? In short, it should be informative, user friendly and attractive to the end user. So, it is essential to exercise much prudence in finding a competent website designer and developer to reflect your service and/or product esteem to the web pages.

Now, where to get the best website designers? As money is always the prime factor in considering upon some deal, most likely the cheap website designing companies are in demand to the market. But the same time a common notion is that, the word "Cheap" never goes along with "Quality". Then should you essentially compromise with the one? Not really. There are a number of affordable website developers doing business online to support their global clientele with superior service quality.

Just make your search with the phrase affordable website designer a list of links will appear from where you need to select the best one. Sounds difficult? In fact, the matter really is. You have to have some knowledge about present market status and website designing standard to pick the best service provider. Don't go with the flowery language- it is wise to go for the companies having a fair track record. Go through their portfolio to get some idea about their standard and talk to the service providers in person before making a final deal. The web designers essentially need to be a patient listener and behave cordially with their client in order to analyze the project requirement perfectly. This can only give out the website you are actually looking at. Be a sensible customer and find the one who can reflect your esteem in true sense.

Sites like YouTube and Facebook are already projecting mobile use to surpass
desktop use as early as *this year*. What's your mobile and tablet strategy?
Allow me to humbly present the wisdom I got from the experience of walking the
last 365 miles. Barefoot. In the snow. Uphill both ways.

http://www.designcaffeine.com/articles/mobile-websites-tablet-apps-and-hybrids-7\
-mobile-strategy-tips-for-2012/

-Greg

Dear !
Hoping ur goood health. i need ur favor plz fill this for me i need as a case
study for my research work. Hardly it will take ur precious 10 mints. Thank
uoooz in anticipation.

Link:
https://spreadsheets.google.com/spreadsheet/viewform?formkey=dG41dWtCM0o3eWd3QWt\
Dc0ZuY1ZueUE6MQ

Regards
Muzammil Khan
QAU Islamabad Pakistan

You've got a private message! Check it here:
http://file1.hpage.com/007642/74/html/hottie.htm

One thing I’ve learned is to do everything you can to rely on CSS3 for drawing UI elements using em or better yet rem units. This helps with resolution independence as well.

One example I’ve created and used at various sizes time and time again is a simple spinner I created entirely in CSS3.

http://jordandobson.com/webkit_loading_animation/resize/

Making sure your design scales well of your base font is really solid way to start. Sencha Blog talks about this as well!

http://www.sencha.com/blog/resolution-independent-mobile-ui

Hey gang,

I've been influenced by blog posts from more than a few folks in this group, so
I'm stoked that I came across it when I did.  I believe I'm about to encounter a
wide range of opinions, but I'd like to put this up for some critical feedback.

About 6 weeks ago I made the decision to execute a minor pivot of my startup,
ShareSquare, even though our prior focus (entertainment/brand QR code campaigns)
was going ok for the moment.  It's a risky decision given our stage as a
company, but I think most everyone here sees the same writing on the wall that I
did.

Leveraging the HTML5 mobile web CMS we built over the last two years (geared
toward social & rich media mobile marketing) I decided to attack the biggest
opportunity I saw at hand: the almost entirely un-mobilized world of artist/band
websites.  (A big culprit in this vertical, as Greg Nudelman pointed out, has
been the irrational exuberance for, and glut of, native apps.)  Consequently,
for mobile traffic upwards of 40%, these artist websites fail miserably on most
accords: inoperable streaming audio/video, obstacles to Liking/following, broken
navigation & carts, and lots of missed conversion opportunities.

Seeing this state of affairs, I wondered if we could take a DudaMobile-esque
approach for easily mobilizing (won't say converting, since we inherently must
"reconsider the content") these existing websites.

If you visit our new homepage at http://getsharesquare.com/ you can drop a URL
into the mobilizer to see how this process starts without registration.  If you
do, you can continue building an HTML5 mobile site for free.

We've gotten some encouraging early feedback from the music community, but I'd
be much obliged for the discerning technical and best practice eyes of the
people in this group.  (I am a bit worried that PPK will find this an
abomination, but I'm hoping it'll all ultimately help our company refine our
offering to quickly address the market as best we can.)

Much thanks & glad to be here,
Matthias

Hi Matthias,

Looks interesting. Products like this are likely bridging solutions. That’s
totally fine for a business. You can make a lot of hay that way, but you’ll need
to keep an eye on when you need to shift again as mobile becomes too important
for outsourcing and automatic conversion to make sense.

-Jason

On Mar 4, 2012, at 7:56 AM, mattgalica wrote:

> Hey gang,
>
> I've been influenced by blog posts from more than a few folks in this group,
so I'm stoked that I came across it when I did. I believe I'm about to encounter
a wide range of opinions, but I'd like to put this up for some critical
feedback.
>
> About 6 weeks ago I made the decision to execute a minor pivot of my startup,
ShareSquare, even though our prior focus (entertainment/brand QR code campaigns)
was going ok for the moment. It's a risky decision given our stage as a company,
but I think most everyone here sees the same writing on the wall that I did.
>
> Leveraging the HTML5 mobile web CMS we built over the last two years (geared
toward social & rich media mobile marketing) I decided to attack the biggest
opportunity I saw at hand: the almost entirely un-mobilized world of artist/band
websites. (A big culprit in this vertical, as Greg Nudelman pointed out, has
been the irrational exuberance for, and glut of, native apps.) Consequently, for
mobile traffic upwards of 40%, these artist websites fail miserably on most
accords: inoperable streaming audio/video, obstacles to Liking/following, broken
navigation & carts, and lots of missed conversion opportunities.
>
> Seeing this state of affairs, I wondered if we could take a DudaMobile-esque
approach for easily mobilizing (won't say converting, since we inherently must
"reconsider the content") these existing websites.
>
> If you visit our new homepage at http://getsharesquare.com/ you can drop a URL
into the mobilizer to see how this process starts without registration. If you
do, you can continue building an HTML5 mobile site for free.
>
> We've gotten some encouraging early feedback from the music community, but I'd
be much obliged for the discerning technical and best practice eyes of the
people in this group. (I am a bit worried that PPK will find this an
abomination, but I'm hoping it'll all ultimately help our company refine our
offering to quickly address the market as best we can.)
>
> Much thanks & glad to be here,
> Matthias
>
>

--

Jason Grigsby
+1 (503) 290-1090 o
+1 (503) 502-7211 m
jason@...
http://cloudfour.com

Hello,

I'm having a problem with a few specific Android devices when using XHR.

It appears that the browser is omitting the Accepts header. When I attempt to
read it server-side (ASP.NET MVC3), Accepts is simply not there. Other devices
are working fine.

With some of the questionable devices, I can detect custom headers (like
x-requested-with). However, with at least one device it seems that virtually
everything is missing.

I am using jQuery 1.6.1 and the $.ajax() to make the requests.

The device that _seem_ to be having this problem are:

* Nexus One 2.3.6 (this one seems to move all headers except for a few, no
Accepts and nothing I add manually)

* HTC Wildfire 2.3.3 (missing Accepts, but looks like x-requested-with is still
present)

* Galaxy S2 - 2.2.3 (I suspect the same problem, but not thoroughly tested)
* Huawei Blaze 2.35 (I suspect the same problem, but not thoroughly tested)


I have not yet:
* attempt to sniff the raw HTTP traffic arriving at the server
* craft xhr requests manually instead of using jQuery

Have you encountered anything like this? Any advice?
many thanks,
Christopher

Practical, effective and most importantly very economical ways to design and
test for mobile platform using RITE (Rapid Iterative Testing and Evaluation)
methodology. 30-minute FREE webinar by Greg Nudelman, on Friday, March 16th, 10
am PT

http://www.designcaffeine.com/articles/free-webinar-agile-mobile-design/

See screenshot below.  NOTE: for Andorid and Mobile User Experience groups, I
might have posted already -- pls. check. DO NOT post again if already posted
last 12 hours

For all IXDA groups, post only under Promotions, NOT Discussions.

FWIW, I’m not saying you shouldn’t pursue this. I didn’t mean to sound negative.
:-)

We spent a lot of time entertaining heading a similar direction which is why the
advantages and disadvantages of bridging solutions are at the forefront of my
mind. We ultimately didn’t go that direction, but it had less to do with the
disadvantages of bridging solutions and more to do with other opportunities we
wanted to pursue.

When I saw what you were up to, it reminded me of all of those conversations
debating the pros and cons hence my response.

BTW, I love the infographic in that post. “Proudly murdering SEO since 1998.”
Heh heh.

-Jason

On Mar 9, 2012, at 12:03 AM, Matthias Galica wrote:

> Jason, much thanks for the feedback, and you make a solid, albeit
far-reaching, point.  While I'd agree that our approach is susceptible, you
could make the argument that some of the small biz vertical-specific projects
(like Dudamobile) could see their mobile sites persist largely unchanged as long
as the desktop websites that bore them.  Not very interesting, but basically all
they need to do is maintain the click-to-call functionality that's heralded to
be driving nutso conversions from local mobile ad buys.
>
>
> Sharing with the group some research that we did with the help of
BuiltWith.com, as you may find it interesting:
http://mashable.com/2012/03/08/bands-mobile-sxsw/
>
> Cheers,
> Matthias
>
> On Thu, Mar 8, 2012 at 10:54 AM, Jason Grigsby <jason@...> wrote:
> Hi Matthias,
>
> Looks interesting. Products like this are likely bridging solutions. That’s
totally fine for a business. You can make a lot of hay that way, but you’ll need
to keep an eye on when you need to shift again as mobile becomes too important
for outsourcing and automatic conversion to make sense.
>
> -Jason
>
> On Mar 4, 2012, at 7:56 AM, mattgalica wrote:
>
> > Hey gang,
> >
> > I've been influenced by blog posts from more than a few folks in this group,
so I'm stoked that I came across it when I did. I believe I'm about to encounter
a wide range of opinions, but I'd like to put this up for some critical
feedback.
> >
> > About 6 weeks ago I made the decision to execute a minor pivot of my
startup, ShareSquare, even though our prior focus (entertainment/brand QR code
campaigns) was going ok for the moment. It's a risky decision given our stage as
a company, but I think most everyone here sees the same writing on the wall that
I did.
> >
> > Leveraging the HTML5 mobile web CMS we built over the last two years (geared
toward social & rich media mobile marketing) I decided to attack the biggest
opportunity I saw at hand: the almost entirely un-mobilized world of artist/band
websites. (A big culprit in this vertical, as Greg Nudelman pointed out, has
been the irrational exuberance for, and glut of, native apps.) Consequently, for
mobile traffic upwards of 40%, these artist websites fail miserably on most
accords: inoperable streaming audio/video, obstacles to Liking/following, broken
navigation & carts, and lots of missed conversion opportunities.
> >
> > Seeing this state of affairs, I wondered if we could take a DudaMobile-esque
approach for easily mobilizing (won't say converting, since we inherently must
"reconsider the content") these existing websites.
> >
> > If you visit our new homepage at http://getsharesquare.com/ you can drop a
URL into the mobilizer to see how this process starts without registration. If
you do, you can continue building an HTML5 mobile site for free.
> >
> > We've gotten some encouraging early feedback from the music community, but
I'd be much obliged for the discerning technical and best practice eyes of the
people in this group. (I am a bit worried that PPK will find this an
abomination, but I'm hoping it'll all ultimately help our company refine our
offering to quickly address the market as best we can.)
> >
> > Much thanks & glad to be here,
> > Matthias
> >
> >
>
> --
>
> Jason Grigsby
> +1 (503) 290-1090 o
> +1 (503) 502-7211 m
> jason@...
> http://cloudfour.com
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>
> --
> Matthias Galica
> Founder & CEO
> http://getsharesquare.com/
> Follow & Like Us
>
>
>

--

Jason Grigsby
+1 (503) 290-1090 o
+1 (503) 502-7211 m
jason@...
http://cloudfour.com

You've got a private message! Check it here:
http://file1.hpage.com/007691/91/html/hottie.htm

Sailing News has just launched their new mobi site. It was built as a responsive
site that re-sizes for the device viewing it.

Have a look at http://www.sailingnews.mobi

Lowis,

This is returning a 403 Forbidden from Apache. No site content is visible.

Regards,
Barney Carroll

barney.carroll@...
+44 7429 177278

barneycarroll.com