SiriBox

SiriBox

I’ve been testing a Google Home for about a month now. It’s a great little piece of technology, but since it lives outside of my digital ecosystem, my use cases are fairly limited.

Google Home integrates with exactly three things in my home: Sonos, Hue and Spotify. The former only thanks to a Sonos bridge and a ChromeCast, the latter thanks to a Spotify family account my parents have.

But, even with only those three use cases, and the occasional timer or search query, I really love the idea of speaking instead of typing.

OK Google, stream Vee-Ar-Tee Studio Brussels on Sonos please. Hey Google, turn on the Slaåpkåmér-lights. Hey Google, play Nothing Else Matters on Sonos.

Yes, the syntax is cumbersome. Yes, sometimes it’s faster to grab an iPhone and use control center, or look outside and check the weather myself. And yes, when music is playing loudly she doesn’t here me. But then again, who does.

The real power of a digital assistant lies with its integrations. And since I live in an iOS and iCloud world, Google Home (or Alexa for that matter) doesn’t really integrate at all with Apple’s services. I can hack IFTTT and its recent iOS integrations to create appointments, but the Apple TV, Apple Music, my reminders, email, messages, FaceTime? Non existing if you ask Google Home.

Fast forward

Now, we all dream. So let’s dream big, by going back to 2006. Apple released the iPod Hi-Fi, their first and only speaker. Great sound, big, heavy and soooo beautiful.

What I’d like is a new iPod Hi-Fi called Siri. A big decent speaker, with integrated microphones, Wi-Fi, bluetooth and all the things needed to add the Siri experience to a speaker.

Hey Siri, play Led Zeppelin. Hey Siri, FaceTime Audio my mom. Hey Siri, remind me to buy Duvel when I get to the mall.

It integrated with iOS and iCloud. It can use continuity to hand-off complex queries to my iPhone or iPad. It does AirPlay, and acts as a HomeKit bridge.

Not that farfetched I think?

Force Touch

Force Touch

  
The rumors of Force Touch on iOS exist as long as the Watch exists. And since Apple added a similar technology to the Mac recently, it’s only a matter of time before this tech appears on iOS. 
But adding the feature is one thing. Implementing software features that accept the input and use it is something else. You have to take existing devices in account (apps still need to support input for non-force-touch devices), accessibility (not anyone can do this easily) and discoverability is another big factor. 

Personally a see four ways Apple could implement this:

Option 1: Replace existing touch events or buttons.

Touch events on iOS are often overloaded and complicated.  Force Touch could take an existing way of doing something and make it easier and faster. 

Similar to how the universal swipe back replaced back buttons and made navigating on big screens faster. Or how pull to refresh made reloading content simple and intuitive. 

I see Force Touch replacing the “long press to access options” feature that now exists in many apps. Most of the time it’s used to show the sharing sheet in some variation, so force press to share could become a thing. 

Eg: force press a tweet in Twitteriffic to retweet or share. Or an article in Unread to save it to Pocket. Or the Springboard to rearrange or delete apps. 

Option 2: System wide gesture

Buttons are almost always used for system wide actions. Volume up, mute, go to the home screen,… The home button specifically is loaded with a lot of stuff, but most importantly: long pressing it loads Siri. If you see the screen as a big button that only Apple can access things become interesting. 

Swipe up brings you control center, down gives you Notifications and the Five Fingers Death Pinch returns you to the home screen. 

Apple can use Force Touch to open the new Proactive Spotlight from anywhere in iOS. Could be useful if they want to make the feature more prominently available. The downside: using the entire screen and all the new tech behind it to load one app seems like a waste of creativity and possibilities. 

But when you consider the Friends button on the Watch, there’s precedent for something like this. 

Option 3: Expanding UI

Force Touch could also be used as a new feature for apps. But there are a few issues with this:

Where on watchOS feature is used to show what would be in navigation or toolbars on the iPhone, here it would be an additional place to put stuff. 

There’s a risk the ‘hidden’ Force Touch menu could become a junk drawer similar to the hamburger menu’s that were used by Facebook & co a while back. They were often a cluttered list of ‘best of the rest’ options that where not useful to display in the main navigation. 

If any developer can add hidden options behind their app, discoverability becomes a major issue. There’s no indication what can be force pressed and what not. You’re never sure if something should happen if you should press longer or if it’s just a regular button. 

Without specific guidance this would become a Wild West of creative experiments that would only confuse or frustrate users.  

In a way option 1 above is a subset of this third option. But at least there we have a precedent. 

Option 4: Unpredictability

Apple could add features to iOS we don’t know yet specific for this option. No one expected Touch ID and especially not the integration with passcodes, Apple Pay,…

Linking Force Touch to Spotlight is one way it could be linked. But triggering a universal dark mode, open an in-app search mode, quickly displaying the settings for an app,… Are just a few ways Apple could surprise us. 

OS X Server 5: Caching iCloud

OS X Server 5: Caching iCloud

For a couple of years now Apple has included a Caching Service within OS X Server. This service allows a company or school to locally cache certain OS X and iOS updates and apps to lower the load on their network when multiple users request the same update.



