The SitePoint Podcast: A Brain of Cats

Produced by The SitePoint Podcast published 11 years ago | Filed in
The SitePoint Podcast

The Internet Archive comes to the rescue of short URLs; Microsoft provides a sneak peek at what’s coming in IE9; and AOL gets a new logo ... or does it? Related posts: 1. SitePoint Podcast #17: 12 Kinds of Awesome A big two weeks for the Web makes for a... 2. SitePoint Podcast #13: Digg.

Running time
0h51m
File size
48.00MB

Download Original File | View original post

Episode synopsis

Episode 38 of The SitePoint Podcast is now available! This week your hosts are Stephan Segraves (@ssegraves) and Kevin Yank (@sentience).

Listen in your Browser

Play this episode directly in your browser! Just click the orange “play” button below:

Download this Episode

You can also download this episode as a standalone MP3 file. Here’s the link:

Subscribe to the Podcast

The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.

Episode Summary

Here are the topics covered in this episode:

301Works Plans to Save Short URLs

Internet Explorer 9: Early Days

Proposed Standard for Resource Packages

AOL Rebranding

Are iPhone Developers Stupid?

Host Spotlights:

Show Transcript

Kevin: November 27th, 2009. The Internet Archive comes to the rescue of short URLs; Microsoft provides a sneak peek at what’s coming in IE9; and AOL gets a new logo … or does it? This is the SitePoint Podcast #38: A Brain of Cats.

And welcome to another episode of the SitePoint Podcast. We have a shortage of hosts this week, just me and Stephan Segraves joining you today, but luckily, there’s no shortage of stuff to talk about, Stephan. We’ve got 301Works.org, the new AOL logo, some whisperings of what’s coming in Internet Explorer 9 and someone asking if iPhone developers are stupid—all that and more on the show today. But let’s start with the 301Works because it’s something we’ve talked about before way back in podcast 24, right, Stephan?

Stephan: Yep, we sure did. We talked about what’s going to happen if— tr.im, at the time, had gone away and the URLs had disappeared and 301Works.org has shown up and they have come up with a way, or have come up with a plan, I should say, to bring back the URLs or give us a historical archive of the URLs if something should happen to another URL shortening service.

Kevin: So to refresh the memories of our listeners, this all has to do with short URLs that have become popular because of Twitter—because Twitter limits the number of characters you can put in a message—and so the shorter the URL the better. So all these services like trim, like bit.ly, which is the market leader, let you create short URLs that redirect to long URLs. So, yeah, as you say, there’s concern and we saw it with tr.im. It almost shut down and at that time 301Works.org was something that had been dreamed up by bit.ly and trim in its death throes at the time, took a shot at 301Works. They called it “little more than a bit.ly public relations stunt.”

Stephan: I think they’re just angry about bit.ly being the Twitter’s de facto standard at the time.

Kevin: Yeah. I can’t say it was a very classy move. It got me wondering. I wondered if they were right that 301Works really was just a way of bit.ly saying everyone else is ‘fly-by-night’ and if anything goes wrong, we’ll take care of it for you.

Stephan: Well, it looks like this is actually moving forward, which is impressive. I mean they’ve got archive, what is it, Archive.org now behind it and they’re coming up with a plan, so I think it looks legitimate that they’re really trying to make this work.

Kevin: Maybe it was a public relations stunt at the time but it looks like it has come a long way and if it’s got the support of Archive.org, color me impressed. There’s this announcement on the Archive.org web site saying that the 301Works.org domain and that the responsibility for that has been handed over to Archive.org. So in the case of any URL shortening service that is a member of this working group; in the case that any one of these goes down or goes away or goes out of business, everyone who’s signed on to this has pledged to hand over the keys to their domain to Archive.org and meanwhile, Archive.org is keeping a running archive of all of these short URLs that are being created so that if they ever need to, if any one of these players goes out of business, Archive.org can take over responsibility for that domain and continue redirecting all those URLs for as long as necessary—which is forever, basically. So this is great.

Stephan: It is good news. It’s really good news. I was looking at the participating companies I don’t see tr.im on the list.

Kevin: No.

Stephan: And so it’s kind of like, “Well, everyone should be participating, why not?”

Kevin: Yeah, and trim at the time said— Well, bit.ly extended an olive branch, as they put it and said, “trim, if you’re going out of business, we’ll take care of you under the 301Works initiative,” and trim said, “Nuts to that. We’re just going to sell our service.” And if memory serves, they couldn’t find anyone willing to pay what it was worth without effectively spamming all the users of the service in return and so they went into business for themselves—or they open sourced it and promised that they would continue funding it for as long as necessary to keep it running. I’m not sure how well that’s working out for them.

Stephan: So that leads to the question of do you think this leads to us being more reliant on the URL shorteners—the services—or do you think we should still do it ourselves because we were having a discussion, should we do it ourselves or should we use a service. I was wondering what you thought about that.

Kevin: Yeah, it’s a good question.

