Chromelessness in Engage 0.3

[Justin Obara]

I did a little bit of digging around on this issue.

So it looks like anchors that point to content on the same page, can cause the the webapp to be loaded into Safari. Meaning that if we use anchors as buttons on a page, we could also experience this problem. However, it seems that form elements don't have this issue, so using a proper button should work.

http://www.coldfusionjedi.com/index.cfm/2008/10/9/Two-iPhone-development-tips-and-jQuery-to-the-rescue

The site mentioned above, talks a bit about these issues, but if you read on down into the comments, there may be some hacks to work around the problem for navigating between pages. Seems like some people have had success keeping the full screen webapp alive outside of safari if you use the link to have javascript change the window.location.href to the desired url.

I haven't had a chance to try this out yet, so I can't confirm or deny the effectiveness. I'm not sure it is even something we would really want to do, even if only temporarily.

Here is another page that talks about ways of overriding native behaviour. This doesn't really address this issue but may be a good reference for other things later.

http://rakaz.nl/2009/09/iphone-webapps-101-getting-safari-out-of-the-way.html

- Justin


On 2010-01-30, at 5:31 PM, Colin Clark wrote:

> Hi everyone,
> 
> There's a key assumption in our mobile designs that we may need to temporarily adapt for the Engage 0.3 release. The designs do an amazing job of providing a rich and immersive experience on such a tiny screen. This is accomplished in large part through the removal of the surrounding browser "chrome"--the Back button, the URL bar, and the lower action bar. 
> 
> Technically, this is feasible in a Web environment but requires some major considerations. Typically, this chromeless experience is accomplished in one of three ways:
> 
> 1. Creating a native application distributed through the iTunes store, which contains a UIWebView and no chrome
> 2. Having users define a home screen icon, which automatically removes Safari's chrome
> 3. Using scrolling hacks to programmatically scroll past the browser chrome upon page load
> 
> There are pros and cons to each approach, but I'll summarize a few of the issue here:
> 
> 1. Native apps require contracts with Apple for distribution with the iTunes store. As a community, we still haven't determined what the best way to do this is; should Fluid distribute the app? Each implementing museum? There is also a substantial waiting period while Apple reviews the application.
> 
> 2. Home screen icons are restricted to consisting of only a single page. Any page transition--any link that takes the user to a new URL--will cause an abrupt change in context. Safari opens up suddenly, and all the browser chrome is visible again. In order to get around this, we need to do some serious Ajax trickery (like jqTouch does) to shoehorn ourselves into a single page.
> 
> 3. Scrolling hacks are ugly and error-prone. It seems that Apple has disabled most of them in recent versions of Safari. They also don't actually remove the chrome, they just make it less conspicuous.
> 
> Jacob took a stab at #2 a few months back with the Screen Navigator component. It was very promising, but had a number of key problems in its first incarnation: 1) it breaks the back button and the browser's native history, and 2) all content had to be hard-baked to work within the Screen Navigator. That made it very hard to unit test and to develop content in a loosely-coupled way.
> 
> Over the past couple days I've delved a bit deeper into this problem. I was able to substantially refine Jacob's strategy by writing a some regular expressions that parse the raw incoming HTML page, organizes the CSS and JS dependencies properly, and injects them into a single page view. The main problem I encountered, in addition to back button/history problem, is that the context of relative URLs changes. In other words, links that are valid outside the Screen Navigator break when content is displayed within it.
> 
> This Screen Navigator strategy is decent one to pursue over the next few months, especially if we can find techniques to ensure that existing content doesn't have to be modified to work inside Screen Navigator. I think Kettle's newly-refreshed URL rewriting features should help a lot here.
> 
> The bottom line, from a technical perspective, is that I've found no expedient way of getting a chromeless experience working within the time frame of our Engage 0.3 release. It's a huge priority, but one we may have to live without until after this release. 
> 
> I'm quite interested to hear design ideas about how we can respond to this issue. I'm also keen to hear if there are any technical strategies I haven't yet considered.
> 
> Colin
> 
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work