Other than that, a card's only defining feature is that it is a grouping of text, images, and links, which has been common on the web since 1993.
Is the idea more that we are moving towards groupings of content which can be consumed by themselves?
"don't think 'rectangle', think flipping, folding, expanding, stacking, grouping, sorting"
So yes, it's rectangular display groupings, but also small-chunks, repurposeable, and amenable to certain interactions reminiscent of physical cards.
I haven't read the article fully yet, but this seems reasonable to me.
That is, when you stack playing cards for use in, say, solitaire, you only have to see a very small portion of the card. Specifically, what suite and value it has. The only reason the cards are the same size is actually to conceal this information when they are turned around.
Contrast this with how I currently scan news headlines in most rss software. By seeing a list of the headlines. Sure, I don't know what the body of the messages are without opening them fully, but the entire point is that I do not feel I have time to read all of the articles and I am relying on a well written summary in the form of a title for my first level of curation.
Moving this to Twitter and the "card" api. I fail to see how focusing on making everything cards will necessarily be better than just focusing on keeping it small.
Consider, I can quickly scan all of my emails from my phone, not because each is presented as a cute card, but because the "list" metaphor has already won there. The effort placed in making the entire message "look good" on the phone is completely avoided by keeping the message "textual" and giving me a list of subjects and authors.
Similarly, twitter has dominance not because they are aiming for "cards," but because their content is guaranteed short. And really, I don't know as that this is a groundbreaking discovery. It is the reason "headline news" is the most disseminated. Sure, fancy graphics and cute typography is a wonderful differentiator, but few things compete with a well done title.
Technically, cards are not far away from any other previous content-delivery system; what's specific to them is their structure - centered around easy-to-scan bits of content, that can be directly linked to. This makes them more apt for social sharing and aggregation than the classic web of interlinked whole pages. Some have pointed out how they increase the granularity of content.
I also foresee them being used as the basis for an end-user development platform, a la Bret Victor's interactive drawing (but not necessarily geometric), as this structure is friendlier and simpler than semantic markup. I believe that this metaphor could close the gap that "Visual Basic", widget-based languages had respect the need to use imperative languages to define behavior.
That "cards can be manipulated" is actually a good thing. It allows both the content creator and the end user to select which tools to use for handling the content. In web pages, snippets can only be manipulated with whatever tools the content platform provides; conversely, RSS feeds are entirely handled by the client, and it's difficult for the content provider to specify some suggested tools (other than cues to some pre-defined microformats).
Imagine a system where users could share content cards like they do on current social webs, but where they're able to define new simple automatic procedures in the way that Victor's "programming-by-drawing-comic-strips" allows for, and I think that's the future of the user-facing side of the web. Hypercard shows that the card metaphor is a good basis for this; and the standards are finally mature enough to make such a system possible on the web.
The essence of the card is that it contains a fixed, small amount of content that can be linked to and reused at different contexts, not that you 'always' have to interact with it in a fixed "3x4 inches" format. If you try out the Smallest Federated Wiki below, you can drag-and-drop cards within a page, but the page doesn't seem to built from cards (although it is). Pages can be created by composing cards and giving them lightweight styles (such as removing the visual frames around them, or showing them in list formats).
If it helps you, this is how I picture a system programmable by the end user through cards:
- The structure is roughly like in the 10/GUI concept demo:[1]
* Information is organized in non-overlapping plaques.
* Plaques can be shown folded (cards), unfolded (pages) or minimized (links).
* Plaques are hyper-linked; clicking on links open related plaques like in the Smallest Federated Wiki. [2]
- Users can create new cards (this is what's missing in current card-based systems, which are read-only):
* Creating a card's structure is like creating a dialog in a traditional visual GUI builder, by composing small elements in a larger layout.
* The card's behavior is programmed with the interactive comic-strip operations that Bret Victor demoed recently in the "Stop Drawing Dead Fish" demo. [3]
Does such system make sense? Can you picture it?
--
[1] http://www.gizmag.com/10gui-multi-touch-interface/13104/
[2] http://fed.wiki.org/view/welcome-visitors/hsi.fed.wiki.org/h...
But, back to the idea of a card containing a fixed amount of content. This seems no different than the semantic idea of RSS or even HTML. Items have dates, links, titles, and descriptions. "Unfolding" is simply following the link to the full item. Seen this way, I am not at all sure how what you are describing is much different than an RSS UI. (Indeed, if you drop the idea of moving and editing items, and move the orientation to vertical, this is the old google reader. Or, the current gnus. :) The only difference is "opening related plaques" becomes "launching relevant related application.")
I argue that twitter gained success because they effectively dropped the link/description part and set a hard limit on how large the title could be. Probably more importantly, they provide the hosting service for everyone.
More directly, twitter has seen success largely by limiting the interactions and capabilities available to users. This would leave the interface we are talking about largely more confusing than twitter, without being as powerful as just giving access to the raw data. More confusing for the less interested audience, and less capable for the more interested audience.
All of this is to say that I am not at all against you doing this. Indeed, I welcome the advances that may come. Sadly, I still can not picture it myself. Instead, I see the ashes and poor reflections of previous offerings.
What changes is that they're now visible to the end user, while their structure previously could only be accessed by the system's developer. Now they can be published through an API, or directly manipulated from a GUI; that's a change in focus - the same operations can be done on the content, but different people can perform them if they are published as atomic cards instead of embedded in larger, whole documents.
Semantic-aware interfaces are less based on applications and more on tasks. These interfaces work just like with the old CLI, where instead of loading data into an app (where available commands are selected and composed by the developer), you have a information flowing through a "pipe" of independent commands selected by the user from all commands available in the system. Environments like KDE Plasma Active [1] (still app-based, but with "Activities" that represent tasks), or the old Cannon Cat and its spiritual succesor Archy (which was a graphical version of Emacs, sort of) [2], are examples of this model of interaction. These are not new concepts, really, but they've never been fully realized in graphical interface (afaik only the Canon Cat and Emacs follow them, and both are text-based).
Yes, Google Reader is a good example of the kind of content aggregation and sharing that I'm pursuing with my ideal system (and many people found it useful, so there's an audience for it). Google Now is another system which has chosen the card metaphor to show information according to context. But Reader was not programmable, as it had fixed styling that couldn't be changed by the end-user; and Google Now has fixed rules created by the provider, not the user. I believe that the card is a natural data structure for people that don't have a programming background to create simple procedures, that would allow users to create new behaviors for these tools.
You've given me some thoughts to chew with the "more confusing than twitter, less powerful than raw data"; I'm certainly aiming for "more powerful than twitter", and I'll have to ponder how to achieve that without making it too confusing. I have some ideas, but it's interesting that you identified this problem.
--
[1] http://www.linuxjournal.com/content/plasma-active-new-approa... [2] http://en.wikipedia.org/wiki/Archy
I definitely look forward to anything that is coming our way. Seriously best of luck on your endeavors here! I have already greatly appreciated the links you've given me.
"Here's some websites that put information in boxes" is plausible but not very interesting; "cards are the future of the web" is more interesting, but doesn't really have any evidence to support it.
The real key here is standardizing the various metadata formats, such as the title field; which ranges from Twitter's `twitter:title` to Facebook's `og:title`.
[1]: I'm building my augmented reality data network, http://aris.io, based on a similar premise, but abstracting these out to explicit "providers".