unnamed (8)

If there's one thing that's kept me from using Feedly's official app, as opposed to using more conventional RSS-style readers in the wake of the Google Reader collapse, it's the interface. Aside from the fact that I find it kind of clunky in general, the inconsistent back button behavior is a real downer. With the latest app update (version 18.1.3), it becomes a little bit less of a headache.

Screenshot_2014-03-03-09-00-45 Screenshot_2014-03-03-09-00-58

Now when you go through the various screens you've viewed with the back button, you'll open the "level selector" (read: the swipe-out side menu that shows all your feeds). Tap the back button again to exit the app completely. That should cut down on the instances of accidentally closing out of the app after reading a single item in a feed.

You can also go to the next feed in your master list once you've finished the unread items in another. Formerly you had to go up one level and select a new feed, now you can just use this handy "load next selection" button once you finish the active feed. Nice.


Feedly is still missing some of the more conventional reader features, including a standard scrolling widget, but these new additions should please those who prefer the swiping interface. The web version of the Play Store still lists the app under version 18.1.2, so it may take a while for the update to go out to all users.

Update: It looks like the 18.3 functionality is only in the beta. It should be pushed out to regular users soon. Thanks to commenters bozzykid and BigTimmay for the heads-up.

Michael Crider
Michael is a native Texan and a former graphic designer. He's been covering technology in general and Android in particular since 2011. His interests include folk music, football, science fiction, and salsa verde, in no particular order.

  • bozzykid

    18.3 was posted as a beta. It will not go out to regular users until they push it to the stable channel.

  • Sean Lumly

    If there was one thing that I would change about Android, it would be the back button. The change I would make would be to get rid of it. It seems like a good idea in concept, but it is rarely consistently used in an app or between consecutively opened apps. Even Google's apps (eg. Youtube) often use the back button poorly IMO.

    Clear and intuitive in-app buttons/gestures custom to the app seems like a better all-around choice.

    • Taco Monster

      The point is that the back button works *across* apps. I would definitely not want to get rid of it (iOS feels crippled for the lack of it) but it does present some usability issues.

      • Sean Lumly

        Correction: the back button is supposed to work across apps.

        Unfortunately whether it works or not is arguable. Yes, the feature is present, but its behaviour is not consistent. I personally think it could be done far better with custom in-app buttons/gestures.

        • Taco Monster

          Again, custom in-app buttons are not going to address inter-app navigation. On the whole, for me personally, the utility of the back button far outweighs its inconsistencies.

          EDIT: As an example, I often open links in Chrome from various other apps. On iOS, to go back to whatever I was looking at, I need to hit the home button twice and then choose the app deliberately. On Android, I just need to hit the back button. I do this so often during the day that being on iOS is super frustrating.

          • Sean Lumly

            I edited my post with something that could remedy that... It's just a suggestion. However, I do believe that this is a problem that can be better designed around, though an effective solution may not be currently observable.

            Here is the idea reposted:

            For example: when using intents, it would be helpful to provide the app with the app that invoked it with a title. In this way, the app could display a back button that stated something like: 'back to Google Chrome', in a style that was intuitive for the app.

          • Taco Monster

            I agree that the intents system leads to some unintuitive behavior: apps opened within other apps making the recents menu a very confusing affair. I suppose that I'm mostly just used to the way things are, but things are far from perfect, and some implementation of your suggestion could be a reasonable solution.

          • Sean Lumly

            Some people have also suggested that the back button be given a type of forced behaviour rather than being definable by the developer. This would be an effective solution as well, if it could be made to work. Even a default behaviour would work (again if this can be done).

          • card_me

            Even Google doesn't use it consistently or follow their own guidelines. The Android design guidelines specifically say that when opening an activity in an app from another app, pressing the back button should take you back to the view you left in the app that you came from. It should not respect the hierarchical layout of the app that was opened; that's what the up button is for.


            Unfortunately, YouTube doesn't work like that at all. You open a video from an app in the YouTube app, but when the video is over and you press the back button, instead of taking you back to the app you came from, it minimizes the video (same as swiping down) and shows the list view one level up in the app's hierarchy. It's infuriating.

          • Sean Lumly

            This was the example that I was going to use. Youtube frustrates me quite often with its handling of going 'back'.

            Another similar example is with gmail notifications. If while in an app you receive a gmail notification, clicking it will open the app as expected; however pressing the back button often take you to the homescreen and not the app you were last on.

          • card_me

            Actually, there is an API for iOS (x-callback-url) developers to use that solves the issue of no back button the way that Android should handle it on a system level. All of Google's apps on iOS actually use this, including Chrome. When I open an article from Feedly, for example, in Chrome for iOS, the upper left corner where you would normally find the software back button in any iOS app expands to include the name of the app (see the picture attached). This button is separate from the browser's back button (which will take you back a webpage) and clearly marked with where it will take you. It's a far more elegant solution than how either Android or iOS handles inter-app navigation currently. The problem is that it isn't system wide, and of course, not being able to set default apps in iOS means that if an app hasn't specifically been designed to use Chrome and x-callback-url, this doesn't even work. But the point remains... there is a way to have consistent UI design and inter-app functionality, better than the Android back button.

            The problem with the back button in Android isn't just poor execution, it's that the entire meaning of the back button has changed over time (notably with the 2.3 -> 4.x jump). Once Google introduced the "Up" button, stuff just started to break down, and apps that are still targeting Gingerbread APIs can work completely differently than apps targeted 4.x and up APIs. Often times the back button is used as a close button, sometimes it goes back a page, sometimes it goes back an app, and sometimes it even opens something else. In fact, that's how apparently this new Feedly update works, where pressing the back button opens the hamburger menu. To me, this is terrible UI design... I have one single button that, within the same app, can take me back sometimes, close something other times, and open something yet other times, not to mention it can leave the app completely and drop me into another app or the launcher. It makes you think before you press the button. That may not seem like such a big deal, and for people like us, it's usually not, but UX design should be intuitive and should never require a user to think too much. I honestly think that Google would abandon the back button if they could (assuming they could rework the "Up" button and implement something similar to x-callback-url), but they're too constrained by both apps using outdated APIs and the unwillingness of manufacturers to give up on hardware buttons (they could just update the behavior any time at the OS level to give a visual clue where the back button is going to take you if software buttons were mandatory).

            Of course, Windows Phone's back button is just a mess, so at least Google has it figured out better than Microsoft.

    • http://petercast.net Peterson Silva

      I really can not grasp what it is that bugs some people so much about the back button, seriously. I may be just dumb enough to not notice the inconsistency; I'm pretty OCD when it comes to visual consistency, but with the back button I just can't see the issue. I use it and have hardly ever felt something like "oh, it didn't do what I thought it would do!". For me it goes like this: if you ask people to _think_ on it, it may become a problem, but if you just let them use it, you'll never see them worry about it. It's like the centipede story.

    • miri

      Much easier said than done. There are so many things to consider with how hierarchical/temporal navigation is handled within and between apps that makes the process of removing the persistent back button a gargantuan feat and having developers modify their apps to compensate for faults of the system is not a solution. Rather, accepting that there will always be significant diversity in navigation models and modifying the system to accommodate them would be a much better solution.

      • Sean Lumly

        Remember, the menu button was a part of Android, and it was deprecated with a compatibility measure (the three-dot button in the nav bar) and design guidelines that placed it in the action bar. Requiring that all apps be updated in order to make such a change would not be strictly necessary, rather compatibility measures (eg. a floating back button up to apps of a certain API level) and updated design guidelines.

        I'm curious about your proposed solution. How would you modify the system to accommodate for diverse navigation models?

        • miri

          That's a different situation as the handling of an Android SDK feature isn't the same as an app not handling it's own up navigation at all. In the former case as it's a matter of the implementation of an SDK feature, there's a certain awareness about the feature but the issue of up navigation extends well beyond Android and there's no surefire way to tell how or whether an app integrates it into it's UI and because web browsers and many mobile platforms (Android included) have persistent back buttons it is quite common for apps not to have a back button in their UI and there's no way to enforce ubiquity pending a change to the system UI. Getting rid of the persistent back button would cause a lot more trouble for developers and users than the minor confusions that come with keeping it as it would break many perfectly good apps whose only fault was not adhering to Android's design guidelines to the letter (considering they were even applicable). You must remember that guidelines aren't a set of rules; their primary function is to ensure that apps are intuitive, powerful, attractive and generally well designed. If a developer can accomplish that outside of the Holo UI (something you should expect to see more of as web apps grow in presence) then by all means they should do so.

          As for how I'd modify the system... Not a clue. It's a complicated issue and every solution has its compromises.

          • Sean Lumly

            You clearly mentioned a solution in your original reply. Can you clarify?
            "Rather, accepting that there will always be significant diversity in navigation models and modifying the system to accommodate them would be a much better solution"

            Sorry, no. Maybe you need to re-read my proposed solution. It would not break apps, but would handle the special case of displaying a back button for apps of an API level prior to the deprecation. This is a reasonable solution and was pprecisely the same solution used to handle the hardware menu button deprecation.

    • Pär Dahlberg

      Funny thing, one of the few things a friend of mine who switched to iOS misses is the back button.

      I would definitely not want to get rid of it, but I agree that it would be a good thing to somehow make it more consistent.

  • The_Anomaly

    I use the Feedly app all the time. The retooling of the back button is a welcome change. Concerning going to the next feed when you're through with the current one. Is that not how it works now? When I'm through with one it scrolls right to the next one. And you don't have to tap "Load Next Section", which seems clunky. I'm probably confused on exactly what that's talking about.

    • http://www.androidpolice.com/ Artem Russakovskii

      This change is for the article view. Before, you would keep swiping right, and at the end, you'd be at a dead end, forced to press Back. Now you can go to the next feed. This is not about the feed list view where you see multiple items at the same time.

      • The_Anomaly

        Gotcha. Makes sense now.

  • http://www.androidpolice.com/ Artem Russakovskii

    As a convert from gReader to Feedly (I still have both installed but as long as I'm online, I use Feedly, strictly in titles-only view), I'm glad they finally tweaked these. The app is a lot more usable now.

  • Brandito

    So when you click through an article and end up on a webpage within feedly, if you navigate within that webpage, hitting the back button won't take you back through your history but instead to the article still? That's my main gripe, why include a browser if your browser doesn't act like any other browser in the world? I'll get right to paying for that subscription!

  • Scott

    Finally! I still accidentally close the app 2-3 times a sesh.

  • Evgany

    What is up with those menu buttons? It should be like this.

  • Fellwalker

    All that fuss, I'm glad I use NewsBlur. Works well across Android and Windows.

  • Irwin

    Still waiting on an update to read/unread font colors. The standard black (unread) and gray (read) are too similar. Perhaps a black bold (unread) and regular gray( read) would be better.

  • Chris

    Still not a fan of the Feedly app. It's still annoying to use. Looks good though.

  • http://www.jusuchyne.com/codingforme Justin Alex

    The best part is that the app now allows you to login using Google+, as opposed to either logging in to your Feedly or Google account.

  • Michael McGrade

    This will fix possibly my only issue with the app. I've been using Feedly shortly after hearing of the closing of Reader and needing a replacement RSS feed. It's been a great service but that back function on the app has caused me many times to just not even reopen the app out of frustration.

  • Matt

    Can we talk about that there is no Offline Reading Mode???

  • Guantaco

    Only problem with it so far is it breaks video playback and doesn't allow me to hit the back button into the original article. Rather it sends me to the refresh screen and loading the entire interface again.