Straight to full-screen mode

[Bruce B]

I finally bought the Pro version, a few days before the sale! No
problem.

I am using the widget to skip over tapping All Articles twice. Now I
want to be able to tap the headline/snippet and go straight to the web
page in full-screen mode. That would save me three taps per article
read.

[Mariano Kamp]

Great, thanks.

I think I like that much to have a separate option/setting like that. I have to ponder this a bit more. But thinking about it I came up with an alternative. What about memorizing the state you were in. That means if you left the article detail view in full screen mode it will open in full screen mode again when you enter it the next time.

Not sure yet, which solution would be better.

Anyway, the best way to get this done is to submit a suggestion to http://newsrob.uservoice.com.

--
You received this message because you are subscribed to the Google Groups "NewsRob User Group" group.
To post to this group, send email to new...@googlegroups.com.
To unsubscribe from this group, send email to newsrob+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/newsrob?hl=en.

[Bruce B]

UserVoice doesn't seem to work with mobile browsers. I tried xScope
and stock. No luck.

On Feb 1, 1:49 am, Mariano Kamp <mariano.k...@gmail.com> wrote:
> Great, thanks.
>
> I think I like that much to have a separate option/setting like that. I have
> to ponder this a bit more. But thinking about it I came up with an
> alternative. What about memorizing the state you were in. That means if you
> left the article detail view in full screen mode it will open in full screen
> mode again when you enter it the next time.
>
> Not sure yet, which solution would be better.
>

> Anyway, the best way to get this done is to submit a suggestion tohttp://newsrob.uservoice.com.

>
>
>
> On Tue, Feb 1, 2011 at 3:10 AM, Bruce B <bberryh...@gmail.com> wrote:
> > I finally bought the Pro version, a few days before the sale! No
> > problem.
>
> > I am using the widget to skip over tapping All Articles twice. Now I
> > want to be able to tap the headline/snippet and go straight to the web
> > page in full-screen mode. That would save me three taps per article
> > read.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "NewsRob User Group" group.
> > To post to this group, send email to new...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > newsrob+u...@googlegroups.com<newsrob%2Bunsu...@googlegroups.com >
> > .

[Mariano Kamp]

I could tell you to submit a suggestion for mobile support to uservoice, but I see the irony ;)

To unsubscribe from this group, send email to newsrob+u...@googlegroups.com.

[Bruce B]

And it would be really cool if I could use the volume rocker to scroll
through an article. xScope works that way.

[Mariano Kamp]

How would you get to the next article then?

[Henrik Heimbuerger]

Yeah, that's my problem with this feature, too. I love the volume control page scrolling in the Dolphin browser, it's really handy and a lot more convenient than scrolling in NR. But then again, for some feeds, I definitely want to jump from article to article fast and scrolling doesn't matter that much. A per-feed option is right out, that would be totally confusing to have the volume control behave differently between feeds.

The only solution I could think of is that the volume control first scrolls, and then jumps to the next article when you reach the beginning of the end of an article (kind of like a unified article detail view of all articles in the current feed). Not the perfect solution either, though. I'm really undecided on this one.

[Alan J Robertson]

Although I can see the merit of an option to allow this, please don't force a change in this behaviour - I rely on using volume to quickly switch articles in a feed (quite a few of the ones I subscribe are American so I there are quite a few irrelevant articles about US-only items).

A.

[Mariano Kamp]

Yeah, that's exactly my issue.

First I though you would use the volume control to page down until the end and then you have to long hold it with a progress bar counting down a second, and then you would advance to the next article.

However that doesn't work for the reason you both mentioned. Sometimes you see the title and know enough to either pin the article or to move on to the next article right away. So it would be annoying to have go down to the bottom of an article and possibly even wait another second.

[Henrik Heimbuerger]

Well, what you could do to solve the problem with those feeds you just want to skim, is go through them backwards. You're always at the beginning of the article, so 'page up' would take you to the previous one. Still not a perfect solution, though.

Bruce, what was your initial idea how this should work and can you comment on the problems we brought up?

