Responsive Text(frankieroberto.com)
frankieroberto.com
Responsive Text
http://www.frankieroberto.com/responsive_text
62 comments
While I think that is one response to this, you seem to be diminishing the importance that extra cruft has upon the effective message conveyed. Simpler is more economic, but it also eliminates those ephemeral things communicated implicitly. A TLDR is certainly an adequate substitute for those not interested enough, but an abbreviation can never capture the full expressive thought contained in a larger, well written text.
Effective visual communication, whether it be anything from body of text to an icon, is not necessarily contingent upon its complexity.
Effective visual communication, whether it be anything from body of text to an icon, is not necessarily contingent upon its complexity.
This is why including a summary prefacing long-form writing is such a good idea in general.
I suppose, depending upon your aim.
(And by long-form, I assume you are talking about an article or something rather than a book.) If you aren't concerned with people actually reading your text then yes, thats probably a good idea. But prefacing in this manner generally tends to disuade meaningful consumption, "why read in 4 pages what was summed up in 4 sentences", a reader might think. I think prefacing could arguably contribute to effective communication, but it stifles engagement significantly.
Just my 2 cents...
(And by long-form, I assume you are talking about an article or something rather than a book.) If you aren't concerned with people actually reading your text then yes, thats probably a good idea. But prefacing in this manner generally tends to disuade meaningful consumption, "why read in 4 pages what was summed up in 4 sentences", a reader might think. I think prefacing could arguably contribute to effective communication, but it stifles engagement significantly.
Just my 2 cents...
A good implementation I've seen of something like this is a responsive version of data tables. Essentially, the data in the table is prioritized, and shown or hidden based on the available real-estate, along with the ability to override the defaults.
Demo available here: http://filamentgroup.com/examples/rwd-table-patterns/
Demo available here: http://filamentgroup.com/examples/rwd-table-patterns/
I think this is a much better use-case for this kind of idea. I especially like that even if I shrink down my browser, I can still re-show the content that got hidden using the dropdown at top-right.
Maybe people's concerns about not seeing the full content could be alleviated by a similar solution for re-showing the text that got hidden in the OP's example?
Maybe people's concerns about not seeing the full content could be alleviated by a similar solution for re-showing the text that got hidden in the OP's example?
Kudos. A similar idea I had but never implemented (no doubt I'm not the only one), that would show/hide text based on user knowledge rather than screen size:
P.S. I'm sure my variation of the idea was anticipated by the creators of CSS.
Mar. 21, 2010
-------------
Sometimes when writing a blog post, article, or other composition that will be
read by more than one class of audience, one audience can become bored or upset
by content that is needed to bring another audience up to speed. For example, a
blog written by a highly technical person both to educate other technical people
and to keep less-technical family members in the loop may include lots of
simplified definitions of technical terms that most technical people already
know. To prevent alienation of the technical group while still preserving the
definitions and explanations for non-technical readers, definitions could be
surrounded by a span or div of class "nontech_definition". A simple script,
client-side custom stylesheet, or alternate stylesheet could then allow
technical readers to set those definitions to visibilty:hidden or even
display:none, and continue on their way uninterrupted by repetitive and
unnecessary (for them) clarifications. To alert the technical readers of this
possibility, a note or link could be provided by the first definition on each
page (or last, or as a footnote or tooltip, etc.) explaining how to hide the
definitions.
P.S. I'm sure my variation of the idea was anticipated by the creators of CSS.
Here's a much better idea for responsive text: put a bare bones summary at the top, then expand the points below. This is useful for people on mobiles.
It's also useful for people with disabilities - blind people apparently like summaries and links, because otherwise it's hard for them to scan.
It also helps people who just aren't great at reading (or reading English), which is a huge deal these days. Almost half the web is below average intelligence now, and over half the web doesn't speak English natively. And everyone is busy.
It's also useful for people with disabilities - blind people apparently like summaries and links, because otherwise it's hard for them to scan.
It also helps people who just aren't great at reading (or reading English), which is a huge deal these days. Almost half the web is below average intelligence now, and over half the web doesn't speak English natively. And everyone is busy.
This only makes sense to me in a progressive loading situation. That is, you load the summaries first, then load additional detail later in the rendering timeline. Fine; I'd get that.
But I don't like the idea of not getting the full story every time. Why not think a couple years out and assume everyone's connection is fast enough to handle text - LOTS of text - even over a mobile connection. It's text. Like one-or-two-bytes-per-character stuff.
I suppose it's also interesting as a navigational scheme. To show summaries automatically and expand on some user action, a la clear (http://www.realmacsoftware.com/clear/).
But I don't like the idea of not getting the full story every time. Why not think a couple years out and assume everyone's connection is fast enough to handle text - LOTS of text - even over a mobile connection. It's text. Like one-or-two-bytes-per-character stuff.
I suppose it's also interesting as a navigational scheme. To show summaries automatically and expand on some user action, a la clear (http://www.realmacsoftware.com/clear/).
The problem with wanting to get the full story every time is that you look something up on Wikipedia and you end up reading the entire site.
A simple, standards-based way to implement this would be to use the HTML5 details and summary elements.
http://html5doctor.com/the-details-and-summary-elements/
You could make default the details to be "open" for big screens and closed, showing the summary only, for small ones. Downside is that you only get two levels if you stick to the spirit and letter of the standard.
http://html5doctor.com/the-details-and-summary-elements/
You could make default the details to be "open" for big screens and closed, showing the summary only, for small ones. Downside is that you only get two levels if you stick to the spirit and letter of the standard.
This is essentially the output phase of something I'm working on for my PhD. I've written a tool that can read salience-tagged CSV input and output a page of responsive text:
http://stephenwattam.com/projects/responsivetext/
The example's a bit crummy, but with some better input it should provide a useful base for visualising important text features.
http://stephenwattam.com/projects/responsivetext/
The example's a bit crummy, but with some better input it should provide a useful base for visualising important text features.
My problem with those responsive web sites is that they only react to changes of the browser window width, but not the height.
For example, on this page, you can change the width so that we only see 3 short sentences. But if you change your browser height from 800x800 to 800x350, you still get the full, long text, but it's cut off in the middle, and there is a scroll bar. If the author's intent was to try hard to show those 3 short sentences without readers needing to scroll, then it fails here.
Responsive websites should be thinking "ok, I've got this amount of space here, let's fill it in the best way possible", not "ok let's make 3 designs based on browser width".
For example, on this page, you can change the width so that we only see 3 short sentences. But if you change your browser height from 800x800 to 800x350, you still get the full, long text, but it's cut off in the middle, and there is a scroll bar. If the author's intent was to try hard to show those 3 short sentences without readers needing to scroll, then it fails here.
Responsive websites should be thinking "ok, I've got this amount of space here, let's fill it in the best way possible", not "ok let's make 3 designs based on browser width".
Absolutely. Responsive design is simply shifting two-column into one-column and getting away with it. That's not always a preferred way, I'd say.
http://news.ycombinator.com/item?id=3597932
http://news.ycombinator.com/item?id=3597932
I like this technique, and I think it would be appropriate to extend it other hierarchical types of data besides just text. For example, a product page might show a list of reviews, with each shown as x/5 stars, and zooming in on the reviews would show the review text. Same with product info - zoomed out = overview, zoomed in: more details appear. This would require zooming in on a specific section of a page though, not just making the entire page bigger. Imagine browsing an online store or search results by zooming in/out using a touch interface, rather than clicking on links to details/reviews/photos
Hiding text elements on simple, informational sites can work. On mobile devices, the performance hit of loading additional elements is compounded because of the slower connection.
The general rule of thumb is if you have a complicated application, consider building a mobile optimized (*not responsive) site or a native application (even better if you have time & money). If you have a simple informational site, I think hiding elements can work though you have to question if you needed the extra copy in the first place.
The general rule of thumb is if you have a complicated application, consider building a mobile optimized (*not responsive) site or a native application (even better if you have time & money). If you have a simple informational site, I think hiding elements can work though you have to question if you needed the extra copy in the first place.
This could be automated by using text summarizing algorithms which pull out key sentences. Then, when you come across a long article, just shrink the screen to summarize.
OS X has a text summarizer, which my brother used to great effect in grad school. Most of his readings were digital, and he just ran them all through the summarizer. He had no trouble participating in class discussions, though occasionally a professor would look at him oddly and say "Well, that wasn't really the main point."
OS X has a text summarizer, which my brother used to great effect in grad school. Most of his readings were digital, and he just ran them all through the summarizer. He had no trouble participating in class discussions, though occasionally a professor would look at him oddly and say "Well, that wasn't really the main point."
The author is a clever and talented guy, but this is terrible idea. I sincerely thank the author for expanding the way I think about content and presentation.
I could see this as a useful tool to create "skim" and "full text" versions of content, especially reference material.
Interesting approach, ultimately though we'll want to optimize for physical device size and distance between user & device :)
I guess this will get easier once almost every display uses the ppi of the iPhone 4.
I guess this will get easier once almost every display uses the ppi of the iPhone 4.
The Boston Globe's home page (http://bostonglobe.com/) does something similar with columns.
I would hate to have to resize my window every time I want to read a more concise version of an article. Still, looks like a fun exercise.
Ugh, this strikes me as a terrible idea.
If it's not important enough to show on mobile it can probably be removed on the desktop too.
If it's not important enough to show on mobile it can probably be removed on the desktop too.
[deleted]
It's like the OS X Summarize service, but on a webpage :)
Has anyone actually ever used this service to any productive end? I never saw the appeal (and don't understand how it got there in the first place), but maybe it's extremely useful to some niche category of users.
Somehow, I feel that even responsive web-design is a half-ass solution to scaling a web-app from a mobile/hand-held to a LCD screen.
For example, right now I am watching your Responsive Text page on an 1920 x 1080 (49" LCD panel) and the text did not scale to a level to which it could. Besides it's not just about font-size or image scaling. It's about managing the size of each pixel too, so that things remain in proportion.
I know this is a hard problem, and there has been no acceptable/worthy answer to this question on SOF either: http://stackoverflow.com/questions/8421533/how-to-obtain-ctr...
For example, right now I am watching your Responsive Text page on an 1920 x 1080 (49" LCD panel) and the text did not scale to a level to which it could. Besides it's not just about font-size or image scaling. It's about managing the size of each pixel too, so that things remain in proportion.
I know this is a hard problem, and there has been no acceptable/worthy answer to this question on SOF either: http://stackoverflow.com/questions/8421533/how-to-obtain-ctr...
I love the idea, but I suspect that most people writing the sorts of content that could benefit from this wouldn't take the time to break down their work in a way that would take advantage of the layout.
I agree, but I think this format could work well in certain situations where it can be done automatically, like for comments with karma. You could vary the threshold for hidden comments, so mobile users see less but overall higher quality comments (with a link to show hidden ones), and desktop users see all by default.
Are you talking about (a) completely hiding low-karma posts, or (b) "minimizing" the text of those low-karma posts in a way similar to how the example works?
If it's (a), that's basically what sites like Slashdot and Reddit already do for desktop users.
If it's (b), the obvious question is how you algorithmically filter text to only include the pertinent information (the given example is almost certainly hard-coded), which doesn't sound like a simple question to answer.
If it's (a), that's basically what sites like Slashdot and Reddit already do for desktop users.
If it's (b), the obvious question is how you algorithmically filter text to only include the pertinent information (the given example is almost certainly hard-coded), which doesn't sound like a simple question to answer.
Maybe you could put unpopular posts in shades of grey? Or smaller fonts?
Excellent idea. I like the idea of different content (rather than only different design) for mobile devices - only show what is absolutely necessary. I also really like that this is done with CSS; much cleaner than a mobile-only site, though you aren't saving any bandwidth here (it's just text, though). Anyway, nice experiment.
This reminds moe of Joe Davis' Telescopic Text: http://www.telescopictext.com/. Assuming you see this on a desktop computer, it's exactly the opposite of Frankie's responsive text: instead of gradually reducing the amount of information, it gradually increases it.
That's really clever. I would like to read news articles written like this: you just click on the parts you want elaborate on.
Not only would it be more convenient for you, to focus on bits of the story you're actually interested in, the newspaper could collect analytics on what parts of the story you're interested in, and suggest further articles, and highly-targeted ads, based on that.
Imagine you see an article about Christopher Hitchens accusing Henry Kissinger of war crimes, and Kissinger is wearing a smart suit, and you dive in to find out more about his couturier. The click-through rates on high-end clothing ads would be vastly more.
Though, to take the opposite tack: would this encourage newspapers to turn into something like mesothelioma blogspam? Writing about something, only because the ads associated with it are profitable, instead of because it's a Fact Worth Knowing?
Imagine you see an article about Christopher Hitchens accusing Henry Kissinger of war crimes, and Kissinger is wearing a smart suit, and you dive in to find out more about his couturier. The click-through rates on high-end clothing ads would be vastly more.
Though, to take the opposite tack: would this encourage newspapers to turn into something like mesothelioma blogspam? Writing about something, only because the ads associated with it are profitable, instead of because it's a Fact Worth Knowing?
It might also be a really bad idea because you constantly force people to make conscious decisions about which parts they want you to elaborate.
Brilliant!
Are you using the Summly API to condense the text?
Could be a good solution to @kyle's comment.
Are you using the Summly API to condense the text?
Could be a good solution to @kyle's comment.
We do something similar to this on Lanyrd - try shrinking the browser window on http://sxsw.lanyrd.com/ for example. The labels on the tabs change from "your sessions, your contacts' sessions, all sessions (1114), attendees (2594)" at the widest setting to "you, contacts, all, attendees" on narrower screens.
It's implemented by wrapping a span with a class of "not-narrow-friendly" around the words that should be hidden at narrow widths, then using media queries to hide them.
It's implemented by wrapping a span with a class of "not-narrow-friendly" around the words that should be hidden at narrow widths, then using media queries to hide them.
I like how you also did that with the dates (e.g. "Friday" goes to "Fri")
Unsolicited feedback: At the narrower widths, the sidebar (.secondary) would be better off falling after the main content (.primary) It might also work having "Filter by topic" turned into a drop down.
Unsolicited feedback: At the narrower widths, the sidebar (.secondary) would be better off falling after the main content (.primary) It might also work having "Filter by topic" turned into a drop down.
How would you handle internationalisation with that approach?
Not something we're worrying about for the moment - the advice we got from people who had done it was "don't do it until you have a much larger team".
Presumably by telling non-English speakers to go piss up a rope.
After a significant amount of window-resizing this ended up throwing webkit into an infinite loop. Impressive.
I may have a problem with OCD, but I would hate the idea that some content is hidden to me just because I'm browsing with the wrong screen/window size.
Hiding redundant elements, navigational bars, maybe images, etc... is fine, but I'm definitely not comfortable with the idea of hiding content based on context.
Hiding redundant elements, navigational bars, maybe images, etc... is fine, but I'm definitely not comfortable with the idea of hiding content based on context.
I'm totally ok with it but I'd probably like a [+] expansion widget or ellipsis mark to indicate hidden content in those contexts.
Yes, I agree. This is a cool idea, but I think I would go crazy if this got any traction. I can see myself now constantly resizing my browser to see if I was missing any content.
Yeah, it's a very interesting idea, but I don't want half the article if I'm browsing on a mobile device.
Besides, I thought the point of responsiveness was to REARRANGE data, not completely eliminate it. styling, yeah, go ahead and get rid of elements and color bars and what have you, shrink pictures, but please don't throw away words!
Besides, I thought the point of responsiveness was to REARRANGE data, not completely eliminate it. styling, yeah, go ahead and get rid of elements and color bars and what have you, shrink pictures, but please don't throw away words!
This was indeed the idea of the W3C when they wrote this. The page he links to even says that:
http://www.w3.org/TR/css3-mediaqueries/ "Among the media features that can be used in media queries are ‘width’, ‘height’, and ‘color’. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself."
The part "without changing the content itself" is pretty clearly not what he is doing here. Like dozens of others have said, just an interesting idea but not something that should be used like this in practice.
http://www.w3.org/TR/css3-mediaqueries/ "Among the media features that can be used in media queries are ‘width’, ‘height’, and ‘color’. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself."
The part "without changing the content itself" is pretty clearly not what he is doing here. Like dozens of others have said, just an interesting idea but not something that should be used like this in practice.
I don't imagine this would be applied to news articles or blog posts. I could see this applied to, say, instructions or travel directions...
"Mobile" web site views drive me up the walls for very similar reasons.
It should be something that's orthogonal to screen size. Maybe have a slider somewhere on the page that allows you to zoom in and out of the content.
I had been using very similar technique in my blog (http://laktek.com), for excerpts and posts lists.
Actually, I believe all contents in a site should have a ranking and loaded depending on the context.
Actually, I believe all contents in a site should have a ranking and loaded depending on the context.
In the end, we'll have so much extra markup and scripts to execute that the users get annoyed by slow downloads and choppy performance, instead of having to zoom interfaces :)
A useful tool for examining responsive content across multiple displays, such as is demonstrated by this post, is http://www.benjaminkeen.com/misc/bricss/. It's a javascript bookmarklet that'll dynamically create multiple iframes, each set to the dimensions of popular device screens, and display them all on a single desktop browser window.
Great for side-by-side comparison and validation of media queries.
Great for side-by-side comparison and validation of media queries.
Excellent idea. Especially in regard to shortening the titles on navigation elements, buttons, and links. Longer, more descriptive labels when screen real-estate allows. Shorter, perhaps more cryptic but made-to-fit, labels when screen real estate is limited.
There are situations in which I might want less textual detail, but they are never indicated by browser window size. Indeed, my iPhone, which has the smallest "window size", provides an excellent experience for reading large amounts of text (especially due to the Retina Display).
One problem is that you’re delivering all the content to the mobile device anyway.
Isn't this a problem with responsive design as a whole any way?
Tighter writing is clearer, and thus easier to read. If you can trim, you should be doing it anyway; leaving the extra amounts to cruft in most cases.