BUZZSTOP

Biceps in this image may appear larger than in reality (lens distortion)

Biceps in this image may appear larger than in reality (lens distortion)

I had the opportunity to be apart of the Moonshine Laboratory GovHack team this year. Over the  48 odd hours we had to build something using public datasets we came up with BUZZSTOP.

With comprehensive public transport data available its time to start thinking about how that information can be used to help the commuter when it is relevant. For all of that data only a small sliver is needed at one moment but that data is invaluable. Checking the weather in the morning using an app is so quick and simple which can mean the difference between a jacket or a raincoat. Being able to see realtime arrival times can change if we have enough time to drop into the shops on our journey him or if a second service will be waiting at an interchange.

This project wasn't necessarily about the app itself. My objective was to focus on the use of the data, to show how invaluable it can be even for the everyday commute. Using Bluetooth beacon technology will allow identification of a stop or a vehicle to contextualise the important information without user intervention.

Moreover, making the contextual data available automatically will allow commuters with vision impairments to be able to use public transit with more confidence and efficiency when only the absolutely necessary information is displayed (available with VoiceOver) without the presence of potentially irrelevant, disruptive data.

This is only the very tip of a deep, churning iceberg. From the introduction of such a small passive device and idea of how to use the data we can achieve such a wealth of information and efficiency to improve our interaction with public transport.

↬ WWDC 2014

This year, in lieu of a golden ticket to San Francisco, I had the opportunity to organise a meetup in Adelaide to watch the Keynote live at 2:30am. Not expecting more than a handful of people to turn up at 2am on a weekday morning, I was surprised to have 12 other Apple enthusiasts in town rock up. So with some comfortable chairs set up, enough sugar and Red Bull to keep us awake for at least 24 hours straight we watched the live stream over the Apple TV.

IMG_1973_2.jpg

Because these individual blogs have separate RSS feeds you may not have seen this post.

Commonwealth Bank to introduce smartphone ATM withdrawals

Commonwealth Bank will allow customers to withdraw cash from ATMs using their smartphones for the first time, under a new update to the bank’s mobile apps.
— James Hutchinson, linked

Interesting to think if this will coincide with some third-party Touch ID capability to further increase security of these kinds of withdrawals.

Bank smartphone apps in general would greatly benefit from a basic authorisation feature provided by Touch ID.

"Siri, how many days until WWDC?" — 33 days.

iBeacons and Location Privacy

One of iBeacons greatest attributes is that it allows end-users to control their location privacy and still benefit from location awareness in applications. With the shift from GPS coordinates to the presence of a physical iBeacon it no longer requires persistent location awareness or allow an application to track precise location information at will.

With iBeacon, end-users need not worry that a particular application may be snooping their current location or if that data is visible to anyone else as it goes through 'the wire'. A huge relief in light of the revelations around the NSA programs.

Unfortunately, this concise differentiation isn't passed on to the end-user in iOS. When the application requests to monitor an iBeacon region what the end-user will see is the same request for an application to access their current, precise location.

IMG_0032.PNG

Whilst it is somewhat accurate, an iBeacon is fixed to a particular location, it doesn't convey that when outside the receivable region of the beacon the application has no way of tracking your location if its only using Core Locations iBeacon regions. However, I believe this clear differentiation needs to be expressed properly to the end-user to inform them about the applications intent and capabilities with what its requesting. A basic example of the OS handling this would be a message like so.

IMG_0033.PNG

This would require that inside of Core Location the request is expressly for — all or mixed options of — iBeacons, GPS locations or Geofencing which is then reflected correctly in the message. However, this may be a problem because of the current implementation of region monitoring is that it can be made at any time in execution. Multiple and mixed region or location monitoring requests may be made independently of one another and not combined in one alert message. This will not be a viable solution for an OS initiated message.

At this time and most likely into the future it will be the responsibility of the developer and their applications presentation to clearly convey their intentions and usage of iBeacon regions. When using iBeacons the request reads the same as "I want your GPS location whenever I want" which is — rightly so — becoming more frowned upon by end-users.

Its up to the developers to be responsible about their location information requirements and educate the end-user consistently as a whole so this truly magnificent technology can be widely adopted and — most importantly — trusted by end-users to reduce the need for GPS location awareness.