Showing posts with label IOS (Apple). Show all posts
Showing posts with label IOS (Apple). Show all posts

Thursday, September 15, 2011

Windows 8: Destination unknown

Earlier this week, Microsoft formally introduced Windows 8 to its developer community at its Build conference. The new operating system was well received--so much so that Microsoft CEO Steve Ballmer had to caution people who downloaded the developer preview version that it's very early software and should in no way be used for production environments. Windows 8 is, in a way, Microsoft's answer to both iOS and OSX from Apple: It will run on PCs, notebooks and netbooks, like Windows 7, but it will also run on tablets, like iOS. It'll run on Intel processors like Windows 7, but it will also run on ARM processors like iOS. It runs all the Win32 desktop-style applications that Windows 7 does, but it also has a touch-oriented user interface and supports touch-based applications like iOS.

Windows 8's "secret sauce" is a new touch-oriented user interface called Metro. Metro is based on the Windows Mobile 7 operating system's user interface for smartphones, which is in turn based on the now-defunct Zune user interface. It does the sliding, zooming and selecting kinds of things that you'd expect from iOS and Android, but it does it on top of Windows. That represents both an opportunity and a problem.

The opportunity is that one operating system, Windows 8, could service both the legacy PC market and the new tablet market. Most observers believe that Apple will eventually unify iOS and OSX; Microsoft has done it with Windows 8. It's much easier for developers to build and support applications for one operating system instead of two.

Windows 8 supports two different kinds of applications: Win32 and Metro-style. Win32 applications are the programs and user interface elements that we've seen on Windows since Windows 3.1. They've been refined and updated over the years, but a Windows XP user shouldn't have any difficulty using a Win32-style program on Windows 8. Win32 apps are designed for a keyboard and mouse, and will work poorly, or not at all, with a touch interface. Metro-style applications, on the other hand, are all full-screen, use a radically different user interface, and are optimized for touch. You can use a mouse and a keyboard with Metro-style apps, but you probably won't want to do so.

Windows 8 systems will open into the Metro user interface, using a touchscreen. If you want to run a Win32 app, you'll switch back to the old user interface, using a keyboard and mouse. You'll then go back and forth between user interfaces as you switch from program to program. You can configure Windows 8 to always use a Win32-style GUI, but then you'll lose access to the Metro-style apps. That's the problem with running both Win32 and Metro-style applications on the same device.

Apple knew that tablets were going to be used very differently from desktop computers, so it optimized iOS for touch on smartphones and tablets. iOS doesn't try to run OSX-style keyboard-and-mouse applications; it offers similar functionality, but the user interfaces are very different. Windows 8, on the other hand, wants to be equally good at desktop and tablet applications, even though the use cases are very different.

For existing Windows users who want to continue using Win32-style apps, from what Microsoft showed this week, there's not much value in upgrading to Windows 8,  other than cutting down on boot times. Customers who are primarily interested in Metro-style tablet apps will find that app developers are starting from scratch, and it may take years for Microsoft to reach parity with the selection in Apple's iOS App Store. Customers who want to use both types of apps, and switch back and forth, are likely to get frustrated very quickly with dealing with two dramatically different user interfaces.

My suspicion, sitting a year or more away from when Windows 8 formally launches, is that Metro-style apps will be used almost exclusively on tablets, and that desktops, notebooks and netbooks will almost exclusively be used for Win32-style apps, despite Microsoft's goal of getting touch-enabled displays on every kind of computing device. This approach will allow customers to avoid switching between user interfaces, but it won't do much for Microsoft's growth prospects. Windows 8 on conventional PCs and Windows 8 on tablets will represent two different markets, and on the tablet side, Microsoft won't be able to leverage its huge PC installed base. It'll be starting from zero. Given that Apple will probably be on the iPad 4 and Google will be on Android 5 by the time that Windows 8 ships, that's not a good place for Microsoft to be.


Enhanced by Zemanta