Stephan: I’m kind of like wanting to go back to bit.ly and just use bit.ly for everything now.

Kevin: I think, technically, the right approach is for people to shorten their own URLs using an open standard like the one that we saw that let you put a <link> tag in your pages saying ‘the short URL to this page is the following’, and that way, everyone’s responsible for maintaining their own URLs, it’s a sharing of the load. If your short URLs stop working, it’s because you fell asleep at the wheel, you didn’t care enough about keeping your content permalinked, but that doesn’t affect the internet as a whole.

Stephan: Gotcha.

Kevin: Unfortunately, on the Web, the best technical solution isn’t always the one that wins out. Sometimes it’s the one that’s the most convenient and so I think people will end up relying on services like bit.ly and the fact that Archive.org is stepping in… You know, Archive.org—this is the business they’re in. They’re in the business of preserving the history of the Web despite the fact that people are lazy and people will let their sites go away and giant sites like GeoCities will shut down because of financial concerns with no thought to the permanent record. So I think if we were all doing the right thing, if everyone chose the right course by history, then there wouldn’t be a need for Archive.org, but I think there is that need and I’m glad they’re there.

Stephan: Yeah, I agree.

Kevin: Interesting though at the very end of the Archive.org announcement, they provide a link to the 301Works web site and it’s a typo–they put a link to 310Works.org. So someone clever jumped on that and put a site up at 310Works.org with some Google ads on it but they were nice enough to actually write on this web site about URL shortening, about why it’s a risky thing and why the 301Works initiative is a good one and they then provide a link to the actual 301Works site. I’m quoting here. They say, “310Works.org is absolutely not the organization that’s needed. In fact, it is a pathetic, confusing, and cheap for-profit-please web site that aims to take advantage of an honest and simple typo. These guys are douches. If however, you really are interested in the longevity of shortened URLs, we suggest you visit 301works.org.” So they have a sense of humor about themselves and that’s great.

Stephan: That was nice of them to give a link.

Kevin: Yeah. Next thing we’re looking at is Internet Explorer 9. We joked about Internet Explorer 9 in my recordings that I did at Web Directions South a couple of months back. One of the attendees there was smart-cracking that was he was really excited about on the web at the moment was Internet Explorer 9, which at the time didn’t even exist. But now Microsoft has come out and provided a sneak peek at what they’re working on for Internet Explorer 9 and what especially interested me in this case is that they’re actually calling it Internet Explorer 9. At this point in the development of IE 7 and IE 8, they said, “Yeah, the marketing people haven’t made a final decision on what it’ll be called so we can’t call it anything other than the next version of Internet Explorer.” So we started calling it IE Next. But it seems like they’ve lightened up or at least they already know that it’s going to be Internet Explorer 9 when they’re done with it, but yeah, here we have on the Internet Explorer blog a look at what’s coming. Stephan, correct me if I’m wrong but you weren’t too impressed by this.

Stephan: No, I mean I don’t use Internet Explorer to begin with, but the first thing that I saw was the lack of ability to pass the Acid3 Test—just caught my eye—and I’m like oh…

Kevin: Yeah, they’re bragging about the fact that their current internal build has achieved 32 out of 100 on the Acid3 Test.

Stephan: Maybe they just haven’t got around to the other 68, I don’t know.

Kevin: And I say bragging. I say bragging and that’s a loaded term so I could be seen as accusing them of pounding their chests and saying, “Look how great Internet Explorer is,” and I hate to make that implication but that’s really how a lot of this blog post reads. It’s written in this tone of, “Here are the amazing things that are coming in Internet Explorer 9. We’re going to have better support for the Acid3 Test,” where browsers like Opera now have released a version that passes Acid3, 100 out of 100. “We’re going to have support for CSS rounded corners,” hallelujah!

Stephan: Finally.

Kevin: Finally but that’s not impressive. That’s, “Wow, at last, you got around to it!” sort of thing.

Stephan: It’s a little bit of cheerleading; I think is what I what I see.

Kevin: It is a bit of cheerleading and I am wondering if Microsoft feels that they have earned the right to cheerlead their browser, whereas in the Internet Explorer 7 timeframe, that entire release, they were hat in hand. They were, “We’re really sorry. We know we screwed up by stopping development on Internet Explorer. Please take Internet Explorer 7 as a token of our apology in this matter.” IE8, they were kind of like, “Yeah, we’ve addressed the most important issues for developers and this is a big step forward in bringing Internet Explorer closer to the competition and catching up on the stuff that we fell behind on.” I’m not seeing a lot of that contrite tone in what they’re talking about in IE9. They’ve posted three videos on the Channel 9 web site, which is kind of a Microsoft developer outreach community site and their interviews with the engineers that are working on this showing off demos of the stuff; and they’re continually saying throughout the video “it’s very early days”. Its’ clear, this is not the complete feature set or the final performance of what we’re going to see in Internet Explorer 9. I think it’ll be interesting to count the number of times they mention the fact that this is an early build, this is early days, we’re just getting started here—this is just a taste of what’s to come.

