I still have a lot to say about the LUUP app, but I see light at the end of the tunnel when someone in the LUUP company is willing to listen to 🔗my complaints and concerns. There has been some progress through several updates. So, it was another attempt to share my thoughts when unable to return the bike at the port due to the unresponsive app.

This happens a lot actually, but I rarely report it because (1) I just can’t. (2) I don’t want to waste another 5 minutes. (3) I’m so angry.

The problem lies in its feature that requires us to send the issue report from within the very app where the issue originates, while it is currently ongoing.

It keeps telling me “Try again” forever when I’m trying so hard to return the bike. Do I need to try harder? But when you’re rejecting me from accessing your server, how can I “Return and report a ride problem”

Thank you for your support as always, I appreciate it. I’m not sure I really needed the refund, as your service was overall worth paying for, despite the issues with the app.

By that report, I wanted you to make it make sense to everyone having the same experience with the built-in report form within the very app where the ongoing issues originated. More precisely, it goes like this:

When finally reaching the screen with the unresponsive “Return and take a photo“ button at the end of all other struggles with the unresponsive processes, it’s always accompanied by another bad boy sitting right above, saying “Return and report a ride problem”.
Maybe this is not the first time seeing it, but a situation makes regular stuff look different, and people might think, “Well, should I press the ‘report’ button instead of the ‘end’ one? It can immediately help me out of the situation, or will it just create another loading icon? Or even worse, it can take me several steps back. Hmm…let’s do it and see what happens next!

So, this is how I got here. And I can imagine there are so many people you never hear from about this. Things would be different if given a separate channel for reporting issues that is located outside the app and has guaranteed access even in those conditions, typically, like something that runs on a browser.

Regards,

It’s highly expected to see some development shortly for this specific issue, as there are easy “solutions” for it, like changing the screen layout to return a vehicle or replacing/refining the report form. But I don’t expect to see the fundamental solution, even though it’s obvious what it would be like.

Yes, it’s obvious. The root cause of the app’s disastrous performance, especially during LUUP’s busy hours, is obviously due to the overloaded server traffic caused by the persistent, unintended, and UNNECESSARY accesses by the massive numbers of users, such as loading the geographical map, looking up the status of vehicles/ports in the specific area. They are mildly big data as a whole, which counts up to approximately 5K-20K ports and 20K-100K vehicles across the nation. If you were to observe every single unit’s real-time status, the total amount of network traffic would be like watching a livestream video in low-middle resolution. Do you need it as a user? Of course, no. You only need to get a bike at point A, ride it, and return it to point B.

But most of you would notice your phone’s unusual behavior from the moment you click LUUP’s turquoise icon. It casually initiates some aimless map lookup for detailed information of vehicles, ports, or whatever had been set as the default screen stuff in the previous session, supposedly. But actually not sure, as I sometimes see random crazy stuff, such as the Australian or African continent. The typical normal one would be an available vehicle map in a 2 km radius of your current location, but is it really “normal”? When people inherently have vastly different normalcy, and how people make individual use of LUUP amplifies the distribution range of average LUUP user’s normalcy, there is no appropriate initial screen stuff considered as “normal” IMAO. But okay, it just routinely does this only for the sake of drawing some stuff, even if it was clearly wrong, some extravagant map nobody wants to see. While there’s no user input, it continues to produce purposeless “normal” screen updates as you walk, take a train, or even drive on a highway.

Now it’s time to get done with your real task, such as printing a receipt or returning a bike at the destination port. These are such simple tasks that it may take only 15 seconds through a couple of clicks on designated buttons, which has nothing to do with 100 Mbit/s networking. But your phone thinks differently. He is such a dedicated, hard-working servant who is always up and ready to show you where and which vehicle you can grab among 4,000 candidates waiting for you at 400 ports within a 10 km radius. So he carefully watches every single motion your fingers make, detects any slightest touch on the screen, and immediately checks up on their status to redraw the map.

This is why it takes 150 seconds, not 15 seconds, just to return a bike. You see at least a couple of the error messages saying “Try again”. So you click on it, he re-sends your GPS, re-looks up on the server to validate the port and bike’s status, and then fails somewhere in the process…Repeat from step 1…
The important thing here is that your unwanted server access is disrupting not only your own task, but also all other users’ tasks online. You unexpectedly became one of them through the app’s arbitrary network access. No one wants to be part of it, but the app just forces you to be.

At some point, you may also realize how financially expensive it has been for you, seeing how much GB your phone consumed just for a few rides on LUUP. Take a look at my phone’s monthly traffic report in the image below. I’m not a super heavy LUUP user, but the extra bill for my phone costs more than the LUUP’s monthly subscription fee.
I assume 90% of it could be eliminated by optimizing the app’s outrageously lax bandwidth usage.

＃LUUP ＃BikeSharingServices ＃eSchooterTokyo