After some back-and-forth with the manufacturer, they agreed to send me their Android SDK and documentation. Sadly, the PDF they sent me was riddled with errors and the software library is also a bit dodgy. So, with the help of Edward Toroshchyn and a hefty amount of automated boiler-plate, I managed to get it working.

The full code is open source, but here's a quick walk-through of the important bits.

First, the AAR library needs to be imported into the project. Place it in app/libs and then include it in the Gradle build file:

dependencies {
    implementation(files("libs/badge_nfc_api-release.aar"))
}

The key to getting it working is in the Android permissions. It needs Bluetooth, NFC, and location. So the manifest has to contain:

<uses-permission android:name="android.permission.BLUETOOTH"/>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-permission android:name="android.permission.BLUETOOTH_SCAN"/>
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT"/>
<uses-permission android:name="android.permission.NFC"/>
<uses-permission android:name="android.permission.NFC_TRANSACTION_EVENT"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

The following imports are needed from the Android Archive library:

import cn.manytag.badge_nfc_api.manager.BadgeWriteManager
import cn.manytag.badge_nfc_api.manager.OnNFCReaderCallback
import cn.manytag.badge_nfc_api.manager.OnBluetoothCallBack
import cn.manytag.badge_nfc_api.manager.OnSendImageCallback

The library needs to be initialised with:

val state = BadgeWriteManager.getInstance().init(this)

When the phone reads the NFC tag, it gets a bunch of information:

BadgeWriteManager.getInstance().setOnNFCReaderCallback(object : OnNFCReaderCallback {
    override fun onReaderMessage(i: Int, tag: Tag) {
        if (i == 0) {
            BadgeWriteManager.getInstance().readNFC(tag)
        }
    }

    //  Get the data from the badge
    override fun onReaderType(tag: Tag, isodep: IsoDep, i: Int, type: String, size: String, color: String) {
        if (i == 0) {
            nfcData = """
                NFC Tag Detected!!!
                Tag: $tag
                IsoDep: $isodep
                Type: $type
                Size: $size
                Color: $color
            """.trimIndent()
            colorFromNFC = color
            tagObject = tag
            isoDepObject = isodep
            badgeType = type
            badgeSize = size
        }
    }
})

The color is most important right now. It says whether the badge is black and white, or black and white and red, or black and white and red and yellow.

After picking an image from the filesystem, it needs to be dithered into the correct colour format:

processedBitmap = originalBitmap?.let { bitmap ->
    colorFromNFC?.let { color ->
        BadgeWriteManager.getInstance().processImage(bitmap, color)
    }
}

Finally, the processed image needs to be converted to bytes and then sent to the badge via Bluetooth:

if (processedBitmap != null && badgeType != null && badgeSize != null && colorFromNFC != null) {
    val imgData = BadgeWriteManager.getInstance().getImageData(processedBitmap!!, colorFromNFC!!)

    BadgeWriteManager.getInstance().sentImageResource(
        tagObject!!, isoDepObject!!, imgData, badgeType!!, badgeSize!!, colorFromNFC!!
    )
}

I realise this is a bit "draw the rest of the owl" but that should be enough to get you started on building an app which can communicate with these badges.

The app I've built isn't the prettiest in the world but at least it works. It scans a badge, gets its info, picks an image, dithers it, then sends it to the badge.

You can play with the code on CodeBerg.

Sometimes it is easy. Analytics show no one is using this feature? Drop it.

Sometimes it is hard. It's a moderately well used feature, but complicated to get running on a new environment. If you keep it - that's a huge extra cost, for marginal utility. If you drop it - die-hard users will complain.

So we come to Philips Hue. I've long been a fan of these smart lights. They've just released a completely redesigned version of their app. And, over on LinkedIn, the designers and product managers are congratulating each other on a job well done.

But reading the reviews and looking at the social media chatter shows a different story.

One of the app's best features was their Android Widgets. I had a row on my homescreen with buttons for each room. Tap the bedroom - lights go on. Tap it again - lights go off. Perfect!

The new version deleted all the widgets, with no way to recreate them? Why? Because the iPhone app can't have widgets, so no one gets them. I wish I was joking.

Philips Hue

@tweethue

@myotheralt Hi Jon, thanks for reaching out about this. We've decided to discontinue the separate Hue widget to focus on bringing more functionality to Siri Shortcuts as it offers more extensive functionality. Same goes for Android. :)

---

Perhaps this is a tiny kerfuffle? Sure, there are lots of users complaining on Twitter - but perhaps they're a vocal minority?

A check on the app's Google Play store rankings tells a similar story. The app used to have an impressive 4.5★ rating. Now it's barely hovering above 3★.

That's a significant drop considering how many people have installed it. The reviews on iOS are also suffering (although it's not possible for me to sort by date on them.)

