It's hard to know whether to compare Steve Ballmer with P. T. Barnum or with the alcoholic persona brought to life by W. C. Fields. John Gruber of Daring Fireball compares him with Grand Moff Tarkin of the original Star Wars film (now episode IV).
In a much longer piece, yesterday, Gruber lays out a compelling argument that Microsoft has entered a phase of long-term decline, whereas Ballmer would have you believe that recent trends in the market are a drop in the bucket when compared with Microsoft's still undeniable dominance of the PC operating system market, as measured by unit sales (counting a netbook the same as a workstation). (Here's Rafe Colburn responding to Gruber.)
But put a roomful of Mac-using journalists and investors in front of him, and even he notices.
Friday, July 31, 2009
Friday, July 24, 2009
ordering feed for uncounted chickens
They say don't count your chickens before they hatch. They also say don't count on any rumors about new Apple products until you hear it from Steve Jobs (or Phil Schiller).
On the other hand, you sometimes have to take uncertainties into account in making plans for the future, rather than waiting for them to be resolved into news.
The rumored Apple tablet device is one such case. If the rumors are true, it's introduction will lead to tremendous change in the personal computer market.
It will enable applications for which the iPhone or iPod touch would be perfectly suited, if they just had a little more screen area, or if they had a few times the memory or faster processors. This by itself is huge.
It will get a jump start by running existing iPhone/iPod touch apps unmodified. This may be speculation, but it makes too much sense not to be part of the plan. Expect the resolution to be a simple multiple of that of the iPhone, like 640 X 960, or maybe 800 X 1200, maintaining the 2 X 3 aspect ratio.
As far as I'm concerned, the prospect of extremely fast cellular wireless internet connectivity is icing on the cake, but there are doubtless potential applications for which this is essential. Moreover, if tethering to your desktop is allowed, it will prove a huge selling point.
In fact, that issue of interoperability with other equipment remains a big question mark. Would an Apple tablet device work as a touch interface input device for your Mac? Would it work as a remote controller and/or handheld viewer for your Apple TV? Chances are the answer to both is "yes, with the appropriate application running."
If you're a (potential) iPhone software developer, you'll be wanting to keep the possibility of a larger device that works very much the same way as does an iPhone in the back of your mind, maybe even starting to accumulate the alternative resources you'd want to include if there were a possibility of your app running on a device with 4..9 (2^2 to 3^2) times the screen resolution, or making sure your app is resolution independent by using vector-based graphics.
To get back to the main point. The significance of the release of this device, if it happens, is too great to ignore just because it might not happen. If it happens (and it's looking like a good bet that it will) it will be HUGE!
(Here's Jason O'Grady's take on what an Apple tablet would need to be successful.)
On the other hand, you sometimes have to take uncertainties into account in making plans for the future, rather than waiting for them to be resolved into news.
The rumored Apple tablet device is one such case. If the rumors are true, it's introduction will lead to tremendous change in the personal computer market.
It will enable applications for which the iPhone or iPod touch would be perfectly suited, if they just had a little more screen area, or if they had a few times the memory or faster processors. This by itself is huge.
It will get a jump start by running existing iPhone/iPod touch apps unmodified. This may be speculation, but it makes too much sense not to be part of the plan. Expect the resolution to be a simple multiple of that of the iPhone, like 640 X 960, or maybe 800 X 1200, maintaining the 2 X 3 aspect ratio.
As far as I'm concerned, the prospect of extremely fast cellular wireless internet connectivity is icing on the cake, but there are doubtless potential applications for which this is essential. Moreover, if tethering to your desktop is allowed, it will prove a huge selling point.
In fact, that issue of interoperability with other equipment remains a big question mark. Would an Apple tablet device work as a touch interface input device for your Mac? Would it work as a remote controller and/or handheld viewer for your Apple TV? Chances are the answer to both is "yes, with the appropriate application running."
If you're a (potential) iPhone software developer, you'll be wanting to keep the possibility of a larger device that works very much the same way as does an iPhone in the back of your mind, maybe even starting to accumulate the alternative resources you'd want to include if there were a possibility of your app running on a device with 4..9 (2^2 to 3^2) times the screen resolution, or making sure your app is resolution independent by using vector-based graphics.
To get back to the main point. The significance of the release of this device, if it happens, is too great to ignore just because it might not happen. If it happens (and it's looking like a good bet that it will) it will be HUGE!
(Here's Jason O'Grady's take on what an Apple tablet would need to be successful.)
Saturday, July 18, 2009
Google VP: the web has won
In an informal panel discussion before the MobileBeat 2009 conference, Google engineering vice president and developer evangelist, Vic Gundotra, said "that the web had won and users of mobile phones would get their information and entertainment from browsers in future." (Financial Times Tech Blog)
Saying "the browser [...] will become the platform that matters," Mr. Gundotra pointed out that browsers built around Webkit would have access to information provided by GPS and accelerometer hardware. Interestingly, both Google's own Android and Palm both make use of Webkit in their respective browsers.
His main point is about the expense of supporting several different operating system platforms, versus the expense of providing a single, cross-platform web application. And, wherever that argument applies, he's certainly right.
My point is that this argument isn't as universally applicable as it might seem.
For example, processor intensive games, commonly done in OpenGL, aren't going to be delivered as web applications anytime soon, because their performance would suffer too much as compared with the same games delivered as native applications. Even if the more important mobile device operating systems all provided both OpenGL and some means of making direct use of it from within their web environments, the chances that the exact same code would run properly on any two is vanishingly small. In any case, game developers have been shifting away from direct coding and towards the use of cross-platform development environments, that provide the tools and performance they need while taking the pain out of supporting multiple platforms. While it wouldn't be what Gundotra is talking about, a hybrid system you might see would couple a native game engine app from the provider of such a development system with web apps that run within the environment it creates. Combined with a web-based framework, like SproutCore, that approach could be very powerful. (Bingo!) Game developers will support as many platforms as makes sense in the market, variations on the web included.
Performance is only one reason for preferring native applications to web applications. There's also the matter of general functionality. I personally lost most of my interest in developing for the web when I discovered there was no standard means of generating synthesized sound in real time, and while workarounds might exist they were both platform and browser specific. I decided I was better off to pick a platform and develop for it instead of for the web. So far as I'm aware, that situation has not yet been remedied in HTML5.
There are good reasons why native applications will continue to have more functionality available than do cross-platform web apps, for some time to come. First, at least in Apple's approach, vending all native applications through its iTunes Store, problem apps are quickly identified and those that remain on the system for more than a few days can be considered trustworthy, far more trustworthy than a web app from some random source. Hence the walls of the sandbox around web apps must necessarily be higher than those that surround native apps.
Almost as significantly, cross-platform web applications depend upon web standards, which require agreement among vendors, which takes time. Any new development will nearly always appear in one or more native app toolsets (long) before it appears as a web capability enjoying widespread support. Consider that the animation capabilities included in HTML5 were first introduced to the market with the advent of the Amiga computer, in 1985, ten years before the web went mainstream.
Then there's the advantage of working with tools you already know. Apple has attracted 100,000 people, with widely varying degrees of programming experience, to their iPhone platform. That's very likely many millions of person-hours spent studying documentation, learning how OS X works, an investment many won't be eager to walk away from to take up HTML5 instead. For more than a few it won't matter at all that their apps only run on iPhone OS devices, and not on everything out there.
And let's not forget that the cost of getting into the web app business includes either running your own continuously connected server or renting space and bandwidth on someone else's, whereas an independent developer working from a coffee shop can get an app published on the iTunes Store, and Apple handles all of the nitty gritty details, for a mere 30% commission.
Nevertheless, there will be situations where web apps make more sense, and it's good to see the standard finally moving forward.
Saying "the browser [...] will become the platform that matters," Mr. Gundotra pointed out that browsers built around Webkit would have access to information provided by GPS and accelerometer hardware. Interestingly, both Google's own Android and Palm both make use of Webkit in their respective browsers.
His main point is about the expense of supporting several different operating system platforms, versus the expense of providing a single, cross-platform web application. And, wherever that argument applies, he's certainly right.
My point is that this argument isn't as universally applicable as it might seem.
For example, processor intensive games, commonly done in OpenGL, aren't going to be delivered as web applications anytime soon, because their performance would suffer too much as compared with the same games delivered as native applications. Even if the more important mobile device operating systems all provided both OpenGL and some means of making direct use of it from within their web environments, the chances that the exact same code would run properly on any two is vanishingly small. In any case, game developers have been shifting away from direct coding and towards the use of cross-platform development environments, that provide the tools and performance they need while taking the pain out of supporting multiple platforms. While it wouldn't be what Gundotra is talking about, a hybrid system you might see would couple a native game engine app from the provider of such a development system with web apps that run within the environment it creates. Combined with a web-based framework, like SproutCore, that approach could be very powerful. (Bingo!) Game developers will support as many platforms as makes sense in the market, variations on the web included.
Performance is only one reason for preferring native applications to web applications. There's also the matter of general functionality. I personally lost most of my interest in developing for the web when I discovered there was no standard means of generating synthesized sound in real time, and while workarounds might exist they were both platform and browser specific. I decided I was better off to pick a platform and develop for it instead of for the web. So far as I'm aware, that situation has not yet been remedied in HTML5.
There are good reasons why native applications will continue to have more functionality available than do cross-platform web apps, for some time to come. First, at least in Apple's approach, vending all native applications through its iTunes Store, problem apps are quickly identified and those that remain on the system for more than a few days can be considered trustworthy, far more trustworthy than a web app from some random source. Hence the walls of the sandbox around web apps must necessarily be higher than those that surround native apps.
Almost as significantly, cross-platform web applications depend upon web standards, which require agreement among vendors, which takes time. Any new development will nearly always appear in one or more native app toolsets (long) before it appears as a web capability enjoying widespread support. Consider that the animation capabilities included in HTML5 were first introduced to the market with the advent of the Amiga computer, in 1985, ten years before the web went mainstream.
Then there's the advantage of working with tools you already know. Apple has attracted 100,000 people, with widely varying degrees of programming experience, to their iPhone platform. That's very likely many millions of person-hours spent studying documentation, learning how OS X works, an investment many won't be eager to walk away from to take up HTML5 instead. For more than a few it won't matter at all that their apps only run on iPhone OS devices, and not on everything out there.
And let's not forget that the cost of getting into the web app business includes either running your own continuously connected server or renting space and bandwidth on someone else's, whereas an independent developer working from a coffee shop can get an app published on the iTunes Store, and Apple handles all of the nitty gritty details, for a mere 30% commission.
Nevertheless, there will be situations where web apps make more sense, and it's good to see the standard finally moving forward.
Subscribe to:
Posts (Atom)