search

hypothesis / product-backlog

Where new feature ideas and current bugs for the Hypothesis product live
118 stars 7 forks source link

Don't cover the page with your sidebar (HTML implementation) #94

Closed dwhly closed 7 months ago

dwhly commented 7 years ago

Feature Request Form

Problem you are trying to address with this feature

Our sidebar overlaps the page. This creates a problem in a couple ways.

First, the text I'm trying to read is overlapped by the sidebar. Sometimes I'd like to actually keep the sidebar open while I read the article, but I can't.

Second, sometimes site owners (like @nickstenning) incorporate H and give it a nice place to live-- but then there's mobile.

squish

Your solution

There have been lots of things discussed over the years.

Related to: https://github.com/hypothesis/product-backlog/issues/25

judell commented 7 years ago

This bookmarklet will often (but not always) do the trick (on bigger screens)

javascript:(function(){document.body.style.marginRight='30em'}())

(to use this, create a bookmarklet and copy the above into the url field)

See: http://jonudell.net/h/page-fit.mp4

sean-roberts commented 7 years ago

My thoughts on this is, some people are going to want it one way and some are going to want it another way. Why do I think that, well most responsive websites are purely built on width of the page before determining how to collapse elements. if we had the width of the page change based on our sidebar it could totally change where the user is on the page when they open the sidebar (because content shifted in a responsive fashion). That's just one of the reasons why going all out with the other approach can backfire.

But I think it should ultimately be in the end user's control which to do based on their specific needs/preferences. So what if we made an option in the extension that allows a user to pick if they want and overlay or not to overlay.

judell commented 7 years ago

+1 to a setting. Then questions are then:

  1. What's the right default? (My $0.02: Make the adjustment by default. But I'm all for a user survey on this point.)

  2. Can it conveniently be overridden per-page? Because there will be certainly cases where the adjustment fails, and likely, in some subset of those cases, makes things worse.

an option in the extension

Why not an account-wide setting?

sean-roberts commented 7 years ago

So the current settings convention is, the settings live on the h website. And the only type of setting is the account settings. I can't help but feel that sidebar settings should not fall under the account settings. Here's why

So one path here is that we make it a setting that is available/set in the context of the client. This will allow the setting to be set in context. We can post the changes to the server to update the setting for the user. There is likely a simple way to build it that will allow the extension to show the options in the chrome extensions page. Doing it in this context will allow us to add other sidebar specific settings more intuitively, like override of the default setting on this given page

