Why cards are the future of the web(insideintercom.io)
insideintercom.io
Why cards are the future of the web
http://www.insideintercom.io/why-cards-are-the-future-of-the-web/
35 comments
At this stage I think the 'card' concept benefits by being loosely defined. A followup tweet from the author (https://twitter.com/padday/status/376019194518589441) emphasizes certain interactions:
"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.
"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.
The problem is, once you make the definition more specific, like this, the idea that "cards are the future" starts looking much more dubious - I'm not sure any of the examples of supposed "cards" in the post fit this definition. Maybe Twitter and Google Now have enough of these elements to count, just about, but I don't see how Pinterest or Spotify do.
"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.
"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.
I can't decide if I like this idea or not. The only reason that stacking/grouping/etc physical cards works is because they are typically fully known. Otherwise, you are just restricting what I can already do with an RSS feed to now having to worry about some potentially idiotic metaphor for manipulation.
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.
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.
Cards can be used at many contexts, for many purposes. Self-contained tweets is good for small talk and social content sharing, but RSS-like snippets that link to external articles are also a valid option.
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.
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.
I can't imagine said system, is the problem. Imagining a system where people share ideas is fine. Trying to pin the idea to a specific metaphor is where I just start grumbling. I agree wholeheartedly that headlines and catchphrases are more easily shared. I am not convinced that they are somehow more natural in manipulation.
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/
[2] http://fed.wiki.org/view/welcome-visitors/hsi.fed.wiki.org/h...
[3] http://vimeo.com/64895205
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...
[3] http://vimeo.com/64895205
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.
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.
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-approa... [2] http://en.wikipedia.org/wiki/Archy
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
So, I think I was using the term "metaphor" where you are using "presentation concept." As such, I think we essentially agree here. I just don't have the vision to see how this graphical based concept will work. This sounds like efforts to move programming out of text based exercises and into visual ones. Or, modifying the AST of a program instead of the text. I clearly think this has some merit, but the largest success that I can think of for this idea is LISP, which fools everyone looking at it into thinking they are looking at text.
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.
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.
Thanks! Yes, I see a trend of modern programming languages towards LISP features. Also visual environments are having a resurgence, now that computers are powerful enough to support "Intellisense"-like autodiscovery and suggestions without grinding the system. I expect future user interfaces to allow users to modify ASTs, and fool them into thinking that they're looking at blogs and wikis. :-)
Sounds like the author wants it to be defined more by the verbs it can be an object of than its looks.
I haven't read the article fully yet, but this seems reasonable to me.
I haven't read the article fully yet, but this seems reasonable to me.
It would be great to have data available in "card format" so that information could be aggregated by users, other apps, or websites as they saw fit. Maybe as an alternative to "mobile" versions of websites, for example. I've toyed around with some ideas here: http://ghn.cloudapp.net - you can right-click to flip, or swipe left/right on each "card" if you are on a touch device.
Like a window?
A "card" is merely a convenient name for the concept of microdata/microformats [1], which happens to often be _visually_ represented as a snippet, or a "card".
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".
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".
While the current trend is obviously about making it easier to navigate using mobile, I could see 'cards' making it easier to navigate using eye-tracking (possibly combined with voice), which is where I think we're heading in the not too far off future (we're a lazy species).
Agreed. If google added a border with some CSS shadows to their results, they would be considered cards.
that's my startup! boom
didn't cuil[1] already try that?
[1]: http://en.wikipedia.org/wiki/Cuil
[1]: http://en.wikipedia.org/wiki/Cuil
Data formatted in a regular pattern so that we can easily parse it.
This sounds like a throwback to WML, not progress.
http://en.wikipedia.org/wiki/Wireless_Markup_Language
http://en.wikipedia.org/wiki/Wireless_Application_Protocol#C...
I thought that the convergence of mobile markup with desktop markup was a great idea, as long as one didn't overload pages with extraneous content.
Really, today's mobile devices are quite capable, and to limit these clients by relegating them to "card" based presentation seems like a step, or two, backwards.
http://en.wikipedia.org/wiki/Wireless_Markup_Language
http://en.wikipedia.org/wiki/Wireless_Application_Protocol#C...
I thought that the convergence of mobile markup with desktop markup was a great idea, as long as one didn't overload pages with extraneous content.
Really, today's mobile devices are quite capable, and to limit these clients by relegating them to "card" based presentation seems like a step, or two, backwards.
Then the future of the web is quite bleak. I don't think there's a standard accepted form for the card, unless everyone decides to copy Twitter et al.
I'm still browsing a fair number of sites that fall outside of social media and "sharing sites". Twitter for me is mostly for news and some social interaction where I see cards being used effectively, Pinterest is nice to look at from time to time, but I'm not stuck there either.
Now more and more people are confusing Twitter, Facebook, Pinterest and family with "The Web", but a fair amount of content still resides on independent sites. That leaves a vast majority of independent sites that may or may not modify their markup to be "card-friendly".
Also, Twitter makes their card-friendly markup explicit and I'm not sure that's gonna fly for the long term. If everyone is willing to standardize on Schema.org markup OTOH, then I'd say it's acceptable.
I'm still browsing a fair number of sites that fall outside of social media and "sharing sites". Twitter for me is mostly for news and some social interaction where I see cards being used effectively, Pinterest is nice to look at from time to time, but I'm not stuck there either.
Now more and more people are confusing Twitter, Facebook, Pinterest and family with "The Web", but a fair amount of content still resides on independent sites. That leaves a vast majority of independent sites that may or may not modify their markup to be "card-friendly".
Also, Twitter makes their card-friendly markup explicit and I'm not sure that's gonna fly for the long term. If everyone is willing to standardize on Schema.org markup OTOH, then I'd say it's acceptable.
What total nonsense. These "cards" just represent what a smartphone can reasonably show. As anyone who's ever tried to read a web "page" on a phone will attest, the format is less than ideal, except possibly on the bigger phablets. Short snippets of content (the Readers Digest version) is just a convenient format, see google weather, tweets, pins etc for examples. Think of it this way, search results are a list pointing to a page, a card is an intermediate format, better than the list item, less than the page.
Then perhaps the question is: are there more situations where we can display information as more digestible, shorter pieces of content?
I've definitely found that bringing that simpler design from mobile to desktop has tested well with people in a lot of situations.
I've definitely found that bringing that simpler design from mobile to desktop has tested well with people in a lot of situations.
Endless scrolling pages, flowing text, drop-down menus... these are all foreign concepts to animals.
People are used to interacting with 2D objects in the world. It feels natural. "Cards" provide a strong figure-ground relationship and let the viewer chunk content. It's the same idea as section headings or pull-quotes in articles.
I hope we can also get to direct manipulation of objects. I'm really sick of clicking/tapping verbs to do an action on an object. We should have some other proxy for behavior than words.
People are used to interacting with 2D objects in the world. It feels natural. "Cards" provide a strong figure-ground relationship and let the viewer chunk content. It's the same idea as section headings or pull-quotes in articles.
I hope we can also get to direct manipulation of objects. I'm really sick of clicking/tapping verbs to do an action on an object. We should have some other proxy for behavior than words.
Cards are a bit of a distraction from direct manipulation. They scream lo-interactivity Web app. They muddle the selection and drag-ability. They have some advantages in presenting datafrom an update stream: Google+'s three column-wide card presentation on a desktop screen is much more modern than Facebook or LinkedIn.
But now, some designers have found their new hammer and everything looks like a nail.
But now, some designers have found their new hammer and everything looks like a nail.
We have been interacting with objects longer than we have been interacting with words for sure, but the words are more expressive. Think about a simple contact information "card" if you will. It's much easier for your brain to parse that tapping on the "call" button will call the phone number, or that that the message button will compose a new message. When there are that many different verbs as options, translating them into object manipulation is just too much. Think about what it would be like if you had to swipe to call but tap to email and twist to send a text message.
Interacting with a verb is easier in the long run.
This is the common argument for using verbs/buttons. And it certainly also makes sense in the physical world, where we pull levers or turn wheels to control larger machines (cars, airplanes, a stove, etc.) In my comment above, I actually mean "action" as "interaction" or more complex than a simple order like send/delete/etc.
The trick to all of this is finding gestures (or whatever you want to call them) that allow some sort of direct manipulation in areas where the human mind has no experience. The best example right now is pinch-to-zoom, which has absolutely no physical equivalent, but is extremely intuitive. Compare this to having arrow and +/- magnifying glass buttons.
As software blends more with the rest of the world, the machine-intentioned interaction is breaking down. It's kind of like trying to draw a photorealistic image using an etch-a-sketch, when instead you just need a pen and paper.
(You could argue that pinch-to-zoom isn't very discoverable/learnable, but the reality is that people figure it out incredibly quickly, which is kind of amazing when you think about it. There's certainly something magically compelling about using one's hands in that way. Perhaps it's actually more important for interfaces to be instantly learnable than "intuitive.")
The trick to all of this is finding gestures (or whatever you want to call them) that allow some sort of direct manipulation in areas where the human mind has no experience. The best example right now is pinch-to-zoom, which has absolutely no physical equivalent, but is extremely intuitive. Compare this to having arrow and +/- magnifying glass buttons.
As software blends more with the rest of the world, the machine-intentioned interaction is breaking down. It's kind of like trying to draw a photorealistic image using an etch-a-sketch, when instead you just need a pen and paper.
(You could argue that pinch-to-zoom isn't very discoverable/learnable, but the reality is that people figure it out incredibly quickly, which is kind of amazing when you think about it. There's certainly something magically compelling about using one's hands in that way. Perhaps it's actually more important for interfaces to be instantly learnable than "intuitive.")
What BS article. Card are just one design pattern of many.
That's probably some guy who is easily convinced of some marketing crap talk. There is always the next thing. Cards will become boring. The next one may even be a fancier version of <marquee> and it will be all the hype until replaced by the next thing.. ZzzzzZZZ
In other words, web content is moving away from a disjunctive relationship (this page, or that page, or...) to a conjunctive one (this card, and that card, and...).
One thing that worries me is that a conjunction is non-indexable (if you have an index then you turn it back into a disjunction).
Ultimately, this means that the address bar (i.e. the thing that lets us index into the web) will become even less useful, and there won't be a canonical way of sharing content; just a bunch of varieties of “share this” buttons.
One thing that worries me is that a conjunction is non-indexable (if you have an index then you turn it back into a disjunction).
Ultimately, this means that the address bar (i.e. the thing that lets us index into the web) will become even less useful, and there won't be a canonical way of sharing content; just a bunch of varieties of “share this” buttons.
[deleted]
Oh dear, sounds like frames again...
Imaging one particular card with heavy multimedia that hogs your whole fucking browser...
Next thing you know now there's CPU & memory meter for cards.
Next thing you know now there's CPU & memory meter for cards.
No reason cards couldn't have URIs (IMO they must have them). That doesn't stop pages aggregating them.
True, but those URIs probably won’t be easily accessible to end users.
I am not against “cards” per se, but I am worried about what the “appification” of the Internet portends. The web put most of the intelligence in the nodes rather than the network (in contrast to, say, cable television). Apps are reversing that. Now if I want to share content, I can no longer easily do so without the network(s) knowing about it. Intelligent networks scare me.
One more thing about disjunctions vs. conjunctions: the former is about random access whereas the latter is about sequential access. Sequentially accessed stuff is consumed by streaming. So I am afraid that what we are going to end up with are a bunch of domain names/apps that correspond to streams; or in other words, cable TV 2.0.
I am not against “cards” per se, but I am worried about what the “appification” of the Internet portends. The web put most of the intelligence in the nodes rather than the network (in contrast to, say, cable television). Apps are reversing that. Now if I want to share content, I can no longer easily do so without the network(s) knowing about it. Intelligent networks scare me.
One more thing about disjunctions vs. conjunctions: the former is about random access whereas the latter is about sequential access. Sequentially accessed stuff is consumed by streaming. So I am afraid that what we are going to end up with are a bunch of domain names/apps that correspond to streams; or in other words, cable TV 2.0.
Think I'm looking at this differently - as breaking down the granularity of a page. If you standardised on a card API it wouldn't quite be a web of things but takes you in that direction. Something like RSS/Atom but less general and oriented to individual items rather than lists, with a richer data model. That content is then available to pages and apps equally and could maybe help against the walled garden effect.
Maybe I've missed something huge, but having a URL is a central part of- at the very least, twitter's cards. The scenario is, user posts a link to the New York Times on twitter (as they do), the new york times has some level of control over the automatically generated preview that appears next to that tweet on twitter.
Design trends are just this - trends. Next year the future of the web will be very different.
Maybe color and images will vanish next and all text will be monospaced. The Typewriter Revolution! The ultimate in minimalism. It could happen...
I'm already seeing that trend. How many blogs have you seen thus far that have abandoned the side widget or even the footer?
Every post is just title, main content in a giant font and a back button. It seems some content creators are tired of shiny doodads.
Every post is just title, main content in a giant font and a back button. It seems some content creators are tired of shiny doodads.
I think http://ia.net/blog/the-web-is-all-about-typography-period is still percolating through.
I think pg is pretty remarkable in the fact that his blog is nearly this - save the side bar and the odd link here and there.
I certainly prefer that to the geocities/myspace level of razzamatazz.
I certainly prefer that to the geocities/myspace level of razzamatazz.
It's about time the web started looking like a decent text editor.
This makes me think of the "hypercards" in _Snow Crash,_ which "look" like business cards in the Metaverse, and are easily transferrable from one avatar to another, but can contain vast amounts of information (such as the "Babel/Infocalypse" card Juanita gives Hiro), viruses (such as the titular one), or even money (the card Uncle Enzo gives Hiro, containing HK$25M). Stephenson probably based this metaphor on the old Apple Hypercard application, but it carries forward well into the Web, and even to an explicitly _Snow Crash_ -inspired environment like Second Life ("notecards" in SL can contain, not just text, but images and even embedded objects).
And for a moment we all thought that skeuomorphic designing was on its way out. Apparently it is, except for cards, which are <breathless> "the future of the web" </breathless>
The biggest reason why companies & brands are taking to cards, and why consumers should be wary of them is the _seamless and transparent transfer of our demographic & contextual information with every click_.
>> The aggregation depends on: >> The person consuming the content and their interests, preferences, behaviour. >> Their location and environmental context. >> Their friends’ interests, preferences and behaviour. >> The targeting advertising eco-system.
Cards take away the control & choice from users about what information they want to transmit to brands through their browsing. That can only be done when we're constantly logged into services from Google, Twitter, Pinterest etc.
I'm not sure that is the future web I dream of.
The biggest reason why companies & brands are taking to cards, and why consumers should be wary of them is the _seamless and transparent transfer of our demographic & contextual information with every click_.
>> The aggregation depends on: >> The person consuming the content and their interests, preferences, behaviour. >> Their location and environmental context. >> Their friends’ interests, preferences and behaviour. >> The targeting advertising eco-system.
Cards take away the control & choice from users about what information they want to transmit to brands through their browsing. That can only be done when we're constantly logged into services from Google, Twitter, Pinterest etc.
I'm not sure that is the future web I dream of.
>Remember, mobile devices are the heart and soul of the future of your business, no matter who you are and what you do.
No, they are almost totally irrelevant to my business, I'm a doctor/plumber/painter/...
No, they are almost totally irrelevant to my business, I'm a doctor/plumber/painter/...
I think you picked some poor choices for examples. I work in healthcare and I can assure you that the future is increasingly going to depend on mobile devices. Doctors in many places have been lugging laptops and crappy Windows XP tablets around for a while now. The push to electronic health records will drive mobile adoption even more.
I have no firsthand experience with the business of painters and plumbers. But thinking about other types of contractors, they do spend their whole day going around to customers (i.e. they are highly mobile). My last HVAC service call involved the technician using a tablet to enter my AC unit's serial number for a real-time warranty check. He then ordered a new part right there in front of me and I signed the sheet with my finger. I expect lots of plumbers would do the same thing with a hot water heater or similar complex repair.
I have no firsthand experience with the business of painters and plumbers. But thinking about other types of contractors, they do spend their whole day going around to customers (i.e. they are highly mobile). My last HVAC service call involved the technician using a tablet to enter my AC unit's serial number for a real-time warranty check. He then ordered a new part right there in front of me and I signed the sheet with my finger. I expect lots of plumbers would do the same thing with a hot water heater or similar complex repair.
>Doctors in many places have been lugging laptops and crappy Windows XP tablets around for a while now. The push to electronic health records will drive mobile adoption even more.
Sure, and a lot have iPads. But it's still quite peripheral to what the do 90% of the time -- and they could do the same almost as well on their laptop already.
Sure, and a lot have iPads. But it's still quite peripheral to what the do 90% of the time -- and they could do the same almost as well on their laptop already.
Peripheral to what they do 90% of the time.
That depends on the doctor. But generally doctors spend ~20% of their day doing data entry. The rest of the time, in general practice, family, etc. clinics, doctors need an EHR at their fingertips when talking to patients and other care providers and carrying an iPad around with an EHR designed for the iPad from the ground up is easier than most desktop-based EHR software.
Could do the same almost as well on their laptop.
Misunderstands why a person uses an iPad instead of a laptop.
That depends on the doctor. But generally doctors spend ~20% of their day doing data entry. The rest of the time, in general practice, family, etc. clinics, doctors need an EHR at their fingertips when talking to patients and other care providers and carrying an iPad around with an EHR designed for the iPad from the ground up is easier than most desktop-based EHR software.
Could do the same almost as well on their laptop.
Misunderstands why a person uses an iPad instead of a laptop.
This is an interesting article which picks up on an emerging trend. However, it conflates the theoretical concept of a "card" with physical designs.
The example of Facebook is apt, as their system is all about discrete, short bits of content (ie. "cards") being shuffled into different views. Despite this Facebook has I think wisely avoided the skeuomorphism of actual card designs.
The concept of cards definitely has legs. The more integrated and easily consumable we can make the web, the better. But the designs don't necessarily matter to that concept.
The example of Facebook is apt, as their system is all about discrete, short bits of content (ie. "cards") being shuffled into different views. Despite this Facebook has I think wisely avoided the skeuomorphism of actual card designs.
The concept of cards definitely has legs. The more integrated and easily consumable we can make the web, the better. But the designs don't necessarily matter to that concept.
I remember as a child being handed packs of cards and told if I read them in an order they made a story. I pick up my daily NYT card stack at the tube station each morning and shuffle it on the way to work. Each day at work I carefully write on blank ruled cards to give to my co workers
Oh come on folks! A card is a good metaphor for a small collection of related bits of data (and wait for the JQuery library coming soon) but really - the future ? For some UX design needs - yes. But we will always need deeper references.
Oh come on folks! A card is a good metaphor for a small collection of related bits of data (and wait for the JQuery library coming soon) but really - the future ? For some UX design needs - yes. But we will always need deeper references.
I believe the palm pre did this like, 5 years ago. Nobody was excited about it then. The concept with the PRE was: Instead of having apps, you have cards- bits of content, that have some chunk of functionality attached to them by virtue of their type. So a contact card has contact stuff on it. A web page card has browser stuff on it. It's a kind of abstraction that allows some new kinds of interaction like, arbitrary sorting of cards, searching through cards, shuffling, etc etc- Making the content itself more like a file icon. Or conversely, bringing more of the content and app functionality into the freedom of movement of a file icon. There's no concept of "opening" a file in an application. The file is just there, with everything you need ready to go.
This new incarnation has to do with facebook and twitter's inclination to actually retrieve the contents of a user supplied inline link to try and show a "preview" inline, so you're not just clicking into the link blindly. The twitter card concept is about giving the people at the destination of that URL some control over the appearance of that twitter preview- by the use of metadata/microformats-like markup. This level of control is starting to approach the uncanny valley of resembling the above Palm-Pre-like card concept; turning the preview into the app functionality itself.
This new incarnation has to do with facebook and twitter's inclination to actually retrieve the contents of a user supplied inline link to try and show a "preview" inline, so you're not just clicking into the link blindly. The twitter card concept is about giving the people at the destination of that URL some control over the appearance of that twitter preview- by the use of metadata/microformats-like markup. This level of control is starting to approach the uncanny valley of resembling the above Palm-Pre-like card concept; turning the preview into the app functionality itself.
The essential attraction of the idea of a card is that the visual representation of the card marries to the backend representation which marries to the social (shareability) representation.
Every so often someone comes out with a 'new' idea to simplify (or make redundant) the design process. Separating discrete snippets of information to be consumed or processed independently, but situated as part of a greater whole, is design. There is no magic bullet. You will still need designers.
Every so often someone comes out with a 'new' idea to simplify (or make redundant) the design process. Separating discrete snippets of information to be consumed or processed independently, but situated as part of a greater whole, is design. There is no magic bullet. You will still need designers.
I think the point is not that design will not be needed, is that card-based designs make sense as a native structure for web content, and thus better than static page designs.
There's a big problem with cards : if they're from different heights, it's really hard to float.
I've implemented something like that in a yet to release project recently, without even thinking of the concept of card. Being a responsive app, it looked to me like an obvious choice.
I've put some lorem ipsum content in those cards, and it looked just beautiful. ... then I placed real content. Shit happened.
Simply using float won't do it when cards have different height, it looks too ugly and have a lot of random almost entirely blank lines.
The look and feel of pinterest was good enough for the type of content I wanted to display, so I had a look to how they did it : every card is absolutely positioned to form a compact canvas, which means they have to compute every card position based on which will be shown.
I'm not saying it's impossible to achieve, but it seems to me it's not that responsive friendly, because it's not css friendly : the straighter solution to make it responsive is to have cards using the whole width of the block they're all in, or to have them all the exact same height.
EDIT : to illustrate this : http://jsfiddle.net/uV645/3/ Resize browser by width to see effect.
I've implemented something like that in a yet to release project recently, without even thinking of the concept of card. Being a responsive app, it looked to me like an obvious choice.
I've put some lorem ipsum content in those cards, and it looked just beautiful. ... then I placed real content. Shit happened.
Simply using float won't do it when cards have different height, it looks too ugly and have a lot of random almost entirely blank lines.
The look and feel of pinterest was good enough for the type of content I wanted to display, so I had a look to how they did it : every card is absolutely positioned to form a compact canvas, which means they have to compute every card position based on which will be shown.
I'm not saying it's impossible to achieve, but it seems to me it's not that responsive friendly, because it's not css friendly : the straighter solution to make it responsive is to have cards using the whole width of the block they're all in, or to have them all the exact same height.
EDIT : to illustrate this : http://jsfiddle.net/uV645/3/ Resize browser by width to see effect.
Have you tried stuff like the masonry or shapeshift plugins for jquery?
Personally I think the "fluid" responsive design for article snippets is a mistake; but then I hate multi-column feed designs, so that may be just a personal preference.
Apple got it right with the iPhone menu structure, which was inspired by the iPod (maybe they nailed it because it was not card-based). There, columns always maintain the same positional relation (there are menus to the "left" and sub-menus to the "right"), so you can always remember by muscle-memory where a particular item is located relative to the others. Re-flowing similar items breaks those relations.
Responsive pages make sense when the side columns are used for side content (i.e. "aside" tags, headers and footers, navigation...) - there, placing the sub-content above or below the main content to show it on a narrow screen is not a problem, since the moved card was subordinate to the main article anyway.
Apple got it right with the iPhone menu structure, which was inspired by the iPod (maybe they nailed it because it was not card-based). There, columns always maintain the same positional relation (there are menus to the "left" and sub-menus to the "right"), so you can always remember by muscle-memory where a particular item is located relative to the others. Re-flowing similar items breaks those relations.
Responsive pages make sense when the side columns are used for side content (i.e. "aside" tags, headers and footers, navigation...) - there, placing the sub-content above or below the main content to show it on a narrow screen is not a problem, since the moved card was subordinate to the main article anyway.
Not yet. To be honest, I've just decided to focus on backend features, put a locked height on items and to get back to this in the "let iterate on design details before releasing" phase.
But those plugins are a perfect fit that I didn't know of, thanks for it !
It's still something that have to be done through javascript, though. So I guess we probably have to consider cards canvas as a feature rather than as a design element (like calendars, graphs, etc).
But those plugins are a perfect fit that I didn't know of, thanks for it !
It's still something that have to be done through javascript, though. So I guess we probably have to consider cards canvas as a feature rather than as a design element (like calendars, graphs, etc).
I know this is simply about design and moving the concept of a content unit away from a container inside a page to a discreet unit, but I can't help but imagine that instead of saving bookmarks I had a collection of micro content. They could be static, or update, or be a feed, but they would be guaranteed to fall under a certain filesize, and have meta info about content type.
I guess formatting RSS and scraped sites / APIs can do all that, but perhaps we can start packaging our content to be more portable as well.
Could micro content have a unique hash? Is that how social sites track reccomendations or do they use the URL?
I guess formatting RSS and scraped sites / APIs can do all that, but perhaps we can start packaging our content to be more portable as well.
Could micro content have a unique hash? Is that how social sites track reccomendations or do they use the URL?
> They can be turned over to reveal more, folded for a summary and expanded for more details, stacked to save space, sorted, grouped, and spread out to survey more than one.
> Content consumption on Facebook, Twitter, Pinterest, Instagram, Line, you name it, is all built on the card design metaphor.
I think this makes sense as a design metaphor. Just as "skeuomorphism" was able to help people develop familiarity with iOS by relating it to the real world, "cards" helps us think about how we organize information for faster consumption.
> Content consumption on Facebook, Twitter, Pinterest, Instagram, Line, you name it, is all built on the card design metaphor.
I think this makes sense as a design metaphor. Just as "skeuomorphism" was able to help people develop familiarity with iOS by relating it to the real world, "cards" helps us think about how we organize information for faster consumption.
Trello (trello.com) is entirely "Cardesign"
What a bs post. The writer observed some sites using a specific pattern and now somehow "it's the future of the web" Please.
Very enjoyable article. I was just thinking that recently, mobile is just a nicer experience and it's because of these cards.
There was something about reading books and magazines before the web came, a gamified experience, because you could more visibly see your progress. On the web you might have read the equivalent of a 1000 page book but you never get the sense of that.
There was something about reading books and magazines before the web came, a gamified experience, because you could more visibly see your progress. On the web you might have read the equivalent of a 1000 page book but you never get the sense of that.
Its just that in web we use the term for 'Media container Formats' as cards, providing one with a way to encapsulate relevant information in a single container.
Like
In 'Broad Adaption', we see Twitter, Google, Apple, Facebook and LinkedIn all embracing this approach and in 'Well Defined Card Types', we see Photos, Videos, News Items, Maps, Offers, Recommendations.
Like
In 'Broad Adaption', we see Twitter, Google, Apple, Facebook and LinkedIn all embracing this approach and in 'Well Defined Card Types', we see Photos, Videos, News Items, Maps, Offers, Recommendations.
So is there a specification for the card? Is it a possibly multi-dimensional data structure or does it also have behaviors?
Wow. So Cards is the new goodness that is totally unlike every other touch screen interface ever developed...
Cards are great for mobile devices where the screen real estate is small and it distinguishes chunks of data well. However, I find it quite scattered and harder to digest on larger screens. It creates un-natural eye flow...
I like the word 'card' to explain it to clients, but really this is just another way to say modules or objects, which we've been using for quite a while.
Designs where information is haphazardly tiled on the screen without organization or any coherent visual flow are hopefully not the future of the web.
We called these content/context boxes in 2007
We called this "HyperCard" in 1987.
They called this the punch card in the 1960s - have I gone too far :)
we called them McBee cards in 1907
http://en.wikipedia.org/wiki/Edge-notched_card
We called them Papyrus rolls back in Ancient Egypt.
(Cue the stone tablet markers in three, two...)
(Cue the stone tablet markers in three, two...)
Ha! Yeps! Touché
It's just encapsulation of content, sort of similar to the old 2004 apple widgets that you could flip around.
Web 3.0 is going to be portlets? Let the games begin... again!
Incredible how nobody remembered Windows 8...
My Yahoo.
Makes me think of a business where you can print these cards via an API and have them delivered for various services. The polaroids of our generation.
We wanted flying cars. Instead we got cards.
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?