Thursday, March 03, 2011

Why you shouldn't announce products without delivery dates and prices

Yesterday, Apple announced the iPad 2 in San Francisco. I won't go over the details, since it seems like every news outlet in the U.S. has already covered them. However, I want to point out one thing that Apple does consistently that its competitors still do all too rarely: Apple announced hard retail availability dates and prices for the iPad 2, iMovie and GarageBand for iOS, as well as the availability date for iOS 4.3. When the event was over, everyone knew when the products would be available and how much they'll cost. Apple regularly does this; in fact, it's rare when Apple announces a product without giving hard prices and availability dates.

Compare that to what its competitors have done. When Samsung announced the original Galaxy Tab Android tablet, it didn't release any prices or availability dates. The information leaked out over the next several weeks. Motorola and Verizon didn't announce prices or availability dates when the Xoom tablet was shown at Mobile World Congress; that information leaked out of Best Buy weeks later. LG's G-Slate came out with German pricing but no U.S. pricing or availability date. Samsung's new Galaxy Tab 10.1 doesn't have either availbility dates or prices.

It's not just the Android tablet vendors who can't get their numbers straight. RIM has been showing the BlackBerry PlayBook for months, still without hard prices or a release date, although a date of April 11th has been leaked. HP held a big event in San Francisco to launch its new WebOS-based smartphones and TouchPad tablet, but gave no prices. As for the ship dates, HP was unwilling to get more specific than "Spring" or "Summer".

It's difficult to take a product announcement seriously if the manufacturer isn't willing to say how much it will cost or when it will be available. I understand the problem when products are sold through mobile carriers, who have their own release schedules and pricing plans. However, Apple works with carriers around the world and has managed to be able to announce consistent release dates and prices.

In hindsight, given the difficulties that Samsung had with the original Galaxy Tab and that Motorola is having with the Xoom, it wouldn't have hurt to delay the announcements until price and availability dates were set. In the Xoom's case, it probably wouldn't have hurt to wait until it ships with LTE built-in and until there's a decent population of tablet-optimized Android apps. Rushing product announcements out in order to "freeze" the market and prevent consumers from buying competitive products may have worked once, but today, when new products are released continuously, consumers won't wait. For example, they're going to compare the second-generation iPad 2 and its 65,000 tablet-optimized apps with a version 0.9 Xoom--not quite ready to ship and with less than 100 tablet-optimized apps--and in the vast majority of cases, the iPad 2 will win.

Google and its partners went through this with Google TV, which should have been announced as a product concept to encourage app developers, but instead was rushed to market at too high a price, with inadequate content partnerships and insufficient user experience testing. RED preannounced its Scarlet camcorder years before it was ready, and ended up educating its competitors, frustrating its customers and frittering away its market credibility.

If you can't announce a hard price and release date, you shouldn't announce a product. It's as simple as that.
Enhanced by Zemanta

Wednesday, February 16, 2011

Is there a hidden reason for Apple's in-app payment policy changes?

Apple's announcements about its in-app purchasing policies have ignited a firestorm of criticism from booksellers, publishers and app developers. First, a little more than two weeks ago, Apple announced that apps for eBooks and similar products had to have in-app purchasing. They could continue to link to an external website and price products on those sites however they wished, but they had to enable and pay Apple 30% of in-app transactions. Also, they couldn't disable all purchasing capabilities in the app in order to avoid the 30% fee. These rules were to go into effect on March 31st.

