Last week I posted on here after I felt really frustrated about a number of bad reviews I had received. I want to please every single one of my users and when I hear that they are not happy with my product, it often gets to me.
That said, despite making me feel frustrated (or maybe devastated as I put it during a frustrated post), reviews are also endlessly helpful. Especially when they say why they like or dislike my app – it gives me a really good insight into what users want. Quite often, I just see the numbers, 5,4,3,5,4,5,4,5. Whilst I like seeing the numbers and it higher numbers make me really happy, they can, quite easily just become a bunch of numbers.
This week I have continued to get less than perfect reviews, but the contents were quite helpful. I could sit down and read each review and try to put myself into the shoes of the user. I addressed each review (not only with a reply, but with some real code change) one after the other. I dealt with it and my app is better for it. Also, the users who gave me the input now have an app which behaves more like they want.
Don’t ever feel bad for leaving constructive feedback for developers. For those who care about what they give their users, this is infinitely helpful.
Some user feedback required additional updates which I wanted to get out before it affects and frustrates too many people:
Bug fix: “Unexpected errors” when trying to find location would happen more frequently than it should. This updates tries to address this – it might just take a couple of seconds for the location to be found.
Usability issue: The “favourites” star was too close to the expand and collapse arrow, which made it easy to accidentally add or remove favourites. I moved this to be out of the way to reduce accidental pressing of this button.
Usability issue: I also added in a prompt to validate the removal of any favourite.
Update: I removed the “experimental” tag from the map views.
Feature: For iOS only, I updated the app so that it is possible to navigate backwards (Android users already have this). This meant that I had to move the menu to the right hand side to make sure that I had space for the navigation button.
Thank you for all the feedback you have provided, it is helpful to make sure that the app is as stable as possible.
Following a fairly rough week in the world of London Bus Pal, I want to take the opportunity to wish everyone a happy 2019. I’ve got many plans for my bus applications.
Firstly, I want to engage more with my users. I am busy putting together a website to make this possible. I want the ability to create a bit of a community – I have a fairly substantial user base, but at the moment, the only way to engage is through reviews and very anonymous analytics. Effectively, most of my users are just numbers – this makes it very difficult for me as an app developer to fully understand what my users want. The one benefit I have however is that I am also a user of my own app, so I represent a proportion of my own users!
I would love to grow my app to the point where I can devote more time to it. Basically, I want to look at a way of reducing my hours at work and have the ability to dedicate some time to app development each week. This is going to take some considerable effort – it is only the first day of 2019, so of course I am going to feel super optimistic (despite being slightly tired and a bit hungover from last night’s celebrations!).
I want to improve some of the functionality in the app – I am very happy with the base functionality and I don’t want to spoil things or over-complicate them, but the app also needs a bit more. I am still toying with the ideas, some of them might require a separate app, but these include: journey planning, improved route displays, incorporating other transport modes and maybe more informational things (very vague, but I know exactly what I mean).
Feel free to leave me a comment or send me an email with any suggestions or requests you may have.
Following some review feedback, I addressed some issues:
Major bug which was introduced from version 4.0.0 onward – if you ask for stops near me, the stops would just display in random order and it might not necessarily be the stops nearest to you. This has been fixed.
Styling updates to make better use of the screen space – similar to how version 3 used to look.
Added back the ability to search by post code which also disappeared from version 4.0.0.
Reviews on the Google Play store since the release of London Bus Pal 4 has been disappointing (it has only been four days since release, but the reviews have been generally negative). At least it feels that way!
I have been moping around all day and I have lost all motivation to improve things.
Six reviews in and my average is 2.5 stars – the last six reviews of version 3.2.11 average 4.67 stars. Bad reviews really hit me hard, because I spend a lot of time thinking about my users and what they would want. I am constantly told by my advertising provider that I can make so much more money with interstitial ads, but I refuse, because I would never want to annoy a user.
As I am full-time employed, I can only work on my app in my free time. This takes quite a lot of energy at times, especially if all I want to do is take some time out. But when users are facing issues, I want to fix it for them.
There is also an unfortunate problem with the rating system. As it stands, anything which is not a 5 star rating, takes my average down. I don’t necessarily agree that every rating should be 5 stars, but I always think about what those 4 star ratings are doing to my average. That said, I am thankful for those 4 star ratings!
Because of the large number of apps on the Google Play store which are
of poor quality or just plainly unusable, I feel that giving me a 1 star
review is comparing me to those publishers.
How do I rate other apps?
Given that we only have 5 stars to play with, there isn’t too much scope to play with, so the difference between poor quality apps and good apps is quite small. Here is my baseline for rating apps:
1 star – the app does not do what it is meant to do
2 stars – the app is clearly missing much functionality or bugs / poor usability get in the way of full use
3 stars – the app does most of what it is meant to do, but with some missing functionality or poor usability hindering use
4 stars – the app does what it is meant to do but for whatever reason I couldn’t give it 5 stars (usually a crash or frustrating usability)
5 stars – the app does exactly what I want it to do
Those are my baselines and I would then subtract stars for negative issues such as crashing, excessive battery usage, unneccessary permission requests, excessive advertising or deceptive practices.
Bug bash! No new features in this release, but after a couple of days of running and seeing how things work out, I made the app more stable by going through all of the logs and making sure that when the unexpected occurs, the app doesn’t blow up!
Bug fix: As part of the rewrite, a feature which was in the app since day was went missing and I added it back now: you can expand and collapse bus stops. This is especially useful if you have a long list of stops and you don’t want to have to scroll through the entire list.
As I’ve just published a fourth major revision of my app, I thought I would relive the history of the app just to see how far it’s come:
Version 1 – the prototype
This version was first published on 6 September 2013, version 1.0.1 (incorrectly numbered 1.01) followed 2 hours later and version 1.0.2 followed 2 days later.
Opening version 1 with no nearby stops (as I no longer live in London) just shows a blank screen. I see no options and I clearly deployed a version with no ads enabled!
Version 1.1.7 was the final instalment of version 1 and went live on 28 December 2013. When I now open the app, I see an error (as I am not anywhere near London), but it is quite generic and could really be anything.
Improvements I can see is a loading indicator, the search bar looks much better and a new map icon which appeared. The map views have always annoyed me as I haven’t given it too much attention. Something else which is quite obvious is that the lines are not high enough for a touch device.
Version 2 – going native
The first release of version 2 was in October 2014. I rewrote the entire app to get rid of Google Web Toolkit and all the callbacks between basically a front-end and back-end.
Opening version 2.0.0, it looks very much like a minor change from version 1.1.7 (except I know it was a substantial change!). The one thing which is obvious is that the listview tiles have become even tighter.
Fast forwarding to version 2.1.3, the list view is still very “tight”. The changes I can see from version 2.0.0 are: I can now search for specific bus stops by name and we now have some settings. In the settings I can see that by this time I changed my implementation to allow more granular view of nearby buses (showing in 15 seconds intervals rather than seeing “due” for 90 seconds, which can feel like forever if you are waiting for a bus!).
Version 3 – material design
Version 3.0.0 was released only a week after 2.1.3, but I had been working on it for quite some time. This version was all about material design and it was fairly cutting edge, as material design was only announced in June of the previous year. The design hasn’t changed too much since this release – apart from a styling change for dialogs. The main design has remained fairly similar since. In the back, there were a fairly large amount of moving parts, but most of this would have been invisible to users.
The next notable update was in May 2018 with GDPR coming around. With 3 days to spare, I put out the GDPR release on 22 May. This caused so many headaches that I had to try again several times to the point where I actually started over and finally released the last version on 7 June 2018.
Version 4 – Flutter and iOS
At work, a colleague told me about Flutter and I decided to investigate. Having looked at it, it seemed to be a really easy implementation of material design and there was the added bonus of being able to also build apps for iOS. I’ve had some requests to also make my app for iOS, but I didn’t want to end up having to maintain two code bases, the only way I would do that is if I ended up with a single code bases. I had considered many times if I should go back to my version 1 design to facilitate this. Early in November, I installed Flutter. It was a slow start, but I gained speed and confidence really quickly that I was using the right technology.
On 16 December, I published version 4.0.0 of London Bus Pal. Not as an Android app, but as an Apple app. I wanted to try the Apple deployment process and see if I missed anything major. And I was still missing map views, so I decided to soft launch on Apple and Android would follow once I had map views in place. Finally on 26 December, I launched version 4.0.3 on Android. Being another rewrite, it is quite nerve wracking, because things which were previously fixed or just stable, might not work. I have seen a few small issues, but not being used to the new error reporting software, I don’t always know if my users can see all of the errors.
Well, for now I’m going to focus on stabilising version 4 of London Bus Pal. The way it has been designed now, means that it should be quite easy to add new features. But I might just leave it alone, because I have a steady following of users.