
Show HN: A UI That Lets Readers Control How Much Information They See - kaycebasques
https://kayce.basqu.es/blog/information-control
======
westoncb
I 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/](http://symbolflux.com/lodessay/)

Also: we started a wysywyg editor to make these 'nesting docs' here:
[http://symbolflux.com/nestingdocs/](http://symbolflux.com/nestingdocs/)

~~~
kaycebasques
Thanks, I'll add to the "prior work" section.

~~~
basch
Mercury Reader (formerly readability)
[https://mercury.postlight.com/reader/](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.

~~~
kaycebasques
Thanks. Added.

------
shaki-dora
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.

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

~~~
shaki-dora
Firs link on th first news source I could think of:
[https://www.nytimes.com/2018/12/10/world/europe/uk-brexit-
ec...](https://www.nytimes.com/2018/12/10/world/europe/uk-brexit-
ecj.html?action=click&module=Top%20Stories&pgtype=Homepage)

That article is textbook inverted pyramid.

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

~~~
kaycebasques
This is the big issue that I've heard from quite a few people.

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

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

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

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

~~~
kaycebasques
Thanks for the input. Any links? I'd like to learn more about these
strategies.

------
StavrosK
This seems similar to Expounder, one of my projects:
[https://skorokithakis.github.io/expounder/](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.

~~~
kaycebasques
Cool! I'll update the "Prior work" section.

------
jasonhong
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)

~~~
kaycebasques
Thanks. I'll update the "prior work" section.

------
onion-soup
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?

~~~
saagarjha
Yup, it’s called an adblocker.

~~~
onion-soup
adblocker is a workaround.

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

~~~
stevenwliao
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...](https://i.postimg.cc/SKkKc85H/Screen-
Shot-2018-12-10-at-11-54-43-AM.png)

Site: [https://www.axios.com/technology](https://www.axios.com/technology)

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

~~~
stevenwliao
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.)?

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

------
danbruc
Here [1] is essentially the same idea and the Hacker News discussion (115
comments) [2] of it.

[1] [http://getcoleman.com](http://getcoleman.com)

[2]
[https://news.ycombinator.com/item?id=14013996](https://news.ycombinator.com/item?id=14013996)

~~~
kaycebasques
Thanks. I'll update the "prior work" section.

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

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

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

~~~
kaycebasques
> They were usually pretty terrible about picking what went where

Therein lies the rub

------
peder541
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/](https://www.okeebo.com/demo/)

I found that it was a lot of extra work for authors and they weren't
interested.

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

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

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

------
heavenlyblue
Seems like a good idea, but I find it hard to correlate between low-detail and
high-detail versions.

~~~
ep103
yeah, I thought this was going to be like, if I click on a paragraph, it
expands into several paragraphs worth of detail.

~~~
kaycebasques
Interesting approach!

------
BoppreH
Reminds me of [http://www.telescopictext.com/](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/](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.

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

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

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

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

------
ouid
Make simple the default mode, and have inline "read more" style expandos. This
isn't a new design but it is a good design.

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

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

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

~~~
kaycebasques
What is the state of automatic summarization, by the way?

~~~
abhinavsharma
This is a good overview:
[https://blog.fastforwardlabs.com/2018/05/02/progress-in-
text...](https://blog.fastforwardlabs.com/2018/05/02/progress-in-text-
summarization.html)

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

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

------
stabbles
After the new media query 'prefers-color-scheme: dark' has landed, we now need
'prefers-content: tldr' as well.

------
monkeydust
Where I work there spending a lot of effort in nlp tools to summarise
documents of all sorts.

I like this idea.

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

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

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