Stephan: Well, I wonder if this is kind of like the positive marketing spin that we’ve seen kind of with Windows 7 where they’re trying to meet the Apple, “We’re positive—we’re doing good things,” standard and they’re not trying to be negative or making up for something that they’ve done wrong in the past. That’s kind of what it comes off to me as. They want to be— “We’re doing something cool. This is new.” They want to be out there and that’s fine as long as their product actually delivers on what they’re promising.

Kevin: What they’re promising so far isn’t a lot. They say that Internet Explorer 9 will have JavaScript performance on par with Firefox 3.7. And for those not keeping track, Firefox 3.6 is currently in beta, 3.7 is kind of a next alpha version that’s coming; and one of the biggest things it has in it is an enhanced JavaScript engine. So IE 9 is aiming to match Firefox 3.7’s JavaScript performance and they say that will bring them much closer to the industry leader, Chrome and browsers like…

Stephan: Safari.

Kevin: Like Safari are also quite fast in the JavaScript stakes. So they’re not aiming to match the leader of the pack, they’re aiming to catch up with the next one.

Stephan: The stragglers.

Kevin: Yeah, the last of these stragglers. They also say they’re working on passing the Acid3 Test although they’re not making any promises there. They demoed CSS rounded corners and they mentioned that they’ve got a lot of new support for CSS 3 Selectors. So congratulations on all that stuff. We’re eagerly anticipating news of what else is going to be in IE 9. So far we’re nodding along but we’re not that impressed.

The other big thing that they mentioned was enhanced rendering performance using Direct2D. So rather than using the slow API that is used to draw buttons and menus and text labels in the Windows user interface—which is GDI—they are moving something closer to the Direct3D, hardware-accelerated 3D rendering engine, only this is a 2D version of that. So they’re going to be using the brains and power of your computer’s graphics processor to smooth out the rendering of fonts and texts and animations within Internet Explorer 9. And I think we’ve seen a lot of similar work from Apple because they rely so much on their Safari rendering engine to provide smooth animations in user interfaces throughout their operating system and to some extent, on the iPhone. That technology is key to Apple’s flagship polish—or Apple’s noted polish in the user experience—and so it’s clear that Microsoft has taken note and they’re trying to bring the same sort of thing to Internet Explorer 9 so that animated web applications will look just as smooth in IE 9 as they do in other browsers. The demo they showed showed just a piece of text slowly getting bigger, and how in IE 8 it kind of gets bigger one whole pixel at a time and therefore it’s kind of a jumpy animation, whereas the Direct2D has sub-pixel rendering and so it’s a very smooth, cinematic experience. It’s all good stuff but I think we agree there’s a lot more work to be done for Internet Explorer to be considered the leader in the market again.

A browser that’s doing more interesting work in advancing the leading edge of web technology is Firefox and there’s this proposal that I caught sight of earlier this week and it’s a proposal for resource packages. This is clearly a proposal that’s supposed to attract the attention of other browser makers and eventually lead to a standard but this is something that’s being implemented in Firefox 3.7 again and they say, “What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site—CSS, JavaScript, images, anything else—in a single HTTP request at the start of the first visit to the page? This is what resource package support in browsers will let you do.”

Stephan, have you ever had to worry about performance issues that come as a result of static things like CSS, JavaScript—all those requests bugging down the browser?

Stephan: Oh, yeah. Yeah, I mean sometimes I’ll be sitting there loading something and it will take longer than what I would expect for my high bandwidth connection to load and it’s not even the connection. It’s actually the browser is having trouble parsing it all out really quickly. So it’s a mixed thing. My connection is slow and then my browser is slow, at the same time. I do have that problem and this sounds like a great way to get around that to me. It sounds like its common sense.

Kevin: For a couple of years now, Yahoo! have really been pushing this agenda that if you want to speed up your sites, you don’t need to focus exclusively on the speed of your PHP page rendering—that a lot of headway can be made just by minimizing the number of files that your browser needs to request to display a page—and that a lot of the waiting time when you’re loading a web page is the browser making its initial connection, and also, browsers tend to put limits on how many things they’ll download at once from a given web site. So if you’ve got 20 files that need to be loaded for your homepage, your typical browser is only going to download, say, four of them at a time and then move on to the next four and then the next four and as a result, that time adds up. And so tools like YSlow—which is a plug-in for Firebug and it spots performance issues that are visible from the client side of your site—they’ve put heavy emphasis on pointing out when you’ve got multiple CSS files, when you’ve got multiple JavaScript files and how these things can be combined into one. And if you really want to take this to extremes, you can do something called CSS Sprites where you try and combine all of the images on your page into a single big image that has them all sort of pasted side by side, and then you use CSS to only display the portion of that master image in each spot on your site so that the browser’s only downloading one image but you’re displaying different parts of it in different parts of your page. I don’t think that’s something your average web site needs to worry about, but if you are a massive media site, if you’re CNN.com or something like that, this kind of work can really make a huge difference to the performance your users see.

