Categories
London Bus Pal

The end of an experiment: why I closed comments forever

After four and a half years, I’ve permanently closed the comments section in London Bus Pal. This decision wasn’t made lightly, but it was long overdue. Here’s the story of how a simple feature became a nightmare, and why closing it feels like such a relief.

The beginning: a simple idea

I wrote the first line of code for the comments functionality in December 2020 with a straightforward goal: give users an organised space to share useful information about buses that wasn’t available elsewhere in the app. The first comment appeared in February 2021, and we had just three comments that entire month. March brought four more.

As usage grew, I noticed the interface wasn’t ideal, so I found a neat chat library to make commenting easier. This was my first mistake. What I intended as an improvement, users interpreted as an invitation to actually chat. Despite my repeated requests to keep discussions focussed on transport information, several people ignored these guidelines entirely. I would come in to see walls of text about homework and school and when I demoed the app to others, I would specifically ask them to not go near the comments-section.

The Monster I Created

What started as a helpful feature quickly spiralled into something I never intended to build. Users began treating the app like a social media platform, posting anything that came to mind rather than focussing on useful information for other people using the app.

The abuse was immediate and persistent. I found myself constantly building new systems to combat it:

  • Comment reporting functionality
  • User muting and banning systems
  • Toxic behaviour detection
  • Profanity filters
  • Increasingly sophisticated moderation tools

Each improvement seemed to invite new forms of abuse, creating an endless cycle of development just to maintain basic civility.

The Moderation Challenge

When things became unmanageable, ial6658 reached out to me offering to help with moderation. I was incredibly grateful and worked with him to get started. My crude initial tools meant I was constantly fishing around in databases, handling everything manually. I spent significant time building proper moderation interfaces just to onboard him.

Soon the team grew: VT and c1taro joined ial6658, followed by hdg. More recently, LS69, dantv102, and GodwinTransit were made moderators, largely based on their exemplary behaviour in the app. These volunteers will continue their invaluable work moderating Discord, photos, and suggestions.

Even with dedicated moderators enforcing the rules, I received several complaints about them “being rude” – for simply doing their job. The irony was infuriating: people were angry at moderators for maintaining the standards that kept the platform usable for everyone else.

Unsung Heroes

I cannot express enough gratitude to these people. They didn’t always have the appropriate tools, but made things work as best they could. The best analogy I can think of is asking someone to clean up a beach after a huge party – dealing with loads of rubbish scattered everywhere – but only giving them a small shopping bag to work with.

These moderators were the unsung heroes that users often took for granted. People didn’t see the countless hours and effort they put in trying to bring civility to an increasingly chaotic situation. They endured many stressful moments: bans that wouldn’t take effect immediately, complete mob mentality during the worst moments and constant cleanup of inappropriate content.

I am deeply thankful for their dedication and look forward to continuing to work with this exceptional team on the features that truly matter to London Bus Pal’s future.

Safety Concerns

Perhaps most alarming were the safety issues. Multiple users posted their home addresses in the app (why?!?!?!) or where they were going to school. I tried to use these incidents as teaching moments about online safety, but it became overwhelming. I wasn’t qualified to be an online safety educator for dozens of children, nor did I want that responsibility.

The Final Straw

One user epitomised everything wrong with the system. After displaying consistently unsafe behaviour – posting school details and personal information online – he was banned. This should have been the end of it.

Instead, it became harassment. He created twelve fake accounts that I’m aware of, each time finding new ways to circumvent the systems I’d built. No amount of intervention helped. What started as unsafe behaviour evolved into direct harassment of myself and the moderators.

This past Bank Holiday Monday, he bypassed yet another ban to post more disruptive content. I spent my entire holiday dealing with this one user. It was then I seriously considered closing the comments section entirely.

The Survey and Final Decision

I ran a survey to gauge user opinion, which provided valuable insights – mostly very supportive, but of course, along with the expected abuse. It became clear I was attracting exactly the wrong crowd: people who thrived on negative attention rather than those who appreciated the effort put into the app.

Like a character from a horror movie you can’t escape, on the morning of May 28th, 2025, he reappeared again. His messages – “this time I will be good” and references to his Monday alias “deserving to be banned” – proved he was taunting us. Only he, the moderators, and I knew about that specific ban.

Shortly before 1pm that day, I pulled the plug forever.

Lessons learned

This experiment taught me valuable lessons, though not ones I’d want to repeat:

  • Feature scope matters: What seems like a simple addition can fundamentally change your app’s purpose
  • Community management is a full-time job: One I never wanted
  • 1% of users consumed 80% of my development time: The maths simply didn’t work
  • Some users will never respect boundaries: No amount of technology can fix behavioural problems
  • It wasn’t all bad: There’s still a community we created from this, it was just in the wrong place

