The mass market doesn't buy, and doesn't want to buy, products based on what they might become months from now if these companies somehow dramatically improve the software. They buy products for what they are today, out of the box.
I would wager that, sometime between now and 30 June 2012, iCloud will offer a web interface just as good as if not better than MobileMe's (and quite possibly, under the hood, based on MobileMe's). They just haven't announced it yet, and if Apple hasn't announced it, they won't talk about it.
In short, there is no reason to assume that iCloud as it will exist 12 months from now will be limited to what was announced one week ago.
§
If you don't already know what Google Rich Snippets or schema.org are, this post is probably not for you.
Google Rich Snippets are not deprecated! The schema.org FAQ states, "If you have already done markup and it is already being used by Google, Microsoft, or Yahoo!, the markup format will continue to be supported. Changing to the new markup format could be helpful over time because you will be switching to a standard that is accepted across all three companies, but you don't have to do it."
This guide is for people who want to do it anyway.
Disclaimer: despite my working for Google, this guide has no official status. It represents nothing beyond my own personal interpretation, based on my experience writing about microdata and Google Rich Snippets in my free HTML5 book which you should totally pay money for because this is the way I want the world to work.
Some notes:
- Google Rich Snippets supported microdata, microformats, and RDFa. Schema.org only supports microdata. If you've been using microformats or RDFa to mark up your Google Rich Snippets, sorry, you backed the wrong horse.
- Microdata is valid HTML5. Take two seconds to upgrade your DOCTYPE and get on with your life.
- The official mailing list is your best bet if you have questions. My blog is where good feedback goes to die.
- There is currently no way of verifying that this metadata, once migrated, will be interpreted correctly by search engines. i.e. There is no schema.org testing tool or validator. Somebody should get on that.
Table of Contents
- Address changes
- Geo changes
- Organization changes
- Person changes
- Event changes
- Product changes
- Review changes
- Offer changes
§
Address changes
http:// is now http://. Some properties have new names.
| Old itemprop | New itemprop |
|---|---|
street-address | streetAddress |
locality | addressLocality |
region | addressRegion |
postal-code | postalCode |
country-name | addressCountry |
§
Geo changes
http:// is now http://. There are no changes to property names or semantics.
Several properties in the old data-vocabulary.org schema were of type http://. In the schema.org vocabulary, many of these now use a location property of type Place. The new Place schema contains a geo property of type GeoCoordinates.
§
Organization changes
http:// is now http://. The new schema has a number of more specific types like Corporation, NGO, and SportsTeam. Use the most specific type that is appropriate.
Some properties have new names or are expressed in different ways.
| Old itemprop | New itemprop |
|---|---|
tel | telephone |
geo | moved to |
§
Person changes
http:// is now http://. Some properties have new names or are expressed in different ways.
| Old itemprop | New itemprop |
|---|---|
nickname | obsolete |
photo | image |
title | jobTitle |
role | obsolete |
friend, contact, acquaintance | obsolete, use knows, follows, or colleagues |
In addition, the affiliation used to be a plain text property. It now takes an Organization. (See also: Organization changes)
§
Event changes
http:// is now http://. The new schema has a number of more specific types like BusinessEvent, SocialEvent, or Festival. Use the most specific type that is appropriate.
Some properties have new names or are expressed in different ways.
| Old itemprop | New itemprop |
|---|---|
summary | name |
photo | image |
eventType | obsolete, use a specific event type if available |
geo | moved to location property |
In addition, the location property used to be plain text or an Organization or an Address; now it must be either a Place or a PostalAddress. (See also: Address changes)
§
Product changes
http:// is now http://. Some properties have new names or are expressed in different ways.
| Old itemprop | New itemprop |
|---|---|
category | obsolete |
review | reviews (type Review) |
offerdetails | offers (type Offer) |
identifier | productID |
The brand property used to be plain text, but it now takes an Organization.
§
Review changes
http:// is now http://. Some properties have new names or are expressed in different ways.
| Old itemprop | New itemprop |
|---|---|
itemreviewed | itemReviewed (type Thing) |
rating | reviewRating |
reviewer | author (type Person or Organization) |
dtreviewed | datePublished |
description | reviewBody |
§
Offer changes
http:// is now http://. Some properties have new names or are expressed in different ways.
| Old itemprop | New itemprop |
|---|---|
currency | priceCurrency |
condition | itemCondition (type OfferItemCondition) |
offerURL | url |
identifier | moved to productID property of itemOffered |
The availability property used to be an enumerated attribute, but it now takes an ItemAvailability.
§
David Flanagan, author of JavaScript: The Definitive Guide, writes:
For 15 years I've been one of those lucky authors who has been able to support himself and his family almost entirely on book royalties. But the publishing industry has been in decline and my royalties checks have decreased more-or-less steadily since the dot-com bust, and I've now decided that I need to look for a salaried job.
15 years is a long time. What a blessing to have been able to do something you love for that long, and get paid for it.
But then he goes off into the weeds a little bit and starts in with his opinions of piracy and Google's role in the world. [Note: I work for Google but not on search. I don't speak for Google and they don't speak for me. It works out well.]
David continues:
I was trying to be provocative when I tweeted the question "Does Google enable piracy?" But I do think it is a valid question. If Google indexes sites like ebookee that link directly to download sites and makes it easy to find the pirated content you want and even offers suggestions on what to search for, I think there is a case to be made that they're encouraging piracy.
Note how quickly we've moved the goalposts from "enabling" piracy to "encouraging" piracy. Lots of technology "enables" piracy; after all, it's only 1s and 0s. In the analog world, even libraries "enable" piracy by putting a photocopier in the same building as a bunch of books. But do libraries "encourage" piracy? No, there are big signs next to the photocopier warning you about copyright law, and photocopies are prohibitively expensive to do anything more than copy a few pages for reference. Does technology "encourage" digital piracy? No, it's only 1s and 0s.
More importantly, contrary to David's assertion, ebookee does not have David's latest book. The entire site is a scam to get people to sign up for Usenet or "premium" file sharing services. They have a page for every book in the universe. A small fraction of them actually have download links, most of which are broken. Mostly, the site just goes round and round. There's a case to be made that the site should be delisted because it's fucking useless, but its existence in search results does not bolster David's argument that Google is "encouraging" piracy.
And now JavaScript: The Definitive Guide is out. I don't have a copy of it yet, but illegal copies are free for anyone who wants one.
This is not true; see above.
And Google will suggest those illegal downloads to anyone who tries to research the book (see the screenshot).
That screenshot actually shows the results of Google's existing filtering program for piracy-related terms like "bittorrent," "rapidshare," and "megaupload." Without that filtering, the suggestion box would be full of piracy-related terms. But more to the point, it would be full of piracy-related terms because that's what people search for. Google's suggestions come from actual searches. It's a mirror onto the world, descriptive not prescriptive. If you don't like how the world looks in the mirror, don't blame the mirror.
David continues:
Here are some small steps that might help:
- Google could filter its search suggestions so that they do not actively suggest piracy.
Google already does this; see above.
- Google could flag (without filtering) search results that are likely links to pirated content. Google already flags some results with "this site may harm your computer". Why not flag pirate sites: "Downloading content from this site may result in legal action by the copyright holder" or "Downloads from this site may be illegal". Or nice and simple: "this site may harm your karma".
The difference is that "this site may harm your computer" is based on an objective measurement. You can read how it works. Suspected sites are automatically verified in a virtual machine running an unpatched browser. It is both fascinating and mind-boggling to imagine that it works at all, much less works at Internet scale in near-real time.
On the other hand, legal concepts like "copyrighted material" are more difficult to automate at Internet scale. This is not to say it's impossible; YouTube has its Content ID program for audio and video, but it relies on the fact that people are actually uploading content to YouTube directly. To replicate this program on RapidShare, Google would need to download everything from RapidShare in order to identify it. Ironically, RapidShare makes this technically difficult in order to discourage third-party downloader programs that help users "steal" content from RapidShare without viewing ads or paying for "premium" membership.
And even if all the technical hurdles could be overcome, it still wouldn't necessarily warrant flagging sites like ebookee, which only hosts links to infringing content and not the content itself. (And if Google did start flagging them, they would just add another layer of indirection, or cloak their download URLs, or some other damn thing. You'll never beat piracy this way.)
Speaking of "beating" piracy, an anonymous commenter makes this point:
One of the reasons iTunes is so successful is that they successfully compete with the file sharers. ... Why should I waste time looking for an mp3 that may or may not be of any decent quality when I can download immediately at low cost from iTunes?
Commenter "Peter" makes a related point:
I have been an OReilly Safari subscriber for several years. I can recommend this to every developer out there. ... Yet, must admit it still pains me that for ~$500/year we as honest subscribers can not get the same convenience (offline access, unencumbered PDF's) as people who just download a pirated PDF library for free.
So is piracy really the problem? Is it even a problem? David has provided no evidence that his book is, in fact, wildly pirated. It's not even available yet from dedicated pirate sites. But the larger, more disturbing question is this: who bothers to steal books these days when you can go to Stack Overflow or a web forum or, yes, even Google, type a question, and get an answer?
I'll close with this observation from "Curt":
Most technical book are actually really painful to navigate, but at [one] time they were the only option, now I can find context relevant information in seconds hence books are less convenient and they cost money. The default is now deeply linked, highly specific data. IMHO you are not losing money to piracy, you are failing to make money due to the inadequacy of the book as a medium for technical data.
I think David would actually agree with this. In response to another comment, David himself wrote:
I will say that my book was written as a book, and it probably wouldn't work well online (regardless of whether it could work financially that way). And maybe that is a big piece of my revenue problem: I'm producing content in an old-fashioned medium.
The "book" is dead. Long live "content." And God help us all if world-class writers like David can't make a living from it.
§
[Original]
Browsers that use modern operating systems more directly deliver better experiences. Browsers that compromise (by spreading across too many OSes and OS versions) face challenges.
We can't decide if we want IE to drive Windows adoption or Windows to drive IE adoption.
The best HTML5 is native to the operating system, so Web sites have the fewest translation layers to pass through.
The browser is part of the OS. The browser has always been part of the OS. We have always been at war with Eastasia.
Native HTML5 support in Windows with IE9 makes a huge difference in what sites can do.
We're really, really sorry about IE6. Not sorry enough to disable Windows activation and allow all the software pirates in China to upgrade, but sorry nonetheless.
Web sites and HTML5 run best when they run natively, on a browser optimized for the operating system on your device.
I think we can all agree to hate XUL.
We're about three weeks into development of IE10, and based on the progress we've made, we want to start engaging the development community now.
Imagine how much progress we could have made if we hadn't ignored the web for ten fucking years.
Native HTML5 ... native HTML5 ... run natively ... most native ... only native ... native graphics ... native ... Native HTML5 ... Native HTML5 ... native and robust ... native applications ... Native implementations ... non-native ... native HTML5 ... native ...
I am high as a kite.
When this post was initially published, I forgot to include the onerror event handler for the HTML5 video element. This caused the video to not play in browsers that don't support MP4/H.264 video. That has been corrected.
The irony of using the phrase "same markup" nine times while delivering different markup to other browsers is entirely lost on me.
The only native experience of the Web and HTML5 today is on Windows 7 with IE9.
We would like HTML5 better if it were spelled "ActiveX."
§
First off, I would like to thank Microsoft for regrouping, restaffing, and developing Internet Explorer 9. There is much to be thankful for. Very soon, new Windows 7 users will have, by default and without any installation, a browser that supports
- Canvas without JavaScript translation libraries
- SVG without amazing translating-to-Flash hacks, including inline SVG in HTML
- Geolocation without plugins
- Persistent local storage (note: this is already in IE8)
- H.264 video without plugins
- New semantics elements without JavaScript shims
- Rounded corners and other CSS improvements
This is quite remarkable. I've been busily updating Dive Into HTML5, changing phrases like "no version of Internet Explorer supports..." to "versions of IE before 9.0 did not support..." I never, ever, ever thought this day would come. Thank you, Microsoft.
So here's a downer: what if this is it? What if, after years of increasing evangelism and fever-pitch hype and demos and speeches and books and talks and blogs and tweets and logos, Microsoft shifts direction once again, destaffs the IE team, and "deprioritizes" any notion of an IE 10? And all these promising technologies die on the vine, or at most, grow up to smack hard against the glass ceiling of "no version of Internet Explorer supports..."
- Web Forms 2.0 (datepickers, validation, and so forth)
- Web Workers (background JavaScript)
- WebSockets (real-time bidirectional communication)
- AppCache (offline web applications)
- WebGL (3-D canvas)
- WebM (open video)
- IndexedDB (advanced persistent local storage)
- History API (twiddle with the entire URL without reloading)
- Device API (videoconferencing without plugins)
- File API (sandboxed in-browser filesystem)
- Audio data API (dynamically creating music with JavaScript)
- and on and on...
What if this is as good as it gets?
§