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 - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