Moving forward

Closing the comments section brings incredible relief. I have my weekends back. I can sleep peacefully without worrying about who might post unsafe information online. The constant context switching between development and moderation is over.

I can now focus entirely on what London Bus Pal was always meant to be: the most reliable source of London transport information. The tens of thousands of users who understand how to behave appropriately online deserve an app developer who isn’t constantly distracted by managing a tiny minority of problematic users.

For those who enjoyed the community aspect, our Discord server remains active – a platform actually designed for the conversations that were happening in my transport app.

Final thoughts

I should have made this decision long ago. Sometimes the hardest part of building software isn’t the technical challenges – it’s knowing when to stop. The comments section taught me that not every user request should be fulfilled, not every feature should exist, and sometimes the best decision for your product is saying “no” to functionality that doesn’t serve your core mission.

This chapter is closed. The experiment is over. And honestly? It feels fantastic.

Disclaimer: I wrote this myself, but got AI to help a bit with structure and clarity

Categories
London Bus Pal

Why subscriptions matter

When I was growing up, the world of software was a simpler place. Companies would create an app, burn it to disc and ship it in a box that you bought in a shop. You paid once, installed the app and used it for as long as you wanted, or until your computer couldn’t run it anymore. Companies used to update their software, but it would often be years between versions and usually you would still need to pay for newer versions. It was an entirely different world.

Today, apps are updated continuously – we expect to get updates continuously without necessarily paying for it. Sort of.

I know subscriptions can be frustrating, I get it. When you open an app and it asks you to subscribe, there’s often a sense of “not another one!”. But I would like to share why subscriptions have become not just common, but essential for apps to survive.

The reality of modern app development

Here’s something that might surprise you: even if I never added a single new feature to my app, I’d still need to update it constantly just to keep it working. Every time Apple releases a new iOS version, every time a third-party service changes their API, every time a security vulnerability is discovered, I need to respond. What worked perfectly last month might break completely this month through no fault of the app itself.

This isn’t a case of planned obsolescence or trying to create work for myself. It’s the reality of building software that depends on an ecosystem that’s constantly evolving. The alternative would be to let the app gradually break and become unusable, which serves no one.

The true cost of “free”

When apps were a one-time purchase, that model worked because the expectation was different. You bought software, used it as-is, and perhaps upgraded to a new version every few years. But today’s users expect their apps to work seamlessly across devices, sync data instantly, receive regular updates and integrate with the latest features their phones offer.

All of this requires ongoing work, and unfortunately, ongoing work requires ongoing income. I’m not trying to get rich quick (I wish!). Quite the opposite actually. I’m trying to build something sustainable that can continue to serve you for years to come.

Keeping things fair

I’ve tried to keep my subscription pricing as reasonable as possible. At the time of writing (and this is always subject to experimentation and change to find the right points), the cost of a subscription is £1.49 per month. It’s less than a cup of coffee from Pret with a subscription! (Yes, there’s an irony in that!). I know every subscription adds up for you, and that’s why I’ve tried to figure out something that is fair for everyone. I want the app to be accessible whilst also being able to sustain the development and maintenance it requires.

This isn’t about profiteering, but finding a balance that lets me continue doing what I love whilst keeping the lights on.

Moving forward, not just maintaining

Beyond just keeping existing features working, subscriptions allow me to actually improve the app. What was acceptable eleven years ago, simply isn’t today. I have to find a balance between maintaining the great features of the app, but also to respond to user feedback and making the app more useful for everyone.

The human element

I’m not a large company with teams of developers and massive marketing budgets. I’m just one person (with a few volunteer supporters of the app to ensure accurate data), working to create something that makes people’s lives a little bit easier. If my app can help someone avoid waiting unnecessarily in the rain or get somewhere a bit quicker, that genuinely makes me happy.

When you subscribe, you’re not just paying for software. You’re supporting an independent creator who’s trying to build something worthwhile. That subscription helps me put food on the table, yes, but it also means I can continue dedicating time to making the app better for everyone.

A choice, not a demand

I want to be clear: I don’t force subscriptions on anyone. The app still offers value without a subscription and I respect anyone’s choice to use it however works best for them. But for those who do choose to subscribe, know that it directly enables me to continue developing, maintaining and improving the app.

Looking ahead

