
Why cards are the future of the web  - jamesbritt
http://www.insideintercom.io/why-cards-are-the-future-of-the-web/
======
woah
This doesn't really go into what a card "is". Is it just a different colored
background or a box with a shadow on it?

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?

~~~
gojomo
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](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.

~~~
taeric
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.

~~~
TuringTest
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.

~~~
taeric
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.

~~~
TuringTest
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/h...](http://fed.wiki.org/view/welcome-
visitors/hsi.fed.wiki.org/hacking-social-impact)

[3] [http://vimeo.com/64895205](http://vimeo.com/64895205)

~~~
taeric
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
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...](http://www.linuxjournal.com/content/plasma-active-new-approach-
tablet-computing) [2]
[http://en.wikipedia.org/wiki/Archy](http://en.wikipedia.org/wiki/Archy)

~~~
taeric
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.

~~~
TuringTest
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. :-)

------
D9u
This sounds like a throwback to WML, not progress.

[http://en.wikipedia.org/wiki/Wireless_Markup_Language](http://en.wikipedia.org/wiki/Wireless_Markup_Language)

[http://en.wikipedia.org/wiki/Wireless_Application_Protocol#C...](http://en.wikipedia.org/wiki/Wireless_Application_Protocol#Criticism)

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.

------
eksith
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.

------
hnriot
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.

~~~
joelanman
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.

------
grinich
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.

~~~
shadesandcolour
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.

~~~
grinich
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.")

------
buster
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

------
noblethrasher
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.

~~~
dalek_cannes
Oh dear, sounds like _frames_ again...

~~~
est
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.

------
f055
Design trends are just this - trends. Next year the future of the web will be
very different.

~~~
coldcode
Maybe color and images will vanish next and all text will be monospaced. The
Typewriter Revolution! The ultimate in minimalism. It could happen...

~~~
eksith
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.

~~~
dreamfactory
I think [http://ia.net/blog/the-web-is-all-about-typography-
period](http://ia.net/blog/the-web-is-all-about-typography-period) is still
percolating through.

------
erbo
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).

------
r0h1n
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.

------
coldtea
> _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/...

~~~
JunkDNA
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.

~~~
coldtea
> _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.

~~~
thetylerhayes
_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.

------
morgante
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.

------
lifeisstillgood
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.

------
TheZenPsycho
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.

------
cam_l
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.

~~~
TuringTest
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.

------
oelmekki
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/](http://jsfiddle.net/uV645/3/) Resize browser by
width to see effect.

~~~
sujeetsr
Have you tried stuff like the masonry or shapeshift plugins for jquery?

~~~
TuringTest
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.

------
jplur
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?

------
maqr
> 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.

------
tzury
Trello (trello.com) is entirely "Cardesign"

------
BaconJuice
What a bs post. The writer observed some sites using a specific pattern and
now somehow "it's the future of the web" Please.

------
unono
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.

------
caniscrator
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.

------
dreamfactory
So is there a specification for the card? Is it a possibly multi-dimensional
data structure or does it also have behaviors?

------
cbsmith
Wow. So Cards is the new goodness that is totally unlike every other touch
screen interface ever developed...

------
electic
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...

------
skunkednoH2O2
[http://insideintercom.io/why-cards-are-the-future-of-the-
web...](http://insideintercom.io/why-cards-are-the-future-of-the-web/)

------
aridiculous
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.

------
pekk
Designs where information is haphazardly tiled on the screen without
organization or any coherent visual flow are hopefully not the future of the
web.

------
samstave
We called these content/context boxes in 2007

~~~
officemonkey
We called this "HyperCard" in 1987.

~~~
dredwerker
They called this the punch card in the 1960s - have I gone too far :)

~~~
TheZenPsycho
we called them McBee cards in 1907 [http://en.wikipedia.org/wiki/Edge-
notched_card](http://en.wikipedia.org/wiki/Edge-notched_card)

~~~
TuringTest
We called them Papyrus rolls back in Ancient Egypt.

(Cue the stone tablet markers in three, two...)

------
gorm
It's just encapsulation of content, sort of similar to the old 2004 apple
widgets that you could flip around.

------
steele
Web 3.0 is going to be portlets? Let the games begin... again!

------
talles
Incredible how nobody remembered Windows 8...

------
spullara
My Yahoo.

------
rfnslyr
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.

~~~
kevindmorgan
[http://bergcloud.com/littleprinter/](http://bergcloud.com/littleprinter/)

~~~
swah
Also
[https://www.adafruit.com/products/717](https://www.adafruit.com/products/717)

------
a3voices
We wanted flying cars. Instead we got cards.