Originally the service only cached OS X installers, but year after year Apple has expanded the service to include: OS X and iOS updates, App Store apps and iBook Store books. And combined with the excellent CacheWarmer this service is a perfect add-on to any medium or large Apple deployment. I’ve even got it running at home, and I’m caching around 500GB of data.

OS X Server 5

Caching Server
Caching Server can accelerate the download of personalized data stored in iCloud, including photos and iCloud Drive. Enabling iCloud Acceleration reduces the amount of iCloud data that needs to be downloaded when users have multiple devices on the same network. – Apple Developer Portal

With the release of OS X Server 5.0 in the fall, Apple will expand this service one again and they’ll now include Users’ iCloud Data as well. Users who use their iPads or Macs on a network that runs a Caching Server will gradually seed their iCloud Documents, Photos and iCloud Backups to that Caching Server. This allows for very fast device restores, pretty sweet!

Capacity and management

But there’s an issue with the implementation: Imagine a network running a Caching Server for 100 users which all have an iPad. Theoretically this would mean a minimum of 500GB of iCloud Data with the 5GB for free cap. But with the arrival of iCloud Photos I guess most users now pay for bigger storage tiers, so we’re potentially looking at around 100GB per user, or  around 10TB of data.

If you consider a small company who probably caches their data on a Mac mini’s internal hard drive and you can see where things will go terrible wrong.

Caching Server currently has a single setting to pick where you want to store your data, and a single slider to pick anything between 0GB and 90% of your storage points capacity.
At the office I currently cache updates and apps on a very fast external Thunderbolt drive and we’ve got around 2TB of data cached. When OS X Server 5 is released, we would now need at least 12TB of storage too cache everything. And we would to migrate all our data, because we can’t just add a second bigger hard drive to manage this new influx of data.

A Solution: looking at NetBoot

There is an easy and existing solution for this problem: Just look at the other service that caches user data: NetInstall.

NetInstall has always allowed Admins to select multiple harddrives to store images and/or user data. You can even select which drives contain only user data, and which store NetBoot-images.
You can – for example – host your most important images on a fast internal drive, and the bulk of user-data on an external drive.

NetBoot

So what I would like for OS X Server 5.0 to do is something similar, but for Caching.
In this scenario you would select multiple storage devices to store all yur cached data. A big, slightly slower drive for all cached iCloud Data (which gets downloaded slowly to user’s devices after a restore anyway), and smaller faster drives for OS updates and apps. This makes managing the server easier.

You could even imagine a company starting with a small internal drive, and gradually expanding their Caching Server setup if necessary.

Bug Report

Although I love the idea of caching iCloud Data on a local network, and can see how this massively improves the restore experience of users, I find this lack of control about what’s stored where a dealkiller. That’s why I’ve created a bugreport for this issue, hoping Apple will fix this issue before launch.

If you’re managing your own Caching Servers and agree with my statements above, please create a similar bug-report and refer to my Bug Report: #21342840BugReport

Low-hanging Fruit

Low-hanging Fruit

Targets or goals which are easily achievable and which do not require a lot of effort

WWDC is around the corner and while Apple uses this time to deliver big features and updates, they often change some smaller details too — changes that improve the user experience considerably.
They remove some small annoyances or give users long requested small features. 

Here’s my current grocery list of low-hanging fruits on iOS:

Within reach 

  • Save Safari downloads to iCloud Drive.
  • iBooks iCloud Drive sync (useful for PDFs)
  • Hide or delete default apps if a replacement is available.
  • iCloud Drive Document Picker as an app on iOS.
  • Editable Control Center buttons.
  • Set a default Document Picker destination (e.g. Transmit instead of iCloud).
  • Hide default Action Extensions (I never print).
  • Health on the iPad.
  • The MarkUp OS X extension on iOS.
  • Sync notifications across the entire platform similar to iPhone and Apple Watch sync.
  • File Picker in Mail similar to the Photo Picker so attach files to new mails (shows a Document Picker).
  • Sharing sheet in Mail.
  • Cross platform App Store bundles containing both iOS and OS X versions of an app. 
  • Landscape home and lock screen on all devices and sizes.
  • Set FaceTime Audio as a default method of calling.
  • Set a different automatic Do Not Disturb time in the weekend. 

Slightly less low-hanging fruit

  • Show your Macs home folder as a Document Picker location on your iOS device using the already existing Back to my Mac technology.
  • Replace default mail, browser and calendar apps with custom ones if they offer specific and required functionality. 
  • Siri via text commands instead of voice commands
  • Buy an OS X app on your iPad or an iPad app on your iPhone which then downloads on the other device.
  • Higher free iCloud tier balanced against the size of your devices. (5GB-16GB, 20GB-64GB, 40GB-128GB)
  • Handoff for AirPlay to the AppleTV
  • Ad Hoc syncing across devices within reach without Internet access (think: syncing iCloud documents between iPhone and iPad on a plane)

Out of reach 

  • Force apps to be retina, iPhone 6 plus compatible and universal across iOS devices.
  • Selective iCloud backup restore.
  • iCloud Backup for OS X.
  • Cache iCloud Backups locally via OS X Caching Server. (Both making one and restoring).