Subscriptions have become part of our digital lives not because developers are greedy, but because it reflects the reality of how software works today. Apps aren’t products that get built once and forgotten (in fact, they will be forgotten really quickly if that’s the case). They’re ongoing services that require constant care and attention.

I’m grateful to everyone who uses the app, whether you are a subscriber or not. Your feedback, your reviews and even just the knowledge that the app is helpful in your daily life means more than you might realise. You’re directly enabling me to keep building something that I hope continues to be useful for years to come.

The digital world has changed dramatically in the last decade and I believe that subscriptions, when implemented fairly and transparently, represent an honest way to sustain the software we use often. I hope this gives you just a little bit of insight why subscriptions have become so common.

Categories
London Bus Pal

I am back!

Well, I wasn’t really ever gone to be honest, but I think it’s about time for an update of where I am.

My last post in 2020 was about adding functionality for bus enthusiasts and looking back and remembering where we were then, I feel proud of what I achieved with this functionality. Last year, I did an interview with Riku Fryderyk and it’s well worth a watch if you haven’t yet. Be sure to also check out the rest of their Youtube channel for some great videos related to transport.

The interview was done while I was in Bangkok as I went travelling for six months. We learn a lot from travelling and definitely a big lesson for me was how difficult it really is to work and travel at the same time. Firstly, there’s a balance to be found in between sitting down and working and going out and exploring new things. I found it hard to achieve this balance, because there’s a huge world to explore and only limited time. Then we layer on the time zone differences (I went from GMT +7 all the way to GMT -3), internet and connectivity in different countries, a laptop that was on the brink and constantly running out of space and the pressure of packing and unpacking, figuring out how to get to the next airport or just where to get your next meal. This is all to say that I really haven’t put as much effort into London Bus Pal as I could have, but I have no regrets either as I managed to really experience a lot in this time and from a personal point of view, I really needed a break.

In all of this time, I have had a few volunteers who have helped out with the app to allow me to focus on development work where I had the time. A huge shoutout and thanks to ThatWestLondonBusGuy, VT, c1taro and hdg for really keeping everything going.

I just arrived back in London a week ago and I have already done a ton of groundwork to continue the next chapter of London Bus Pal. There’s a lot of improvements coming and I am grateful that I can be back in this great city and use my own app again. I am energised, motivated and ready to go. The list of improvements is long, so please be patient as I slowly work through everything. I’m very confident that the London Bus Pal of six months from now will be a great improvement on what we have already today.

I will write some updates here from time to time (in fact, I’m literally going to write another post as soon as I post this one, so look out for it).

Categories
London Bus Pal

Devastation of bad reviews

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.

Categories
London Bus Pal

Version history

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 was my first attempt at ever making an Android application. I used Google Web Toolkit which I then rendered in a web view in the application (basically GWT compiles into very optimised Javascript). Not being a fully native app wasn’t really an issue since I managed to successfully do callbacks between the app and the web view, so the app would handle things like a user pressing the back button or doing an in-app search without any hassle. Correctly handling the user pressing the back button is something which stands out for me.

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.

Version 1.1.7 – the “Metropolitcan line” purple stands out.

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

Version 2.1.3

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.2.11 – The final version of the third rewrite

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

Version 4.0.0 – Not made public for Android

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.

What’s next?

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.

Categories
London Bus Pal

What a GDPR disaster!

May 2018 has been a really long and frustrating month in terms of updates to London Bus Pal.  I would never have imagined just how much effort I would need to put into my app when I thought that I was free from any GDPR requirements.