And it looks like the person who wrote this proposal had something to do with YouTube because they point out the need, for example, that YouTube is constantly displaying thumbnails of related videos down the side and those dynamically generated thumbnails—it’s a different combination of thumbnails for every page on YouTube and as a result, they can’t do clever things like CSS Sprites in order to save load time.

And it’s nice and backwards compatible. The idea is you make a web page just as you would before but then you put a <link> tag again–a magical <link> tag–at the top of your page that says, “Before you start downloading any of the CSS, JavaScript, and images referenced in this page, download this one file first and this file is a ZIP file, which contains as many of these static resources as you can fit in there.” It downloads this one file, it figures out where all of these files are linked from—where they belong in your site—and then as it processes your page and it sees an image that it would load otherwise, it goes, “Oh, I’ve already got that from the resource package. I don’t need to download it again.” And so at an extreme, you can download a whole web page with two HTTP requests: one for the web page and one for the resource package.

Stephan: It seems like it’s a great idea, right? I wonder why we haven’t been doing this before. The only thing I wonder about is the ZIP file and security things that. Do you think anything about that or do you think I’m kind of… I was just wondering. We see cross-eyed scripting, things that were people have gone and they’ve gone and done things behind the scenes and that seems like something that if someone figured out a way to put a harmful ZIP file there or change the path for that ZIP file—that we could see something that’s infecting people’s machines, maybe, or browser. I don’t know. I’m just thinking outside the box.

Kevin: Yeah. I don’t quite see it because it’s downloading the ZIP file just as it would download any other things, so if you can replace that ZIP file, you can already wreak a whole lot of havoc. It might be a way of compromising a site in a way the developer might not notice right away. I can see that. The developer goes and looks at it as JavaScript file and goes, “Well, looks fine to me. I can’t see anything wrong with my site,” but meanwhile, the hacker has replaced the ZIP file with a version that contains a malicious copy of that JavaScript file. So I could kind to see that but I don’t think it’s a real risk here. The biggest risk I see here—it’s not a security one, and we mentioned it earlier—that I don’t think the technically correct approach always wins on the Web. I suspect this is one of those things that looks great on paper, solves all the problems, but is any real world developer actually going to go to the trouble of creating these resource packages and keeping them up-to-date whenever they make changes to the files on their site?

Stephan: Well, it seems like it’s a much more compact way of managing a site. To me, it makes sense even if I’m— I’m not a developer, I’m not a CSS developer, but if I was trying to organize my site into a single file, it seems that that makes sense. We already use tools—like I use Coda—and I already use that tool to organize my site. This seems like this would be a great way to just have a plug-in for Coda and package it all up and ZIP it up and upload it–when I’m done editing.

Kevin: Okay, yeah. If the development tools start generating these resource packages automatically, that would be pretty cool, I have to say.

Stephan: I think that’s a long ways off though. I think since we’re still on paper here, first you’ve got to get the browsers to pick it up. Are they going to really want to write the browser to do this?

Kevin: Well, Firefox is leading the way. They’re going to put this in and I guess see how it works and it’s nice that it’s backwards compatible. So just for the sake of argument, let’s say every browser implemented it except one—and I’m not pointing any fingers here—it would make the sites a lot faster on the browsers that did support it, and those that didn’t support it would continue to download the static files the normal way. So yeah, it’s good in that way; the backwards compatibility I applaud. I mean if you were able to drop this backwards compatibility issue, you could quickly make this even more effective by just—you know in Internet Explorer when you save a web page, it gives you the option of saving it as a single file like a compiled web page file that contains everything in it?

Stephan: Yeah.

Kevin: You could put up web pages in that format on the web or something open source and similar but right now, this proposal is talking about cutting it to two requests per page for a fully optimized page, but the natural thing to ask is why don’t you just cut it back to one—make it a single file that contains everything—and then you lose that backwards compatibility because older browsers won’t be able to read those single page packages or those single file packages. So yeah, looking forward to seeing this implemented and for tools to start getting on board as well. I think that is a really important point. CSS Sprites, for example, is really a case of taking extreme measures for performance and the reason for that is there are no tools for automating it. It is a labor intensive thing to do.

Stephan: Yep and if you can take out the labor part of this, then there’s a little bit of an incentive besides just performance, it’s also organization. So it makes sense.

Kevin: AOL is re-branding and it seems like they’re re-branding because Time Warner is splitting them off. After absorbing them several years ago—I’m not sure exactly when—AOL has been operating as a part of Time Warner and it’s being split off into its own company. It’s going to be a content company now. They’re no longer focusing on providing internet access or a richer internet experience. They’re focusing on creating content for the Web. Welcome to the club, guys. And they’ve got a new set of logos, a new brand, and the yellow running man is nowhere to be seen.

Stephan: So does this mean I have to throw away my 4,000 hours? Are those CDs useless now?

