Room for improving usability and reliability
Let me start by saying that I'm a regular user of public transport. Sometime last year, BMTC released a mobile app that's meant to give users accurate and timely information about bus routes and arrival times. I've been using this app for a few months now. It's particularly useful on routes where buses are few and far between. An accurate foreknowledge of arrivals can save commuters from long waits. How does this work?
Each bus is fitted with a GPS transceiver. The location of each bus is conveyed in real time to a central system. Actually, the update happens every 10 seconds. Once the system is updated, users can query the system from their mobile apps to know when a particular bus is arriving at their bus stop. A more detailed narrative was published recently on Factor Daily. They also published a basic review of the app itself.
The app has its problems, mainly from the perspective of usability. The system itself has reliability issues. Let's look at these one at a time.
Takeaways from Alexa Dev Day, Bangalore
Voice-based interfaces are all in rage right now. On one side tech is being driven by Machine Learning. On the other side, speech-to-text, text-to-speech and Natural Language Understanding are complementing it from the perspective of user interfaces. This is not to say that keyboards and touchscreens are going to go away. It does suggest that there are many applications where sight and touch can be freed for parallel tasks while you converse with your apps using voice.
Some of the speech agents that power voice-based interfaces are Siri, Alexa and Cortana, just to name the well-known ones. Today I had the chance to attend Alexa Dev Day organized by Amazon Alexa team. Similar events are scheduled to happen all across the world in the coming weeks. The event hall was packed, mostly with developers, and mostly with those who already owned Echo devices. I found this to be the key differentiator with Alexa. Amazon has managed to get Echo devices into a number of homes and offices. Early adopters perhaps bought them for the novelty factor but thanks to them, basic uses cases have been shown to work. Now there's sufficient interest from developers to reach this bunch of Echo owners and beyond to interest them with innovative apps. Novelty therefore is moving from Echo hardware to apps powered by Alexa. I met someone trying to do railway ticket bookings with Alexa. A couple of guys from Sulekha are exploring voice-based hyperlocal searches. Another person is looking to give first-aid advice and emergency care.
Authors: Lea Verou
Publisher: O'Reilly, 2015
Front-end web designers have to know CSS very well in order to create styling that's effective and maintainable. This is easier said than done because CSS is a complex language. To be good at it, one must learn from the masters and Lea Verou is one of them. The author presents those parts of CSS that are not obvious. She uses CSS in very creative ways to overcome limitations in the standards. Readers should already have some grasp of the basics. When they are ready to take their knowledge to the next level, this is a book that they cannot miss.
The book itself has been designed using CSS. The secrets are presented as solutions to well-stated problems. There are 47 secrets in all but readers will learn a lot more than these. All examples can be tried interactively online and the links to these examples are conveniently placed at the end of each section. Readers are of course at liberty to use their own tools (such as http://jsfiddle.net/) to try out the examples. This implies that we can learn the secrets by practice, which makes the book all the more enjoyable.
What we commonly label as "disruptive" is often the result of breaking the status quo. Disruptions seem to have their cycles and a few important ones come to my mind. In 1800s, we invented steam engines, cracked the math of thermodynamics, giving way to a number of derived industries: factories, locomotives, mills, etc. The lifecycle of this innovation reached its destiny sixty years later with the first ever depression. People could have been smarter and learned their lesson. But they became smarter by inventing Electricity and Magnetism just eight decades later (1880s) than the invention of steam engines. That disrupted status quo and rapid electrification took place across the world. Another eight decades later (1960s) we got transistors, computers and the beginnings of the internet. Six decades since then (2020s), we are in the cusp of another cycle. The sure candidate for next disruption is AI along with bio/nano technology.
I notice a pattern here. All disruptions happen when the previous one is mastered, done and dusted. Today we are within arms length of reaching the limits of Moore’s Law. The situation is primed for the next disruption. Amidst the evolution on doubling computing power every year and a half, the silent winner has been an exponential increase of data over the same period. Every computerized establishment saved cost, did more of the same (old) business in the same business year. Well, we homo sapiens, are too smart to run same (old) businesses. We leveraged data for intelligence and built new markets, new products and new strategies. In the last 2-3 decades of the recent technological cycle, we have progressed enough on big data technologies to enable the next disruption.
Powered by Multi-access Edge Computing (MEC)
Until a few years ago, for many decades, telecom operators had been claiming that all they provided was a "dumb pipe". It was not their concern what those pipes carried; and they were not responsible for content that was served or consumed at both ends of the pipe. Their main goal was to ensure that the pipes had enough bandwidth to serve average and peak traffic requirements. All was well and good until over-the-top (OTT) content starting dominating the market. Such content bypassed legacy circuit-switched services and value-added services provided by the operators.
Indeed telecom operators started to lose both ends of the bargain. They now wanted control over the content and charge a premium but all they could collect from their customers was for bare bits and bytes. In a price-sensitive market, "unlimited plans" became the order of the day. When OTT content became predominant, operator revenues started to drop. Content also became rich in multimedia, particularly video that congested backhaul links. Operators couldn't afford to upgrade these backhauls. Yes, operators were providing dumb pipes but apparently even these had a hard time keeping up with demand.
Learnings from Mobile Growth Bangalore Meetup
If you're a beginner to the world of mobile apps, you may be looking for someone to guide you. Developing an app and getting it out on the app store is only the start of a long journey. Many questions will hound you from the start. Why are so few users downloading my app? Why do many users stop using the app within a few days? Why are users not making purchases via the app? Why are users not using the app as often as expected?
Obviously, all these questions cannot be investigated at the same time. Where exactly should you focus your efforts and budget? How should the issues be prioritized? Is it a matter for developers, digital marketeers, product managers or customer support staff? Wouldn't it be nice if there's a community of mobile developers to share and exchange best practices? That's exactly what Mobile Growth provides.
If there's one thing that's unique about being human, we can't deny that it's speech. Sure, animals have a way of communicating but that's not in any way as refined as we humans do. The key lies in the way we are able modulate sound waves with the rolls and wags of our tongue. Perhaps, it's for this reason we have phrases such as "mother tongue". Aural communication in the rest of the animal kingdom is limited to coarse sounds that we simply name as moos, grunts and hee-haws. But it's not going to be long before we lose our monopoly of speech.
The best machines could do in the past were beeps and alarms. Those of us who have lived through the times of early fixed line modems can recall the staccato of beeps as they tried to handshake and establish a connection to a server somewhere on the internet. Of course, machines also talk among themselves silently, by parsing bits and bytes. But now the time has come for machines to talk directly to humans via human speech.
Achieving Meteor 2-second rebuild time for £830
This was my purely hardware solution to the problem of slow Meteor build times.
When I decided to get into development I was adamant that I wasn’t going to run out and buy the latest and greatest in hardware until I actually knew how to code and knew what my requirements were in the long term.
So I went out and bought a used 15" Acer laptop for £150. It had the following spec:
- Memory: 6GB RAM
- Processor: Intel Pentium CPU 6200 @ 2.13GHz (Dual Core)
- OS: Ubuntu 16.04.1 LTS 32-bit
- Storage: 153.5GB HDD
With this setup, I saw rebuild times of 15-30 seconds (including the browser refresh) of a side project using Meteor 1.4, React and a Mongo-db instance with around 1500 records. I found these times to be excruciatingly slow when it came to making multiple changes to my code and waiting to see the results. You can see the initial version of the project I was working on here.