Implement fragment highlighting

[aerugo]

We want to implement fragment highlighting in the UI.

• Fragments can be identified in posts by toggling "highlighting". When a fragment is highlighted, the rest of the post text turns grey.
• If multiple fragments in the same post are highlighted, they are black, while the rest of the post is grey.
• If nothing is highlighted, then the entire post is black.
• Highlighting is specific to a post. Highlighting only turns the rest of that post grey, not the other posts in the same topic.

A new column is introduced to show the highlight toggles

When highlights are toggled, the rest of the text in the post that is not highlighted turns grey. This transition should be to lower the opacity, and it should happen with a smooth but fast animation.

Highlights are specific to a post - posts above and below are unaffected.

[skoteskote]

What is the use case for this? I think it adds unnecessary clutter to the reading experience.

An alternative proposal:

• Hoovering over a code highlights all fragments this code is applied to in the post. This doesn't work on mobile.

[aerugo]

Hoovering over a code highlights all fragments this code is applied to in the post. This doesn't work on mobile.

No, that will not work on mobile, or when the post is so long that the codes and post are not seen together. We need a toggle.

[skoteskote]

What is the use-case for being able to highlight codes?

[aerugo]

What is the use case for this app? I think you should rather be asking yourself - is it a fun mechanic for exploration?

There are many potential use cases of this app, I suppose. Especially if one imagines using it outside of the context of BBU. In the context of Babel, the purpose is to make it fun and insightful to explore the texts, annotations, and code of the Babel universe. And highlighting fragments through toggling codes is fun. It’s also interesting to see the post from a new perspective by highlighting a couple of codes and reading only those fragments as if they were the only text in the post.

Another perspective is that the main mechanic of this app is to allow the user to explore annotated text as one would explore a landscape. An important aspect of hiking is that for every movement forward there is an equivalent movement backwards that ends you up where you started. Another important aspect of a hiking is that sometimes you need to move forward just so that you can better understand the territory.

In the fragment view you have access to primary information and connecting information. Primary: Fragment text, fragment code Connecting: Post title, overlapping codes Actions: Move to the post. Move to a code.

Code view Primary: Code name and definition Connecting: Number of annotations, fragments Action: Move to a fragment. If you came from a post, you can move back to the post through the right fragment if you remember it from the post.

Post/topic view Primary: Post and other posts in topic Connecting: Fragments and codes of fragments Actions: Move to a code. If there are quotes or links, move to a post.

On the post page, being able to see the text of the fragments is a way to map the territory, as it is the multivalent view of fragments as seen from the perspective of the single post, just as the code list under each post is the multivalent view of codes from that perspective.

Furthermore, it opens up for a new action: Being able to click the fragment in the post and move to its page. That’s not possible without highlighting because we don’t want to have the entire post be covered in hidden links that you accidentally tap with your finger as you scroll. Being able to move directly to a fragment is not so important right now, but it will be later.

On Sun, 9 Jan 2022 at 10:21, skoteskote @.***> wrote:

What is the use-case for being able to highlight codes?

— Reply to this email directly, view it on GitHub https://github.com/aerugo/bbu/issues/2#issuecomment-1008260819, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3MU6OO6TCII6HXSZU73WLUVFHQFANCNFSM5LKT4ECQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[skoteskote]

I was not clear - What I meant is: What is the specific use-case of the feature that allows the user to toggle codes in the post view?

I agree it's could look cool and maybe be fun, but I don't think it is useful and I don't think people will use it. I believe we should make the reader experience as accessible as possible, and not add too many features. The fewer buttons the better.*

This feature is particularly confusing when more than one code is toggled ON, ultimately leading to a large portion of text being highlighted without any way of distinguishing between the individual codes, which ultimately defeats the purpose of the feature. It is only really useful if I toggle only one code, hence I see no reason to allow the user to toggle more than one code, and hence the list of buttons is redundant.

If the purpose of this feature is for the reader to be able to see what fragment in the post a code is applied to then I see two solutions:

• Only allow toggling one code at a time as per my previous example, but with a different mechanic to be mobile compatible. One solution could be that pressing the code in the list reveals the fragment highlight and fades the other codes, instead of sending the user directly to the code view. Then the user can choose to press the code to go to code view, or press the fragment to go to fragment view.
• Use some form of color-coding that is triggered by the user unfolding the code list: Each code is assigned a random color, each corresponding fragment is underlined by the color of the code. This will probably work well on posts with few codes, but will be messy on posts with many codes. I'm very not keen on adding colors, but my argument for that is purely aesthetical.

