Show HN: A UI That Lets Readers Control How Much Information They See
kayce.basqu.es
kayce.basqu.es
Also: we started a wysywyg editor to make these 'nesting docs' here: http://symbolflux.com/nestingdocs/
The interface thus becomes: stop reading when it stops being new or interesting.
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.
Basically a form of adaptive learning https://en.wikipedia.org/wiki/Adaptive_learning
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.
That article is textbook inverted pyramid.
Instead of adding work to the authors, simply use the semantic markup...or even let the reader do so.
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...
> 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.
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.
in that sense, writing with this in mind makes the ROI pretty obvious, since it's being written already in the first place.
I like the idea of Parametric Press (given that I made something similar), but I prefer the granularity of Expounder.
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.
Screenshot: https://i.postimg.cc/SKkKc85H/Screen-Shot-2018-12-10-at-11-5...
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 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.
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?
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.
Therein lies the rub
I found that it was a lot of extra work for authors and they weren't interested.
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.
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.
-----
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.
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.
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
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.
1. the ability to identify which components of a summary you would prefer to see expanded.
2. for expansions to be more clearly highlighted
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.
I like this idea.
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.