Tom Singer

@tomsinger

Replying to @edent@edent I can sort by most recent using my iPhone, they have the same level of praise as Android! pic.x.com/Ko0n1wSsFQ

---

I get it. I truly do. Philips couldn't afford the expense of maintaining an Android and iPhone version of their app, so they rewrote the whole thing in Flutter. That way they only have a single code base to worry about. I daresay that iOS is their biggest user-base, so anything which is too hard for Apple to support gets dropped. From a purely business perspective, I guess it makes sense.

But this is an app used by people who have made a considerable investment buying into the ecosystem. The bulbs are not cheap, and they're installed in people's personal homes - so when the app screws them over, it feels like a slap in the face.

Removing features is an insult to your users. It is an insult to people who have paid good money to you, and who have spend significant time learning how to use your product. When you remove functionality, you're telling your customers that they've wasted their time and you simply don't care.

Programming computers is hard. Keeping people happy is hard. Upgrading systems and retaining compatibility is hard. Removing functionality makes life easy for you - but, guess what? Your job is to work hard to make things easy for your customers.

I have a Pioneer / Onkyo sound system. It's pretty nice and comes with a (not too crappy) Android app to let me remote control it.

One day, the app updated itself. The changelog was the usual bland "bug fixes and improvements" message, but when I opened it, this happened:

Why does a remote control need to know my location? I assumed it was for some marketing bollocks, so I refused permission. Then the app refused to work.

Let's ignore the grammatical atrocities in the pop-up. Something that was working fine and is now broken because the app developer didn't think that people would dare refuse their demand for sensitive data.

I complained, along with several other users. A few weeks later, they published an update:

The new app works even if I don't give it permission to track me. Result!

Cause #1

The first mistake was Pioneer / Onkyo. They should pop up a message saying "Hey, we would like your location so that we can..." and then let the user make an informed choice as to whether to grant that information.

If the user refuses, gracefully degrade and provide some other way to accomplish the task manually.

Cause #2

Google, in its wisdom, has tied "Location" into things like BLE Scanning and WiFi scanning. The excuse is that you can use these things as a proxy for location. That is, if I know you are near access point X your location is probably near Y.

I appreciate that. But is there a better way to request the permission? "Allow WiFi scan? This might share your location." That's probably not the best way to word it - but the current situation just confuses and upsets customers.

This is a much complained about problem with Android. And one which won't be fixed anytime soon by Google.

Permission to speak freely

In the bad old days of Nokia, apps constantly asked for permission. It was a running joke that the web browser app would ask for permission to connect to the net, and then ask if you really wanted to connect to a secure website.

You think I'm joking? This was a common experience on Symbian:

Android and Apple were meant to free us from this drudgery. With their carefully curated walled gardens, and double-checked apps, there was no need to bother the user with requests for permission.

Then this happened: App developers abused that trust and started cramming in needless permissions in order to exploit the user.

Users don't want to have to think about this. App stores don't want to police the apps they stock. Developers don't want to put friction in the user journey. Regulators don't want data being shared without consent. Users say they want to manage their permissions, but don't really understand the consequences.

What a mess! Perhaps I should find some AA batteries for the physical remote instead...?

So, when they announced their new app, I was expecting something a little bit special. And that's exactly what I've got.

An automatic torch to help you when you're rooting around in dark cupboards trying to read your meter. Brilliant.

So, not only does the app fulfil its main purpose (submit gas & electricity meter readings, see my bill, etc), someone has obviously taken the time to see how the app works in the real world. Sure, there are plenty of standalone torch apps in the world - but this is the first time I've seen one so thoughtfully integrated into an app.

Ultimately, this app is probably going to be used once per month. It needs to be simple enough to use that the customer doesn't have to relearn how to operate it every time. More than that - it needs to be delightful to use.

As much as we would all love our users to open our app several times a day, the reality is that they won't. That's why we need to concentrate not on beauty, not on overall UX, but on tiny moments of joy which reminds people why they should keep our app on their phone and keep coming back to it.

Typing your username and password into a third party site is bad idea. A really bad idea. I mean, you may think it's a bad idea to give your bank details to a Nigerian prince but that's just peanuts compared to giving away your password to an untrusted site!

So, that's why we use OAuth. Rather than handing details to a random site, we authenticate against a trusted site which then redirects us back with an authentication token.

That's all well and good on the web, but on mobile apps it becomes a little more difficult.

This is the popular mobile game Temple Run. After dying in the game (as I frequently do!) you can Tweet your score. But, first, you need to connect with Twitter.

However, clicking the button, presents this screen: This is a pop-up within the game. What you see in the screenshot is the totality of what the user sees.

There are now two important questions:

1. How can the user tell if this is the genuine Twitter site?
2. Why is there no indication that the site is served over HTTPS?

