Tag Archives: Apps

#Jafac picture

#JAFAC – Don’t Miss It Next Time

I had the privilege to speak at the very first edition of #JAFAC hosted at the fantastic GRIDAKL. Many people requested that speakers share their slide decks. Since there’s nothing sensitive in mine, I’m able to post it below.

During the interactive part of the talk I mentioned a number of apps. Some these (iOS) apps were: Air NZ, Amazon, Chirp, Drafts, Emoji++, Evernote, Garageband, IMDb, Instagram, Instapaper, Kibo, MacID, Musixmatch, OmniFocus, Overcast, Slack, Starbucks, Trello, Way2Ride, Workflow, and Trade Me.

I didn’t know what to expect when I was invited to take part in this event. I have a lot of respect for the people who put it together, so I went. This tweet right after the conference pretty much sums up my experience:

I came back reassured, inspired, and motivated. Thanks Sandy, Brenda, David, Steph, Jimmy, Christine, Te Miha, Richard, Colart, and everyone else I had the pleasure to listen and to talk to.

It was also very impressive to see just how knowledgeable were all the people in the attendance. Day two, the un-conference, enabled all of them to play a more active part and turned into such a revelation.

Stephanie BySouth

“Coaching Leaders” session with Stephanie BySouth. Part of un-conference on day two

If you focus on enabling people to work together successfully, if you are all about empowering teams, if you are keen to find ways to remove needless processes, if you want to learn on how to use feedback properly, if you desire to be in the company of really smart (Agile) people, then trust me, you don’t want to miss the next edition. In the mean time, I’ll leave you with a quote from Sandy: “no pain, no Spain”.

AirPlay Speakers. A SONOS Alternative for iOS Users

I have been jealous of my friends sporting SONOS setups for a while now. My reasons for not jumping on the SONOS bandwagon are not limited to just the steep prices that the SONOS speakers come with. The reality is that I prefer to use my own music / sound playing apps and because I listen to podcasts for a considerable amount of time. In this blog post I will describe a cheaper and more flexible alternative for achieving the multi-room setup that SONOS is praised for, using AirPlay enabled speakers.

Scenario

In this article, I’ll describe my actual home setup. I need at least three speakers: two for my lounge area and one for my office. I wish to be able to play music and podcasts (via my Overcast, my preferred Podcast app) to either speaker independently or to all speakers simultaneously.

The SONOS Ecosystem

Pros

play1-blk-front

SONOS PLAY:1

Part of the SONOS promise is that you can easily and painlessly play the same music in multiple locations (rooms), using speakers that “play nice” and “just work” with each other. I believe that SONOS does deliver on this promise.

Scaling the SONOS setup is trivial, all that’s required is buying another speaker and adding it to the setup.

Cons

I have three main reasons to hold back from buying into the SONOS ecosystem:

  • SONOS speakers are quite expensive (arguably they do have very good sound)
  • They require the use of the SONOS app
  • Integration limitations

Now that Apple Music is available for SONOS my third reason is all but gone, but I have to acknowledge that this may not be your case if you prefer streaming apps that are not available in the SONOS app.

Cost

The cheapest speaker is the SONOS PLAY:1. It costs for $199. A high-er end SONOS PLAY:5 speaker costs $499. The SONOS SUB Wireless Subwoofer and the SONOS PLAYBAR TV cost just under $700 each.

The AirPlay Solution

Pros

iW3S_F.jpg.450x400_q85

iHome iW3

My needs are quite specific, therefore some of these pros may not apply to everyone.

  • AirPlay is available to any app (it’s a global iOS setting). It’s also easily accessible from the iOS Control Center
  • Big choice of speakers (most are budget friendly)
  • Old Airport Express units can turn any speaker with Line-In into an Airplay Speaker
  • Very easy to use as external speakers for Apple TV
  • Can stream the sound from any of my Macs (iTunes even has support for multiple speakers)
  • Most speakers have Bluetooth too, thus making them really good travel companions (to locations where WiFi is not available)

Scaling the AirPlay setup is not too difficult, after adding another speaker to the setup, there’s an option AirFoil configuration step.

Cons

The initial setup is more complex than with SONOS. Usually it requires joining an adhoc WiFi network provided by the speaker, followed by entering the local WiFi settings which enable to speaker to join the local network and become a wireless speaker for any AirPlay device.

SONOS speakers can easily turn into a 5.1 setup when enough speakers are added to the setup. AirPlay speakers haven’t really solved this, yet.

Cost