This is http://newsrob.uservoice.com/forums/35624-general/suggestions/925715 btw. and you should vote it up if you're interested in an implementation for this. Unfortunately, the suggestion doesn't give a real solution either.

[Alan Robertson]

Good thought, Henrik, but I tend to have my feeds configured as oldest at top so would have to switch that too...

A.

--

Sent by Dr Alan J Robertson

Clinical Research Fellow, University of Dundee

Cardiology Registrar, Ninewells Hospital, Dundee

01382 660111 (page 5026)

[Mariano Kamp]

How about making the button do double duty based on a delay?

Pressing it 1-350 ms advances to the next article, > 350 ms pages down.

Doesn't feel right, but maybe it inspires you to find something better?

[Alan Robertson]

That would work for me and would seem to preserve existing functionality whilst allowing for a new feature.

A.

--

Sent by Dr Alan J Robertson

Clinical Research Fellow, University of Dundee

Cardiology Registrar, Ninewells Hospital, Dundee

01382 660111 (page 5026)

[Henrik Heimbuerger]

I'll have to give it a try, but that sounds like an option.

For some reason, I never thought of switching up the functionality (short press advances articles, long press advances page), good thinking there.

I'm a bit afraid that the lagginess of my CPU will lead to a lot of misdetections, but we'll see about that.

[Bruce B]

I never use the volume rocker to move to the next article. I have too
many feeds to look at each article. As usual, I don't use my phone the
way most people do.

On Feb 12, 6:12 am, Henrik Heimbuerger <hheimbuer...@gmail.com> wrote:
> I'll have to give it a try, but that sounds like an option.
>
> For some reason, I never thought of switching up the functionality (short
> press advances articles, long press advances page), good thinking there.
>
> I'm a bit afraid that the lagginess of my CPU will lead to a lot of
> misdetections, but we'll see about that.
>
> On Fri, Feb 11, 2011 at 11:56 PM, Alan Robertson <alanjrobertson.uk@
>
>
>
> gmail.com> wrote:
> > That would work for me and would seem to preserve existing functionality
> > whilst allowing for a new feature.
>
> > A.
>
> > --
> > Sent by Dr Alan J Robertson
> > Clinical Research Fellow, University of Dundee
> > Cardiology Registrar, Ninewells Hospital, Dundee
> > 01382 660111 (page 5026)
>

> > On 11 Feb 2011, at 22:56, Mariano Kamp <mariano.k...@gmail.com> wrote:
>
> > How about making the button do double duty based on a delay?
>
> > Pressing it 1-350 ms advances to the next article, > 350 ms pages down.
>
> > Doesn't feel right, but maybe it inspires you to find something better?
>

> > On Fri, Feb 11, 2011 at 11:09 PM, Henrik Heimbuerger <<hheimbuer...@gmail.com>
> > hheimbuer...@gmail.com> wrote:
>
> >> Well, what you could do to solve the problem with those feeds you just
> >> want to skim, is go through them backwards. You're always at the beginning
> >> of the article, so 'page up' would take you to the previous one. Still not a
> >> perfect solution, though.
>
> >> Bruce, what was your initial idea how this should work and can you comment
> >> on the problems we brought up?
>
> >> This is
> >> <http://newsrob.uservoice.com/forums/35624-general/suggestions/925715>

> >>http://newsrob.uservoice.com/forums/35624-general/suggestions/925715btw.

> >> and you should vote it up if you're interested in an implementation for
> >> this. Unfortunately, the suggestion doesn't give a real solution either.
>

> >> On Fri, Feb 11, 2011 at 3:15 PM, Mariano Kamp < <mariano.k...@gmail.com>
> >> mariano.k...@gmail.com> wrote:
>
> >>>  Yeah, that's exactly my issue.
>
> >>> First I though you would use the volume control to page down until the
> >>> end and then you have to long hold it with a progress bar counting down a
> >>> second, and then you would advance to the next article.
>
> >>> However that doesn't work for the reason you both mentioned. Sometimes
> >>> you see the title and know enough to either pin the article or to move on to
> >>> the next article right away. So it would be annoying to have go down to the
> >>> bottom of an article and possibly even wait another second.
>
> >>> On Friday, February 11, 2011 at 2:41 PM, Alan J Robertson wrote:
>
> >>> Although I can see the merit of an option to allow this, please don't
> >>> force a change in this behaviour - I rely on using volume to quickly switch
> >>> articles in a feed (quite a few of the ones I subscribe are American so I
> >>> there are quite a few irrelevant articles about US-only items).
>
> >>> A.