I was on holiday and I saw some emails from Google and then also saw an article on The Register (https://www.theregister.co.uk/2018/05/10/google_gdpr_consent_klaxon/) which pretty much made it clear that I would have to do something.  Upon return from my holiday, I immediately got on the internet and started reading all kinds of horror stories of people building entire consent databases and having to come up with really intricate ways to obtain and store consent.  It felt like it was overkill and like it was completely against what I thought the spririt of GDPR was (less data, not more!).  The panic started to set in as it seemed like this was a much bigger beast than I had anticipated and I started studying the regulation itself, rather than just reading blogs based on third-hand information.  At least it turned out that I was right and that GDPR was meant to limit and reduce the amount of data we process, not process more data because of it.

After reading the regulation and no consent SDK being available yet from Google, I decided to build my own pages to manage this in the app.  I settled on the following requirements:

  • Location permission – I already had to obtain these due to Android requirements and my app works fine without it.  I decided to still build a screen to tell users about it and that they can revoke permissions if they want.
  • Ads – this was the main reason I built this, because it felt like Google was willing to stop us from using AdMob if we did not do something to gain consent.  To be honest, I understand where they are coming from as they would be held responsible if they didn’t insist on us doing something.  The consent isn’t to consent to ads or not, it was basically to use personal data to personalise ads or not.  More on this later!
  • Crash reporting – as I didn’t consider capturing crash reports as a legitimate enough reason to keep my app going, I decided that I had to gain consent to store crash reports.

There is very little else that I do with data – I just take a location or bus route or bus stop request, get the relevant data and show it back to the user.  I really have no interest in obtaining data I don’t need.

So I built my GDPR consent screens and I ran into a bit of trouble.  My crash reporting and analytics tools are bundled together really.  If I switch one off, I have to switch both off.  I then decided to change the wording for crash reporting to something along the lines of tracking expected and unexpected behaviour (the former being analytics and the latter being crash reporting).  I had some issues with the analytics, so I then had to go and find each use and check if I could use it or not before posting something as I didn’t use standard methods everywhere.

Due to the GDPR consent screens being one of the first screens and having to test with different permutations, I decided to just do some manual testing instead of expanding (and fixing) my automated tests.

I changed my AdMob settings to select my own technology providers and I published version 3.2.6 on Wednesday morning, two days before GDPR was due.  Things sort of looked normal, my ad revenue seemed unaffected and even though I could see a bit of a drop in users reported through my analytics tool, the users who still opted to keep crash reporting and analytics on, still had a 100% stability rate.

Over the next two days I noticed some 1-star reviews, two of them were removed before I could get to them and it just looked like someone trolling the updated GDPR screens.  But there were some legitimate ones too and I started to investigate.  I noticed on the Play Store that my app stability had decreased since the GDPR release and I found some specific pieces of code I missed!  If someone had chosen to turn off analytics, I still had some instances where I was trying to track events and it would crash the app.  I asked the users to contact me to give me more detail to help my investigation.

Rushing to get a fix out, I made sure I found all of the uses, fixed it and I released version 3.2.7 on Saturday morning.  I received another 1-star review saying that the app was broken – this review was left for version 3.2.7 and I also received an email from one of my users who confirmed the same.  Frustrated, I decided to take the nuclear option and remove all of my GDPR updates (by reverting the code back to version 3.2.5) and then just serving non-personalised ads.

I have now scrapped the idea of requesting consent for crash reporting and analytics since I believe that this is actually crucial information for the app to work based on the nightmare I had.  I was trying to stick to the “letter of the law”, rather than the spirit of the regulation.  The data I am collecting does not contain enough information to personally identify anyone and I’m happy to have it go under scrutiny.

Today I watched as my revenues plummeted.  This is either due to only serving non-personalised ads or the fact that it’s a bank holiday in the UK.  It’s probably a combination of both – I can see my click-through ratio has gone down and so has my CPC.  So I made another attempt at implementing a quick consent request so that I can at least get personalised ads back on for some of my users.

Effectively, all of the work I have done to implement GDPR in version 3.2.6 and 3.2.7 had to be undone and I started from scratch.  This time also, I have taken a softer approach and just made it a pop-up where you can choose Yes, No or Later – similar to my rating pop-up.  (I still used all of the saved consents from version 3.2.6 and 3.2.7 if it worked, so at least people won’t be annoyed with more pop-ups!).

I’m going to package version 3.2.9 now and publish it to all the app stores.  I am hoping that this is the final version for GDPR and that I can finally get onto other things.  If you are a user who was impacted by my GDPR disaster, I can only apologise!!!

Categories
London Bus Pal

Map views are here!!

I was hoping to get this out there quicker, but rather late then never!

This week I added some map views of all the data to London Bus Pal.  There are four “distinct” views of data in the application, but only three maps are interesting (seeing a single bus stop isn’t the most interesting view!).

Multi-stop view

If you switch to the map view from a list with multiple bus stops on, you will get a view similar to this.  It shows you markers of all the stops near you with their “letter” indicators on, it there are any.  This is a really useful view to see any bus stops in the area or near somewhere else you might be going (try searching by post code).  Tapping any of the markers will give you the name of the stops and where it goes – if you tap on the information box that appears, you will then be taken to the screen to see the estimated arrival times for all buses serving that stop.

Screenshot_2013-09-21-22-20-51

Bus prediction view

The next view that is possible is one showing you a list of all stops for any specific bus over the next 30 minutes and the number on the marker indicates how many minutes the bus is expected to take to get there.

Screenshot_2013-09-21-22-22-27

Bus route view

The last view I want to show you, is the bus route view.  This is a calculated route based on all buses for that route over the next 30 minutes showing their stops.  Red markers indicate one direction and blue markers indicate another direction.  The pins are also arranged so that you can get an idea of which way the bus is going (I will add some arrows soon!)

Screenshot_2013-09-22-09-21-17

If you don’t have London Bus Pal yet, you can download it from the Google Play Store: https://play.google.com/store/apps/details?id=com.mulder.buspal

 

Categories
London Bus Pal

London Bus Pal launched – the ideas

Image

My first Android application was launched on 6 September 2013.  It’s called London Bus Pal.

I’ve had the idea for quite some time, but just never got around to doing it.  Finally, over the summer, I sat down and gave it a go.

The idea was for a bus time predication application which you could just open and it would know what you were looking for without complicated set ups.  It should just load it up and it show you what’s nearby.

I went off and built much of the application which can be seen today.  You could see all stops near you and then drill through items to see specific buses, stops and even routes (the route functionality only came later).

One issue I had, which took a while to sort out, was that the way in which I calculated distance, did not take into account roads, so in my case at home, my nearest bus stop, wasn’t the quickest one to walk to.  So I decided to calculate the walking route for each stop near me and then show the closest ones to me in that way.  Unfortunately, this ended up being a really slow process and I actually had to remove this feature.  It was definitely going to add to the cool factor for this application, but sometimes you just have to make a call and say, it’s not worth it!

So what did we end up with:

  • Stops near me – when you open the application or tap on the home button, the application tries to find your location and shows you all the bus stops in the area with all of their arrival times in the next 30 minutes.  (This does not work if your location could not be determined – there are many reasons for this).  You can expand and collapse all the stops and if you tap on a bus, you get taken to the bus view (see below).
  • Specific bus view – when you tap on a bus in the stops near me or bus stop view, you get taken to the specific bus view which will show you the route details and bus registration number at the top.  You then get a view of the expected time of arrival at all the stops for the next 30 minutes.  This is a useful view for me to keep open and refresh from time to time once I am on the bus, just to check progress.  (A slightly hidden feature is when you see a bit of a thicker line between two stops – this means that the bus changed direction between these stops and it will be heading back to where it came from).
  • Bus stop view – this is similar to the stops near me view, except you only see a single bus stop.  It simply shows you the next buses for any stops for the next 30 minutes.
  • Bus route view – this is a fairly unique view which I haven’t seen available on many other applications.  First, to access it, tap on the bus route details on the top of the specific bus view or enter a route number in search.  This gives you an overview of all the stops on the route, in route order and it shows you when the next bus is due at each of the stops.  It’s quick to see if there is a gap in the service anywhere between stops using this view!
  • Search functionality – this acts as a “short-cut” to many of the views mentioned above.  By entering a post code, or GPS co-ordinates, you will get the stops near me view (but for the entered location), enter a bus stop number (which you can see on the side of the bus stop) for the bus stop view of that bus, enter a bus route number for the bus route view and enter the bus registration number to find a specific bus (I have to point out that this does not work on customised number plates and I believe that some of the New Buses for London have custom number plates).

I decided to stick with this core feature set for now and get the application out there.  There are still many features which I think would make the application truly great, but these will have to wait a while as I only have ten fingers to type with!  As it stands, the feature set is very usable and I use this application constantly and very seldom use any of my competitor applications.

Some of the features I will be working on in the coming weeks and months include (if you are reading this in the future, be sure to check out the latest feature set of the application as this would hopefully not always be work in progress):

  • Bus stop notifications – sometimes TfL puts out alerts or notifications for specific bus stops or routes.  London Bus Pal doesn’t currently display these, so it’s difficult to know if there are any issues affecting your local stop.
  • Map view – being able to see bus stops on a map, especially for the stops near me feature would really add great value to the application.  Sometimes I am also on a bus and I wonder if I could get off early or I am just on a strange route and I want to see which stop I should use.  Being able to see that on a map would be a lifesaver!
  • Strip-maps (maybe) – this would just be a cool feature to have – to see buses on a strip map.  I’ve got some really cool ideas for this.
  • Bookmarks or favourites – most applications have this and they tend to be useful.  We all have our favourite stops and it’s always great to have these ready.  Hopefully the “stops near me” facility partly fulfils the requirement for this feature until it is actually implemented.

If you came across this blog and don’t know what I am talking about, you live in London (or sometimes travel to London) and you have an Android phone, then why not download London Bus Pal: https://play.google.com/store/apps/details?id=com.mulder.buspal.

Looking forward to loads of downloads 🙂