Thanks for chiming in! Sorry for the delay, I’m currently traveling and connectivity is spotty.
There are some good points made here. As I mentioned at the end of the article, the complexity of the code may convince you that it’s not worth the effort. Perhaps the caveats I highlighted in the article reinforced that decision. That’s all very well; at the least, I hope this article offers a slightly more defensive method for those already trying to implement the technique (which is very commonly done today with a simple unconditional scrollTo).
The comments about whether or not this technique is disorienting to users are certainly interesting. I’m just as eager to hear some user research on the topic as anyone! As a smartphone user myself, I’m not sure I’d agree. To my taste, this can add a nice – albeit minor – finishing touch to a web app that’s already optimized for use on my touch device. My opinions aside, the trends seem to be going in the direction of making web apps feel more like app-apps, so we’ll likely see more of this merging going on – if so, I’d prefer seeing standardization for a less hackish approach!
Anyway, I’ll try and address some of the unique points above.
- The meta tag “apple-mobile-web-app-capable” kicks in once a web[site|app] is bookmarked to the homescreen on an iOS device, so from a browser perspective, it doesn’t do much.
- @RUDIE: That’s a fair point. For what it’s worth, in jQuery Mobile we do keep track of scroll distance before changing pages, and always return to that spot when the user returns to that page. Unfortunately, this article was long enough already :)
- Matt: Yep, this purely just scrolls the chrome out of view. Try the demo page and you’ll see it’s all there when you need it. As you mentioned, there are more aggressive approaches out there to keep the address bar hard to access – I agree, they make no sense at all. Comparing this to disabling right-click, or “disabling” any feature for that matter, seems a little strong to me. ;)
- DAVID: heh, well, I guess you could make that argument. Nothing is being disabled or broken here though, and you can just scroll up the page to get the address bar again. I think there’s a fine line though: we commonly make enhancements on top of default browser behavior, such as handling a link via Ajax instead of a full page refresh.
- Dustin: Fair point! Though you’ll still need the other checks in there anyway (hash, scroll distance before load, etc)
For those only concerned with filesize, here’s a minified version. It’ll come across the tubes at around 200 bytes (not kb): https://gist.github.com/1504263
Whew sorry – that’s what I get for signing offline for a whole day! :)
Thanks!
Scott Jehl
Hey, everybody.
Thanks for chiming in! Sorry for the delay, I’m currently traveling and connectivity is spotty.
There are some good points made here. As I mentioned at the end of the article, the complexity of the code may convince you that it’s not worth the effort. Perhaps the caveats I highlighted in the article reinforced that decision. That’s all very well; at the least, I hope this article offers a slightly more defensive method for those already trying to implement the technique (which is very commonly done today with a simple unconditional scrollTo).
The comments about whether or not this technique is disorienting to users are certainly interesting. I’m just as eager to hear some user research on the topic as anyone! As a smartphone user myself, I’m not sure I’d agree. To my taste, this can add a nice – albeit minor – finishing touch to a web app that’s already optimized for use on my touch device. My opinions aside, the trends seem to be going in the direction of making web apps feel more like app-apps, so we’ll likely see more of this merging going on – if so, I’d prefer seeing standardization for a less hackish approach!
Anyway, I’ll try and address some of the unique points above.
- The meta tag “apple-mobile-web-app-capable” kicks in once a web[site|app] is bookmarked to the homescreen on an iOS device, so from a browser perspective, it doesn’t do much.
- @RUDIE: That’s a fair point. For what it’s worth, in jQuery Mobile we do keep track of scroll distance before changing pages, and always return to that spot when the user returns to that page. Unfortunately, this article was long enough already :)
- Matt: Yep, this purely just scrolls the chrome out of view. Try the demo page and you’ll see it’s all there when you need it. As you mentioned, there are more aggressive approaches out there to keep the address bar hard to access – I agree, they make no sense at all. Comparing this to disabling right-click, or “disabling” any feature for that matter, seems a little strong to me. ;)
- DAVID: heh, well, I guess you could make that argument. Nothing is being disabled or broken here though, and you can just scroll up the page to get the address bar again. I think there’s a fine line though: we commonly make enhancements on top of default browser behavior, such as handling a link via Ajax instead of a full page refresh.
- Dustin: Fair point! Though you’ll still need the other checks in there anyway (hash, scroll distance before load, etc)
For those only concerned with filesize, here’s a minified version. It’ll come across the tubes at around 200 bytes (not kb): https://gist.github.com/1504263
Whew sorry – that’s what I get for signing offline for a whole day! :)
Thanks!