> >>> On 11 Feb 2011 12:51, "Henrik Heimbuerger" < <hheimbuer...@gmail.com>

> >>> hheimbuer...@gmail.com> wrote:
> >>> > Yeah, that's my problem with this feature, too. I love the volume
> >>> control
> >>> > page scrolling in the Dolphin browser, it's really handy and a lot more
> >>> > convenient than scrolling in NR. But then again, for some feeds, I
> >>> > definitely want to jump from article to article fast and scrolling
> >>> doesn't
> >>> > matter that much. A per-feed option is right out, that would be totally
> >>> > confusing to have the volume control behave differently between feeds.
>
> >>> > The only solution I could think of is that the volume control first
> >>> scrolls,
> >>> > and then jumps to the next article when you reach the beginning of the
> >>> end
> >>> > of an article (kind of like a unified article detail view of all
> >>> articles in
> >>> > the current feed). Not the perfect solution either, though. I'm really
> >>> > undecided on this one.
>

> >>> > On Fri, Feb 11, 2011 at 12:30 PM, Mariano Kamp <<mariano.k...@gmail.com>
> >>> mariano.k...@gmail.com>wrote:

> >>> >> <http://newsrob.uservoice.com>newsrob.uservoice.com.

>
> >>> >> On Tue, Feb 1, 2011 at 3:10 AM, Bruce B <bberryh...@gmail.com> wrote:
>
> >>> >> I finally bought the Pro version, a few days before the sale! No
> >>> >> problem.
>
> >>> >> I am using the widget to skip over tapping All Articles twice. Now I
> >>> >> want to be able to tap the headline/snippet and go straight to the web
> >>> >> page in full-screen mode. That would save me three taps per article
> >>> >> read.
>
> >>> >> --
> >>> >> You received this message because you are subscribed to the Google
>
> >>> >> Groups
>
> >>> >> "NewsRob User Group" group.
> >>> >> To post to this group, send email to <new...@googlegroups.com>
> >>> new...@googlegroups.com.
> >>> >> To unsubscribe from this group, send email to

> >>> >> <newsrob%2Bunsu...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com<
>
> >>> >> newsrob%2Bunsu...@googlegroups.com >
>
> >>> >> .
> >>> >> For more options, visit this group at
> >>> >> <http://groups.google.com/group/newsrob?hl=en>
> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>> >> --
> >>> >> You received this message because you are subscribed to the Google
> >>> Groups
> >>> >> "NewsRob User Group" group.
> >>> >> To post to this group, send email to <new...@googlegroups.com>
> >>> new...@googlegroups.com.
> >>> >> To unsubscribe from this group, send email to

> >>> >> <newsrob%2Bunsu...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com.
> >>> >> For more options, visit this group at
> >>> >> <http://groups.google.com/group/newsrob?hl=en>

> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>> >> --
> >>> >> You received this message because you are subscribed to the Google
> >>> Groups
> >>> >> "NewsRob User Group" group.
> >>> >> To post to this group, send email to <new...@googlegroups.com>

> >>> new...@googlegroups.com.
> >>> >> To unsubscribe from this group, send email to

> >>> >> <newsrob%2Bunsu...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com.
> >>> >> For more options, visit this group at
> >>> >> <http://groups.google.com/group/newsrob?hl=en>

> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>> >> --
> >>> >> You received this message because you are subscribed to the Google
> >>> Groups
> >>> >> "NewsRob User Group" group.
> >>> >> To post to this group, send email to <new...@googlegroups.com>

> >>> new...@googlegroups.com.
> >>> >> To unsubscribe from this group, send email to

