Show HN: A UI That Lets Readers Control How Much Information They See(kayce.basqu.es)
kayce.basqu.es
Show HN: A UI That Lets Readers Control How Much Information They See
https://kayce.basqu.es/blog/information-control
68 comments
Thanks, I'll add to the "prior work" section.
Mercury Reader (formerly readability) https://mercury.postlight.com/reader/ and Slashdot both belong as prior art. Slashdot has had the ability to change length of comments for a long time.
Thanks. Added.
Journalism already has a mechanism for this. In a news story (as opposed to longer, narrative stories), the important news is up top, followed by background in order of importance.
The interface thus becomes: stop reading when it stops being new or interesting.
The interface thus becomes: stop reading when it stops being new or interesting.
Yes, the inverted pyramid can handle most cases in journalism.
The example that I provide in the post (a tutorial split between 2 audiences) is an example where this UI may be useful. Granted, even that is an edge case. I think there are different, more straightforward strategies for handling split-audience tutorials. This post was just an exploration into a UI that intrigued me.
The example that I provide in the post (a tutorial split between 2 audiences) is an example where this UI may be useful. Granted, even that is an edge case. I think there are different, more straightforward strategies for handling split-audience tutorials. This post was just an exploration into a UI that intrigued me.
I like that use case. I'm often bored by technical books where I know some of the material but don't have the patience to find the new material. Ebooks/articles that adapt to the reader's existing knowledge would be interesting. Either via a quiz up front or marking sections you already know as you go.
Basically a form of adaptive learning https://en.wikipedia.org/wiki/Adaptive_learning
Basically a form of adaptive learning https://en.wikipedia.org/wiki/Adaptive_learning
[deleted]
> Journalism already has a mechanism for this.
The most famous technique that is completely ignored by mainstream journalism. Name three popular news platforms that still apply it. I've seen one - I don't even remember which one, but it pops up on HN every now and then; it's characteristic for having a bullet-point TL;DR at the top.
The most famous technique that is completely ignored by mainstream journalism. Name three popular news platforms that still apply it. I've seen one - I don't even remember which one, but it pops up on HN every now and then; it's characteristic for having a bullet-point TL;DR at the top.
Firs link on th first news source I could think of: https://www.nytimes.com/2018/12/10/world/europe/uk-brexit-ec...
That article is textbook inverted pyramid.
That article is textbook inverted pyramid.
FT, Economist, WSJ, NY Times, The Times etc. Most newspaper I read follow that general format, often with a summary paragraph at the end.
I think this is more robustly solved by just collapsing headings and letting the user expand them if they want. See: Wikipedia on mobile. The issue with the author's approach is that you don't know what information you are gaining/losing by switching between modes, and the onus is on the author to decide what information is available at each tier. What's unnecessary trivia for one reader may not be for another.
This is the big issue that I've heard from quite a few people.
Seems like documentation has already been able to handle this for centuries, via table of contents, overviews, introductions, detail sections etc, and readers have handled that fine.
Instead of adding work to the authors, simply use the semantic markup...or even let the reader do so.
Instead of adding work to the authors, simply use the semantic markup...or even let the reader do so.
Definitely. In another section which I eventually scrapped (I'm the author) I argued that for most situations I think there are more straightforward ways to segment content for different audiences.
However, there are some edge cases where one page must serve multiple audiences. Such as a "get started" experience that you have invested a lot of time and money into and which is unfeasible to duplicate. Or news articles. But then again, the inverted pyramid seems like a pretty good solution for news articles...
However, there are some edge cases where one page must serve multiple audiences. Such as a "get started" experience that you have invested a lot of time and money into and which is unfeasible to duplicate. Or news articles. But then again, the inverted pyramid seems like a pretty good solution for news articles...
From the article:
> My initial impression is that the ROI does not justify the effort.
> It depends on how strongly users respond to the feature, because it'll create a noticeable amount of work for writers.
The author is probably correct about the ROI not justifying the effort, but I think UI design should also be considered as an input for whether users would respond to the feature. The UI as it stands is technically functional and easy to understand, but not exactly effortless or convenient to use. In particular, there's quite a jarring difference between the modes during switch, making comparison impossible.
An inline UI next to/within the content, with some logic to ensure the nearest content to the control stays at the same scroll-position during change would help a lot with this.
e.g. Expounder (linked in a sibling comment) looks to be a much nicer UI implementation from my quick glance at it.
> My initial impression is that the ROI does not justify the effort.
> It depends on how strongly users respond to the feature, because it'll create a noticeable amount of work for writers.
The author is probably correct about the ROI not justifying the effort, but I think UI design should also be considered as an input for whether users would respond to the feature. The UI as it stands is technically functional and easy to understand, but not exactly effortless or convenient to use. In particular, there's quite a jarring difference between the modes during switch, making comparison impossible.
An inline UI next to/within the content, with some logic to ensure the nearest content to the control stays at the same scroll-position during change would help a lot with this.
e.g. Expounder (linked in a sibling comment) looks to be a much nicer UI implementation from my quick glance at it.
> The UI as it stands is technically functional and easy to understand, but not exactly effortless or convenient to use. In particular, there's quite a jarring difference between the modes during switch, making comparison impossible.
Agreed about the jarringness. I actually had a section about how jarring it felt (I'm the author of the blog post) but scrapped it because I was spending too much time on the post :D
> An inline UI next to/within the content, with some logic to ensure the nearest content to the control stays at the same scroll-position during change would help a lot with this.
Cool ideas. I initially wrote off the UI idea as low ROI (as you can see in the post) but maybe my opinion would change if I saw someone really nail this feature. Also, the low ROI comment only applies if we have to manually markup the content. If we can automate that side of it, then that changes the ROI equation.
Agreed about the jarringness. I actually had a section about how jarring it felt (I'm the author of the blog post) but scrapped it because I was spending too much time on the post :D
> An inline UI next to/within the content, with some logic to ensure the nearest content to the control stays at the same scroll-position during change would help a lot with this.
Cool ideas. I initially wrote off the UI idea as low ROI (as you can see in the post) but maybe my opinion would change if I saw someone really nail this feature. Also, the low ROI comment only applies if we have to manually markup the content. If we can automate that side of it, then that changes the ROI equation.
erm, commenting on the ROI bit, but in Journalism AFAIK (or at least writing articles and so on) there are concepts of how a title/ sub-heading / article should be written to give the maximum amount of info based on its "part" (if i make myself clear in that a title/sub-heading/article is a part of an article).
in that sense, writing with this in mind makes the ROI pretty obvious, since it's being written already in the first place.
in that sense, writing with this in mind makes the ROI pretty obvious, since it's being written already in the first place.
Thanks for the input. Any links? I'd like to learn more about these strategies.
This seems similar to Expounder, one of my projects: https://skorokithakis.github.io/expounder/
I like the idea of Parametric Press (given that I made something similar), but I prefer the granularity of Expounder.
I like the idea of Parametric Press (given that I made something similar), but I prefer the granularity of Expounder.
Cool! I'll update the "Prior work" section.
Just FYI, might be interested in Ted Nelson's old idea of StretchText. It was never really implemented, to the best of my knowledge.
https://en.wikipedia.org/wiki/StretchText
https://en.wikipedia.org/wiki/StretchText
Thanks. I'll update the "prior work" section.
Can there be a UI that lets readers agree/desagree on Cookies once and forever so that the popup is not shown again, and to block 'please disable adblock' popups? An, also, firmly let the website know that the user wants to stay in the mobile browser and doesn't wish to download another app just to read a 1000 words article?
I recently seen a trial of this concept on the BBC News website, where you could choose between in-depth and summarised, simplified coverage of various aspects of the story. It was at the section level, so you could read a detailed account of one part of the story but a summarised version of another.
I can't find a link to the story, but it was within the last couple of months.
In my case, I actually flipped between both versions to see the different ways it was covered.
I can't find a link to the story, but it was within the last couple of months.
In my case, I actually flipped between both versions to see the different ways it was covered.
Axios also puts this to great use with a "go deeper" button. It's very helpful for deciding how much of each story to consume.
Screenshot: https://i.postimg.cc/SKkKc85H/Screen-Shot-2018-12-10-at-11-5...
Site: https://www.axios.com/technology
Screenshot: https://i.postimg.cc/SKkKc85H/Screen-Shot-2018-12-10-at-11-5...
Site: https://www.axios.com/technology
Thanks, I'll add to the "prior work" section.
On one hand, forcing users to click a button to see content is kind-of user-hostile, IMO. It's appropriate for a homepage, though. I don't like it when a homepage shows the full content of each post because it forces me to do a lot of scrolling if I'm not interested in a post. So my first impression is that Axios is doing it well and thoughtfully.
But on the other hand, the interaction enables me to track what percentage of users actually care about the content, which is really useful data to me as a documentation author. I'm not saying we should do it --- I'm firmly on the "put the user first" side of the debate --- but I just wanted to point out that the current state of documentation is kind of a dark age. We have no idea what our readers actually care about.
On one hand, forcing users to click a button to see content is kind-of user-hostile, IMO. It's appropriate for a homepage, though. I don't like it when a homepage shows the full content of each post because it forces me to do a lot of scrolling if I'm not interested in a post. So my first impression is that Axios is doing it well and thoughtfully.
But on the other hand, the interaction enables me to track what percentage of users actually care about the content, which is really useful data to me as a documentation author. I'm not saying we should do it --- I'm firmly on the "put the user first" side of the debate --- but I just wanted to point out that the current state of documentation is kind of a dark age. We have no idea what our readers actually care about.
I agree that "show more" is not the right form of interaction for a documentation page. Have you considered measuring engagement in other ways (tracking search results, link clicks, anchor clicks, short "is this page helpful" inline surveys, etc.)?
I'm doing a big investigation at the moment to find out if "was this page helpful?" meaningfully correlates to quality.
I do track the other interactions you mentioned, but it's difficult to map them to actionable ways to improve quality. And then even if we do make them actionable, it's hard to prove that they have actually improved quality. I'm just starting out a rigorous study of this field, though, and am hopeful that we can make advances.
I do track the other interactions you mentioned, but it's difficult to map them to actionable ways to improve quality. And then even if we do make them actionable, it's hard to prove that they have actually improved quality. I'm just starting out a rigorous study of this field, though, and am hopeful that we can make advances.
Here [1] is essentially the same idea and the Hacker News discussion (115 comments) [2] of it.
[1] http://getcoleman.com
[2] https://news.ycombinator.com/item?id=14013996
[1] http://getcoleman.com
[2] https://news.ycombinator.com/item?id=14013996
Thanks. I'll update the "prior work" section.
I really like this in concept.
There's times when I hit a site and I'm just there to do one of maybe three common things, but it's sort of "hidden" in a jumbled site.
Granted this is all about data on screen but I would think you could extend it to common actions or such.
Maybe you'd also learn that all your users really just use or want a simple view rather than a more complex site?
There's times when I hit a site and I'm just there to do one of maybe three common things, but it's sort of "hidden" in a jumbled site.
Granted this is all about data on screen but I would think you could extend it to common actions or such.
Maybe you'd also learn that all your users really just use or want a simple view rather than a more complex site?
I've seen a network configuration tool that had a drop down in the application header where you could choose between "Simple", "Advanced" and "Expert"; each presented largely different user interfaces, which were actually quite good. E.g. with "Simple" there simply was a list of Wi-Fi networks and a wizard for creating new ones or changing them with basically three options: SSID, password and whether it's a guest network. It didn't let you choose what encryption or channel to use, because "simple users" don't care about that. On "Expert" on the other hand already the listing had many more columns (channel, connected clients etc.) and the configuration pages gave you full acess to basically everything down to beacon intervals and stuff like that. Instead of checking a box labelled "guest network" you could add arbitrary iptables-rules etc.
Yeah I used to be a network engineer and there were a number of tools that to some extent offered an advanced and simple view.
They were usually pretty terrible about picking what went where (I suppose that's the real trick) but the idea was always a good one.
They were usually pretty terrible about picking what went where (I suppose that's the real trick) but the idea was always a good one.
> They were usually pretty terrible about picking what went where
Therein lies the rub
Therein lies the rub
It's a good idea, and has its place. However, you can run into issues where less skilled users will choose the more advanced path because they overestimate their ability.
This was common in OSX control panels
[deleted]
A link to this tool would be much appreciated!
I explored a similar idea after college as a way to improve textbooks. I haven't done any maintenance in years, but the demo is still online: https://www.okeebo.com/demo/
I found that it was a lot of extra work for authors and they weren't interested.
I found that it was a lot of extra work for authors and they weren't interested.
When the light/dark slider is all the way to the dark side, the controls themselves become very difficult to see. Also, it's interesting that the point on the slider where the text and background color match is not in the middle — it's significantly to the left. Anyone have an idea of why this is the case?
Even if this is a good idea, it seems like a slider is the wrong way to control it.
You really only have a few discrete levels, and as a reader you probably always want to be able to tell which level you're at. So maybe some radiobutton like UI that's anchored to the window.
You really only have a few discrete levels, and as a reader you probably always want to be able to tell which level you're at. So maybe some radiobutton like UI that's anchored to the window.
Yeah, I said exactly the same thing to myself in a section of this post that didn't make the final cut (I'm the author). I definitely agree that, if you put this in your UI, you'd have to create a sticky control pane that reminds the reader what mode they're in, and lets them bail out at any time. When a reader does bail, they should be looking at the same content as before. It shouldn't jump them to some other section.
Seems like a good idea, but I find it hard to correlate between low-detail and high-detail versions.
yeah, I thought this was going to be like, if I click on a paragraph, it expands into several paragraphs worth of detail.
Interesting approach!
Reminds me of http://www.telescopictext.com/ , where instead of a single slide users can click on sections that they want more details on. I used the concept myself a few years ago to create my Pathfinder character sheet (https://boppreh.com/chomsky/).
Didn't feel very useful, but it was a fun experiment and allows for some clever plays like looping "expansions", and hiding punchlines to jokes behind a click.
Didn't feel very useful, but it was a fun experiment and allows for some clever plays like looping "expansions", and hiding punchlines to jokes behind a click.
Unintuitive and not very useful tbh. Seems like something that would be good at first glance, but a really bad idea once you dig into it.
-----
I would like to see some suggestions on the semantics of different levels of content detail. Because different authors could organize their articles in different ways such that it would be hard to navigate the information since there's no standard for what to expect.
Which leads to another issue which is that it doesn't really remove the hidden detail from the user's focus. There's no way to know which level of detail is correct for them. If you read and article and think "this doesn't make sense, there should be some more information" then you'd have to scroll through multiple levels (plus or minus one level) to make sure that it's the level of detail you're on and not the article that omitted that information.
And moving in between levels isn't easy either. It's not just certain sections, individual paragraphs seem to change from level to level. Which means that if you read a tldr view and you want more information, there's no way to gracefully add the new detail. You essentially have an entirely new article.
Perhaps the biggest issue is that I am not sure such a feature even if it was ironed out would be useful. I think readership detail is usually binary. Either someone wants a coarse overview, or they want the full story. I know that there are obviously exceptions like where there's a lot of fluff to a story and you wish they'd cut it out but that's typically the purpose of those articles. They're meant to be read that way. We already have things like table of contents and certain standards in writing that make navigating the details of an article pretty fast already without adding some kind of complicated ui into the mix.
I am not even sure that an author would want to put in all this effort and write an article in such a way. Writing is usually very purposeful and thinking about how to write something that makes sense at multiple levels of detail seems like it would be really troublesome.
As a side note, the background color option on their test example should not be a continuous range. The halfway value makes everything grey.
-----
I would like to see some suggestions on the semantics of different levels of content detail. Because different authors could organize their articles in different ways such that it would be hard to navigate the information since there's no standard for what to expect.
Which leads to another issue which is that it doesn't really remove the hidden detail from the user's focus. There's no way to know which level of detail is correct for them. If you read and article and think "this doesn't make sense, there should be some more information" then you'd have to scroll through multiple levels (plus or minus one level) to make sure that it's the level of detail you're on and not the article that omitted that information.
And moving in between levels isn't easy either. It's not just certain sections, individual paragraphs seem to change from level to level. Which means that if you read a tldr view and you want more information, there's no way to gracefully add the new detail. You essentially have an entirely new article.
Perhaps the biggest issue is that I am not sure such a feature even if it was ironed out would be useful. I think readership detail is usually binary. Either someone wants a coarse overview, or they want the full story. I know that there are obviously exceptions like where there's a lot of fluff to a story and you wish they'd cut it out but that's typically the purpose of those articles. They're meant to be read that way. We already have things like table of contents and certain standards in writing that make navigating the details of an article pretty fast already without adding some kind of complicated ui into the mix.
I am not even sure that an author would want to put in all this effort and write an article in such a way. Writing is usually very purposeful and thinking about how to write something that makes sense at multiple levels of detail seems like it would be really troublesome.
As a side note, the background color option on their test example should not be a continuous range. The halfway value makes everything grey.
> I would like to see some suggestions on the semantics of different levels of content detail.
My colleague had the same response. He phrased it like this: "I always end up reading the whole article anyways because I don't trust what the author considers to be high importance and low importance."
> And moving in between levels isn't easy either. It's not just certain sections, individual paragraphs seem to change from level to level.
I'm assuming that you mean Parametric Press's implementation. In my blog post (I'm the author) I instinctively marked up sections as high-priority or low-priority. But I hadn't thought about this until you pointed it out. Inevitably, some authors would markup a section as high-priority, but put low-priority paragraphs within the section. So paragraphs would disappear from the section, as you said.
> I am not even sure that an author would want to put in all this effort and write an article in such a way.
Yes. Speaking from the experience of creating this prototype, it sucked to author this. That's why I said that users would have to positively respond strongly to this feature in order to make it worthwhile. Otherwise writers simply won't have the motivation to do it.
My colleague had the same response. He phrased it like this: "I always end up reading the whole article anyways because I don't trust what the author considers to be high importance and low importance."
> And moving in between levels isn't easy either. It's not just certain sections, individual paragraphs seem to change from level to level.
I'm assuming that you mean Parametric Press's implementation. In my blog post (I'm the author) I instinctively marked up sections as high-priority or low-priority. But I hadn't thought about this until you pointed it out. Inevitably, some authors would markup a section as high-priority, but put low-priority paragraphs within the section. So paragraphs would disappear from the section, as you said.
> I am not even sure that an author would want to put in all this effort and write an article in such a way.
Yes. Speaking from the experience of creating this prototype, it sucked to author this. That's why I said that users would have to positively respond strongly to this feature in order to make it worthwhile. Otherwise writers simply won't have the motivation to do it.
Thanks for making this and for all the great pointers here. I have been taking notes for years to build something like this. I had come across a zooming UI concept from Microsoft which dealt with a similar idea (don't remember the details) back in 2012. I hadn't followed up with this after that.
Regarding the significant effort for writers I have been exploring a few options as that felt like the biggest drawback for this to catch on. I think we will soon figure out ways to make it less painful which will make it totally worth it
Regarding the significant effort for writers I have been exploring a few options as that felt like the biggest drawback for this to catch on. I think we will soon figure out ways to make it less painful which will make it totally worth it
> Thanks for making this and for all the great pointers here.
My pleasure. Thank you for reading.
In the "updates to the prior work" section I have now linked to an HCI thesis that automates the process of flagging important content. That would be one way to reduce the workload for writers.
The other approach is to just simplify the process of marking up content. If you write the markup yourself in markdown or HTML (or whatever), like I do, I think it may always be a bit of a hassle. Maybe a code editor plugin could help here. But if you author in a GUI environment, flagging the priority of content might be a bit less of a hassle.
My pleasure. Thank you for reading.
In the "updates to the prior work" section I have now linked to an HCI thesis that automates the process of flagging important content. That would be one way to reduce the workload for writers.
The other approach is to just simplify the process of marking up content. If you write the markup yourself in markdown or HTML (or whatever), like I do, I think it may always be a bit of a hassle. Maybe a code editor plugin could help here. But if you author in a GUI environment, flagging the priority of content might be a bit less of a hassle.
Make simple the default mode, and have inline "read more" style expandos. This isn't a new design but it is a good design.
As I mention in the post, you have to be careful about the logic that handles hiding information. If you use `display:none`, that content becomes inaccessible to screen readers.
[deleted]
I've wanted to see something like this for a long time. IMHO the missing pieces are...
1. the ability to identify which components of a summary you would prefer to see expanded.
2. for expansions to be more clearly highlighted
1. the ability to identify which components of a summary you would prefer to see expanded.
2. for expansions to be more clearly highlighted
At first glance, I thought this was an UI proposal for automatic summarization before I read the full post. Once summarization is more mature and reliable, something like this would be cool.
What is the state of automatic summarization, by the way?
This is a good overview: https://blog.fastforwardlabs.com/2018/05/02/progress-in-text...
I worked for a company where we gave you two modes to view things (a A/V version with bullet points, and a text transcript version). Its cool in concept. BUT, once you get into this you're doubling the amount of work as an author for very little gain (unless the modes are "instruction-ally purposeful" in some way). In addition, if you do any multi-lingual work (we did), you've doubled your translation cost per language as well.
Its also hard to validate the perspectives of your users. One TLDR user isn't the same as another - one wants 2-3 paragraphs another wants three bullets. You can put in that work here, but... its work. And you're not guaranteeing anyone ever sees the bulk of your long-form to which you probably want them to see to make a lasting connection and because you put the effort in to generate.
Its also hard to validate the perspectives of your users. One TLDR user isn't the same as another - one wants 2-3 paragraphs another wants three bullets. You can put in that work here, but... its work. And you're not guaranteeing anyone ever sees the bulk of your long-form to which you probably want them to see to make a lasting connection and because you put the effort in to generate.
Yeah, to improve the ROI we need to either make this extremely useful for users, or lower the cost for authors by automating the process or by making it really easy to markup content.
After the new media query 'prefers-color-scheme: dark' has landed, we now need 'prefers-content: tldr' as well.
Where I work there spending a lot of effort in nlp tools to summarise documents of all sorts.
I like this idea.
I like this idea.
In yet another section that I ultimately scrapped, I suggested that this might be an effective way to automate the process of summarizing documents. The usual approach is to manually create a section that summarizes the document. Which can eventually become out-of-sync with the actual content. This approach would ensure that the summary is always in-sync with the actual content.
I really appreciate the spirit of this idea. Humanizing information is essential for learning and idea sharing.
I think the academic community could benefit greatly from this concept. Formal academic papers are confusing, but not without reason...they are standalone essays or dissertations that seek to persuade readers of a thesis based on all the evidence that an author can squeeze into a single publication. While it is understandable that these documents are long and complex, it makes it all the more difficult for less-specialized readers to consume and leverage this valuable, innovative information.
I would love to have a tool like this in the top corner of a digital academic library. Maybe instead of tldr <-> detail, a bar like this: layman <-> expert.
I think the academic community could benefit greatly from this concept. Formal academic papers are confusing, but not without reason...they are standalone essays or dissertations that seek to persuade readers of a thesis based on all the evidence that an author can squeeze into a single publication. While it is understandable that these documents are long and complex, it makes it all the more difficult for less-specialized readers to consume and leverage this valuable, innovative information.
I would love to have a tool like this in the top corner of a digital academic library. Maybe instead of tldr <-> detail, a bar like this: layman <-> expert.
Nice idea of TLDR vs Detailed view, however to manually re-write the content suitable for the interface is too much effort. This would be useful in my opinion if AI summarizes and creates a TLDR for you. Perhaps that could be a useful browser plugin.
Also: we started a wysywyg editor to make these 'nesting docs' here: http://symbolflux.com/nestingdocs/