Well, of course cards are semantically equal to RSS feeds or HTML tags - the card is a presentation concept for the idea of a "container", after all; programmat

Well, of course cards are semantically equal to RSS feeds or HTML tags - the card is a presentation concept for the idea of a "container", after all; programmatically, they can be treated the same as any other information block. 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-approach-tablet-computing http://www.linuxjournal.com/content/plasma-active-new-approa... [2] http://en.wikipedia.org/wiki/Archy http://en.wikipedia.org/wiki/Archy