> >>> >> <newsrob%2Bunsu...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com.
> >>> >> For more options, visit this group at
> >>> >> <http://groups.google.com/group/newsrob?hl=en>

> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>> > --
> >>> > You received this message because you are subscribed to the Google
> >>> Groups "NewsRob User Group" group.
> >>> > To post to this group, send email to <new...@googlegroups.com>

> >>> new...@googlegroups.com.
> >>> > To unsubscribe from this group, send email to

> >>> <newsrob%2Bunsu...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com.
> >>> > For more options, visit this group at
> >>> <http://groups.google.com/group/newsrob?hl=en>

> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "NewsRob User Group" group.
> >>> To post to this group, send email to <new...@googlegroups.com>

> >>> new...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> <newsrob+u...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com.
> >>> For more options, visit this group at
> >>> <http://groups.google.com/group/newsrob?hl=en>

> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>>   --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "NewsRob User Group" group.
> >>> To post to this group, send email to <new...@googlegroups.com>

> >>> new...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> <newsrob%2Bunsu...@googlegroups.com>

> >>> newsrob+u...@googlegroups.com.
> >>> For more options, visit this group at
> >>> <http://groups.google.com/group/newsrob?hl=en>

> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "NewsRob User Group" group.
> >> To post to this group, send email to <new...@googlegroups.com>

> >> new...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> <newsrob%2Bunsu...@googlegroups.com>
> >> newsrob+u...@googlegroups.com.
> >> For more options, visit this...
>
> read more »

[Mariano Kamp]

It feels a bit gimmicky to me. But anyway, I can implement it and we try it out.

Could one of you please submit it to newsrob.uservoice.com?

To post to this group, send email to new...@googlegroups.com.
To unsubscribe from this group, send email to newsrob+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/newsrob?hl=en.

[Henrik Heimbuerger]

http://newsrob.uservoice.com/forums/35624-general/suggestions/925715

[Mariano Kamp]

I was about to implement that, but it doesn't feel right.

When hitting vol down the next article is shown, when hitting vol down for 500ms the article is paged down.

This doesn't feel "right", because you can quickly browse through different articles by hitting the vol down key repeatedly, but because of the 500 ms delay this doesn't work for paging down.

[Henrik Heimbuerger]

Any chance you could provide us (me ;) ) with your current test build implementing that? Maybe with the 500 configured in newsrob.debug (I wouldn't mind having to restart NR when changing it and all that). I'd really like to give it a try and see what it feels like.

Next to the feed blacklisting, that's really the one feature I'm longing for the most.

Have you considered switching it up, short presses for paging and long presses for switching? Yes, that'd definitely add the need for a new configuration setting, but it might be still worth a try.

[Mariano Kamp]

Yes, I can implement something like that testwise.

Options? Noooooooooo. I don't think so ;) Ok, we'll see. 

[Mariano Kamp]

Try this version.

Default is 650 ms, but can be set via pagingDelayMs.

Please also take into consideration while testing: Holding a vol key for a longer time. This now leads to scrolling to the bottom of the document. Browsing through all articles by holding the key is not possible anymore (which is fine with me).

[Henrik Heimbuerger]

First impression: probably doesn't work as intended on the Hero/CM7. When holding for ~650ms, I actually get about 3-4 page scrolls. (I would assume that NR processes multiple events here. It's still a smooth scrolling, just multi-page instead of single-page.) When keeping the button held, it actually *does* scroll all the way to the bottom of the article.
Just tipping the volume rocker shortly switches to the next article as before.

That browsing through all articles by holding the key doesn't work anymore is no problem for me either. In fact, I don't see a use case for this at all. I think it's actually an indication that hold-for-switch is the better solution, as holding makes no sense for switching, but does make some sense for scrolling.

[Henrik Heimbuerger]

Experimenting with 100ms and 25ms, I can get almost consistently to one (but still mostly two) page scrolls. I think if this were to be implemented, you'd have to prevent multiple page scrolls in succession, i.e. only one page scroll can be trigged from a 'volume button up' event after 'volume button down' + X seconds. You need to release the button again afterwards before you can trigger the next one. (I'm suspecting that's what you intended to implement, but the Hero probably sends slightly different events, right?)

