Adding Pause/Play JS. See #5 #6

Closed
wants to merge 8 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

borkweb commented Aug 27, 2012

  • Adding pause/play events
  • Add class to liveblog container
  • Auto-unpause on click of the nag

See: #5

borkweb and others added some commits Aug 27, 2012

@borkweb borkweb Adding Pause/Play JS. See #5
- Adding pause/play events
- Add class to liveblog container
- Auto-unpause on click of the nag
887bc6d
@borkweb borkweb Merge pull request #1 from borkweb/5-pause-play
Adding Pause/Play JS. See #5
4423ce4
@zbtirrell zbtirrell added toolbar UI component with play/pause link
This adds the play/pause link which allows a reader
to control the "nag" functionality.  This also includes
a hook to allow other tools to be incorporated in the bar.
43e110f
@borkweb borkweb Adding Pause/Play JS. See #5
- Adding pause/play events
- Add class to liveblog container
- Auto-unpause on click of the nag
a283137
@zbtirrell @borkweb zbtirrell added toolbar UI component with play/pause link
This adds the play/pause link which allows a reader
to control the "nag" functionality.  This also includes
a hook to allow other tools to be incorporated in the bar.
a2757d9
@borkweb borkweb Find the nag before sliding it up. d7a2733
@borkweb borkweb Merge branch '5-pause-play' of github.com:GigaOM/liveblog into 5-paus…
…e-play

Conflicts:
	js/liveblog.js
536e038
Owner

nb commented Aug 27, 2012

In the course of development we discussed the option of automatically showing new entries and we decided against it. Mainly for two reasons:

  • If there are a bunch of new entries, the user may get lost and don't know which entries are new and which old. Especially if she has scrolled a bit down and after some time goes up.
  • Automatically adding new entries messes up with the scroll. If a user's reading a entry when we add a new one everything is scrolled down, which is annoying. This one is fixable, but given the other issue we decided to go the nag way exclusively.

For admins/editors we don't show the nag.

In what cases do you think the play/pause would be useful?

Contributor

borkweb commented Aug 28, 2012

Those are definitely some good arguments for using the nag by default.

However, I have been a live blog viewer for a number of years now and being required to click something to see live updates seems painful to me - I always have the stream up on a second monitor so I can code while watching the live updates. If those updates suddenly required interaction, the liveblog becomes less than ideal. I would promptly find a different liveblog that doesn't require clicking :)

I view The Verge, Engadget, MacRumors, etc as a good model to base off of as they've all been doing this for a long time.

One possibility to address the issue that you have outlined (pushing the page down is a huge issue), is to auto pause if the user is scrolled down. Perhaps leveraging .scrollTop to determine if the user has scrolled down, and if so, auto-pause if new entries come in.

Contributor

borkweb commented Aug 28, 2012

I've added the function for auto-pausing if there are new entries and the user has scrolled past a certain distance. (I arbitrarily chose 150px, though I'm not sure if that is a reasonable number).

Owner

nb commented Sep 1, 2012

After some real-life testing, we think you have a point :-)

Could you make your fork public, so that I can see your commits and to be able to pull the changes in my local repo?

Contributor

borkweb commented Sep 1, 2012

Sweet! Rather than make the repository public (so we don't expose your private repo), I've added you as someone that can view the repository.

Let me know if you really do want our repo public and I can do that instead. Thanks!

Owner

nb commented Sep 1, 2012

We open-sourced it. Private repos are lame :-)

Contributor

borkweb commented Sep 1, 2012

w00t! That's good news! Making it public :D

Owner

nb commented Sep 1, 2012

@borkweb I played with it and it works nicely.

However, I also did some user testing and I found a problem – people don't really understand what play/pause means. We will very hard time to communicate what issue we are solving, because it's pretty low-level: "we need this, because otherwise when we add new content it will scroll you down".

We should either find a way to communicate the need for the play/pause in a better way or find a way to get rid of it. I like the latter more.

Here is how it would work:

  • If a user has scrolled to the top we automatically snow the new entries.
  • If a use has scrolled down and a new entry comes in, we show them a non-obtrusive nag that there are new entries with a link to go back to top and view them. Before they click we don't move their scroll at all. The nag could be a semi-transparent thing on the side. The nag shouldn't go away when they scroll.
  • When they click view, we scroll them to top and show all the new entries. All the new entries are highlighted. The background fade out time is proportional to the number of entries, so that if there are lots of new entries the highlight doesn't disappear too quickly.

I like this approach, because the user doesn't need to do anything and we just do what is best for them in any moment:

  • Don't need to communicate what each state means, because the user doesn't need to change them manually.
  • If they're on top and are following the new entries, we just give them more when they come in.
    *If they have scrolled, we don't mess with their reading older entries, but keep reminding them that there are new entries and whenever they're ready they can go and read them.

What do you think? Does this cover all of our bases?

Contributor

zbtirrell commented Sep 2, 2012

This is certainly more complicated to implement, but I think this describes a much better user experience.

On Sep 1, 2012, at 3:16 PM, Nikolay Bachiyski notifications@github.com wrote:

@borkweb I played with it and it works nicely.

However, I also did some user testing and I found a problem – people don't really understand what play/pause means. We will very hard time to communicate what issue we are solving, because it's pretty low-level: "we need this, because otherwise when we add new content it will scroll you down".

We should either find a way to communicate the need for the play/pause in a better way or find a way to get rid of it. I like the latter more.

Here is how it would work:

If a user has scrolled to the top we automatically snow the new entries.

If a use has scrolled down and a new entry comes in, we show them a non-obtrusive nag that there are new entries with a link to go back to top and view them. Before they click we don't move their scroll at all. The nag could be a semi-transparent thing on the side. The nag shouldn't go away when they scroll.

When they click view, we scroll them to top and show all the new entries. All the new entries are highlighted. The background fade out time is proportional to the number of entries, so that if there are lots of new entries the highlight doesn't disappear too quickly.

I like this approach, because the user doesn't need to do anything and we just do what is best for them in any moment:

Don't need to communicate what each state means, because the user doesn't need to change them manually.
If they're on top and are following the new entries, we just give them more when they come in. *If they have scrolled, we don't mess with their reading older entries, but keep reminding them that there are new entries and whenever they're ready they can go and read them.
What do you think? Does this cover all of our bases?


Reply to this email directly or view it on GitHub.

nb referenced this pull request Sep 18, 2012

Closed

Pause/Play #5

nb was assigned Dec 20, 2012

nb referenced this pull request Dec 20, 2012

Merged

Unobtrusive updates #62

Owner

nb commented Dec 20, 2012

The implementation of this now happens in pull request #62.

nb closed this Dec 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment