In spite of its great capabilities and effectiveness as a example, even Joe was not really prepared for how popular it became. From his blog http://www.joehewitt.com/blog/iphonedevcamp.php
[quote] Another fun thing about iPhoneDevCamp was my constant surprise as I found one project after the other using the iPhone app template that I threw together on Thursday night. I didn't really think this bit of code was ready for prime time, which is why I didn't even mention it on this blog. I only posted a link to it on the iPhoneWebDev Google Group. When I woke up the next morning it was already on Ajaxian. Later that evening, Jeffrey Grossman launched Movies.app, which used the template for its UI. The next morning I met Kristopher Tate of Zooomr, who had created a Google Code project based on my code and started using it to build a music browser. Throughout the weekend I met one group after another using the template for their Hackathon projects. I guess the lesson is that people are really happy to be able to focus on their apps instead of re-inventing Apple's UI! I'm definitely going to put some more time into it this week to clean it up and add some more features that people asked for. [/quote]
[quote] I most sincerely hope that the iPhone doesn't give rise to a bunch of Safari-centric, egotistical, incompatible, and "standards para-compliant" applications – i.e., stuff that is formally standards compliant (because it is, after all, HTML and JavaScript) but that uses so many WebKit or Safari-specific idioms that ends up not working properly (if at all) in other browsers.
Otherwise, we'll be back where we started when IE was all the rage, and repeating all the same mistakes.
So remember: Just because you're doing it on the coolest phone on the planet doesn't automatically make it right.
Update: For instance, I've been playing around with Joe Hewitt's navigation sample, which is pretty neat, but only works on the iPhone browser and on the WebKit nightlies (yes, I refuse to run Safari 3.0 anywhere but Windows until it's stable).
After doing a few simple changes, it now works in "regular" Safari (2.0) and my Nokia. Although I haven't replaced the animation code with "normal" jQuery effects yet, all it takes is to change the handlers in a standard way:
$(document).ready(function() { // Show the page corresponding to the home button link // (we get the button's link and then the element that has that hash as its ID) showPage($('#' + $('#homeButton').get(0).hash.substr(1)).get(0));
// Teach all links to invoke the showPage function $("a").click(function(){ // Show the first match for "#hash" showPage($('#' + this.hash.substr(1)).get(0)); });
// Periodic checks for iPhone orientation setInterval(checkOrientAndLocation, 300);
Nothing else was changed (except removing addEventListener from iphonenav.js). But the rest – all the rest – looks like it can be replaced by six to ten lines of jQuery code…
Of course the CSS is all shot due to "proprietary" WebKit stuff, but that's fixable. If I have time, I'll post the results somewhere. [/quote]
I've invited the TaoOfMac blogger, who is professional a cell phone developer in Europe to join us here in iPhoneWebDev.
So maybe we should find a way to collectively make a better example, one that works on the iPhone, but doesn't completely break other desktop or cellphone browsers. I'd be glad to host a SVN repository, with Joe as lead, to allow multiple people to contribute to make what is currently the best example code we have into something even better.
On Jul 9, 2007, at 10:56 AM, Christopher Allen wrote:
> So maybe we should find a way to collectively make a better example, > one that works on the iPhone, but doesn't completely break other > desktop or cellphone browsers. I'd be glad to host a SVN repository, > with Joe as lead, to allow multiple people to contribute to make what > is currently the best example code we have into something even better.
> Thoughts?
I think it's a fantastic idea. Joe has done a incredible job but hardly deserves to support the whole world. Frankly, it seems to me like Apple could post a template or a javascript or something other than a glossy page of metrics, but I'm preaching to the choir here.
> P.S. Anyone have a better name for this project?
On 7/9/07 10:56 AM, "Christopher Allen" <Christoph...@iPhoneWebDev.com> wrote:
> [quote] > I most sincerely hope that the iPhone doesn't give rise to a bunch of > Safari-centric, egotistical, incompatible, and "standards > para-compliant" applications - i.e., stuff that is formally standards > compliant (because it is, after all, HTML and JavaScript) but that > uses so many WebKit or Safari-specific idioms that ends up not working > properly (if at all) in other browsers.
> Otherwise, we'll be back where we started when IE was all the rage, > and repeating all the same mistakes.
> So remember: Just because you're doing it on the coolest phone on the > planet doesn't automatically make it right.
Great post Chris! Guess I should have read it before I posted my comments.
The collapsible navigation in my example works on Safari 2, FF, IE, and Windows Mobile. It's just plain old simple js. If I can get my hands on an iphone for testing, I can figure out why content is being duplicated and streamline it. Then I will be happy to share it with the world.
Dean Hamack Macromedia Certified Flash MX Designer/ Lead Web Developer Bushido Designs Tel:(206)523-6705 www.bushidodesigns.net
> I've invited the TaoOfMac blogger, who is professional a cell phone > developer in Europe to join us here in iPhoneWebDev.
Erm.
(/me waves at onlookers)
Actually, I'm now in Marketing. I'm trying to forget as much of WML and mobile browser tech as I can, but I can try to keep some of the neurons for that around... :)
> So maybe we should find a way to collectively make a better example, > one that works on the iPhone, but doesn't completely break other > desktop or cellphone browsers. I'd be glad to host a SVN repository, > with Joe as lead, to allow multiple people to contribute to make what > is currently the best example code we have into something even better.
Well, I'd seriously recommend looking at something _like_ jQuery, if only because using it helps (a lot) in terms of portability across browsers.
I happen to like jQuery because it suits the way I think about the DOM, i.e., as something I can query, filter, slice, dice, etc.
And I happen to not like Prototype because at the time I really needed to use something like it it wasn't all that well documented...
There's a bunch of alternatives out there (I've catalogued a few over at http://the.taoofmac.com/space/JavaScript), but nothing that lets you manage the DOM quite like jQuery.
And since I'm guessing that a lot of people will be going for the "all-in-one-page" approach for now, I'd think that ability to play around with the DOM would be useful...
Anyway, besides JavaScript, I'm a bit concerned about all the -wekbit- ness in CSS.
I think there should be some sort of "UI Library" that provided iPhone-native widgets that degraded to something usable in other browsers, starting with WebKit on other phones (and Safari 2.0, which may be suitable for testing that to some extent).
Other mobile browsers out there are... Different.
NetFront on SonyEricsson devices has CSS support, but I haven't pushed it to its limits (I'll be playing around with a new one soon, will tell), and then there's all the Opera variants (we can leave Opera mini to last, since it's server-side rendering and in flux right now until they get 4.0 together).
So I'd probably order things thus:
1. iPhone Safari + Safari 3.0 2. Nokia WebKit + Safari 2.0 3. Opera for Series 60 + Opera 9.0 (desktop, Wii, etc., later Java/ mini) 4. Mobile IE + IE... 4?5?6? :)
Which gives you a nice orderly set of mobile browsers to develop for and desktop browsers to test against, with (hopefully) a manageable set of quirks.
(Firefox can be used as a catch-all reference for CSS stuff that the above doesn't cover - I didn't mention it because there aren't that many mobile browsers derived from it...).
> P.S. Anyone have a better name for this project?
Erm... "iUI" is taken, and "mobi 2.0" is kind of... weird, so I'd stick with the current one until things settle :)
I love jQuery, but I would strongly like to avoid dependencies on any JavaScript libraries. Every byte counts when you're developing for a phone that downloads so incredibly slowly. When we started the Tilt game, my teammates suggested using jQuery after I had already started without it. When we added jQuery, the game went from loading in less than a second, to waiting about four seconds, and this was over WiFi. That 667mhz processor doesn't like to have to parse and interpret large amounts of JavaScript either.
As far as standards support - I know this is politically incorrect, but I think it's too soon to start worrying about that. Let me know when there is another phone that is even remotely close to the capabilities of the iPhone's browser. Those proprietary -webkit tags allow us to do some really advanced stuff that saves a lot of bandwidth and makes pages look great, -webkit-border-image and -webkit- text-shadow in particular. I think it's a little too soon to start watering down the capabilities of iPhone apps. My philosophy is that we *should* build proprietary apps that work only on the iPhone to motivate other companies to catch up faster.
I also really do not think you should be trying to make your iPhone apps degrade. You should write your iPhone apps separately. The iPhone is a dramatically different experience and you owe it to your users to optimize for that environment instead of spending your time trying to create a single app that morphs. Inevitably, people who go that route are going to make compromises that hurt the iPhone experience, and that would make me sad. Again, let me know when there's another phone that approaches it, and then we can talk about degrading.
> I love jQuery, but I would strongly like to avoid dependencies on any > JavaScript libraries. Every byte counts when you're developing for a > phone that downloads so incredibly slowly. When we started the Tilt > game, my teammates suggested using jQuery after I had already started > without it. When we added jQuery, the game went from loading in less > than a second, to waiting about four seconds, and this was over WiFi. > That 667mhz processor doesn't like to have to parse and interpret > large amounts of JavaScript either.
Odd, since a bog standard Nokia consumer device does that just fine. And I would suppose that would be a transient limitation until Apple tweaks the platform.
> As far as standards support - I know this is politically incorrect, > but I think it's too soon to start worrying about that. Let me know > when there is another phone that is even remotely close to the > capabilities of the iPhone's browser.
Erm... You're kidding, right? Yes, WebKit on the iPhone seems to be pretty impressive. But I've had WebKit browsers on other devices for a good while now, and the basic capabilities - the _core_ ones, not the interaction/cosmetic ones - are mostly the same.
> Those proprietary -webkit tags > allow us to do some really advanced stuff that saves a lot of > bandwidth and makes pages look great, -webkit-border-image and - > webkit- > text-shadow in particular. I think it's a little too soon to start > watering down the capabilities of iPhone apps.
It's not watering down, it's making sure you can re-use your coding investment on something else.
> My philosophy is that > we *should* build proprietary apps that work only on the iPhone to > motivate other companies to catch up faster.
Okay, you lost me there. I disagree, completely.
I understand your enthusiasm, but I have gone through too many platforms to see things that way. Sure, I use a Mac and wouldn't use _anything_ else at home, but the world just doesn't work that way.
I am lucky enough to be able to try out pretty much every new phone that comes out in Europe - when I have time. I have used Blackberries, SonyEricssons, Nokias, even Windows Mobile devices of all sorts - _at least_ a different one _per month_, and, on occasion (when I'm asked to do solutions testing) several a week.
I have also been tied to (and am still very much aware of) what it takes to run a mobile portal for hundreds of different mobile devices, and believe me when I say that there are a lot more _working_ XHTML mobile browsers out there than you may think.
Yes, the iPhone is better. There's no denying that.
But rushing headlong into a single way of doing things without caring for either code re-use or standards compliance is not a good survival strategy for _developers_, since you may not be able to re-use the skills you learn when you tie yourself to a very specific platform.
So when developers go and code their nice iPhone-specific apps, they will be limited to the (still fairly small, if not minuscule) global footprint of iPhone users.
You can say that the iPhone will evolve (and I will agree), but nevertheless the reality is that not everybody will have one.
And yet, the very fact that it exists and has (hopefully) workable web applications (not just in terms of interaction and design, but also in terms of business models) may bring about (or rather, _is_ bringing about) a renewed interest in web-based mobile applications - for _all_ mobile phones.
The prospective market for those will expand, and with it the opportunity for developers. And other manufacturers are sure to at least _try_ to catch up with Apple.
And what happens when you have five or six dominant mobile devices with decent browsers one or two years down the line (I'm personally betting sooner), and working business models to sell those applications?
Are you going to stick to supporting _just_ the iPhone, or will you re-code everything for each new device? And would you prefer to have planned for that from the start, or have to do it again, and again, and again?
_That's_ why I think there should be careful planning, standards compliance (and forethought) when designing iPhone applications, not just blind faith.
I largely agree with you. In particular I mostly hear about multi- function sites from those that have not lived with an iPhone, or really have a different business model and are just wanting to be compatible with its browser. Those of us that live with one all day long have a very different motivation I think. We love the device and can think of sooooo many things we could do with such constant access. The difference between wearing an iPhone and having access to a computer, is something like the difference between a traveling salesman having a laptop and a desktop back at the office. The frequency of access makes all the difference. Luckily there is room for us all and we do not need to make anyone else play by our rules.
> I love jQuery, but I would strongly like to avoid dependencies on any > JavaScript libraries. Every byte counts when you're developing for a > phone that downloads so incredibly slowly. When we started the Tilt > game, my teammates suggested using jQuery after I had already started > without it. When we added jQuery, the game went from loading in less > than a second, to waiting about four seconds, and this was over WiFi. > That 667mhz processor doesn't like to have to parse and interpret > large amounts of JavaScript either.
> As far as standards support - I know this is politically incorrect, > but I think it's too soon to start worrying about that. Let me know > when there is another phone that is even remotely close to the > capabilities of the iPhone's browser. Those proprietary -webkit tags > allow us to do some really advanced stuff that saves a lot of > bandwidth and makes pages look great, -webkit-border-image and - > webkit- > text-shadow in particular. I think it's a little too soon to start > watering down the capabilities of iPhone apps. My philosophy is that > we *should* build proprietary apps that work only on the iPhone to > motivate other companies to catch up faster.
> I also really do not think you should be trying to make your iPhone > apps degrade. You should write your iPhone apps separately. The > iPhone is a dramatically different experience and you owe it to your > users to optimize for that environment instead of spending your time > trying to create a single app that morphs. Inevitably, people who go > that route are going to make compromises that hurt the iPhone > experience, and that would make me sad. Again, let me know when > there's another phone that approaches it, and then we can talk about > degrading.
On 7/9/07 1:55 PM, "Rui Carmo" <rui.ca...@gmail.com> wrote:
> Yes, the iPhone is better. There's no denying that.
> But rushing headlong into a single way of doing things without caring > for either code re-use or standards compliance is not a good survival > strategy for _developers_, since you may not be able to re-use the > skills you learn when you tie yourself to a very specific platform.
> So when developers go and code their nice iPhone-specific apps, they > will be limited to the (still fairly small, if not minuscule) global > footprint of iPhone users.
Amen. And I think there's another distinction that needs to be made - the difference between "hobbyists" and professional developers.
None of my clients are going to pay me to build an application that only works on the iphone. But I'll bet a lot of them are going to be willing to shell out some dough to make sure their sites still work well on it, along with other mobile devices.
My mini-site for the tattoo convention earned me a bottle of very expensive tequila from the organizer of the event. So it's paying off already :)
Dean Hamack Macromedia Certified Flash MX Designer/ Lead Web Developer Bushido Designs Tel:(206)523-6705 www.bushidodesigns.net
You make many good points. I can suggest that part of the difference is that you are in Europe. In the US from what I have seen (limited by your standards), the options are not nearly as good because the carriers have such a stranglehold on the devices. This above all else may be what we hope for from the iPhone, and in the near term will not get. Until devices are separated from the carriers in the US we are going to have much less choice then you in Europe.
>> I love jQuery, but I would strongly like to avoid dependencies on any >> JavaScript libraries. Every byte counts when you're developing for a >> phone that downloads so incredibly slowly. When we started the Tilt >> game, my teammates suggested using jQuery after I had already started >> without it. When we added jQuery, the game went from loading in less >> than a second, to waiting about four seconds, and this was over WiFi. >> That 667mhz processor doesn't like to have to parse and interpret >> large amounts of JavaScript either.
> Odd, since a bog standard Nokia consumer device does that just fine. > And I would suppose that would be a transient limitation until Apple > tweaks the platform.
>> As far as standards support - I know this is politically incorrect, >> but I think it's too soon to start worrying about that. Let me know >> when there is another phone that is even remotely close to the >> capabilities of the iPhone's browser.
> Erm... You're kidding, right? Yes, WebKit on the iPhone seems to be > pretty impressive. But I've had WebKit browsers on other devices for > a good while now, and the basic capabilities - the _core_ ones, not > the interaction/cosmetic ones - are mostly the same.
>> Those proprietary -webkit tags >> allow us to do some really advanced stuff that saves a lot of >> bandwidth and makes pages look great, -webkit-border-image and - >> webkit- >> text-shadow in particular. I think it's a little too soon to start >> watering down the capabilities of iPhone apps.
> It's not watering down, it's making sure you can re-use your coding > investment on something else.
>> My philosophy is that >> we *should* build proprietary apps that work only on the iPhone to >> motivate other companies to catch up faster.
> Okay, you lost me there. I disagree, completely.
> I understand your enthusiasm, but I have gone through too many > platforms to see things that way. Sure, I use a Mac and wouldn't use > _anything_ else at home, but the world just doesn't work that way.
> I am lucky enough to be able to try out pretty much every new phone > that comes out in Europe - when I have time. I have used > Blackberries, SonyEricssons, Nokias, even Windows Mobile devices of > all sorts - _at least_ a different one _per month_, and, on occasion > (when I'm asked to do solutions testing) several a week.
> I have also been tied to (and am still very much aware of) what it > takes to run a mobile portal for hundreds of different mobile > devices, and believe me when I say that there are a lot more > _working_ XHTML mobile browsers out there than you may think.
> Yes, the iPhone is better. There's no denying that.
> But rushing headlong into a single way of doing things without caring > for either code re-use or standards compliance is not a good survival > strategy for _developers_, since you may not be able to re-use the > skills you learn when you tie yourself to a very specific platform.
> So when developers go and code their nice iPhone-specific apps, they > will be limited to the (still fairly small, if not minuscule) global > footprint of iPhone users.
> You can say that the iPhone will evolve (and I will agree), but > nevertheless the reality is that not everybody will have one.
> And yet, the very fact that it exists and has (hopefully) workable > web applications (not just in terms of interaction and design, but > also in terms of business models) may bring about (or rather, _is_ > bringing about) a renewed interest in web-based mobile applications - > for _all_ mobile phones.
> The prospective market for those will expand, and with it the > opportunity for developers. And other manufacturers are sure to at > least _try_ to catch up with Apple.
> And what happens when you have five or six dominant mobile devices > with decent browsers one or two years down the line (I'm personally > betting sooner), and working business models to sell those > applications?
> Are you going to stick to supporting _just_ the iPhone, or will you > re-code everything for each new device? And would you prefer to have > planned for that from the start, or have to do it again, and again, > and again?
> _That's_ why I think there should be careful planning, standards > compliance (and forethought) when designing iPhone applications, not > just blind faith.
Does anyone have a working demo of the jQuery changes that TheTaoOfMac came up with? I'm not too familiar with jQuery (although it looks like I'm going to be very soon), so I would like to see a demo of it before I start implementing it in my web apps, but I think it looks very promising.
On Jul 9, 1:56 pm, "Christopher Allen" <Christoph...@iPhoneWebDev.com> wrote:
> In spite of its great capabilities and effectiveness as a example, > even Joe was not really prepared for how popular it became. From his > bloghttp://www.joehewitt.com/blog/iphonedevcamp.php
> [quote] > Another fun thing about iPhoneDevCamp was my constant surprise as I > found one project after the other using the iPhone app template that I > threw together on Thursday night. I didn't really think this bit of > code was ready for prime time, which is why I didn't even mention it > on this blog. I only posted a link to it on the iPhoneWebDev Google > Group. When I woke up the next morning it was already on Ajaxian. > Later that evening, Jeffrey Grossman launched Movies.app, which used > the template for its UI. The next morning I met Kristopher Tate of > Zooomr, who had created a Google Code project based on my code and > started using it to build a music browser. Throughout the weekend I > met one group after another using the template for their Hackathon > projects. I guess the lesson is that people are really happy to be > able to focus on their apps instead of re-inventing Apple's UI! I'm > definitely going to put some more time into it this week to clean it > up and add some more features that people asked for. > [/quote]
> [quote] > I most sincerely hope that the iPhone doesn't give rise to a bunch of > Safari-centric, egotistical, incompatible, and "standards > para-compliant" applications - i.e., stuff that is formally standards > compliant (because it is, after all, HTML and JavaScript) but that > uses so many WebKit or Safari-specific idioms that ends up not working > properly (if at all) in other browsers.
> Otherwise, we'll be back where we started when IE was all the rage, > and repeating all the same mistakes.
> So remember: Just because you're doing it on the coolest phone on the > planet doesn't automatically make it right.
> Update: For instance, I've been playing around with Joe Hewitt's > navigation sample, which is pretty neat, but only works on the iPhone > browser and on the WebKit nightlies (yes, I refuse to run Safari 3.0 > anywhere but Windows until it's stable).
> After doing a few simple changes, it now works in "regular" Safari > (2.0) and my Nokia. Although I haven't replaced the animation code > with "normal" jQuery effects yet, all it takes is to change the > handlers in a standard way:
> $(document).ready(function() { > // Show the page corresponding to the home button link > // (we get the button's link and then the element that has that hash > as its ID) > showPage($('#' + $('#homeButton').get(0).hash.substr(1)).get(0));
> // Teach all links to invoke the showPage function > $("a").click(function(){ > // Show the first match for "#hash" > showPage($('#' + this.hash.substr(1)).get(0)); > });
> // Periodic checks for iPhone orientation > setInterval(checkOrientAndLocation, 300);
> Nothing else was changed (except removing addEventListener from > iphonenav.js). But the rest - all the rest - looks like it can be > replaced by six to ten lines of jQuery code...
> Of course the CSS is all shot due to "proprietary" WebKit stuff, but > that's fixable. If I have time, I'll post the results somewhere. > [/quote]
> I've invited the TaoOfMac blogger, who is professional a cell phone > developer in Europe to join us here in iPhoneWebDev.
> So maybe we should find a way to collectively make a better example, > one that works on the iPhone, but doesn't completely break other > desktop or cellphone browsers. I'd be glad to host a SVN repository, > with Joe as lead, to allow multiple people to contribute to make what > is currently the best example code we have into something even better.
> Thoughts?
> -- Christopher Allen
> P.S. Anyone have a better name for this project?
> I have also been tied to (and am still very much aware of) what it > takes to run a mobile portal for hundreds of different mobile > devices, and believe me when I say that there are a lot more > _working_ XHTML mobile browsers out there than you may think.
I didn't say anyone should ignore these other browsers, I'm just saying that for now they should build one version for iPhone and one for other phones. We're talking about tiny apps that run on a tiny screen and have small feature sets - the cost of managing two UI code bases will often be not that high.
> You can say that the iPhone will evolve (and I will agree), but > nevertheless the reality is that not everybody will have one.
This is true, but for those users that do have an iPhone, it is wrong to hurt their experience. In my opinion, if we start preaching for people to continue to use the familiar "graceful degradation" model, the result will be iPhone apps that miss their potential. At least until Nokia and others catch up, which I hope they do soon.
The word "standard" is often used prematurely. Standards are supposed to come from lessons learned by creating products that advance the state of the art. Sadly, web standards have tended to come instead from slow-moving working groups comprised of people who have never written a real web app in their life. The iPhone is a new platform just brimming with potential for new design and interaction patterns, and in my opinion we should attempt to achieve those patterns through whatever means possible, and then create standards later based on what we learn. Frankly, I think that the web has been hurt badly by this standards obsession. It has given browser makers an excuse not to innovate - they just wait for instruction from the W3C, which has been asleep at the wheel. The lack of progress in browser technology the last 5 years has been an absolute tragedy.
A lot of what I'm saying hinges on my belief that iPhone Safari will soon allow us to do more multi-touch stuff with JavaScript. That's what really separates the iPhone from other phones, not just what browser engine they use. Once that happens, designing an iPhone apps means relying on gestures instead of putting lots of buttons and scrollbars in the UI. In my opinion, "gracefully degraded" web pages will probably wind up leaving lots of crud in the iPhone apps that don't need to be there, because it was just easier to just target the lowest common denominator.
> And yet, the very fact that it exists and has (hopefully) workable > web applications (not just in terms of interaction and design, but > also in terms of business models) may bring about (or rather, _is_ > bringing about) a renewed interest in web-based mobile applications - > for _all_ mobile phones.
> The prospective market for those will expand, and with it the > opportunity for developers. And other manufacturers are sure to at > least _try_ to catch up with Apple.
> And what happens when you have five or six dominant mobile devices > with decent browsers one or two years down the line (I'm personally > betting sooner), and working business models to sell those applications?
> Are you going to stick to supporting _just_ the iPhone, or will you > re-code everything for each new device? And would you prefer to have > planned for that from the start, or have to do it again, and again, > and again?
> _That's_ why I think there should be careful planning, standards > compliance (and forethought) when designing iPhone applications, not > just blind faith.
> You make many good points. I can suggest that part of the difference > is that you are in Europe.
I'm positive it is. Which, in its own twisted way, is not exactly in my favor right now :)
> In the US from what I have seen (limited > by your standards), the options are not nearly as good because the > carriers have such a stranglehold on the devices. This above all > else may be what we hope for from the iPhone, and in the near term > will not get. Until devices are separated from the carriers in the > US we are going to have much less choice then you in Europe.
Well, I'm yet to ascertain exactly what an European iPhone will look like (and when it will be available, and via whom), so I wouldn't score Europe that highly in terms of choice where it regards the iPhone...
But I have to wonder if all the folk here in this group are US-based or if I will be alone in trying to explain that wild abandon and handcrafting JavaScript code will not be that good a long-term strategy for you guys :)
Anyway, there are other options besides jQuery out there (btw, 1.1.3.1 is _fast_). And you could always consider doing an "iQuery" with the minimum code required to ensure everyone had a good, fast framework to build iPhone apps (increasing the chances of code re-use inside the community) and still allow for "sidegrading" iPhone apps to other browsers by replacing/tweaking that "iQuery".
The source code for jQuery is out there - and the uncompressed form is pretty readable...
> Does anyone have a working demo of the jQuery changes that TheTaoOfMac > came up with? I'm not too familiar with jQuery (although it looks > like I'm going to be very soon), so I would like to see a demo of it > before I start implementing it in my web apps, but I think it looks > very promising.
> On Jul 9, 2007, at 9:29 PM, Joe Hewitt wrote: >> My philosophy is that >> we *should* build proprietary apps that work only on the iPhone to >> motivate other companies to catch up faster.
> Okay, you lost me there. I disagree, completely.
For me you are both right. Yes, there is a certain need for highly optimized standards enforced browser independent web site design. But, that has always been true.
On the other hand, it seems perfectly reasonable to start off writing an app that works on the target device. It's kinda finicky. Not every client wants to publish their app to the world, either.
The reason we have Joe's "example" is because he wrote for the target device. It is excellent in that it sorta looks like an iPApp and sorta behaves like one, oh yea and it runs.
I think the boundary here is the need to create iPhone support for a site and the need to create apps that have a reasonable feature parity with the existing iPhone applications. Certainly both are reasonable specifications, but currently nobody has either wrapped up.
Last night I used Joe's example to turn a otherwise silly CGI into an amazing "app" to wow my friends and family. They all think I'm a genius for code I wrote a year ago and essentially rewrapped with a very clever style sheet. Even with Joe's code it's just a hack, but after a revision or two it could be really handy. So, I think Joe is a genius and I say we give him plenty of room. Personally, I can't wait for the updates!
> Anyway, there are other options besides jQuery out there (btw, > 1.1.3.1 is _fast_). And you could always consider doing an "iQuery" > with the minimum code required to ensure everyone had a good, fast > framework to build iPhone apps (increasing the chances of code re-use > inside the community) and still allow for "sidegrading" iPhone apps > to other browsers by replacing/tweaking that "iQuery".
I'm not sure what that side-port would be, or what what would be in it - we already strip it down to the bare minimum of functionality that nearly everyone uses (Ajax and Effects are usually the two areas that some users don't, sometimes, use - but more often than not, they're used by most people).
@Joe, et. al.: I'm not sure where most of the time is being spent - it's certainly not in the download of the code (20k will be smaller than most images used). So my guess is that the packed version of jQuery is putting the processor through unnecessary strain.
This is minified (no time spent uncompressing) and comes in at about 35k. If this proves to drastically help you guys, I'll put some serious effort into reducing some file size for 1.1.4 and run it through Dojo's ShrinkSafe (which will reduce the size without adding decompression overhead). I'd guess that the final result of that would be around 30k, maybe slightly less.
On 9 Lug, 19:56, "Christopher Allen" <Christoph...@iPhoneWebDev.com> wrote:
> Nothing else was changed (except removing addEventListener from > iphonenav.js). But the rest - all the rest - looks like it can be > replaced by six to ten lines of jQuery code...
Here is a mootools version, which is downloadable in dependencies, and much smaller:
window.onDomReady(function() { // Show the page corresponding to the home button link // (we get the button's link and then the element that has that hash as its ID) showPage('#' + $('homebutton').hash.substr(1));
// Teach all links to invoke the showPage function $$('a').addEvent('click', function(){ // Show the first match for "#hash" showPage('#' + this.hash.substr(1)); });
// Periodic checks for iPhone orientation setInterval(checkOrientAndLocation, 300);
I tried to test over edge, but I lost patients after a while because a.) I can barely get a signal in my office as it is, and b.) it's so slow horrible that I can't get any consistent results. That being said, however, it looks like your new version is a very significant load time improvement. The tests I did over edge seemed to be about the same for the load times between the two versions, but I think the bandwidth is the only bottleneck there. Thank you for the link, this is a huge step around the bandwidth issues!
I really love jQuery, and so does Chris and some of the other guys here at (mt) if you know 'em, but do you have to download the entire package? I know I could go through the .js file and strip out the functions I'm not using, but it would be nice to have a quick and easy way to compile the jQuery js file using only that which is needed... (kinda like mootools :-x). Just a suggestion!
On the subject of standards vs. innovation, well thats a pretty touchy issue, and against my better judgement I'll throw in my two cents. I believe that there is a place and time for both. We should always strive to push each individual hardware device to it's limits, exploiting everything we can about it in order to make a richer experience for the user, after all the user is what matters most imho. However, for larger applications that involve man-hours in the hundreds, it's obviously important to create portable code that will work on a wider range of devices with as little tweaking required as possible. I don't think that either method is greater than the other, in fact, I strongly believe that each method is necessary for growth.
As many of us have heard before, scalability, usability, production time, and coolness-factor are just a few of the things that one should take into consideration upon starting a new project. Some things may be sacrificed on a per-project basis, but you should never lock yourself into believing that any one of them is irrelevant.
Dain Kennison
On Jul 9, 4:56 pm, John Resig <jere...@gmail.com> wrote:
> > Anyway, there are other options besides jQuery out there (btw, > > 1.1.3.1 is _fast_). And you could always consider doing an "iQuery" > > with the minimum code required to ensure everyone had a good, fast > > framework to build iPhone apps (increasing the chances of code re-use > > inside the community) and still allow for "sidegrading" iPhone apps > > to other browsers by replacing/tweaking that "iQuery".
> I'm not sure what that side-port would be, or what what would be in it > - we already strip it down to the bare minimum of functionality that > nearly everyone uses (Ajax and Effects are usually the two areas that > some users don't, sometimes, use - but more often than not, they're > used by most people).
> @Joe, et. al.: I'm not sure where most of the time is being spent - > it's certainly not in the download of the code (20k will be smaller > than most images used). So my guess is that the packed version of > jQuery is putting the processor through unnecessary strain.
> This is minified (no time spent uncompressing) and comes in at about > 35k. If this proves to drastically help you guys, I'll put some > serious effort into reducing some file size for 1.1.4 and run it > through Dojo's ShrinkSafe (which will reduce the size without adding > decompression overhead). I'd guess that the final result of that would > be around 30k, maybe slightly less.
I agree with Joe's take on all this as it relates only to iPhone-centric applications. I used to work in the music industry, living in recording studios for weeks at a time. I once asked the mixing engineer why they spend so much money, time and effort to make sure the mixing room is a near perfect listening environment when a huge majority of end listeners don't have anything near as good. His reply made perfect sense. "We mix the music in as perfect as an environment as possible to guarantee the music sounds as good as it can under perfect conditions. This naturally lends itself to graceful degradation to lesser optimized listening situations. Ie.$19 in-ear headphones, 4" computer speakers and boomboxes." They do switch between different types of speakers and check it in mono as a good indicator of how it would 'render' over the average stereo system or am radio etc., but the main goal is to make it sound as good as it possibly can. Even if 60% of the listening audience is using cheap-ass in-ear headphones that don't reproduce lower frequencies properly, they don't compensate in the mix by pumping the bass.
I'd like to point out that as Christopher has mentioned countless times, there are at least three different niches of programming aimed at the iPhone. Compatible with, optimized for and made for iPhone. Those who seem outraged that someone would even think of designing something that only rendered properly on the iPhone are probably living in that 1st category. That's all find and good. Each category of programming is going to have its own rules/ideals for what is the overall good for that category. However, for clarity and sanity, the debating of those rules/ideals needs to be restricted to their individual categories. The thing that's going on here is a cross category debate of rules/ideals. As soon as the 'compatible with' camp starts telling the 'made for' camp how to do things, both camps start spinning their wheels and chasing their tales. If 'compatible with' is your thing, or what your client will hire you for, GREAT! I wish you all the best. But if 'made for' is your niche, then do not hesitate to pull every CSS trick/hack out of the book to elevate the experience of your iPhone app as high as possible. Don't 'pump the bass' just to make it compatible with other phones or desktop browsers as that would lessen the iPhone experience of the app. I'm not talking in absolutes here, ie.yes, you can adjust code so it does similar things on other devices... So don't flame me or start any sort of device wars. That's not what this is about at all.
I know that for me, for the time being, I am concentrating on how to get the coolest, most useful experiences out of an iPhone app. It is a non-issue that it may not work properly on any other device/browser since that's not what it was made for in the first place. Like DHH of Rails say's whenever someone suggests this or that feature, "That sounds like a great idea. You should do that." Joe's initial UI is a great start in iPhone centric apps. The fact that someone else is tweaking it to be somewhat more cross-platform friendly is pretty cool and an example of how the community together can move forward. The whole pointing finger thing, telling someone to change their creation to fit some other device is short-sighted and self-centered. If I were Joe, I'd tell those people "That sounds like a great idea. You should do that."
-=Randy
On 7/9/07 2:25 PM, "Joe Hewitt" <joehew...@gmail.com> wrote:
>> I have also been tied to (and am still very much aware of) what it >> takes to run a mobile portal for hundreds of different mobile >> devices, and believe me when I say that there are a lot more >> _working_ XHTML mobile browsers out there than you may think.
> I didn't say anyone should ignore these other browsers, I'm just > saying > that for now they should build one version for iPhone and one for > other > phones. We're talking about tiny apps that run on a tiny screen and > have small feature sets - the cost of managing two UI code bases > will often be not that high.
>> You can say that the iPhone will evolve (and I will agree), but >> nevertheless the reality is that not everybody will have one.
> This is true, but for those users that do have an iPhone, it is wrong > to hurt their experience. In my opinion, if we start preaching > for people to continue to use the familiar "graceful degradation" > model, the result will be iPhone apps that miss their potential. At > least until Nokia and others catch up, which I hope they do soon.
> The word "standard" is often used prematurely. Standards are supposed > to come from lessons learned by creating products that advance the > state of the art. > Sadly, web standards have tended to come instead from slow-moving > working groups > comprised of people who have never written a real web app in their > life. > The iPhone is a new platform just brimming with potential for new > design and interaction patterns, and in my opinion we should attempt > to > achieve those patterns through whatever means possible, and then > create > standards later based on what we learn. Frankly, I think that the web > has > been hurt badly by this standards obsession. It has given browser > makers > an excuse not to innovate - they just wait for instruction from the > W3C, which > has been asleep at the wheel. The lack of progress in browser > technology the > last 5 years has been an absolute tragedy.
> A lot of what I'm saying hinges on my belief that iPhone Safari will > soon allow us > to do more multi-touch stuff with JavaScript. That's what really > separates the > iPhone from other phones, not just what browser engine they use. > Once that > happens, designing an iPhone apps means relying on gestures instead of > putting > lots of buttons and scrollbars in the UI. In my opinion, "gracefully > degraded" > web pages will probably wind up leaving lots of crud in the iPhone > apps that > don't need to be there, because it was just easier to just target the > lowest common > denominator.
>> And yet, the very fact that it exists and has (hopefully) workable >> web applications (not just in terms of interaction and design, but >> also in terms of business models) may bring about (or rather, _is_ >> bringing about) a renewed interest in web-based mobile applications - >> for _all_ mobile phones.
>> The prospective market for those will expand, and with it the >> opportunity for developers. And other manufacturers are sure to at >> least _try_ to catch up with Apple.
>> And what happens when you have five or six dominant mobile devices >> with decent browsers one or two years down the line (I'm personally >> betting sooner), and working business models to sell those applications?
>> Are you going to stick to supporting _just_ the iPhone, or will you >> re-code everything for each new device? And would you prefer to have >> planned for that from the start, or have to do it again, and again, >> and again?
>> _That's_ why I think there should be careful planning, standards >> compliance (and forethought) when designing iPhone applications, not >> just blind faith.
> On 9 Lug, 19:56, "Christopher Allen" <Christoph...@iPhoneWebDev.com> > wrote: >> Nothing else was changed (except removing addEventListener from >> iphonenav.js). But the rest - all the rest - looks like it can be >> replaced by six to ten lines of jQuery code...
> Here is a mootools version, which is downloadable in dependencies, and > much smaller:
Pretty neat. Mootools has been on my radar for a while, but I never did much testing with it. Can you do the scrolling bits with it as well?
>> Anyway, there are other options besides jQuery out there (btw, >> 1.1.3.1 is _fast_). And you could always consider doing an "iQuery" >> with the minimum code required to ensure everyone had a good, fast >> framework to build iPhone apps (increasing the chances of code re-use >> inside the community) and still allow for "sidegrading" iPhone apps >> to other browsers by replacing/tweaking that "iQuery".
> This is minified (no time spent uncompressing) and comes in at about > 35k. If this proves to drastically help you guys, I'll put some > serious effort into reducing some file size for 1.1.4 and run it > through Dojo's ShrinkSafe (which will reduce the size without adding > decompression overhead). I'd guess that the final result of that would > be around 30k, maybe slightly less.
Hmmm. Now that you mention decompression (JS decompression/parsing at the interpreter level) I have to wonder - does the iPhone support gzip transfer-encoding (i.e., compression within the HTTP stack)? HTTP/1.1 pipelining?
Because I think someone should sit down and look at those and factor them into page load/parsing times, etc.
EDGE can't be worse than GPRS in that regard, and my experience is that tweaking the server to use gzip and pipelining considerably improves the overall experience for mobile devices - one socket connection, multiple requests without setting up another socket, etc...
On 7/10/07, Rui Carmo <rui.ca...@gmail.com> wrote:
> Hmmm. Now that you mention decompression (JS decompression/parsing at > the interpreter level) I have to wonder - does the iPhone support > gzip transfer-encoding (i.e., compression within the HTTP stack)? > HTTP/1.1 pipelining?
> Because I think someone should sit down and look at those and factor > them into page load/parsing times, etc.
> EDGE can't be worse than GPRS in that regard, and my experience is > that tweaking the server to use gzip and pipelining considerably > improves the overall experience for mobile devices - one socket > connection, multiple requests without setting up another socket, etc...
That is a good question. I vaguely heard that it did at WWDC, but I don't recall seeing it officially on any slides or anything.
Time for me to go look up some Apache configuration docs ;-)
> On 7/10/07, Rui Carmo <rui.ca...@gmail.com> wrote: >> Hmmm. Now that you mention decompression (JS decompression/parsing at >> the interpreter level) I have to wonder - does the iPhone support >> gzip transfer-encoding (i.e., compression within the HTTP stack)? >> HTTP/1.1 pipelining?
>> Because I think someone should sit down and look at those and factor >> them into page load/parsing times, etc.
>> EDGE can't be worse than GPRS in that regard, and my experience is >> that tweaking the server to use gzip and pipelining considerably >> improves the overall experience for mobile devices - one socket >> connection, multiple requests without setting up another socket, >> etc...
> That is a good question. I vaguely heard that it did at WWDC, but I > don't recall seeing it officially on any slides or anything.
> Time for me to go look up some Apache configuration docs ;-)
> I love jQuery, but I would strongly like to avoid dependencies on any > JavaScript libraries. Every byte counts when you're developing for a > phone that downloads so incredibly slowly. When we started the Tilt > game, my teammates suggested using jQuery after I had already started > without it. When we added jQuery, the game went from loading in less > than a second, to waiting about four seconds, and this was over WiFi. > That 667mhz processor doesn't like to have to parse and interpret > large amounts of JavaScript either.
> As far as standards support - I know this is politically incorrect, > but I think it's too soon to start worrying about that. Let me know > when there is another phone that is even remotely close to the > capabilities of the iPhone's browser. Those proprietary -webkit tags > allow us to do some really advanced stuff that saves a lot of > bandwidth and makes pages look great, -webkit-border-image and -webkit- > text-shadow in particular. I think it's a little too soon to start > watering down the capabilities of iPhone apps. My philosophy is that > we *should* build proprietary apps that work only on the iPhone to > motivate other companies to catch up faster.
> I also really do not think you should be trying to make your iPhone > apps degrade. You should write your iPhone apps separately. The > iPhone is a dramatically different experience and you owe it to your > users to optimize for that environment instead of spending your time > trying to create a single app that morphs. Inevitably, people who go > that route are going to make compromises that hurt the iPhone > experience, and that would make me sad. Again, let me know when > there's another phone that approaches it, and then we can talk about > degrading.
|
