Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't open sidebar and focus on annotation if a link (and only the link) is highlighted #1218

Closed
dwhly opened this issue May 19, 2014 · 9 comments

Comments

@dwhly
Copy link
Member

dwhly commented May 19, 2014

We need to think about how to solve this. I'd say that the link under a highlight should take precedence in terms of clickability. One can always get to the annotation in other ways?

@BigBlueHat
Copy link
Contributor

@dwhly we're likely to hit a snag if the annotation highlight is just the link.

Perhaps we present a "link box" (ala Google Docs, etc) if/when they click a highlight containing a link, but the default action would be to load the annotation (as it is now).

Do we have a keyboard short cut for toggling highlights/modes?

@csillag
Copy link
Contributor

csillag commented May 19, 2014

Perhaps we present a "link box" (ala Google Docs, etc) if/when they click a highlight containing a link,
but the default action would be to load the annotation (as it is now).

I have always found the "link box" (used by Google Spreadsheet, by example) painful to use.
However, if they could not find a better solution, I am not sure there is one.
(They tend to think about these UI questions really hard.)

The should not stop us thinking about this, but for now, I think we could go with the link box approach.

Do we have a keyboard short cut for toggling highlights/modes?

Not yet, but we have an issue for that: #722.

@dwhly
Copy link
Member Author

dwhly commented May 19, 2014

I'd say only if the link is directly below the cursor-- otherwise no reason for the link box. Assume that's what you meant. You did say "a highlight containing a link" as opposed to "a highlight where there is a link underneath the cursor".

@BigBlueHat
Copy link
Contributor

Good catch. :)

On May 19, 2014 6:07 PM, Dan Whaley notifications@github.com wrote:

I'd say only if the link is directly below the cursor-- otherwise no reason for the link box. Assume that's what you meant. You did say "a highlight containing a link" as opposed to "a highlight where there is a link underneath the cursor".

Reply to this email directly or view it on GitHubhttps://github.com//issues/1218#issuecomment-43564655.

@tilgovi
Copy link
Contributor

tilgovi commented May 20, 2014

Is there a way this could be dismissed by thinking about what it is we are really trying to do?

What action do we have for clicking on a highlight that's important? The answer: we "focus" the annotation. That means it shows up in the sidebar (view changes to "selection") and it's expanded.

I'm on record repeatedly saying I think we should kill the expanded/unexpanded distinction, or change it to a "show more / show less" status on the quotes and bodies.

I'm also on record opposing these different "views".

Some further thinking is required for mobile, but for desktop I'm not actually convinced that we need to capture the click at all. There are alternate possibilities for selecting than mouse click.

@dwhly
Copy link
Member Author

dwhly commented May 20, 2014

The central question seems to be whether its useful to be able to click (or pick your alternate selection method) on a highlight and isolate that annotation (or annotations) in the sidebar as a result. Whether its expanded or unexpanded as a result is maybe not relevant for this question? (Not that it's not an important question-- but maybe not in this issue?)

I think what you're saying is that if we use non-click selection method X then we can pass clicks through to links?

I guess that would come down to the method you're suggesting and how utilitarian it is.

@tilgovi
Copy link
Contributor

tilgovi commented May 20, 2014

Agree that the question of expansion is a minor detail.

I'm not so much suggesting a change as I am trying to isolate the
assumptions implicit in the conversation and elucidate the places to
scrutinize such that alternatives become apparent.

This seems to have worked well enough because you nailed it. So far we've
assumed selection is by click on a highlight, and removing this behavior
would close this issue.

My only concrete proposal for an alternative is to scrap the heatmap tabs
as they are now and instantiate a tab at the point of any heatmap click.
Multiple such tabs could be present at once, allowing the view to be pinned
to a union of the sets of annotations from disparate locations, and cleared
by clicking on an X on each tab. In my mind I imagine a prompt in the
sidebar which clears the entire selection, returning to what we now call
"Document" view.

That's just a sketch for others to jam on.
On May 19, 2014 9:18 PM, "Dan Whaley" notifications@github.com wrote:

The central question seems to be whether its useful to be able to click
(or pick your alternate selection method) on a highlight and isolate that
annotation (or annotations) in the sidebar as a result. Whether its
expanded or unexpanded as a result is maybe not relevant for this question?
(Not that it's not an important question-- but maybe not in this issue?)

I think what you're saying is that if we use non-click selection method X
then we can pass clicks through to links?

I guess that would come down to the method you're suggesting and how
utilitarian it is.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1218#issuecomment-43577065
.

@judell judell changed the title Can't click on links if highlights exist Can't open sidebar and focus on annotation if a link (and only the link) is highlighted Jun 11, 2015
@lenazun
Copy link
Contributor

lenazun commented Jan 28, 2016

The current behavior on this in Chrome 47.0 is that clicking on a highlighted email does focus the annotation, then follows the link about a second after.

@nickstenning
Copy link
Contributor

Hi there! I'm going to close this as part of a clean-up of all issues currently open on this repo that represent ideas or features rather than reports of bugs or technical chores.

I want to be clear that this isn't intended to say anything at all about the content of this issue—it certainly doesn't mean we're no longer planning to do the work discussed here—just that we don't want to use GitHub issues to track feature requests or ideas, because the threads can get long and somewhat unwieldy.

If you're interested in what we are working on at the moment, you can check out our Trello board and, for a longer-term view, our roadmap.

And, if you're interested in following up on this issue, please do continue the discussion on our developer community mailing list. You might also want to check out our contributing guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants