Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upRealtime annotation #104
Comments
nickstenning
added
0 - Uncategorized
Epic
1 - Backlog
and removed
0 - Uncategorized
labels
Oct 23, 2014
nickstenning
removed
the
Epic
label
Nov 4, 2014
nickstenning
changed the title from
Rework/productionise realtime feature
to
Realtime annotation
Nov 4, 2014
nickstenning
added
the
Needs design
label
Nov 4, 2014
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
aron
Nov 5, 2014
Okay, I've been giving this some thought this morning. I think the implementation from a front-end perspective largely depends on the amount of annotations created.
The following assumes low traffic, under say 1 annotation every 30 seconds. Any more than this and we likely want to buffer annotations and show a notification that allows the user to manually trigger the the update, much like Twitter does on it's feed.
For insertions we have the following cases...
- Insertion of a new annotations card. This should make space for the card then fade it into view (video).
- Insertion of a new reply into a collapsed thread. This should "pulse" the background of the annotation card to indicate updates have been applied (video)
- Insertion of a new reply. This should fade in the annotation much the same as the new card. The entire card color should pulse.
- Insertion of a highlight. I think we should just insert this into the document. If highlights are visible then we can fade them in.
For edits I think we can just pulse the card for the moment.
For deletions there are two use cases...
- An entire thread is removed. We should just fade out and remove the card.
- A parent annotation is removed but it still has children. We should update the card content and pulse the background color to indicate a change.
There are still some outlying questions that we need to answer.
- What happens if an annotation is changed while it is out of view? My thinking is that the transition be suspended until it scrolls into view. Otherwise it would be easy to miss. This might be too difficult for a first pass at this feature though.
- What happens if a user is editing or interacting with the sidebar? I'd like to ensure that the view doesn't move around. Ideally if a user is interacting with a card it remains in place. Again not sure how difficult this is. The last thing we want is for someone to be creating an annotation and have the form pushed out of view by new annotations.
- Do we need an indicator of new annotations as they come in? Something like a badge near the search bar?
aron
commented
Nov 5, 2014
|
Okay, I've been giving this some thought this morning. I think the implementation from a front-end perspective largely depends on the amount of annotations created. The following assumes low traffic, under say 1 annotation every 30 seconds. Any more than this and we likely want to buffer annotations and show a notification that allows the user to manually trigger the the update, much like Twitter does on it's feed. For insertions we have the following cases...
For edits I think we can just pulse the card for the moment. For deletions there are two use cases...
There are still some outlying questions that we need to answer.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dwhly
Nov 5, 2014
Member
The following assumes low traffic, under say 1 annotation every 30 seconds. Any more than this and we likely want to buffer annotations and show a notification that allows the user to manually trigger the the update, much like Twitter does on it's feed.
I'd support this if the rate was measured over some time (> 5 source level annotations over 30 seconds?) and not two annotations that just happened to come in at approximately the same time. Also, if its a collapsed card w/ the reply count updating that's much less intrusive. I'd probably just let those happen. Generally: Lets tend towards letting realtime happen, and see when and where it's annoying and then turn the volume down, rather than prejudge that.
Having observed a flood of realtime annotations (which was quite exciting) a couple weeks ago on the bitcoin page (https://poloniex.com/) I'd say that it was not overwhelming at all. If two annotations happened to come in together a couple seconds apart I'd not have wanted it to stop updating.
- Insertion of a new annotations card. This should make space for the card then fade it into view (video).
Great.
- Insertion of a new reply into a collapsed thread. This should "pulse" the background of the annotation card to indicate updates have been applied (video)
Unless I'm mistaken the video does not seem to show this behavior. The card doesn't have any replies.
- Insertion of a new reply. This should fade in the annotation much the same as the new card. The entire card color should pulse.
Yes.
- Insertion of a highlight. I think we should just insert this into the document. If highlights are visible then we can fade them in.
You mean a new annotation whose selection is in the viewport (highlights only work as "only me" visibility now).
For edits I think we can just pulse the card for the moment.
Ok.
For deletions there are two use cases...
- An entire thread is removed. We should just fade out and remove the card.
Sure.
- A parent annotation is removed but it still has children. We should update the card content and pulse the background color to indicate a change.
Ok.
Isn't there also the case where a reply that has no children is removed? Or a branch of a thread is resolved or archived in some way (we should probably plan for this)? I assume again we should pulse the card and update.
What happens if an annotation is changed while it is out of view? My thinking is that the transition be suspended until it scrolls into view. Otherwise it would be easy to miss. This might be too difficult for a first pass at this feature though.
You might pulse the up or down arrows on the heatmap. I agree that queueing stuff is probably not sustainable.
What happens if a user is editing or interacting with the sidebar? I'd like to ensure that the view doesn't move around. Ideally if a user is interacting with a card it remains in place. Again not sure how difficult this is. The last thing we want is for someone to be creating an annotation and have the form pushed out of view by new annotations.
Yes. Though what if they're creating a reply and the parent is deleted?
Do we need an indicator of new annotations as they come in? Something like a badge near the search bar?
In addition to all the other visuals? Not sure about that.
I think the other major case that's missed here is what notification we see when the sidebar is closed. We used to have an action where the related tab updated and flashed. I'd like to see that come back.
Another thing: For a new source level annotation, the selection/highlight should probably also flash even if show annotations are turned off, to show where it's anchor is.
I'd support this if the rate was measured over some time (> 5 source level annotations over 30 seconds?) and not two annotations that just happened to come in at approximately the same time. Also, if its a collapsed card w/ the reply count updating that's much less intrusive. I'd probably just let those happen. Generally: Lets tend towards letting realtime happen, and see when and where it's annoying and then turn the volume down, rather than prejudge that. Having observed a flood of realtime annotations (which was quite exciting) a couple weeks ago on the bitcoin page (https://poloniex.com/) I'd say that it was not overwhelming at all. If two annotations happened to come in together a couple seconds apart I'd not have wanted it to stop updating.
Great.
Unless I'm mistaken the video does not seem to show this behavior. The card doesn't have any replies.
Yes.
You mean a new annotation whose selection is in the viewport (highlights only work as "only me" visibility now).
Ok.
Sure.
Ok. Isn't there also the case where a reply that has no children is removed? Or a branch of a thread is resolved or archived in some way (we should probably plan for this)? I assume again we should pulse the card and update.
You might pulse the up or down arrows on the heatmap. I agree that queueing stuff is probably not sustainable.
Yes. Though what if they're creating a reply and the parent is deleted?
In addition to all the other visuals? Not sure about that. I think the other major case that's missed here is what notification we see when the sidebar is closed. We used to have an action where the related tab updated and flashed. I'd like to see that come back. Another thing: For a new source level annotation, the selection/highlight should probably also flash even if show annotations are turned off, to show where it's anchor is. |
nickstenning commentedOct 23, 2014
As a user, I would like to see other annotations being made on the page as they are made, so that I can engage in a discussion without reloading.
Acceptance criteria