Kevin: Yeah. I think they’ve been useless for awhile just between you and me. The logo is kind of a non-logo. It’s really interesting. It’s not so much a logo as a branding approach. So they’ve got the letters A-O-L and the A is still upper case but the O, L are lower case, Aol. So like a word, “Aol” and you can’t really tell if the L is a capital I or not. So it kind of looks like AoI as well, and then a period, a full stop at the end and that’s the logo—and it’s white. So it this logo appears on a white piece of paper, it’s going to be invisible. The idea is, the logo, the text becomes visible by having it against a colored background, a picture, a dynamic image of some kind and the samples they show on the logo announcement have it against a gold fish, against a hand giving the “Rock!” sign, a swirly sort of blue ink thing, some scribbles of various colors and I can’t even make out with that last one is—it looks like someone’s brain made of cats. Use your imagination. But you weren’t too impressed by this?

Stephan: No. From my understanding, this is actually done by the same company that did the 2012 London Olympics logo.

Kevin: Oh dear.

Stephan: Which if you haven’t seen that is also a piece of work, if I do say so myself.

Kevin: I’m surprised they’re still getting work.

Stephan: If you haven’t seen this, you have to go see it. It’s like bright pink and purple.

Kevin: I have to say I like this a lot better than the 2012 logo.

Stephan: Oh, yeah. This is better. Maybe that’s how they got the work, I don’t know.

Kevin: There’s a video version that’s nice and again, they’ve just got that white text but it’s being revealed by interesting videos, paint of two different colors splashing together in the center of the screen to reveal the AOL text that was there all along but it was invisible against the white background. The last one is especially funny—it’s some sort of high impact dance move because it’s a guy standing in the middle and his two friends run up to him and step on his chest and his back as they do a flip in the air at the same time. It’s all very exciting.

Stephan: I think the video was really cool. What bothers me is the logos that they’ve shown that are still logos. I mean, they’re not logos. What bothers me is they almost look like they’re print—like they should be on like a newspaper because they’re grainy, it doesn’t look refined, it just kind of looks like this threw some crappy fonts…

Kevin: Stock photos.

Stephan: …yeah, on a stock photo. But the video is, like you said, is cool. It’s neat, it’s kind of modern. I like that.

Kevin: A subtle thing that’s going on in the photo versions at the very least I like is that the white Aol text is never completely revealed by the picture that’s behind it. There’s always sort of a piece of the letter A or a piece of the letter L that’s sticking out over the edge of the photo and connecting with the white background and so the text sort of feels like it’s pulling air into the photo. Do you see what I mean? It keeps that connection with the wide open white space?

Stephan: Yeah. It’s like infinite even though it’s connected. Yeah, I see that.

Kevin: I like it. I’ve seen recent re-brandings, the city of Melbourne, the ANZ Bank—the Australian New Zealand bank down here in Australia—we’ve had a couple of high profile new rebrandings happening and both of those are right up there with the 2012 Olympics. They’re pretty horrendous and I will congratulate AOL for their creativity and for creating something interesting here, but no one seems particularly blown away by this.

Stephan: There’s not a lot of fondness for it.

Kevin: Well, what it lacks is a clear visual brand like something that you’re going to recognize at a great distance driving down the freeway as you see it on a billboard. The brand that they’ve created is a non-brand here. It’s something that you’re going to have to squint and discover anew every time you see it.

Stephan: That’s a good way to put it. Yeah, it’s not like a font that you know right off the bat as AOL or it’s not the bold letters like we used to see with the running man, it’s none of that; so you really got to think about if for a second. When I first saw it I was like, “What kind of one-sentence word is that?”

Kevin: Yeah.

Stephan: What kind of one-word sentence is that, sorry.

Kevin: Yeah, exactly, AOL.

Stephan: AOL.

Kevin: Or it’s not even AOL. It’s Aol.

“Are iPhone developers stupid?” asks Peter-Paul Koch. In fact, his initial blog post didn’t even ask it. He just came out and said it. “Apple is not evil. IPhone developers are stupid.” And this has to do with something that we haven’t actually mentioned in the podcast before. It’s been on our radar and that’s the furor surrounding the process that an iPhone developer has to go through to get their application approved for sale in the Apple App Store. Without going over every single example because we’d be here all day, there are many examples of developers who’ve put in months of work in some cases on an app, spent thousands if not millions of dollars in development and preparing their marketing push for launch day and then they put this app to Apple and Apple goes, “Nah. Rejected. Rejected because it will confuse users,” and they’re rarely more specific than that.

Stephan: Yeah, it’s pretty bad in my opinion. I’m kind of more on the side of Apple choose to open the store and just monitor it for people who are sending out bad apps or apps that are dangerous to the phone rather than choosing which apps get on the store and which apps don’t. I don’t know. It seems like it’s counter-intuitive.

Kevin: I’m going to make a big bet here because this thing seemed to be coming to a head. We’re at the point in the past week— did you see the Airfoil debacle?

Stephan: I did not.

Kevin: Well, Airfoil is this application for the Mac and for Windows, but mainly Mac users use it and it’s this app that lets you grab the audio from any application on your computer or all the audio for your computer and transmit it either to another computer running their free Airfoil Speakers application, or to an AirPort Express or an Apple TV and these devices have built-in music streaming capabilities so you can send music from iTunes. Well, Airfoil lets you send it from any application to these devices and they have an application Airfoil Speakers for the iPhone and iPod Touch. This app has been on the App Store for almost a year now if not longer and it just lets you receive this stream of audio from any computer running Airfoil. And no problem, you might think, and the 1.0 application has been very successful for them and Apple approved it and kept it in the App Store and then shortly after they found a few bugs so they wanted to release version 1.0.1.

Well, what happens is with the App Store, you have to submit updates as a new application to be approved and Apple denied that update. Even though it contained some critical fixes to an application that Apple had previously approved and continued to keep in the App Store after they rejected 1.0.1 and the reason they rejected it is because at a glance, Airfoil Speakers contained images of Apple hardware. So if you were receiving audio from an iMac, it would show a picture of an iMac in the Airfoil Speakers application. But what was happening was that they were using Apple’s own APIs to provide these images. The Airfoil application running on the iMac would say, “I need to send a picture of this computer to the receiving end to let them know what this computer looks like.” And so they ask Mac OS X. They say, “Mac OS X, you’ve got a documented way for me to get a picture of the computer I’m running on, can you give me that picture?” And Mac OS X gives it that picture and they send it to Airfoil Speakers and Airfoil Speakers displays it.

So this is a feature in Apple’s operating system that Apple provides and yet when Airfoil Speakers used it, Apple rejected that application for the fact that they were using images of Apple hardware–even though they had previously approved a version of the application that did the exact thing, that just had more bugs in the application.

Stephan: Yeah, it’s backwards. That’s backward.

Kevin: So like I said, we could talk all day telling these stories—and this is a typical one—but things are coming to a head because in response to this, the company behind Airfoil, which is Rogue Amoeba, they posted a big blog post explaining how they finally got their application approved by stripping out all of the images of Apple hardware or stripping out the code that was displaying those images and they got Apple to approve it six months or something after they originally submitted it to Apple. As a result, they are giving up on iPhone development and there have been a few high profile developers who’ve taken this stance that iPhone development is just too hard because Apple’s draconian App Store approval proces—its black box nature—the fact that you can’t predict reliably whether something you’ve written is going to be approved by Apple or not. The rules are vague and their enforcement is inconsistent.

So developers with greater and greater profiles have been walking away from the iPhone platform and Apple started doing something about it. Phil Schiller, one of the big muckety-mucks at Apple was speaking to Business Week this week and said that they’re working on these very problems and in fact, Apple turned around and got in touch with Rogue Amoeba as a result of their blog post and said, “Look, you were right, we were wrong, submit yet another version of your app that brings those icons back, those images of Apple hardware back, and we’ll approve it right away.” And they did. They approved it within 24 hours, within one working day.

So Apple is doing stuff about this but I don’t think their position can hold. The more people that they concede to as a result of angry blog posts, the more angry blog posts they’re going to get and I’m betting that within 12 months Apple is going to have to lift the restriction on iPhone applications that makes it so that applications can only be installed from the iTunes App Store.

Stephan: You think so?

Kevin: I think they’ll continue to keep the App Store closed and requiring Apple approval but if you want to distribute your app another way, just put it up on your web site so that people can click on it in mobile Safari and download it and install it. They actually support this now but they really put strong restrictions on it so it can only be used for beta programs by developers. I think there’s a limit on the number of copies of an application that can be distributed this way using ad hoc distribution but I think they’re going to be forced to open that up.

Stephan: See, I think I disagree because this is a moneymaker for them. I mean, the App Store, they get a percentage of the pie. So I don’t see them wanting to give that up completely.

Kevin: But I think the App Store will continue to be the most convenient way for a developer to make money off of their iPhone app. I think if they want to sell it and they don’t want to go through all of the pain of setting up an ecommerce web site to buy it and trying to get people to come and discover their app… Developers will continue to submit stuff to the App Store because it’s the easiest way to make money on the iPhone platform.

Stephan: Yeah.

Kevin: But if you want to do something that Apple isn’t quite happy with or won’t approve for one reason or the other, I think they will provide that alternative and so Apple will then be justified in saying, “Look, it’s our store, we can put what we want in it and what we don’t want in it and if you’re not happy with our policies, start your own store.”

Stephan: I guess the Apple Store could become an exclusive place for your apps. It could become the target of apps.

Kevin: It’s the boutique. And finally, Apple could throw away all the fart applications and all the gross-out apps that I think everyone agrees are in poor taste but because there’s no rule-breaking going on in these applications, that Apple can’t deny them.

Stephan: Yeah. Well, I did see a Cha-Ching app that got rejected because it was too simple. You just hit the button and “Cha-Ching!” That’s all it did and it was rejected. There was a guy who made a video about it.

Kevin: Too simple.