One the the most affordable options is the iHome iW3 AirPlay Rechargeable Wireless which retails for $49.95!

The audio aficionados can splash out on a Bowers & Wilkins Zeppelin Air Wireless AirPlay Speaker Dock. Amazon sells it for $420 at the moment.

I happen to have a Mac that is always on at home, so I decided to also purchase AirFoil. This has enabled me to group my speakers into “rooms”.  The Mac version costs $29.

Alternatives

Bluetooth

Most people will probably just use Bluetooth, and that’s ok. Not everyone needs the lossless audio that SONOS and AirPlay offer.

AirPort Express

As I mentioned above, an old Airport Express can turn an existing speaker into an AirPlay enabled speaker. Check out Apple’s refurbished store for a deal on AirPort Express units or buy from Amazon for $29. You don’t need the current generation one.

Android

There are apps out there that allow Android to tap into AirPlay. I am not familiar enough with them, and I suspect the new Chromecast Audio may actually be a more suitable solution. Chomecast Audio sells for $35.

Conclusion

I implemented the AirPlay solution for myself and I’m happy with it. I’d love to hear your thoughts, especially if you prefer an alternate setup.

DevMob 2014 – Epilogue

This year’s DevMob was different compared to all the previous DevMobs: there was tangible equilibrium between iOS and Android, with both platforms showing maturity in terms of tools, design metaphors and developer attention.

Sponsors & Venue

DevMob2014

DevMob 2014 – Wellington

This (un)unconference1 would not have been possible without support from the sponsors: Microsoft, Alphero, Xero, Powershop, CactusLab, JSA, and 3 Months.

This year, the swag was particularly nice (thanks to the Alphero team). The sponsors also contributed with very interesting talks, availability and engagement throughout the weekend, and a wicked Lego Death Star draw!

It was Wellington’s turn to host, and the chosen venue was Samuel Marsden Collegiate School. I give it the thumbs up: the food was great, there were plenty of rooms (and each had a projector), and we were even allowed to use the amphitheatre.

An evolving conference

Over the years, the conference evolved from being focused on iOS only, to sharing the spotlight between iOS and Android. This reflects the marketshare and the user base of the two platforms, and the ever growing number of developers interested in them. As one of the attendees who hasn’t missed a single iteration of this event, I’m happy to see such organic growth. It’s also good to see that the Microsoft folk have not given up, and keep attending these gatherings and contributing with incredibly useful insights (Azure being one such example).

My observation (potentially wrong) is that, year after year, the iOS talks have become a bit more abstract and more high level (a good incentive for me to return). At the same time, the audience has managed to keep some practical sessions on the board:

  • the show-and-tell sessions took a UI/UX spin
  • the demos contained products that are more and more polished (even though their authors consider them “rough”)
  • the live coding sessions were focused on concepts that a newcomer would probably struggle to fully understand, but would still find valuable

If a couple of years ago Julius was struggling2 to attract a handful of devs to take part in a blue-sky discussion, this year all the Android sessions had full rooms. Refreshingly, Google’s Material Design was at the centre of most discussions. The tools and libraries that people spoke about covered everything you can possibly think of: from analytics, networking, and storage, all the way to dependency injection and reactive programming.

I’m sad to see that Android developers still have to battle with basic things such as networking and resource loading. Michael Rueger from Xero gave a very good talk about the way their app tackles this area. I definitely think his talk should be shared at one of the next Wellington Android Development Meetups. While I’m talking about Xero, Glenn Parker was particularly active and even shared some interesting work they have underway. The Poweshop folks also contributed a great amount, confirming that Wellington is the place to be for Android developers. Not to be outdone, I shared as much as I could about the way that we do things at Trade Me.

No doubt about it, Android is a first class citizen and there’s some outstanding work being done in this space.

New in 2014

Back in 2009 when Jade Software launched DevMob (under the NZiDev moniker), the questions that people used to ask were along the lines of “how do I code, test, deploy, market my app, all at the same time?”. After just 5 editions, this question has transformed into “how do I run a distributed team? how do we collaborate with designers and testers? how do you manage an app’s backlog?”.

This year, I believe two themes were new to the stage: mobile development at scale, and an in-depth look at how to build mobile software. The gimmicky apps were pretty much absent, confirming that the mobile gold rush is well and truly over. For a change, Layton and Karl did not have to too many questions on how to build the next million dollar app.

Scale

Surprisingly, managing scale was probably one of the most talked about things this year. So much so that the group ended up creating a follow-up session after Luke Gumbley‘s “Backlog management / Feature planning” talk.