Personally, I think I could work well with something like: Tipping the volume rocker once scrolls a single page, holding it for 100ms causes a switch to the next article. I really find that to be the most intuitive and reliable approach. When page scrolling, you don't really want to wait (should be immediate). When switching between articles, it takes (at least my old phone) at least a second to switch anyway, so holding the button for a tenth of a second feels very natural.

I was surprised how 'long' 100ms actually feels. I would have expected to accidentally trigger this action a lot when I want to just tip the rocker, but there's no way I could accidentally cause that. The two modes of interaction feel very naturally different (sorry, can't find a better way to phrase this).

Obviously, that's a major change of approach and would alienate a lot of users. So that would definitely require a new configuration flag. In fact, I'm not so sure I would want it on a tablet, for example. It's just on the phone where I find scrolling on the screen really awkward, cause it always blocks my vision and I then have to refocus my eyes on the text.

[Henrik Heimbuerger]

In case it wasn't clearly deductable from my excitement, I'd even want this feature if you decide not to implement the setting and only allow page scrolling via the hold action. :)

[Mariano Kamp]

Did you try to release the vol down button when the scrolling starts?

written on a mobile device

Am 17.06.2011 18:53 schrieb "Henrik Heimbuerger" <hheimb...@gmail.com>:
> First impression: probably doesn't work as intended on the Hero/CM7. When
> holding for ~650ms, I actually get about 3-4 page scrolls. (I would assume
> that NR processes multiple events here. It's still a smooth scrolling, just
> multi-page instead of single-page.) When keeping the button held, it
> actually *does* scroll all the way to the bottom of the article.
> Just tipping the volume rocker shortly switches to the next article as
> before.
>
> That browsing through all articles by holding the key doesn't work anymore
> is no problem for me either. In fact, I don't see a use case for this at
> all. I think it's actually an indication that hold-for-switch is the better
> solution, as holding makes no sense for switching, but does make some sense
> for scrolling.
>
> On Fri, Jun 17, 2011 at 4:31 PM, Mariano Kamp <marian...@gmail.com>wrote:
>

>> Try this version<https://sites.google.com/site/newsrobapp/beta-program/newsrob489-3.apk?attredirects=0&d=1>

[Henrik Heimbuerger]

Yeah, but I have to release it very accurately. Like within 10ms after the scrolling fires, or so. And I probably can't rely on visual results, simply because my device is so slow to react. :)

I guess we're talking about KeyEvents here? (I'm clueless.) In that case, to quote http://developer.android.com/reference/android/view/KeyEvent.html:

"Each key press is described by a sequence of key events. A key press starts with a key event with ACTION_DOWN. If the key is held sufficiently long that it repeats, then the initial down is followed additional key events with ACTION_DOWN and a non-zero value for getRepeatCount(). The last key event is a ACTION_UP for the key up."

So I guess my 'three page scroll' is a caused by the event sequence: ACTION_DOWN(repeatCount=0), ACTION_DOWN(repeatCount=1), ACTION_DOWN(repeatCount=2), ACTION_UP.

Again, I'm clueless and just attempting what Eric Lippert calls 'psychic debugging' here. ;)

[Mariano Kamp]

Yes, of course, but on the Galaxy Tab the repeat rate seems different. 

Btw. you can see more details in the log. There I log the time of the initial keyDown and the subsequent keyDowns.

Anyway, I will think about that. Maybe I will limit the scrolling to just once, or need to manage my own repeat rate. 

[Henrik Heimbuerger]

I'm not sure how to read that. Are we talking about the "ShowArticleActivity.newPosition() took" lines? I got no hits when searching for "keydown".

I think just limiting to once is fine, though. I would use touch-scrolling for browsing large passages anyway. The smooth (non-page) scrolling is just nicer if you just want to get an overview of an article. (Although I almost never do that anyway.)

And in the 'alternative' mode (holding for switching articles), we already established that holding down the buttons isn't really useful anyway.