Stephan: I’ve never heard that before.

Kevin: Wow. During the elections, there were apps that all they did was display the logo of the political party that you supported.

Stephan: Yeah.

Kevin: It was like the image application. That’s all they did is display an image when you started them up.

Stephan: I think it’s because they don’t have internal standards. I think that they give people some vague rules and these people just interpret them however they want and that’s why you get this disparity. But this article…

Kevin: Anyway…

Stephan: Oh sorry. We’ve gone off topic.

Kevin: Way off topic.

Stephan: The article that talks about that the iPhone developers are stupid because they should be taking advantage of the web side of the iPhone and the Safari browser and WebKit and all that, and saying that you should use that instead of it—and you don’t have to worry about the App Store at all. And he actually comes back and he wrote another post, I guess, a follow-up to this kind of saying that he was wrong, whatever, but…

Kevin: So yeah, he said if iPhone developers aren’t happy with the App Store (and why would you be), you should just build the web app because web apps can be icons on the iPhone home screen just like native applications can but they’re not subject to any rules or restrictions whatsoever. If you can build a web site, you can build an application for the iPhone and Apple can’t do anything about it. And that was his initial point—IPhone developers are stupid, they are drinking the Kool-Aid. Apple tells them to build native apps and so they build native apps. Dion Almaer of Palm, previously Mozilla and Faruk Ateş, they both wrote strongly-worded posts saying that, “Yeah, you’re not quite right there, PPK”—Peter-Paul Koch was the author of the original article—the reason people build native apps for their iPhone is that web apps aren’t quite there yet. They don’t provide full access to the hardware features that you get on the phone and they don’t provide the same level of user experience—the sleekness of the experience, the integration in the iPhone platform—all those things aren’t quite as polished in a web apps for the iPhone and the reason someone buys an iPhone is because of the polish. And so if you want to stand out on the iPhone platform, you do it with a native app.

Stephan: I have to say this. I’ve used the Flickr application on the iPhone and I’ve also used the web site, and the web site’s darn good. I mean the web site is cool. I mean it’s got location awareness and everything—like it can find photos that are around me.

Kevin: They did a beautiful job with that web application I have to say.

Stephan: Oh, they did. They did. And the app though itself—I think is terrible. It’s slow. It takes forever to load a picture. It takes forever to take a picture. It’s not smooth like what I was expecting it. I use the web app almost exclusively and never use the actual iPhone application.

Kevin: And it seems like because the application came so late, it seems like Flickr were planning on everyone just using their web app.

Stephan: Yeah.

Kevin: And that’s why it’s so good. And the reason the web app wasn’t quite enough is because it doesn’t provide that integration. You couldn’t— Using a web app, you can’t pick photos from your camera roll on your iPhone and upload them to Flickr—and they needed an application to do that. It looks like they did the minimum necessary to provide that picture but I think you’re right. The right way to view photos on Flickr on your iPhone is to use their mobile app.

Kevin: Facebook did something similar. Facebook’s mobile web site for a long time was a shiny example of a mobile web application looking like a native iPhone app, and in fact, the people behind it released their user interface framework so that other people could do the same sort of tricks. But eventually Facebook built their own native application just because they were able to provide an even sleeker, richer experience.

Stephan: My opinion on this is that people who build them are just trying to build a simple application to do some data entry or something for a web site that they have—it makes sense to just do a mobile iPhone version, not an app. But I think there’s some applications out there that deserves the application treatment. I’m a plane nerd for those listeners who don’t know. I’m a huge airplane nerd and I downloaded the LiveATC.net app so I could listen to air traffic control near my home airport; and it’s an amazing app. I mean the thing just streams over 3G air traffic control—and I can’t imagine them trying to do that through the mobile API. Just can’t.

Kevin: So PPK’s follow-up blog posts in response to the criticism he got, he’s basically saying, “I was wrong and yet there are things in my original post that I still think are worthwhile saying,” and this follow-up post I think is a must-read. It really is quite insightful. He’s calmed down and found the nugget of truth that got him angry enough to write the rant that was mostly nonsense. Sorry, PPK.

The follow-up post says, first of all, one of the really good reasons for building a native app for the App Store is it’s much easier to make money off of a native app than off of a web application. If you want to sell access to your web application that is custom designed for the iPhone, yeah, it’s going to be much easier to get it on to the device because you don’t have to have it approved by Apple, but getting people to find it, providing a convenient way for people to pay for it—compared to the App Store—there’s no competition there. On the iPhone, you click a link on a web page that points to the App Store, it says, “Do you want to install this? It will cost $0.99.” You say “Yes”, you have spent $0.99 and you’re done. The developer gets 70% of that. Doing that with other web application, you’re going to be dealing with PayPal at the simplest and providing that slick experience to install it, and then explaining to them how to get an icon on their home screen from within mobile Safari is a nightmare. So, making money: much easier using the App Store. Then there are all the issues with a device APIs, which is why Flickr ended up writing their own native app because if you want to hook in to certain features of the iPhone, you can’t do that with web apps yet. He says, “Look, that’s going to be solved. If Apple is not working on improving device integration with web apps, they’re fools,” and so he’s willing to bet on that becoming better in time, but right now he concedes it’s not quite there yet and so native apps have the edge.