Team building, maintaining happiness, and dealing with ownership, all got tackled by the audience. The information flowed freely and openly thanks to the trusted environment that makes so many people return to this event year after year.

Depth

It wasn’t just the management side of things that was new this year. The sessions went deeper into the product life-cycle with topics such as API design, security, functional testing and mocking, UX, continuous integration and more.

I was happy to see large development houses (Cactuslab, JSA, Powershop, Trade Me, Vend, Xero, etc) share intimate details about how they tackle many aspects of the SDLC. The fact that non-coding topics permeated DevMob 2014 is encouraging for future iterations of this (un)conference.

Until next time

I missed out on the socialising that traditionally happens after the first day of the conference. I suppose that’s part of the deal when the event is hosted in one’s home town.

Many thanks to the hosts Nat, Janine, TanyaJulie and everyone who contributed to making this event a success.

If I got anything wrong, or if you wish to pass any feedback, you can reach me on twitter.

Notes:
1 To learn more about (un)conferences you can visit Nat’s website, buy this Kindle book, or, my favourite option, just take part in one!
2 Julius is no longer struggling to attract new people to his talks. He now just needs to find a way to keep Sam awake. (Okay, this photo is cropped and you can’t see the 30 people sitting behind Sam, but it’s funny nonetheless.)

Julius teaches Sam Material Design

Julius teaches Sam Material Design

 

Smart Lock – I called it

In my Log In post I was hoping that One day, smarter Log In pages would be able to Trust my location. A mere 2 days later, Google announces Smart Lock (as part of Google Play Services 6.5 and Lollipop).

The Verge provides a good translation of what this will mean to regular users.

In a nutshell, you can now define a location as safe, and then your Lollipop phone won’t ask you to unlock it when you’re nearby—it’ll just let you straight in.

 

Apps vs. Websites – The ownership perspective

This topic has been covered time and time again. Typically, these articles cover a mix of technology, performance, ROI, look and feel, and other such metrics.

Today I’m going to suggest that the end user’s ownership of an app (as opposed to a website) is one criteria that businesses should consider when making the decision to build a Native App. I’m also proposing that building a Responsive Website is no longer an option, but an expectation.

In 2014, even the cheapest smartphones come with HTML5 capable browsers! End users do not and should not have to understand why a website is different, and sometimes even feels alien, when viewed on a mobile device. The time when we had to compromise on mobile because of technical reasons is long gone. Let’s leave this here.

If the mobile browsing experience is in the same class as the browser experience then why should you even consider an app?

Unless you’re planning to build an amazing app that you plan to support long term, keep up to date with the fast evolving mobile UI/UX, in which you utilise the mobile platform paradigms to the point that the user feels like it was built in collaboration with the designers of the first party apps, then you probably shouldn’t build an app.

The subtlety here is that it all boils down to the fact that you own your website, but the end user owns your app.

If the user has a bad experience on your site, they can’t get rid of your mobile optimised (hopefully responsive) website. Your links will always work, even if they remove all shortcuts or bookmarks. A short url, a web search result or an ad will always be able to bring them back. When they’re back you’ll have a chance to make them change their mind and convince them to return in the future.

On the other hand, if the user has a bad experience with your app, they can simply forget the app ever existed on their device. They will delete it and they’ll do that almost as a punishment for your failure to delight them. Deleting the app will close all the communication channels once provided by that medium: all extensions and widgets will be gone, all URL schemes will seize to function. The reality is your app is competing with potential photos of their friends and family, or with another app that is more in fashion than yours.

The end user owns your app because they install it, they dedicate disk space to it, and they can get rid of it if they choose to. They are in complete control of this lifecycle and, you may not realise this, this lifecycle has financial and psychological implications.

Unlike accessing your website, when installing your app the user is likely to be asked for their password (or fingerprint for Touch ID). Even if your app is free, the psychological connection is made: they acquired your app. They are now using disk space just to have your app around.

Your app must be delightful, it must add value every time it’s used, otherwise the user will eventually run out of patience and delete it. Once they do, you will face a big uphill battle to convince them to give your app another try.

There is no such psychological attachment to your website because the user is not involved in the site’s lifecycle. They usually just “ask” a search engine for it. When they run out of space for their next photo they won’t think which sites they can remove…

If you can’t build a delightful mobile app, then you’d better have an amazing responsive website. The reality is though, that if you don’t have both, then it’s likely that you’ll never be the first port of call for a mobile user.