*Books are AMAZING from a UX perspective. No buttons, no settings, no fluff. You can't get it wrong. We want to replicate this simplicity as far as possible, but still allow the user to explore the corpus non-linearly. Hyperlinks in text are a great cheat to achieve this. Adding buttons are not.

[aerugo]

I think that it being fun is reason enough. But I also disagree on the premise: I do think it is useful and I do think people will use it. We will have to agree to disagree.

On Sun, Jan 9, 2022 at 1:52 PM skoteskote @.***> wrote:

I was not clear - What I meant is: What is the specific use-case of the feature that allows the user to toggle codes in the post view?

I agree it's could look cool and maybe be fun, but I don't think it is useful and I don't think people will use it. I believe we should make the reader experience as accessible as possible, and not add too many features. The fewer buttons the better.

This feature is particularly confusing when more than one code is toggled ON, ultimately leading to a large portion of text being highlighted without any way of distinguishing between the individual codes, which ultimately defeats the purpose of the feature. It is only really useful if I toggle only one code.

If the purpose of this feature is for the reader to be able to see what fragment in the post a code is applied to then I see two solutions:

• Only allow toggling one code at a time (as per my example, but with a different mechanic to be mobile compatible.)
• Use some form of color-coding that is triggered by the user unfolding the code list: Each code is assigned a random color, each corresponding fragment is underlined by the color of the code. This will probably work well on posts with few codes, but will be messy on posts with many codes. I'm very not keen on adding colors, but my argument for that is purely aesthetical.

— Reply to this email directly, view it on GitHub https://github.com/aerugo/bbu/issues/2#issuecomment-1008292071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3MU6M37RLNBN65RHGFI7LUVGAJBANCNFSM5LKT4ECQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[skoteskote]

What do you think of the alternative solution I presented in my previous reply:

• Only allow toggling one code at a time as per my previous example, but with a different mechanic to be mobile compatible. One solution could be that pressing the code in the list reveals the fragment highlight and lightly fades the other codes, instead of sending the user directly to the code view. Then the user can choose to press the code to go to code view, or press the fragment to go to fragment view.

[aerugo]

I would like us to try it as designed before making any decision, the new version is ready soon, and what you propose would require additional development anyway.

Only allow toggling one code at a time as per my previous example

For the reasons I wrote above, I actually think it's quite fun and interesting to highlight multiple sections.

Books are AMAZING from a UX perspective.

And books can be highlighted, with a highlighting pen, and you can see multiple highlights at once.

Then the user can choose to press the code to go to code view, or press the fragment to go to fragment view.

Having the code do one thing when clicked once and then do something else when clicked again seems really confusing. The obvious thing would be that clicking the code again just removes the highlight.

[aerugo]

This is my main design principle when thinking about this:

Another perspective is that the main mechanic of this app is to allow the user to explore annotated text as one would explore a landscape. An important aspect of hiking is that for every movement forward there is an equivalent movement backwards that ends you up where you started. Another important aspect of a hiking is that sometimes you need to move forward just so that you can better understand the territory.

Being able to see and toggle the fragments gives the experience of context between the code-words and the text, helping you map the territory.

[aerugo]

I understand that you are attached to the idea of a clean "no buttons" interface. And perhaps we can find a way to achieve this with words, rather than buttons.

[skoteskote]

With your solution, the highlights in the text are indistinguishable from each other, ultimately rendering them pointless. I understand your idea behind it, but I don't think this solution achieves that idea.

Key problem is: There are multiple fragments nested in each post. If we think it's important for the user to be able to distinguish between which codes are attached to which fragments, and to be able to do this with many codes at a time, then we need to have a way of distinguishing the fragments from each other within the post.

I have a hard time seeing how it can be implemented with words. The only way I can think of is adding colors, but there might be other solutions.

Hence I think the better solution is to allow the user to only highlight one code at a time. I agree that my proposed double-clicking is confusing. But I'm sure there's another solution that doesn't introduce unnecessary complexity.

[aerugo]

With your solution, the highlights in the text are indistinguishable from each other, ultimately rendering them pointless.

They are only indistinguishable when you have multiple toggles on at once. Just as layers in photoshop are indistinguishable from each other when you have multiple layers visible. You start with one, then add another, then maybe remove the first one. But in another case, the purpose is not knowing exactly which is which is rather a sort of "cut and paste" exploration - "what does this post look like when only seeing the themes of motherhood and exploration".

You are only looking at their "point" from the utilitarian perspective of analysis. I am also looking at it from the playful perspective of discovery - in this case of how different fragments create associations when put in focus together.