[Rachel]

I use the volume keys to switch articles a lot, and I prefer just
pressing the key rather than having to hold it down, even for just
milliseconds. I think a lot of users would feel the same way.

If you choose to change this, I think you would have to make it an
option.

[Mariano Kamp]

Hi Rachel.

The volume keys will still work to change articles. However pressing+holding them instead of just pressing them will scroll the article. 

So the default behavior won't change unless you hold the volume keys... except that in the past holding(!) the volume keys would start advancing the articles until you release that. This "feature" will no longer work, but I don't see much sense in it anyway and it was never meant to be a feature, but was an oversight.

Does that work for you? 

--

[Mariano Kamp]

Henrik,

489-4 should work as we discussed.

Rachel, 

you can try this out for yourself if you install 489-4. I am interested in your feedback.

Download 489-4

[Henrik Heimbuerger]

(Single-)page scrolling on hold now works perfectly on the Hero/CM7.

I'm still in favor of an option (!) to switch these around, making scrolling the default and article switching the button hold action, but I'll try it for a while first before coming to a final verdict.

[Mariano Kamp]

When considering this, please also think about if any feature at all makes sense for the "hold" activation then? If you just delegate the function to the "hold" activation/secondary action, that you wouldn't use either way, it's probably not necessary to actually offer a secondary action at all.

[Henrik Heimbuerger]

Mmmh, maybe I wasn't clear enough. Two actions: short press and hold. Two functions: switch to next/previous article and paging inside the current article. My idea was just to switch these two around from how they are assigned right now.

I would personally say that, the more intuitive assignment would be short press for paging and long press for switching between articles. Right now, it's the other way around: short press for switching between articles and long press for paging (and that's already a massive improvement for my personal workflow, don't get me wrong). I think the current method is less intuitive, but of course we're all used to short pressing for article switching that because it has been that way for a long time. So the setting is primarily needed to not scare of existing users. I think new NR users would find short press paging much more intuitive. (The reason is simply that paging is a more common operation that needs to be done more often, so a 'quick' action makes sense. Switching articles is a more meta function in the bigger sense, so a 'bigger' action feels okay.)

I'm definitely using both a lot. Paging I mostly need for feeds with long text articles, while switching I need for high-volume feeds with short articles. (Note: I'm not in favor of making this feed specific, because that always makes it very unintuitive -- you're never quite sure which mode you are currently in if it depends on the feed.)

[Mariano Kamp]

No, you were clear. I have the feeling that you are missing the use of the volume keys to quickly scan through articles. So instead of scanning the headlines in the article list, some users open an article and then quickly thumb through the articles by using the vol down key. That wouldn't work (quickly) anymore when jumping to the next article would only be on hold.

When inside an article I agree with you, but adding a new state, inside/outside article, only makes things more complicated.

[Henrik Heimbuerger]

Yeah, I guess I'm a bit biased here because on my old phone, it takes 3-5s to switch articles anyway. :) That means a) that I can't quickly thumb through articles anyway, so I'm processing these feeds (of which I have few) from the article list. And b) that holding for 0.5s would only make a very minor relative time difference for me.

But yeah, as usual, don't optimize for my second generation phone. Makes no sense. :) (No irony.)

[Alan J Robertson]

I'm afraid I'm one of those folks who uses volume down to quickly go through articles, Henrik! - I tend to just swipe up and down with my finger for scrolling.

I've got a few Android feeds that I follow that are fairly US-centric and have occasional videos in them, so I tend to load the feed then very quickly page down through it using volume down.  Any that appeal I then mark as unread on the way down and come back to them, either on device or on the PC later.  A delay using this would be a bit of a pain.

I don't envy you trying to make these decisions, Mariano!

a.

Sent by Alan J Robertson (a...@alanjrobertson.co.uk)
Tel: +44 (0)7939-558-403

[Rachel]

Hi Mariano,

What you are talking about (a short press to change articles and a
long press to scroll the page) is my preferred way. I usually just
use the touch screen to scroll long articles and so I never hold down
the volume keys to do anything.

