The Wall Street Journal has been reporting on Google’s mobile phone efforts and how it is beginning to draw some interest from carriers, especially in the United States. Here is what Om Malik has been able to gather from his sources.
read more | digg story
Wednesday, October 31, 2007
Sunday, October 28, 2007
Hulu Launches! Should YouTube Be Worried?
While it may not live up to its billing as a “YouTube killer,” Hulu is as different as a web video service could possibly be from the market leader.
read more | digg story
read more | digg story
Monday, October 22, 2007
HTML5 Wrapper for Google Gears
"...Gears is a capable and much more mature implementation, both WebKit and Gears use the same SQLite server, so it should be just a matter of writing a simple wrapper to bring Gears back into the standards fold...."
read more | digg story
read more | digg story
Sunday, October 21, 2007
MySpace Gets in Bed with Roommates
MySpace continues its march into original content with the launch of Roommates, a new, scripted original web series, today. The move represents MySpace’s first co-development project and first original web series created specifically for MySpace TV.
read more | digg story
read more | digg story
Monday, October 08, 2007
Safari on Windows: Beyond the Browser, Apple's Decoy into Microsoft's World
On June 11th 2007, Apple introduced a beta version of Safari 3 for Windows. Safari is Apple's flagship browser, built on-top of possibly the fastest web browser engine, WebKit.
As soon as it came out, I threw it at our DWR-driven CSS-rich/DOM/script-intensive Used Cars Search results-page and compared rendering/execution speeds with IE6 on the same Windows XP machine. I counted 2+ seconds on IE6 vs 1+ seconds on Safari. Not bad for beta software, i thought, most especially software developed by Apple for its competitor's operating system.
The speed of Apple's web browser on Microsoft Windows is a testament to the maturity and strength of WebKit.
That's all dandy, but here's the twist: Safari 3 on Windows is a Decoy, something to stimulate pundit, media, and industry's attention, generate buzz, and throw them off the scent of the real story underneath. The real story here is WebKit. iTunes. Quicktime: The makings of an enabling software platform, and Safari and iTunes being the manifestation of what underlying platforms such as WebKit and QuickTime can do.
History just may prove me wrong, but I can't imagine Safari-on-Windows, in and out of itself, being part of Apple's longer-term strategic product offerings. I don't picture them running ads on TV encouraging users to switch from Internet Explorer to Safari, in a World where so many Windows users don't even know what their web browser is, and still consider it "that Internet Icon Thingie in the Start Menu".
On the Mac, WebKit enables far more than just "Safari". It also enables a whole realm of useful mini-applications, called "Widgets", running inside "Dashboard". With theoretically little added engineering resources, Apple could create great opportunities by developing a WebKit-only equivalent of Dashboard for Windows.
One of Windows Vista's "touted features" are "Gadgets", Microsoft's attempt at cloning frameworks such as Apple's Dashboard Widgets, Yahoo's Konfabulator, which provide application development platforms that leverage web standards.
Why would this be great opportunity for Apple? Bring more value to their developer community, and establish a budding footprint of Mac Developers releasing narrowly-focused applications simultaneously to Mac and Windows, thereby allowing them to multiply their audience by a factor of ... uhm ... a lot.
While Mac OS X Dashboard Widgets have access to the full underlying Cocoa APIs to provide rich functionality, there already exists a vibrant ecosystem of great widgets built solely with Web Standards, simply leveraging WebKit. A WebKit-only version of Dashboard would nicely cater to this community ... today.
"Gadgets" on Windows are a Vista-only feature. It will take some time for Vista to supplant XP. It will take some more time for Windows developers to release great "Gadgets" for Vista.
If a WebKit-only version of Dashboard was available for Windows tomorrow, Apple could release it to millions of PC users as part of one its routine iTunes updates for Windows. And many of these mini applications would be available to them, near-instantly.
By doing this, Apple would add value to its existing developer community, catch the attention of Web Developers who are on the fence as to where to start their development efforts for Mac Widgets vs Vista Gadgets, by giving them the opportunity to not have to choose.
While leveraging web standards to build useful desktop applications on both platforms would be an encouraging development, the rabbit-hole may yet go even deeper.
Consider iTunes and Safari, two applications that look absolutely identical on both Mac and PC. Are we to believe both applications live in two radically different code bases? What if Apple had internally developed an easier way to code applications for both Mac and Windows? What if XCode was to one day also produce Windows binaries?
Could this hurt Apple's competitive edge? I don't believe so, quite on the contrary. It comes down to providing even more value to their developer community, and help grow it by "reaching out to the other side". Windows users looking to switch to Mac don't make this decision based on specific pieces of 3rd-party software they'll be able to run on their shiny new Mac. They'll switch because of the iApps, which Apple doesn't have to release to Windows and likely never will, and an overall more pleasant, secure, stable, fun computing experience.
The way I see this unfold isn't thru the release of a Windows binary of the Cocoa framework. This would mean that to run Mac apps, an additional framework would need to be loaded on a Windows User's machine, much like .Net. This would strike me as redundant.
I don't either see XCode ported to Windows. It'd be rather pointless as the key audience for this product would be Mac Developers looking to release their apps on Windows, not Windows developers who are primarily .Net developers and already enjoy Microsoft's awesome IDE.
Instead, picture the ability for Mac OS X's XCode to load-up key windows APIs, translate Cocoa source-code into .Net source code, and compile the whole thing into a binary to be tested ... in Parallels ... or a Windows box nearby :).
As soon as it came out, I threw it at our DWR-driven CSS-rich/DOM/script-intensive Used Cars Search results-page and compared rendering/execution speeds with IE6 on the same Windows XP machine. I counted 2+ seconds on IE6 vs 1+ seconds on Safari. Not bad for beta software, i thought, most especially software developed by Apple for its competitor's operating system.
The speed of Apple's web browser on Microsoft Windows is a testament to the maturity and strength of WebKit.
That's all dandy, but here's the twist: Safari 3 on Windows is a Decoy, something to stimulate pundit, media, and industry's attention, generate buzz, and throw them off the scent of the real story underneath. The real story here is WebKit. iTunes. Quicktime: The makings of an enabling software platform, and Safari and iTunes being the manifestation of what underlying platforms such as WebKit and QuickTime can do.
History just may prove me wrong, but I can't imagine Safari-on-Windows, in and out of itself, being part of Apple's longer-term strategic product offerings. I don't picture them running ads on TV encouraging users to switch from Internet Explorer to Safari, in a World where so many Windows users don't even know what their web browser is, and still consider it "that Internet Icon Thingie in the Start Menu".
On the Mac, WebKit enables far more than just "Safari". It also enables a whole realm of useful mini-applications, called "Widgets", running inside "Dashboard". With theoretically little added engineering resources, Apple could create great opportunities by developing a WebKit-only equivalent of Dashboard for Windows.
One of Windows Vista's "touted features" are "Gadgets", Microsoft's attempt at cloning frameworks such as Apple's Dashboard Widgets, Yahoo's Konfabulator, which provide application development platforms that leverage web standards.
Why would this be great opportunity for Apple? Bring more value to their developer community, and establish a budding footprint of Mac Developers releasing narrowly-focused applications simultaneously to Mac and Windows, thereby allowing them to multiply their audience by a factor of ... uhm ... a lot.
While Mac OS X Dashboard Widgets have access to the full underlying Cocoa APIs to provide rich functionality, there already exists a vibrant ecosystem of great widgets built solely with Web Standards, simply leveraging WebKit. A WebKit-only version of Dashboard would nicely cater to this community ... today.
"Gadgets" on Windows are a Vista-only feature. It will take some time for Vista to supplant XP. It will take some more time for Windows developers to release great "Gadgets" for Vista.
If a WebKit-only version of Dashboard was available for Windows tomorrow, Apple could release it to millions of PC users as part of one its routine iTunes updates for Windows. And many of these mini applications would be available to them, near-instantly.
By doing this, Apple would add value to its existing developer community, catch the attention of Web Developers who are on the fence as to where to start their development efforts for Mac Widgets vs Vista Gadgets, by giving them the opportunity to not have to choose.
While leveraging web standards to build useful desktop applications on both platforms would be an encouraging development, the rabbit-hole may yet go even deeper.
Consider iTunes and Safari, two applications that look absolutely identical on both Mac and PC. Are we to believe both applications live in two radically different code bases? What if Apple had internally developed an easier way to code applications for both Mac and Windows? What if XCode was to one day also produce Windows binaries?
Could this hurt Apple's competitive edge? I don't believe so, quite on the contrary. It comes down to providing even more value to their developer community, and help grow it by "reaching out to the other side". Windows users looking to switch to Mac don't make this decision based on specific pieces of 3rd-party software they'll be able to run on their shiny new Mac. They'll switch because of the iApps, which Apple doesn't have to release to Windows and likely never will, and an overall more pleasant, secure, stable, fun computing experience.
The way I see this unfold isn't thru the release of a Windows binary of the Cocoa framework. This would mean that to run Mac apps, an additional framework would need to be loaded on a Windows User's machine, much like .Net. This would strike me as redundant.
I don't either see XCode ported to Windows. It'd be rather pointless as the key audience for this product would be Mac Developers looking to release their apps on Windows, not Windows developers who are primarily .Net developers and already enjoy Microsoft's awesome IDE.
Instead, picture the ability for Mac OS X's XCode to load-up key windows APIs, translate Cocoa source-code into .Net source code, and compile the whole thing into a binary to be tested ... in Parallels ... or a Windows box nearby :).
Subscribe to:
Posts (Atom)