But honestly I don't really understand why you are so adamant about debating this before you even get to try it out. Let's see how it works, then iterate. Perhaps we can switch to one at a time if it makes more sense.

[skoteskote]

I just think this feature might be a waste of time since it's I don't see how it achieves its purpose, and think it's a bad design both from a UI and UX perspective. But if you are very keen on the idea then of course go ahead and implement it!

I generally think it's better to discuss design features before implementing them, and I'm also wary of design decisions based on "it could be a fun feature." I am also a bit confused, as I thought you asked me for my comments on the design of this app? If you do not want me to come with any suggestions or critiques then please let me know.

[aerugo]

I generally think it's better to discuss design features before implementing them

Yes, but it is too late in this case - the work is basically already done. We can iterate later of course, but that makes more sense to have this conversation in more depth after actually trying it, don't you think?

I am also a bit confused, as I thought you asked me for my comments on the design of this app?

I think you're being a little unfair. All of the other suggestions are great, we should implement them. But you also need to expect pushback on some suggestions? Otherwise it's not feedback, but directives. This one we just don't agree on, especially as it was originally formulated, and I suspect that it has its basis in that we view the purpose and vision from different perspectives. And if that is the case, that's the conversation we need to be having, rather than one debating about a specific feature.

Books are AMAZING from a UX perspective. No buttons, no settings, no fluff. You can't get it wrong.

I would actually say that books do have buttons. It's just that the buttons are analogue.

What is a button? An object that performs a function.

In a book you have many such objects that are not part of the text, and some are not even strictly text at all:

• Asterisks
• Footnote numbers
• Page numbers
• Figure references

All of these are basically analogue buttons. They grab your attention and encourage you to perform the specific action they are "programmed" to do.

Books are also interactive. You can write in them, add bookmarks to them, tear pages out of them. All of these can be considered features. If we want to truly replicate the "simplicity" of something as multi-functional as a real-world book, we would need plenty of functions that are not even on the roadmap.

[aerugo]

and think it's a bad design both from a UI and UX perspective.

Sure - the design has not had a lot of thought. But let's then focus on how to make the design better, not just scrapping the idea.

[skoteskote]

I was not aware of the work already being done. Then I see no reason not to finish it.

Of course I expect pushback, but that's a part of having a discussion no? I am really just trying to improve the app. It feels somewhat like you'd rather not have discussions? Anyhow lets take this to signal.

[skoteskote]

Can't really stop thinking about this. It's an interesting UX challenge. My main issue with the original proposal is that there is no distinguishing between fragments in the post, which makes the toggle somewhat meaningless. For short posts where I can see both codes and post on one screen, it can work since I can toggle the code to see which fragments it highlights. If I need to scroll I will immediately forget which code I toggled, and which fragment was highlighted or not. I understand the desire to let the user play with this, and think it can be useful if done right.

Two other potential solutions:

I am not sure I agree that asterisks and footnotes are akin to buttons, but I get your point. So why not use these well-established solutions to the same problem? One solution is to treat the codes as footnotes, and use the language for that:

• Each code is assigned a number.
• This number is displayed after the fragment as well, using standard footnote formatting.
• These are only shown after the user toggles the codes arrow.

Pros:

• It is easy for the user to remember which codes are attached to which fragments.
• We don't introduce any new design conventions that the reader needs to understand.

Cons:

• Not possible to toggle codes, the user can just see which codes are for which fragments.
• Will look ugly and confusing on posts with many codes.

[skoteskote]

Solution two (beware this one is radical!):

Conflate fragment and post view into the same view.

• Pressing a fragment in code view takes you to a post view with the fragment highlighted.
• The codes of that fragment are shown in the foldout below (folded out by default) with their respective code information.

• If the user presses another fragment, that fragment is highlighted as well and its codes added to the list below.
• Pressing on a fragment again dehighlights it and hides its codes from the list.
• Pressing anywhere on the screen that is not text highlights ALL fragments and folds in the code list, meaning we see the same view as the user sees in the old post view. The user can fold out the code list to see all codes again. (Not sure this is the best mechanic.)
• Pressing a fragment again here dehighlights it, just as previously.

Pros:

• Fewer buttons and fewer pages.
• Contextualises the fragments to the posts. This is something I think is important as many fragments are uninteresting by themselves.
• Allow the user to explore the posts in the way the original feature proposal intended.

Cons

• Will not work well on long posts where the user needs to scroll to see the codes. One solution to this could be to "freeze" the codes to the bottom of the screen (with some size limit) but I'm not too keen on splitting the view into two elements. However, the original proposal has the same problem.