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!
Show HN: A UI That Lets Readers Control How Much Information They See
41–50 of 69 posts
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#42At 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?
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#43I 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 langua…
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.
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#44Make 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.
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#45I 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…
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...
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#46I 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.
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#47I did a quick side project with my sister on a UI with similar goals. We called the documents, "variable level of detail documents"—demo here http://symbolflux.com/lodessay/ Also: we started a wysywyg editor to make these 'nesting docs' here: http://symbolflux.com/nestingdocs/
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.
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#48I 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…
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
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.
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#49Journalism 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.
Re: Show HN: A UI That Lets Readers Control How Much Information They See
#50From 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 technical…
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.