Yesterday, Apple announced its subscription processing system, and announced a new, more restrictive set of rules. There cannot be any links within an app for purchasing subscription content from outside the app--only in-app purchases are allowed, for which Apple gets 30% of each transaction. Further, the price charged inside the app must be as low or lower than the price charged for the same subscriptions sold anywhere else (for example, a publisher's own website.) The subscription rules go into effect June 30th.

There's considerable confusion as to whether the new subscription rules supersede Apple's earlier statements about eBooks, or if there will be separate policies for content sold one time, such as eBooks, and content sold on a subscription basis. If the former is true, Apple has closed the loopholes and made it impossible to sell content on an iOS device without paying Apple 30%.

Apple had to know that these policies would result in charges of price-fixing and anti-competitive behavior. The company is very profitable and is sitting on one of the biggest cash reserves in U.S. business, so it doesn't need the money from transactions. So, why is it pursuing policies that are guaranteed to cause friction?

One possibility is that Apple is trying to get Amazon to stop its "most favored nation" pricing policy, which requires that any publisher or author who sells through Amazon insure that Amazon's prices are as low or lower than any other reseller. Apple's argument could be that if its pricing policy is anti-competitive, so is Amazon's, and conversely, if Amazon's policy is legal, so is Apple's.

Another possibility is that Apple is planning to make some pricing changes that will lower the profit margins on its iPads and iPhones. There have been a flurry of rumors recently about an "iPhone nano" that would sell at a significantly lower price than the existing iPhone 4. This new, less-expensive iPhone will make less money per unit and could cannibalize some sales of the iPhone 4 and forthcoming next-generation iPhone. In addition, Apple may be planning to bring out the iPad 2 at a lower price, with commensurately lower margins. By increasing its transaction revenues, Apple can subsidize these lower prices and maintain its overall margins.

It makes sense for Apple to announce its new in-app sale pricing policy before the next wave of iPads and iPhones is launched, and to give vendors (and the market) more than four months of notice. If Apple doesn't need to launch its new products with lower margins (which is looking increasingly likely on the tablet side), it can rescind or modify the in-app pricing policies. Or, if antitrust litigation pressure from the U.S. or E.U. gets too great, Apple can change its policies before announcing prices for its new products.

In any case, I wouldn't be surprised if Apple modifies its new policies before they go into effect, but neither would I assume that Apple will change its mind.
Enhanced by Zemanta

Thursday, October 07, 2010

Apple TV vs. Google TV: A clear choice for consumers

Now that Apple TVs are showing up in stores (and are being snapped up by customers), and Logitech has set a ship date and price for its Google TV set-top box, consumers will have a clear choice between the companies' fundamentally different approaches to user interaction.

Apple TV takes over the living room screen while you're looking for content, but once you press "play", it gets out of the way, and you watch television as you always have. However, it doesn't interact in any way with your existing cable, satellite or IPTV set-top box, and your existing video signal doesn't pass through the Apple TV box.

Google TV, on the other hand, turns television into a content source for the Internet, and turns your big-screen television into an oversized Internet browser. Your existing video signal passes through the Google TV box. It overlays a search bar and search results on live television. It puts web pages on the television screen, with the live television image as a small "picture-in-picture" overlay.  If you're a Dish Network subscriber, Google TV takes over the electronic program guide functions as well.

The fundamental question for consumers is: Do you want to browse the Internet on your living room television? If you do, Google TV is the way to go. Or, do you want to watch television on your television and simultaneously browse the Internet through a tablet or laptop? If so, Apple TV should be your choice. The "wild card" in all this is the fact that Apple TV runs iOS and could run third-party apps in the future. This would dramatically increase the functionality of Apple TV, although it would still be a separate content source, not a television pass-through device.

Many people believe that Apple's long-term game plan is to make much of the content that's currently available through cable, satellite and IPTV set-top boxes available through Apple TV, thus competing directly with the existing service providers. If that happens, Google TV's ability to pass through video from existing set-top boxes would no longer be an advantage.

As a practical matter, I think that the price difference between Apple TV and Google TV, and Apple TV's inherent ease of use, will be the most important factors driving sales for the holiday shopping season. Apple TV is $99 complete, while Logitech's Revue running Google TV will be $299.99 (Dish Network subscribers can buy it for $179). The Revue comes with an ugly QWERTY keyboard as its remote control; a slightly more elegant optional remote control can be purchased for $129.00, and an HD video camera for webcasting and videoconferencing will cost $149.99. (Sony's new remote control for its Google TV implementation looks like it was designed by the same team that did the Pontiac Aztek.)

My suspicion is that in-store demos of Google TV are going to go "off the rails" as soon as people pick up the keyboard and try to use the TV as a web browser. Apple TV is point-and-click simple, but when consumers realize that they have to type in order to use Google TV, interest is going to drop very quickly. I could be wrong, but I think that Apple TV will win the battle, at least this holiday season.
Enhanced by Zemanta

Wednesday, September 08, 2010

Inkling and Kno: Two very different takes on how college eTextbooks should work

Earlier today, Kno, a Silicon Valley-based startup, announced that it has raised $46 million in its most recent round of funding, to add to the $10 million it previously raised. Kno and San Francisco-based Inkling, which recently announced its eTextbook application for the iPad, compete directly with each other, but the two companies have dramatically different approaches to how eTextbooks should look and work.

Kno began with the concept of reproducing print textbooks as closely as possible in an electronic form. For the Kno team, that meant preserving the look and feel of individual pages, right down to the page numbers. A professor who tells students to read "Chapter 6, pages 137 through 149" in a textbook can be confident that the chapters and page numbers will be identical in the print and Kno eTextbook versions. To make the Kno approach work, the company designed its own eTextbook reader (Kno refers to it as a "tablet", but it's really two tablets stitched together.) The Kno reader's dual displays are designed to show 99% of all college textbooks in use today at 100% magnification. In other words, no panning, scrolling or zooming are needed. It's just like reading a paper textbook. In addition, the Kno displays can be controlled by touch or with a stylus, so students can write notes in the margins of their eTextbooks and highlight text, just as they can with print textbooks.

The downside of the Kno approach is that the Kno reader that's needed to make everything work is heavy (the weight of two average textbooks), big (the size of a large notebook computer, except turned vertically) and expensive (the company says that it will be "under $1,000.") If the reader isn't accepted by students, the rest of the Kno approach will fall by the wayside. Kno took the "path of least resistance" approach: Make the eTextbooks just like print books so that students won't have to relearn how to use them. Use the same page format as existing print so that publishers don't have to pay to reformat their books for Kno.

Inkling, on the other hand, started with the content of textbooks and went from there. Inkling recognized that tablets like the iPad would likely become the preferred devices for reading eBooks (even though the iPad didn't exist when Inkling began development.) Since they didn't know what screen sizes their eTextbooks would have to work on, they designed Inkling to support a variety of screen sizes. Their system starts with Adobe InDesign (and possibly Quark) files, integrates audio, video, animations and hyperlinks, and outputs eTextbooks that dynamically reflow to fit the screen size of whatever device is used to read them.

There are a number of downsides to the Inkling approach: For example, page number references are no longer valid between print books and eTextbooks, so professors will have to refer to chapters and sections, not page numbers. (Update: A commenter says that Inkling maps the print version's original page numbers to the eTextbook version and allows users to navigate using the print page numbers.) Disiplay of eTextbooks on devices with screens smaller than 7" will be marginal at best. Inkling requires much more redesign and reformatting of content than does Kno, so it costs more and takes more time to create Inkling eTextbooks, and publishers have to be much more involved in the conversion process. On the other hand, Inkling eTextbooks work with the iPad, and will likely work on Android tablets in the future. Inkling doesn't have to build, sell and support its own tablets, and it's already supporting a wildly popular platform.

Kno's approach may be the path of least resistance in the short run, but it's hard to believe that we'll see millions of college students carrying heavy, bulky, expensive Kno eTextbook readers instead of cheaper, lightweight iOS and Android tablets that can do much more. Inkling's approach is better suited to where the industry is going. Making eTextbooks that look and work like their paper counterparts is an interim strategy at best. The value of a textbook is the information it contains, not its packaging, and that's why my money's on Inkling for the long run.
Enhanced by Zemanta