I was referring to what Henrik said about switching it around and
using a long press to do the article switching. I use the volume keys
a lot to switch articles, so I would really prefer to keep the short
press for switching articles. If you want to change this, I think it
should be an option because it will really slow me down if I have to
long press to switch articles.

Rachel

[Mariano Kamp]

Hi Rachel.

Yes, I get that and the use case you describe will absolutely still be supported in future versions.

The reason why I asked you to try the beta out is in order to find out if the additional functionality that is put on top of the existing functionality would hinder in any way to use the existing functionality. Because if that is the cases then I don't want to offer the combined functionality at all (only the two functionalities separately, separated by configuration). 

The last thing I want for NewsRob is to be fiddly to use, e.g. sometimes you advance to the next article and sometimes you scroll when using the vol down key, because you held it a little too long.

So to make a long story short, please test the usability of the new feature. In your case it should be possible to go ahead the way you used NewsRob before ... without experiencing any change.

[Mariano Kamp]

I don't envy you trying to make these decisions, Mariano!

It's actually not bad at all here on the mailing list. This is about understanding the use cases.

It becomes ugly after a release when people sometimes don't find the way they have used NewsRob before to be working anymore. Then the new behavior is "introduced behavior" and changing it back is a change too, which will get other people frustrated.

;) 

[Henrik Heimbuerger]

Two more reasons why 'short press for paging' is imho the better default:
a) While it's of course not Android standard, it has become a de-facto standard in many other apps, including but not limited to other reader apps like Aldiko, browsers like Dolphin HD and the official Read It Later app.
b) Short pressing can easily be mistaken for long pressing (by pressing too long, duh) while the other way around isn't easily possible (because you can just hold until you get the visual feedback). Switching articles however is the more destructive function, it can mark the article as read and even if you go back, you have lost your current reading position. So it would make sense to use the more reliable action (long press) on the more destructive function (switching articles).

But yeah, I completely agree that configurability is necessary if this was to be changed from existing behaviour.

--

[Rachel]

Hi Mariano,

I probably won't have time to test the beta until next week.

Rachel

[Mariano Kamp]

No problem. Just use 489-5 then. In 489-6 I disabled this functionality for the moment, because the next release will only be a bug fix release. After that bug fix release I will enable this functionality again in the next beta.

[Jay Carlson]

On Monday, June 27, 2011 8:12:34 AM UTC-4, Mariano Kamp wrote:
> No problem. Just use 489-5 then. In 489-6 I disabled [volume scrolling] functionality for the moment, because the next release will only be a bug fix release. After that bug fix release I will enable this functionality again in the next beta.

These are gone from the beta site by now, unsurprisingly. :-)

I have a couple of devices including a nook touch and a Galaxy Tab. As discussed, any app on the nook touch really wants page up/down scrolling because the display is not responsive enough for dragging, especially not for flick-to-scroll. But drag-scrolling is inconvenient on devices larger than (say) an iPhone, and flick-to-scroll is a little game of timing and dexterity. They're very "cool", but most of the time you just want "give me the next page" without all of the eye-tracking required. (I blame Apple's excitement about gestures for setting this trend.)

I navigate between articles using the left and right on-screen arrows. I'd be very happy to give up the volume keys for page-up/down, and at one point I remapped my Tab's volume control keys to "space/dpad-up" to try to get some of this system-wide (and this sorta worked on the touch too.) Now that there's apparently special case code for the nook touch model in your app, one machine's fixed; so if I could have volume keys for the Tab and the phone....

There are other possibilities for scrolling besides stealing the volume keys. Above and below the left/right hover article navigation buttons could be page-up/page-down buttons. Or additional arrows could be added at the top and bottom of the screen, although I suspect that's not as good for portrait tablets, depending on how you hold them.

IMO paging is a core service for text-centric apps and ought to be handled by the OS, instead of everybody stealing the volume controls.

Jay Carlson

n...@nop.com

(For high-volume feeds I tend to pick articles I want to read by pinning them from the list view, mark the feed read, and then work with unread articles. A short-press key for scanning articles doesn't help me much.)