To your other question, it's not hard to do site-specific overrides. But I wouldn't want to track that in our DB. Leaving it up to the extension to manage that can keep the data client side (easier, faster, and less info about our user's locations in our db).

I think the smart default would be to go the new approach, as well.

judell commented 7 years ago

a setting that is available/set in the context of the client

There you go.

it's not hard to do site-specific overrides

What I meant: I default to adjusting the page, the adjustment makes things worse, can I turn it off for that page? But until/unless that's a problem, unimportant.

sean-roberts commented 7 years ago

Yeah we are on the same page. Not difficult

judell commented 7 years ago

https://github.com/hypothesis/browser-extension/issues/19

katrinleinweber commented 6 years ago

If hypothes.is would be injected like CTRL+H or +B in Firefox open the History or Bookmarks bar, could that circumvent this issue of covering content and debating a default? This seems to be the Fx57-compatible guide, but I'm not sure about Chrome.

klemay commented 6 years ago

this also presents an issue when annotating video - see: https://twitter.com/threexco/status/954418362544676864

judell commented 6 years ago

This is the experience I want, and am enjoying: http://jonudell.net/h/pdf-experience-in-experimental-extension.mp4

I've been using this code in the experimental extension for a while: http://jonudell.net/h/pagefit.js

A few days ago I realized it wasn't working for PDFs, so I put it directly into the pdfjs kit. And it works beautifully there, better than for random web pages because the HTML structure that's generated for PDFs is consistent.

I'm still testing this out, but it seems promising.

ajpeddakotla commented 6 years ago

Note from backlog grooming:

judell commented 6 years ago

My experience with the minimal solution mentioned above ( https://github.com/hypothesis/product-backlog/issues/94#issuecomment-359055472) ::

When I switch from the experimental extension back to the production extension, the absence of this page adjustment is painful.

might also resolve this issue on mobile

FWIW I don't think squeezing the page to accommodate the sidebar will be helpful on a small screen. Experiments with opening annotations inline suggest that will be a more fruitful approach.

-

On Wed, May 16, 2018 at 9:47 AM, Arti Walker-Peddakotla < notifications@github.com> wrote:

Note from backlog grooming:

  • Education users have noticed this repeatedly
  • This is the first thing that users have noticed in terms of bad UX.
  • There are ways we can approach this that might also resolve this issue on mobile (or make it more responsive).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hypothesis/product-backlog/issues/94#issuecomment-389588103, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC1rZqGFpWmqE-zKWRsmZshEg0TEZM1ks5tzFglgaJpZM4LM_kk .

klemay commented 6 years ago

User request: https://groups.google.com/a/list.hypothes.is/forum/?utm_medium=email&utm_source=footer#!msg/dev/0E9GtIU_WBo/_yTox3RyEgAJ

klemay commented 5 years ago

This came up in conversation at the ATI workshop today. A reviewer mentioned that they could only look at the source text or the annotation at any given time, since the Hypothesis sidebar covered the PDF when open.

klemay commented 5 years ago

User request from Zendesk: https://hypothesis.zendesk.com/agent/tickets/3689

jeremydean commented 5 years ago

@judell does this workaround allow the user to resize the underlying text and have the h sidebar snap into position in response?

michelle sprouse who presented at i anntotate last year has recently switched to perusall. the reason she cites is that students can resize text in a document and not have that resizing interfere with reading and annotating the document--ie. the annotations are not covering the document.

CC @dwhly

judell commented 5 years ago

@jeremydean not sure what you mean by "resize the underlying text and have the h sidebar snap into position in response".

What the code does currently, as shown in http://jonudell.net/h/pdf-experience-in-experimental-extension.mp4, is make the HTML in the rendered PDF page narrower by the width of the sidebar. Zooming in and out within the PDF viewer doesn't affect that rearrangement.

the annotations are not covering the document

Yep, it's a real drag when they do. The workaround I came up with aims to be of general use, in both HTML and PDF scenarios. Results vary a lot for HTML because of the variability of what's being adjusted. But as I've mentioned here and elsewhere, every page rendered by PDF.js with our annotation overlay has exactly the same structure. So my recommendation would be to make a sidebar-accommodating adjustment for PDF first, and worry about HTML separately.

Come to think of it, we did exactly that in the original Canvas prototype. I wouldn't recommend reusing my method exactly. It doesn't for example respond to a window resize, and can doubtless be improved in various ways. But I'm certain there's some fairly straightforward variant of the idea that can make the H experience with PDFs a whole lot nicer.

jeremydean commented 5 years ago

Right, I meant zoom in and out on the pdf or web page. The use case I’m trying to accommodate is for someone needing to resize text for accessibility.

On Thu, Apr 11, 2019 at 5:23 PM Jon Udell notifications@github.com wrote:

@jeremydean https://github.com/jeremydean not sure what you mean by "resize the underlying text and have the h sidebar snap into position in response".

What the code does currently, as shown in http://jonudell.net/h/pdf-experience-in-experimental-extension.mp4, is make the HTML in the rendered PDF page narrower by the width of the sidebar. Zooming in and out within the PDF viewer doesn't affect that rearrangement.

the annotations are not covering the document

Yep, it's a real drag when they do. The workaround I came up with aims to be of general use, in both HTML and PDF scenarios. Results vary a lot for HTML because of the variability of what's being adjusted. But as I've mentioned here and elsewhere, every page rendered by PDF.js with our annotation overlay has exactly the same structure. So my recommendation would be to make a sidebar-accommodating adjustment for PDF first, and worry about HTML separately.

Come to think of it, we did exactly that in the original Canvas prototype. I wouldn't recommend reusing my method exactly. It doesn't for example respond to a window resize, and can doubtless be improved in various ways. But I'm certain there's some fairly straightforward variant of the idea that can make the H experience with PDFs a whole lot nicer.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hypothesis/product-backlog/issues/94#issuecomment-482348779, or mute the thread https://github.com/notifications/unsubscribe-auth/ADHFzk5-L8l9maH6iZozCNZtibXTOlk4ks5vf7XNgaJpZM4LM_kk .

-- Dr. Jeremy Dean Director of Education

hmstepanek commented 5 years ago

Recent discussion prompted by: https://github.com/hypothesis/client/pull/1169.

jfix commented 5 years ago

[I've been redirected from the Hypothesis Open Slack workspace to this issue by @klemay, thanks! Here is what I said, slightly edited for clarity:]

I seem to have come across a usability issue when using the hypothesis sidebar on mobile devices.

More specifically, when the sidebar (using the classic theme) is open, its close button in the left top corner covers the underlying page’s hamburger button. When I click the sidebar close button the sidebar does close, but for some reason the click/tap event is passed through to the underlying hamburger button and opens the page’s menu which, of course, is not desirable.

An animated GIF, for your viewing pleasure:

34pfjw

If the GIF confuses you more than it enlightens, a real-life demo of the issue can be seen here (I only used the Chrome debug tools to emulate mobile devices): https://jfix.github.io/mkdocs-hypothesis-test/vol1/introduction/S2/

The background context here is that I’m discussing with the maintainer the integration of a Hypothesis extension into MkDocs’ Material theme (https://squidfunk.github.io/mkdocs-material/), a really great static site generator.

Of course, as a workaround I could use the clean theme which positions the close button not at the top but a bit further down, but a) I want to not open the sidebar by default but can’t find an ‘open sidebar’ button when using the clean theme, and b) it’s a workaround, not a solution. :wink: I’d like to leave the theme decision with the website publisher, not force them to use one over the other because of this.

judell commented 5 years ago

Here's an update prompted by feedback from an instructional designer who asks:

the annotation field is in the way of the text. Is this as intended?

As per above, the problem is eminently solvable for PDFs and I have been using an effective solution in a custom variant of the H extension for some time.

This instructional designer, however, is reacting to the sidebar covering a regular web page in an LMS assignment. The proof-of-concept solution for that case is not 100% reliable, but often helpful. It's available for trial at http://jonudell.info/h/#bookmarklet as the pagefit bookmarklet.

klemay commented 5 years ago

I've opened a separate issue for implementing this for PDF first: https://github.com/hypothesis/product-backlog/issues/1046

We'll keep this open until we're able to implement for HTML as well.

hftf commented 5 years ago

I could basically solve this problem myself by setting different margins for body if you set a class on body when the sidebar is open and closed.

mkdir-washington-edu commented 4 years ago

https://hypothesis.zendesk.com/agent/tickets/7396

it would be nice if you wrapped the annotated page in a <div> with a max-width set to the available space, so that the annotation column doesn't make the annotated article unreadable by covering part of it up.

mkdir-washington-edu commented 4 years ago

A good point was also made by a right-to-left language user: https://hypothesis.zendesk.com/agent/tickets/8692

my main problem is with the placement of the sidebar which appears in the right where many persian blogs and news shows its content from right corner.

mattdricker commented 3 years ago

User feedback: https://app.hubspot.com/contacts/6291320/ticket/417672585/

chrisshaw commented 2 years ago

Issue was linked to Harvestr Discovery: View annotations side by side with the content

robertknight commented 2 years ago

The HTML document integration (HTMLIntegration) in the client now has support for this, but it is behind a feature flag (HTMLIntegration.sideBySideEnabled) that is currently only enabled for VitalSource EPUBs. Shipping this for HTML documents is a matter of testing the current implementation with a variety of websites and tuning/tweaking it until we get it to a point where we are happy to ship it. For the initial release it doesn't need to actually work on all websites - there are some designs where it just doesn't make sense to try to fit the page content alongside the sidebar, but the idea is that it will fail gracefully on sites where it doesn't work.

hftf commented 2 years ago

How goes the testing/tuning/tweaking? 😶‍🌫️

robertknight commented 7 months ago

Side-by-side mode for HTML pages has been enabled for all users for over a year now. I think we can call this "done" and handle improvements in follow-up issues.