This is a clear anti-pattern! We're teaching people to give over their usernames and passwords to sites that appear to be genuine - yet offer no way to validate their legitimacy.

We've been trying to educate people to look at the URL bar - to check that they've visited the correct site and that there's some form of SSL verification (commonly a padlock).

I'm not suggesting that Temple Run is doing anything other than pointing to the correct site. Just that they aren't giving the user a chance to verify the authenticity.

How To Solve This Problem

I haven't the foggiest! Thoughts?

We can't rely on the user having the Twitter app installed and firing via intent (or similar). Due to the huge variety of phones and Operating Systems, there's no easy way (that I know of) to redirect from a website back to the app. There needs to be a way to keep everything in-app to keep the user experience.

So, come on then oh great minds of the Internet, how do we fix this?

Customers don't understand your company's acronyms, processes, or business model.

It's worse than that, though - most users don't even recognise your company's name!

Here's a great example. In Zinio's world, everyone knows who Zinio are. They live in Zinio town, drink Zinio coffee from the Zinio shop. ZINIO! It's the first thing on their minds when they wake up, and what they dream of in their Zinio beds.

They are completely disconnected from the real world. They just don't understand how non-customers see them.

Which leads to this disaster.

Zinio have placed a button on the PlayBook - and, apparently, have never tested it with a non-Zinio aficionado.

The first thing to note is that no one is ever going to click on that icon. Neither the name or the graphic hold any interest to people who don't know what Zinio is.

Most normal people just don't go around clicking random buttons to see what they do. Computers are mysterious and pressing the wrong button could easily break them.

But, let us imagine that a curious user hits the button - what should they see?

A splash screen? An explanation of why Zinio is awesome? A demo? A fully working application which - later - prompts them to create an account?

In short - the elevator pitch. The trailer. The hook. Call it whatever you want - you need to make people give a damn about your product.

There's an excellent talk that Mark Curtis of Flirtomatic gives about the sign-up process. In it, he describes how sign ups to the service rocketed once they minimised the amount of information they asked if a user. Why would a user give over any information without understanding what's on offer?

In the case of Zinio on the PlayBook, there's a complete absence of understanding of a normal user.

• The icon is meaningless.
• The name is unfamiliar.
• There's no way of knowing what the app does if you open it.
• There's no incentive for the user to register.

Would anyone - who didn't already know about Zinio - ever sign up to this?

I wonder who is paying for this deal? Is it RIM paying to have a killer app on its PlayBook? Is it Zinio paying RIM to access all their customers? In either case - it looks like a wasted opportunity.

First thing's first, this is a great idea for a QR Scanner. It saves all your scans - so you can retrieve them by category, it checks to see if links are safe to click on, it allows you to share scans with friends, and it also has a gameification element.

But I really don't like it. It's slow to start up, has a UI which is only really suitable for iPhone users, and has some basic usability flaws.

On With The Review!

The first thing you have to do is set up an account? Why? I just want to scan me some QR codes! I now understand that there are a bunch of social features - but that's not explained here. Just "give us all your personal details for some unspecified purpose." Hardly encouraging.

The email field doesn't tell the Android system that it's for email - so there's no @ key present on the keyboard. Annoying oversight.

It gets worse. There's a password field which doesn't tell the user the password parameters! How long does my password have to be? Do I have to use mixed case, numbers, symbols? What? So, of course, after submitting, it tells you that you did not pass the stringent password requirements.

As a side note - if you were sending an email to people who had registered on your mobile app, would you make the email mobile friendly? QR Pal didn't. I don't understand why. They know this email is probably going to an Android phone, why didn't they make sure the email looked perfect on the device?

So, on to the app itself... This, may I remind you, is an Android app. Yet their UI has been lifted wholesale from their iPhone app.

The UI will be totally unfamiliar to anyone who is used to Android apps and the way they work. Pressing the Android's menu button does nothing.

Even the settings page is iPhone-styled.

Scanning codes is as quick as any other scanner - and seems to work as well.

Now, I say "quick", but you have to wait a good 5-10 seconds after clicking the app's icon before you can scan. Why? Because you have to see their splash-screen.

Now, there are a few nice features - checking to see if a URL is likely to be harmful is one. Of course, it means that you are sending all your scans back to the QR Pal mothership. I wonder what they do with them all?

Once a code is scanned, it's saved in your wallet. Scans are grouped by category. Sadly, they don't check for duplicates.

Conclusion

The thing is, QR Pal is chock-full of good ideas.

Integrating with Twitter, LinkedIn, and Facebook is a smart move.

Checking links for safety is a bit of a gimmick, but a good differentiator.

Their live map of scans is cute - although the app never asks for my location.

They have a "points" system - but it's never really explained why, how, or what it's for.

