A was forced to upgrade to the beta version 4.0 of the NewsBlur Android app as my Nexus phone has just been updated to Android 5.0 Lollipop. I like the offline sync function but I am very scared by the presence of both mark newer and older as read options in the tap list. I am reading my stories oldest-first from all threads at once (‘All stories’ list). I am scrolling down the list regularly marking all the seen (i.e. older) stories as read.
However, in the current beta-version of the app there are both options to mark older and newer stories as read side by side. I am quite sure I will by accident tap on the wrong option (i.e. mark newer as read instead of the correct older as read option) one day and I will effectively completely and irreversibly destroy my 400 long list of unread stories with no confirmation or anything.
Such a extremely dangerous function should definitely be protected at least by a confirmation dialog (at least when marking more then 5 stories or so at once) or should be removed at all (at least as a configuration option in the application settings).
I really do not know why to add option to destroy all stories further in the list which the user does not have any chance to see at all. Function ‘Mark previous as read’ as implemented in the 3.6 version of the app was definitely the correct and totally satisfactory implementation of this function. Please, add that back, do not let users to destroy their valuable long time build lists of stories to read with no chance to rescue.
There’s no preference on marking a feed as read, so why would be there a preference on marking just part of a feed as read? Have you ever accidentally set this off?
You are right with the marking the feed as read button that I didn’t use by accident. However, that is a completely different situation from my point of view as that button is in the upper right corner of the screen far away from any GUI element a use regularly. Thus, this button is save for me.
However, the ‘wrong’ mark as read is next to the ‘correct’ one I use two or three times in a minute when scrolling down the list. Its simply too easy to hit the wrong one by accident. (That is my experience with NewsBlur app used on the daily basis. I hit the wrong option from the menu two or three times in a month. Hitting ‘Save this story’ by accident is not a problem and is easily solved with ‘Unsave this story’, but hitting the wrong mark as read option would be a disaster.)
I really think we need just one ‘Mark previous as read’ button marking as read the seen and scrolled-down stories, i.e. the older stories in the oldest-first list setting and newer stories in the newest-first list setting.
Damn. I’ve done it again a couple of days after that.
Double Damn. Today, I marked previous as read, which is what I intended to do. However, it has also marked other stories as read that were later in the feed, and added some new stories. With 311 left (whoops, just returned to the main page and that 311 jumped magically to 375) please can someone explain how I get back to the story that was immediately next when I marked previous as read?
Please can I have my the NewsBlur Android app back?
We’re looking into it. Possibly adding some sort of unicode character (⇡ and ⇣) to the menu to help show which stories you’re marking. I also think we’ll change the order of the menu items to look like the web. See the screenshots on this ticket: https://github.com/samuelclay/NewsBlu…
I very very much appreciate your efforts and really love NewsBlur, however, I am not sure it is a good solution. Even with the good visual distinction the buttons are still close together. On mobile phone in a trembling bus, tram or train it is still very likely to hit the button by accident. That is my real life experience.
I’m not sure if I’m near a typical use case but I would love for all the “mark many items read” buttons behind some form of confirmation dialog. I was very careful on the previous versions of mobile for this same reason and I am discovering I have to be even more careful on the new version.
At least for me I use the unread status marker as assign of whether or not I’m done with the item so all of my feeds have unread only filters on. This makes the problem particularly dangerous for populous feeds.
I’ve returned to this thread because I’m still finding I am hitting the wrong button. My work flow has stories with oldest first, unread only. I look at a page a time** on my tablet, and my intention is to “mark older as read” on a story near the bottom ***. However, I frequently find I have by mistake hit the “mark newer as read” button which leads to swearing, then trying to re-sort and filter the stories so I can find out what I didn’t read that I wanted to.
Please can anyone explain a good reason that they would wish to mark newer stories as read that they’ve not even got round to viewing yet?
I can just about get that if I sorted the other way round, I might wish to not only mark stories I’ve scrolled past as read, but if I’d not looked at newsblur for a while there might be thousands of old stories that I’m just never going to get to. So in the case of the stories being sorted newest first, I can understand a scenario where you could justify having both mark newer and also mark older as options.
What I can’t understand is the point of the mark newer button when I’m sorted oldest first. The only value it had is in increasing my stress level.
** if I look at more than a page a time I have to then scroll back to the top of the unread stories, which is a right royal pain in the a. Why you changed it from just greying them out I’ll never understand. If only it jumped to show next unread at the top of the screen? On a phone (5" screen) it is much much more frustrating, to the extent that I hardly ever use my phone to use newsblur .
*** please can you change the operation of the “mark older as read” so that it does what it says. If the story I touch and hold is timed 15:00 then the button should mark stories timed at 14:59 and earlier as read. It should not include other stories at 15:00 (that I can’t see because their times are off the page).
[I have previously written about both of these problems on get satisfaction]
Using 4.7.0b1
I’ve returned to this thread because I’m still finding I am hitting the wrong button. My work flow has stories with oldest first, unread only. I look at a page a time** on my tablet, and my intention is to “mark older as read” on a story near the bottom ***. However, I frequently find I have by mistake hit the “mark newer as read” button which leads to swearing, then trying to re-sort and filter the stories so I can find out what I didn’t read that I wanted to.
Please can anyone explain a good reason that they would wish to mark newer stories as read that they’ve not even got round to viewing yet?
I can just about get that if I sorted the other way round, I might wish to not only mark stories I’ve scrolled past as read, but if I’d not looked at newsblur for a while there might be thousands of old stories that I’m just never going to get to. So in the case of the stories being sorted newest first, I can understand a scenario where you could justify having both mark newer and also mark older as options.
What I can’t understand is the point of the mark newer button when I’m sorted oldest first. The only value it had is in increasing my stress level.
** if I look at more than a page a time I have to then scroll back to the top of the unread stories, which is a right royal pain in the a. Why you changed it from just greying them out I’ll never understand. If only it jumped to show next unread at the top of the screen? On a phone (5" screen) it is much much more frustrating, to the extent that I hardly ever use my phone to use newsblur .
*** please can you change the operation of the “mark older as read” so that it does what it says. If the story I touch and hold is timed 15:00 then the button should mark stories timed at 14:59 and earlier as read. It should not include other stories at 15:00 (that I can’t see because their times are off the page).
[I have previously written about both of these problems on get satisfaction]
If you select a story and then go to “Mark older as read”, it should include that story. Otherwise, select the slightly older story to use as the line.
I don’t follow your ** comment. I suggest starting a new thread which just has that feedback. Including screenshots is a sure way to get me to fix what you think is broken.
As for the main comment, the order of the mark read buttons changes depending on your story order. So it should follow that the top option marks the stories above as read, and the bottom option marks the stories below as read. Post a screenshot if that isn’t the case.
I have found that the latest version of the app does indeed only mark up to and including the current story as read. The previous bug of marking everything that showed the same time as read has been fixed, and I had not noticed. Thank you.
Please could you reconsider the buttons, even if only for the case where stories are presented oldest first?
Having both “Mark older as read”, and “Mark newer as read” seems bound to create mistakes. They are next to each other. I still cannot understand why I would even want to be able to mark stories that I’ve not yet looked at as read.
If I am ordering stories oldest first, unread only, and reading in the order that NewsBlur presents them, what circumstance would occur that I would want to “Mark newer as read”? I cannot think of one. So what use is the button? The only thing I can see it doing is making me curse due to hitting it by mistake - whether that be my finger brushing it as I tried to move it to touch the “Mark Older as read” button, or just missing it as I am jolted - be that while walking, on the tube, on the bus… , or just missing it.
Maybe it is just me, but I doubt I am the only one to hit the wrong button.
I also still do not see the reason of the existence of both buttons (was there a request form someone of this feature? But there are several people strongly against it; It is no new functionality request – hide these buttons is trivial and need no development, just comment them out in the source code: https://github.com/samuelclay/NewsBlur/blob/master/clients/android/NewsBlur/src/com/newsblur/fragmen… [or something like that. So please please do it.).
To be hones this problem (existence of both buttons with high probability of mistake destroying my complete unread list) was the only reason I was looking for an alternative and I have found News+ (https://play.google.com/store/apps/details?id=com.noinnion.android.newsplus.premium) +
NewsBlur+ extension for News+ (https://play.google.com/store/apps/details?id=com.asafge.newsblurplus). It is even features-richer alternative client that is definitely able to substitute the official app. There are only minor problems with syncing read stories back to NewsBlur server (so sometimes I see stories read on my phone still unread on PC/tablet) but until the mark as read newer/older button problem is solved in the official client it is the only usable app for me.
I will sometimes use both options in the feed list.
For example, if I scan down the list there might be a story in the middle I want to keep unread for later. With both options I can easily mark the stories before and after as reading leaving on the desired stories marked as unread.
@Mark Anderson - I just mark the story to save it. That does the job far more easily. It is very easy to unsave it once read. I can’t imagine scrolling down a couple of hundred stories past one I want to return to, then scrolling back up, marking newer as read, and praying that there haven’t been any newer new stories added on to the bottom. Also, how do you deal with it if you find two stories you want to come back to? Sorry, can’t comprehend.
I only do this very ocassionally, for example, when I know I’ll come back to it within the same reading session. I tend to keep up with all the feeds I read and I never have more than 50 unreads probably in any one feed.
To be honest I can’t comprehend how people can press the wrong menu item. I use mark older as read all the time and have never done this.
The problem is that there is a trade off between complexity in the app and what suits most users. It isn’t realistic to put an option in for every use case that anyone comes up with.