Interoperability versus user experience is the big one. If your application calls for polish above all else—if your business goals require you to provide the most polished experience possible on a single device, the iPhone—then native apps are the way to go. However, if interoperability is an important thing on your radar, if being able to build an application that will work with little or no modification across lots of different devices—not just the iPhone—and you’re willing to sacrifice a tiny bit of user experience polish to get that interoperability—quadruple your market in exchange for slightly jerkier animations, for example. If that’s a reasonable trade off, then you should be building web apps and sacrificing the user experience polish that you get with the native APIs on the iPhone.

He closes with a discussion of the fact that it’s interesting that the market leaders in the mobile application space, which are Apple and Google—Apple with iPhone, Google with their Android platform—have bet on native apps or at least a custom software development kit with new languages and new frameworks to build applications specifically for their devices. Whereas the market trailers—the Palms, the Microsofts—they’re all betting on open web technologies, whether it’s actually building web sites that display as applications on the phone or in the case of Android, they just built an SDK that requires web developers to use their existing skills to build native apps for the phone. The market trailers are betting on web standards. And it’s clear: whenever you’re behind you bet on openness, you work together because that openness lets you team up against the market leaders and yet they’re not doing a very good job of developer outreach. They’re betting on these technologies that thrive on the web developer community and then they’re not engaging with that community or at least they haven’t been very good at it so far. So he expresses his frustration there. Great article I think. Really insightful on many fronts and I’m glad he backed down from his extreme initial position in order to give us those insights.

Let’s close off the show with just a couple of host spotlights this week.

Stephan: Yeah. So I’ll go first. I’m a big data visualization fan. I love charts–they just fire me up.

Kevin: I love them too. The info graphics that you get in newspapers are really, I geek out on those when they’re well-done.

Stephan: Yeah. So I found this web site, it’s on Tumblr. It’s ilovecharts.tumblr.com. They’ve got a bunch of charts of mixed things. Some of them funny, some of them really cool where we are debt-wise, things like that—just random charts. Some of them may be inappropriate, I don’t know but there’s some really good ones—things from the Washington Post, they’ve collected all of them and put them in one place. So it’s a neat little read, ilovecharts.tumblr.com.

Kevin: Yeah. I’m just scrolling through here, sorry. I’ve got distracted already. My host spotlight is a site called Support Details and you can find it at supportdetails.com. The tagline on the site is “tech support anger management” and it’s when someone tells you your site isn’t displaying right in their browser and then you inevitably get into that email back and forth where you’re like, “Well, what browser are you using?” “Oh, I’m using Internet Explorer.” “Well, which version of Internet Explorer?” “Oh, IE 8 I think.” “Okay, what version of Windows are you on? What is your screen resolution? Is your browser window maximized or not?” And next thing you know you’ve sent six emails back and forth and then you realize it’s because they have JavaScript disabled in their browser. This site saves you all of that time because if someone tells you they’re having a problem with their site, you just say, “Okay, go to SupportDetails.com, fill in your name, your email address, and my email address, and click ‘send details’ and you get an email with their operating system, their screen resolution, the web browser and version they’re using, the size of their browser window, their IP address, their color depth, whether JavaScript is enabled, whether cookies are enabled, and the version of Flash that they’re using. And this will save so much time! I’m really happy I keep a link to this on my desktop because…

Stephan: Sounds useful to me.

Kevin: Great site. If you are ever responsible for trying to figure out why your site isn’t displaying quite right in one obscure browser configuration on the other side of the planet, use supportdetails.com. It’s free and it’s very nicely designed too.

Our signoffs also will be short this week. Stephan?

Stephan: Yep. My name is Stephan Segraves, you can find me on badice.com and my Twitter is @ssegraves.

Kevin: You can follow me on Twitter @sentience and SitePoint @sitepointdotcom on Twitter. Visit us at http://www.sitepoint.com/podcast for all the new shows and to subscribe using iTunes or whatever podcast listening software you have to get every show automatically.

This episode of the SitePoint podcast is produced by Carl Longnecker and I’m Kevin Yank. Thanks for listening. Bye-bye.

Theme music by Mike Mella.

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.

Related posts:

  1. SitePoint Podcast #17: 12 Kinds of Awesome A big two weeks for the Web makes for a...
  2. SitePoint Podcast #13: Digging into the DiggBar Digg’s new DiggBar has problems … or does it? Kevin...
  3. SitePoint Podcast #18: Internet Explorer 8 … Percent? All eyes are on the Microsoft marketing machine as it...

You might also like...

Comments

PHP tutorials

PHP forum discussion

PHP jobs

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development

Developer Jobs

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Cancel
“Programs must be written for people to read, and only incidentally for machines to execute.”