Sunday, March 29, 2009

Back To The Drawing Board

The last two weeks I worked on NewsRob more than ever before. I ripped out most of its guts and replaced the existing, well partitioned implementation with another implementation that was geared for performance.

Unfortunately it seems really hard to get the new, less well partitioned implementation stable again. Taking into account that I can't work on NewsRob on the next weekend it will take at least another two weeks to get it bug free. And I will always keep the penalty of high maintenance costs due to the lack of structure in the better performing implementation.

I just played with NewsRob 1.7.0 on my girl friends G1 and have to say that those high maintenance costs (read less features in the same time frame) don't seem worth the effort. NewsRob is performing quite well in most of the cases that count for me. Yes, the new version would make switching between the Article List and the Show Article screen almost instantly and the scrolling is much smoother, but at the end of the day this is more interesting for demos or people commenting in the Android Market than for the every day use.

Also I got a couple of mails that the performance is at least good enough and there were no lasting complaints on the previous blog entry.

So to make a long story short. I haven't made a decision yet, but I lean towards throwing away the work of the last two weeks and go back to NewsRob 1.7.0. I will think a little more about it though, but there is definitively no release coming out today.

If I have answered your bug reports/mails with "That's fixed in the next release.", well, that isn't exactly true anymore ;) I will go bug hunting in the old implementation then...


  1. Mariano

    Have only encountered one bug with the current version and pretty much use it everyday so its not all bad!

    Sorted my performance issue out, just switched off the download articles for offline reading functionality. Now I get the headers and only go online to get those which dont have any content in the rss feed. So happy with performance.

    What about Locale support for the new/current version?

    One request for current/new version, you know the two navigation triangles which appear when you touch the screen, the ones which move up and down (left or right!?) a feed. Any chance of moving these to the top or bottom of the screen. Im right handed and tend to scroll the screen down with my thumb, have found myself pressing the right hand triangle a lot which is really annoying, would be good to move these to the bottom of the screen to prevent accidently hitting them or maybe have a longer press before they pop up, they are quite big and I dont tend to use them very often, could you put a function in to switch them off maybe?

    Anyway still using the app and still find it very useful so keep up the good work. Would be happy to pay for it (also if you offered a version which removed the ad support on paying would be nice).

    Did the name change to include Google Reader make any difference?


  2. Hi Ben,

    thanks for the feedback. As you've probably noticed I also put out a new version yesterday night. So far I haven't gotten any bug reports for 1.8.3.

    Your solution to the performance problem doesn't give you the ability to read offline though ;-(
    I will start working on making the download configuration more fine grained. Maybe that will help? We'll see.

    I also have on my todo list to store and display more details about articles and their stats. One of the stats will likely be the download times.

    Locale support is also on that list, but I can't make any commitment on when I am able to release it. It's not a small task, so I can't just sneak it into my usual schedule.
    So I am still up for it, but I can't say when exactly I will come round to implement it.

    I can't really say if the name change to include "RSS" made any difference with certainty. I changed a couple of other things in the same period and was featured on the home page of at the same time.
    I have the feeling though, that it helped. Downloads jumped during that time. Since your last post the installed base has roughly doubled!

    Now about the navigation. This is very much a matter of personal taste. I'd like to hear more feedback from other users before changing it.
    But before that here is some more background:
    The current positioning is in line with the Pictures application. I like to stay consistent with apps provided by Google, if possible.
    Also it is exactly in the middle for a reason: It is easy to remember where the on-screen-controls are, even when they are not visible.
    When hitting the right spot - that is the middle of one of the buttons - it will be triggered, even though it wasn't visible at the time of tapping. So you can switch to the next article with one tap, instead of using one tap to bring up the on-screen-controls and one tap to trigger them.
    I'd like to keep that feature and therefore a longer press is not such a good option on first glance. I will think more about that though.

    I can see that many features of NewsRob are not known to users and reading the website or this blog is not an option for many of those users. As a consequence I try to make things simpler and simpler as I go along.
    One consequence is that I don't want to make things configurable if it is not really, really necessary. Hence making navigational options configurable doesn't sound too good me.

    I will see how many people will voice an opinion and think about it some more.

    Since NewsRob 1.7 the header panel has always the same size, so it might be an option to position the on-screen-controls for navigation in the upper third and still have them available at the same place every time. It will look a little odd though I suppose.

    Putting the controls on the bottom will make the bottom very crowded when the zoom controls also come up.

    What about training your thumb to go a little to the left? ;-)

    I was also thinking about defining a stripe running through the middle of the screen from the top to the bottom insensitive for the navigation controls.
    Unfortunately this makes things more complicated too. Some people would need a visual hint which are is insensitive to the navigational touch and other users would likely be confused by the lack of discoverability of the navigational controls.

  3. hi mariano

    personally, and obviously an individual opinion, i dont have any need for the navigation triangles. My reasoning is that as I download around 250 articles, across 10 categories/labels, I have setup in google reader its very unlikely I would want to scroll sequentially through one category and view each article.

    Typically I would refresh my feeds, update 250 articles and then select a specific category/label from the main screen, I will then scroll through the articles to find anything that is interesting within that category, id then select that articles and read it. Once finished reading I typically hit the back button on the g1 and then scroll through the remainder of the list to see if anything else is interesting. I wouldnt really want to scroll through with the navigation triangles especially as I may have over 50 articles within one category.

    My other reasoning is that the android browser doesnt have navigation triangles and from a simplicity perspective I could argue that not having them makes sense as it keeps it inline with the browser which I can access Google Reader on also (which doesnt have the triangles). In general from a UI perspective users arent expecting them.

    I just find them a little intrusive as everytime I scroll with my thumb they pop up, I may touch the screen 5 times and they pop up 5 times for no real reason (I also occasionaly hit them which can be annoying also)

    I dont see a problem as a user configurable option set to on by default. very often the best apps are the ones which work out of the box but allow users who want to some configuration options within the settings, users that dont want to mess about in the settings dont need to as the application works without needing to. The option to turn them off would be nice.

    on the locale support, the real user requirement that needs fufilling for me is the need to be able to schedule an update for a specific time or specific times in the day as opposed to the predefined times in the settings, my problem is, if I set it to update evrey 4 hours its inefficent use of battery when in reality I might just read articles when Im travelling to and from work so only update at 8am and 5pm. Locale is one way of meeting this requirement but a simpler way woud be to just have the option to schedule a number of updates within a 24 hour period. e.g. abiltity to define the number of updates and on which days e.g. M T W but not T F. dont forget some users may not like Locale or even want to install it. Im finding it to be a bit erratic at the the moment and to save battery I disable GPS which effectively switches it off.

    Anyway thats my thoughts, obviously one persons, maybe you could setup a poll or discussion on the main site to discuss improvements.

    On the name change I guess it could never hurt to have RSS in the title, we'll never know but if it got one more user because of it then maybe it is a success ;-)


  4. Hey Ben.

    >> My reasoning is that as I download around 250 articles, across 10 categories/labels, I have setup in google reader its very unlikely I would want to scroll sequentially through one category and view each article. <<
    I am not sure I understand that. You set up the labels, but don't use them? Do you use "all articles" then? But still don't got there one after the other, right? Instead you peak at the title on the Article list, mark some of them as read using the swipe-gesture (you know that?) and open others of more interest? Is that how you operate?

    So you're changing very very frequently between the list and the detail view. There is a thing (caching inflated GUIs) to speed this transition up a little bit. This should help you and I will implement this during the next two upcoming releases.

    >> In general from a UI perspective users aren't expecting them [the triangles].<<
    Well, users expect to be able to go back and forth in the articles. I think that the triangles are what users would most likely expect, or what would say they expect more?

    >> [..] very often the best apps are the ones which work out of the box but allow users who want to some configuration options within the settings, users that dont want to mess about in the settings dont need to as the application works without needing to. The option to turn them off would be nice. <<
    Ok, I will think about it some more. Currently I have the feeling that is very harsh to completely drop them, even as an option. And I **guess** that not many users share your needs, but of course I might be wrong. Maybe I can add a delay, that you have to touch the screen at least 1000 ms to get the on-screen navigation and that any significant finger movement during the delay will reset the counter.

    But this is not on the top of my queue at the moment. And I do this in my spare-time, so it might take a while until I get around to it.

    Regarding the Locale support. To schedule something to happen at a certain time you can configure Locale to keep the GPS off. But it's still there if you need it.

    When is it coming? I can't commit to that, but here are my current plans:
    This release: I want to offer the option that only the feed content (that is the images in the article) is downloadable, the feed content and the web page (as today) and no download at all. This should be configurable on a per-feed-basis.
    Next release: Initial Locale support (covers your use case) XOR exposing feeds as top level objects below the dashboard/label-level
    2nd next release: the other thing :-)

    Usually releases are two weeks, but that's no hard rule. If it takes longer to get it stable, it takes longer.

    Yeah, hard to say, but I guess that there is more than one user now using NewsRob, because of the name change. Thanks.