3 ms·

Then, I'll have to finish my PhD and show the world how it's done. :-) The essence of the card is that it contains a fixed, small amount of content that can be

Then, I'll have to finish my PhD and show the world how it's done. :-) 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/ http://www.gizmag.com/10gui-multi-touch-interface/13104/ [2] http://fed.wiki.org/view/welcome-visitors/hsi.fed.wiki.org/hacking-social-impact http://fed.wiki.org/view/welcome-visitors/hsi.fed.wiki.org/h... [3] http://vimeo.com/64895205 http://vimeo.com/64895205

taeric 13y ago
The 10gui demo is somewhat neat, though it does harken to traditional wacom devices in my mind. The GUI part is the neatest, and I'm just not sure how I feel about moving actions which are almost strictly conceptual now, choosing applications, and moving them to a physical component. Well, at least more into a physical concept. (That is, right now picking an application to run is more conceptual. You state the application name you want to launch. In the physical analogy, you have to find the application you want to launch.) I fully grant that this is territory that most guis already breach. (I'm much more heavily into the command line than I would guess most are.) 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.
- TuringTest 13y ago
  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
  - 13y ago

taeric 13y ago

The 10gui demo is somewhat neat, though it does harken to traditional wacom devices in my mind. The GUI part is the neatest, and I'm just not sure how I feel about moving actions which are almost strictly conceptual now, choosing applications, and moving them to a physical component. Well, at least more into a physical concept. (That is, right now picking an application to run is more conceptual. You state the application name you want to launch. In the physical analogy, you have to find the application you want to launch.) I fully grant that this is territory that most guis already breach. (I'm much more heavily into the command line than I would guess most are.) 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.

TuringTest 13y ago
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
- 13y ago