You see - every idea they have is good, but none of them seem fully realised. Making the whole UI look like an iPhone app makes Android users feel like they're an afterthought. I doubt it will play well on BlackBerry and WP7 when they launch.

But the absolute killer, for me, is the start-up time. When I want to scan a code, I want to scan it right there, right then. I may be on a busy street, about to get off a train, or taking someone's business card. I do not want to watch QR Pal's splash screen.

My preferred scanner ZXing for Android starts instantly. It doesn't do all of the fancy stuff of QR Pal - but it doesn't need to. It's quick, simple, and all the features work.

QR Pal is a great idea for an app. But they need to fix the UI, start-up speed, and finish the features they've started. Once it's done that, it will be an excellent app.

My second app presents a series of buttons which call the USSD commands - so you don't have to remember if it's the HLR or VLR which is queried by *#103#.

Useful, I know....

You can download the app by scanning in this QR code.

Android App - Vodafone UK USSD Commands

The majority of these codes only work on phones with a Vodafone UK SIM who are on the Vodafone UK network. I've no idea what the codes do on other networks.

A detailed explanation of the commands is available on Betavine.

Sadly, Android provides no native way to capture or interprate USSD responses. Please star the feature request if you're interested in seeing this in future versions of Android.

One last thing - this app was neither designed nor approved by Vodafone UK. It has nothing to do with them!

Terence Eden is on Mastodon

@edent

Here at @nesta_uk for What's App a look at the emerging app economy.

---

It was an excellent panel - despite being a bit stale, pale and male.

But I can't help feeling that the central premise of the event was flawed.

We were meant to be discussing the "emerging economy" of mobile applications.

Emerging

Emerging? Mobile apps are beyond that. They have emerged. They are mainstream and they have been for a while. Vodafone* has been selling apps for nearly 6 year. Other mobile operators have been selling games, application, tools, utilities, ebooks, and other apps for just as long.

And it has been profitable.

Economy

Ah, that word, "profitable". I'm not an economist, but I would have thought that an economy requires the exchange of money somewhere along the lines.

The vast majority of downloads from app stores are free. Now, undoubtedly a few of those free apps lead on to purchases - but not many. (See Tomi T Ahonen's amazing dissection of the hype).

Then there's the pricing of the applications themselves.

A game like Angry Birds (which seems to be a favourite) costs around 59p. A few years ago it would have sold for £4.99 via an operator store. 15 years ago the same quality game on the MegaDrive would probably have cost around £35.

Cheaper prices are good for customers - but are they good for the economy when the price continually trends downwards?

So we have a range of apps with an average price of £0.00. Of those that cost, the monetary sums are very low. Making money from apps is a fool errand.

So, who is making money?

The developers aren't - not in any significant way.

The payment gateways aren't - 30% of 0 is still 0.

Advertisers are - lots of adverts on apps which are given away.

The device manufacturers are - they can sell more hardware on the basis of freely developed 3rd party content.

The operators are - they're selling more phones and more data bundles.

So what (if anything) has changed?

Open

What the app space hasn't been is open. True, anyone could develop a J2ME or S60 app - and many did. But getting them distributed was always hard unless you could do a deal with a major publisher.

Now, the middle-man is (nearly) gone. The developer can submit their work to a central app store and have it in front of potential customers. Almost instantly.

Quality

Because there are many more highly-spec'd phones and SDKs have improved immeasurably, there's been an outpouring of new developers.

But are they any good?

In the bad old days - when people actually made money from apps - there was a quality threshold.  If an app was buggy or crap, customers would ring up a call-centre and demand a refund.  That's costly to a company, so naturally the bar for apps was set fairly high.

It also encouraged conservatism - releasing a beta app with experimental functionality was a risk.  Few people would buy it and the cost of refunds could be horrendous.

Now, we have everyone and her sister developing iFart apps.  Reading the reviews of paid-for apps can be quite depressing - constant tales of broken or missing functionality.

So, we have a decrease in price and a decrease in quality - but a rapid increase in supply.  Rapid to the point where developers struggle to even give away their product.  Is this a healthy economy?

What's Next

Despite my grousing, I enjoy living in a world where anyone - even me - can develop an app.  The financial rewards are more like a lottery than a business, it's true.  The rewards to society where a company can take a punt on a product like AudioBoo are immense.

But can it last? I've no doubt that this current boom will mirror the home-computer boom of the early 1980s.

The fragmentation that bedevilled that market will weaken the mobile marketplace - even with initiatives like JIL and WAC.

We'll probably see another Codemasters emerge from Britain's bedrooms - and the rest either get bought out or fail.

But I bet they have fun doing it.

Disclaimer.

*I work for them but this blog is a personal comment. Please set your bias filters accordingly.