picomac

I've been considering my thoughts on the progress of emoji since Apple released the first iOS 10.2 developer beta several days ago, setting off a flood of new emoji screenshots in my Twitter timeline. I'm glad that I delayed a bit, as this weekend was Emojicon. I follow three(!) people who were in attendance, so my timeline filled with smart thoughts (not just hot takes) about the past, present, and future of emoji.

Of course, there was discussion of the role of platform vendors in shaping style, use, and even meaning of emoji, and Apple is a major player. If that wasn't obvious years ago, it became so this summer when the iOS 10.0 betas kicked off the squirt gun / pistol controversy. The debate then centered on miscommunication — an innocuous symbol on iOS could appear as a violent one on Android, Windows, or the web. It also served as a crash course for many in how emoji actually work.

There's very little magic to emoji (setting aside ZWJs): the Unicode Consortium releases a specification that says what codepoints correspond to what characters. They provide reference descriptions and examples but they don't provide the actual glyphs. That's up to font makers to do for anything specified in Unicode, from the Latin alphabet English uses, to Cyrillic, to Japanese kanji, to emoji. That allows for considerable variation and stylistic choice.

Range of expression from diff emoji systems VS range of expression from diff typefaces. All the same, tho not the same 🤔 #emojicon pic.twitter.com/CBBwuLg1lB

Font design is not unfamiliar territory for Apple — it's one of the things that set the original Mac apart. Even working within the limits of ASCII encoding, there were emoji-like glyphs in Susan Kare's Cairo font that shipped in 1984. Recently, Apple has taken typography seriously by developing the (2014) San Francisco typeface and making it a hallmark of the Mac and iOS experience. I'm sure people complained when it replaced Helvetica on iOS, but nobody complained that it hindered their ability to express themselves.

Changing the system font or default font for iMessages should never prevent someone from sending a message today that they would have in the past. But some emoji have gained lives beyond their Unicode specifications. Here in Michigan, PART ALTERNATION MARK 〽️ looks enough like a yellow block capital M that it's become a stand-in for the University of Michigan's logo. Infamously, the cleft in the peach emoji has made enough people think it looks like a butt that 99% of its use does not represent fruit.

I woke up to dozens of mentions about the peach emoji not looking like a butt anymore

Happy Tuesday

This is where Apple's emoji design can have weird ramifications. The change from a revolver that fires lethal bullets to a squirt gun that fires only water is a deliberate, possibly political change. But erasing an entire class of emoji use just by making a piece of fruit more photorealstic is something that might not have crossed the mind of an Apple designer. It seems like it's time to open up choice of emoji to users, especially when differences in emoji design are just a font away.

Unfortunately, Apple has largely locked down the ability to choose fonts on iOS. The iWork apps only offer a handful, unless you rely on third party apps like AnyFont to shoehorn new typefaces into iOS. Even in Notes, which has gained lots of rich text capabilities, the font has to be chosen on an application-wide basis. But such an option could be opened up for Messages, ensuring that "legacy" emoji meanings could be preserved by those who want them. This isn't antithetical to Apple's vision for Messages, considering that it's opened up third-party sticker pack creation to anyone with Xcode and a folder full of images.

If emoji don't fit people's needs, perhaps they will turn to stickers, but that would be a loss; the power of emoji is in their universality — their shared cultural currency wouldn't have the same value if iOS and Android had never adopted them. Users recognize the value of emoji, and they're open to expansive change. (I'm sure I'll send and receive lots of bacon and avocado emojis in the future.) But changes that limit utility are hard enough for people to adapt to when its just pure software. Emoji aren't a language, but they're part of modern communication. I hope Apple and all platform vendors will understand the monopoly power they hold and wield it carefully, so all their users can speak freely. 🍑

A lot has happened since August.

August was when I put Picomac on hiatus. Taking one week to travel after a death in my family spread into two, and then a month, and then more. Daily writing and recording was excellent practice but also draining, so it was a welcome respite. But I never intended it to turn into a cancelation — so thanks to all who stayed subscribed to the feed.

Meanwhile, Apple was busy. iOS 10 went from early public beta to GM to final release. The iPhones 7 were announced and went on sale. There are new Watches, weird new TV features, and finally a slot on the MacRumors Buyer's Guide that doesn't say "DON'T BUY".

In my own Apple world, I finally bought a new iPad (a 9.7" Pro replacing a 3rd generation), waffled on ordering a jet black iPhone, and my iMac is celebrating its first birthday. I've more than acclimated to the features of iOS 10; I've come to rely on them daily, even without 3D Touch. There's so much wild and wonderful Apple stuff that I want to talk about, and I've repeatedly found myself back in the dilemma that led to Picomac in the first place: tweets just don't cut it.

So I'm treating this as Picomac, season 2. As a listener and/or reader, you can expect things to pick up largely where they left off. The most noticeable change will be to the schedule: expect multiple updates per week, but not daily. (You may have noticed that the tagline has changed accordingly.) In compensation, I'm also not going to stick to the 500-word hard cap I used to impose on each update. Things will decompress a bit, but still be bite-size.

It feels fitting to make this change on the eve of NaNoWriMo, one of my initial inspirations for Picomac. I should be on pace to hit 100 updates and 50,000 words by the end of 2016. I may not have time to write and record every single day, but there's always something to talk about. So, how about that new Touch Bar…?

The nicest camera in my house is a Canon T3i. It's about five years old and for my needs it still takes fantastic pictures. One thing it doesn't do is keep accurate time. That's not its purpose; it's precision optics, not a precision chronograph.

But photo timestamps matter, and I always forget to check my camera's clock before going on a big trip. A week later, I have 1500 photos from the T3i that don't line up with the 100 or so photos I took on my phone (largely panoramas, something the iPhone does really well and SLRs don't handle). If the camera kept good time, this wouldn't happen, or at least the solution would be simple.

Most photo organization apps, like Lightroom, which I use, have the ability to batch correct photo timestamps — if you forgot to adjust your camera's time zone. I was in California, so I had that problem, but correcting three hours westward wouldn't solve it; my timestamps were some 3 hours and 18 minutes off from my iPhone photos.

I suspected my solution would lie on the command line — spoiler alert: it was — but I searched for a GUI tool designed for this task. An $8 mini version of A Better Finder Attributes claims to be a timestamp unitasker, but I couldn't sort out the ABFAX demo's interface. HoudaGeo, primarily designed for geotagging, will tackle the problem, but at $40 it's priced for users who will take advantage of all of its features.

So I turned to Exiftool, an omnibus photo metadata munger for the command line. It was quick to install with Homebrew, and I found the one-line command I needed in its documentation. (I had to run it twice on the first batch of photos, because I adjusted 18 minutes in the wrong direction!) Adding a simple Bash for loop blasted through 1200 more photos in no time.

Another loop removed the archived originals that Exiftool thoughtfully creates…although that can amount to gigabytes of extra storage when processing lots of photos.

Even after that, my photos weren't sure what time zone they were in. Lightroom displayed the unaltered iPhone photos in what would be Eastern Standard Time, even though we're currently observing Daylight Saving Time. I gave up on aligning them to a "true time" as long as SLR and iPhone would happily interlace. And they did, except for the iPhone videos (7 hours off) and some iPhone shots identified as coming from an "Unknown Camera" (5 hours off). But with a few tweaks, all is in order. Now, thanks to a little command line magic and some persistence, I can relive my trip in order.

You probably already know the first rule of using in-flight Wi-Fi: buy the pass before you get on the plane. The second rule is to make sure that you have everything you need to cash in the pre-purchased pass. That's the rule I forgot.

A week ago, I was traveling to San Francisco and had some podcast work that needed to get done along the way. Four hours in the air would be enough to do my work, and also enough to justify a $16 Gogo plan. I'd never crossed that value threshold before, so I didn't have a Gogo account. No problem, right? As I was packing, I grabbed the closest computer (my iMac), created an account, and made my purchase, all with the help of 1Password. I got on the flight, opened up my MacBook, and realized that my Gogo credentials were…nowhere.

This was a combination of user error on my part and some recent changes to how 1Password does syncing. A few months ago, I realized that when syncing 1Password vaults with Dropbox, a lot of information is stored in the clear — no passwords, of course, but the titles of all your accounts. It's a small chance that my vault would be compromised this way, but confirmation that I have an account on a certain site could make it a greater target. As a result, I switched to iCloud syncing, which makes all that data opaque. iCloud syncing Just Works™, so there's no control over exactly when it syncs. If I'd still been using Dropbox, my vault would've synced over as soon as I logged onto the ground-based airport Wi-Fi prior to boarding. iCloud didn't think the sync was urgent — the 1Password app wasn't open, after all — so it just didn't perform it.

All that aside, I would've been fine if I could have reset my Gogo account password. There's an option for that, even on the plane, but it requires answering a security question. And what is my mother's maiden name? It's…a randomly generated string saved in 1Password. (I used to use all lowercase strings with no spaces; a recent 1Password update seems to have removed that option in the password generator, favoring diceware instead. That was even more frustrating, because I could remember two of the words but not the third!) That left me completely sunk. I could buy another pass, at the increased in-flight rate of $27, or disconnect for four hours. I opted for the latter, and still managed to squeeze in my work. At least the first rule of plane Wi-Fi did some good: those pre-paid passes are valid for a year, so I got to use it on the way home — after I triple-checked that 1Password had synced.

Since I last mentioned weather apps when I did some spring cleaning on my iPhone, I've settled on a single solution that works best for me: Storm by Weather Underground. (It replaced their other, slightly less geeky "Wunderground" app.) But the fact of the matter is that, unlike a few years ago, I haven't tried many new weather apps recently. Patrick Dean summed this up on twitter, pointing out that just about any competently made app reaches the threshold to be featured, as weather is still a top-level category in the App Store.

I think there's one clear reason for this: homogenization of weather data. In the early days of the App Store, weather apps could differentiate themselves based on the source and accuracy of their data; attractive presentation came second. That all changed three years ago with the introduction of forecast.io. If you don't know the history, forecast.io is the open API by the creators of Dark Sky.

When Dark Sky came onto the scene in 2011, it was head and shoulders above other weather apps, with groundbreaking features like predictive radar maps and push notifications for impending precipitation. But even in version 1.0, it was clear to me that some things were amiss. It was less accurate on the iPad than on the iPhone because it made its weather predictions client-side, using the GPU. In fact, Dark Sky is a classic example of "machine learning applied to a problem we (and the machine) know nothing about". Its algorithm doesn't analyze weather data, it analyzes images, specifically radar map frames. This is what gives its future maps an unearthly, unrealistic quality; storms that have been developing or diminishing suddenly turn into zombie clouds drifting in straight lines across the map. In fact, if you click the play button on the map in the latest version of Dark Sky, it stops at the present time, as if it's ashamed of how bad those future maps look.

In serious contrast, Storm offers a 5-hour future radar map underpinned by meteorological data. Storms can appear out of nowhere along front lines, or die down before reaching your location. It's this one feature, plus its excellent daily and hourly graph views, that make it my top weather app. Almost everything else in the App Store is just the same forecast.io data — a computer's idea of weather — dressed up in new skins. The greatest innovation has been to make the interface super-snarky; an advance in entertainment, but not in utility. There may never be another great iOS weather app, because the hard part is gathering the data. Weather Underground operated stations for years, and is now (regrettably) under the weather.com umbrella. There is free weather data out there, but you get what you pay for: a slick interface for a couple of bucks.

I joined Flickr in 2005, when it was young enough that, like many fledgling internet services, you could refresh the global timeline and keep tabs on everyone's activity. In the past 11 years, I've uploaded over 9000 photos to Flickr and geotagged 7500 of them. And now I have a problem.

Flickr was the first piece of software, native or on the web, that let me add location data to my photos. It was all done by hand, as this was before my first iPhone or any other device that added geolocation automatically. I painstakingly dragged and dropped photos onto the map, often — because of Yahoo's crummy map data — with Google Earth side by side, especially for places that a street map considers the middle of nowhere, like archaeological sites in Sicily. Later, apps like iPhoto added geotagging capabilities (and removed them, and added them back), but I kept on with Flickr because it was my central photo hub.

Some of my fine-grained Flickr geotags in the Forum Romanum.

Flickr is still alive and kicking despite several apparent death knells in the past. But this week's news that Verizon is buying Yahoo gave me another push to liberate my geodata and keep it stored in my local Lightroom photo library. There's only one problem: I don't know how to do it. Flickr allows bulk downloads of photos, but it doesn't alter the original EXIF data, so that means the geotags aren't baked in. And the native map view on the Flickr site has barely changed since its introduction almost 10 years ago, including limiting you to viewing less than 100 geotagged photos at a time.

Perhaps I'm missing something, but there is no direct or even indirect conduit for my 7500 pairs of latitudes and longitudes to get matched to photos in the Finder or Lightroom. The closest answer I've gotten is "use the API to write something yourself", but that's far from a simple or complete solution. But unless an alternative presents itself, that's likely the route I'll take. Hopefully it won't be a race against the clock, facing an API shutdown date. (None has been announced, but it's hard to be optimistic about Flickr's bright future.)

When I get my geolocation data out, I'll know better than to lock it into a new proprietary system — especially one that I don't control. I was way more lax about my data in 2007 or 2008, when I started geotagging. I didn't even have regular backups, so Flickr actually saved my bacon when I had a catastrophic hard drive failure and would have otherwise lost about 2500 photos for good. I treat my data much more carefully today, or at least I will once I can get my hands on it.

HomeKit launched in iOS 8 and has operated as a stealth feature for the past two years. It's powerful enough to have Siri control your lights but so invisible that you need to download a third-party app to get it working (some app, any app, not necessarily the app that goes with your HomeKit accessories). This is changing in iOS 10 with a first-party Home app and something I think is far more useful: access to HomeKit scenes and accessories in Control Center.

In fact, the entire third pane of Control Center is dedicated to HomeKit. (I'm not sure what people with no HomeKit devices see there. Blank space?) Devices can be switched on or off with a tap, and further controlled after a hard press or long press. For lights, that means a big sliding dimmer switch, and a button to access another screen for setting color. There you can set up six presets or dig even deeper to access color wheels. One wheel is a standard RGB rainbow, and the other controls color temperature.

If you're familiar with color temperature at all, it's probably from the desktop utility f.lux, which automatically adjusts temperature based on time of day — cooler and bluer during the day, warmer and orangier at night. Color temperature is measured in Kelvin, just like heat temperature, because there's supposed to be a direct correspondence to physical properties of ideal objects at those heats.

In reality, color matching is a mess and 5000K here may not be 5000K there. My Philips Hue bulbs, although boasting their color range on the packaging, never let me directly set a K value; I always have to choose from an onscreen color palette. Their idea of white light temperature goes from yellowy to mildly blue. Apple's, on the other hand, goes all the way to deep orange and deep blue, more Florida Gators than f.lux.

In practice, this means that what I see is not what I get in my HomeKit apps. The same bulb set to the same moderately warm tone can appear onscreen as everything from beige to green!

And I still haven't managed to set a pleasing color that feels white with Apple's wheel. Fortunately, the workaround is to set a good color in another app, then activate Control Center and set the current color to one of the presets. Having done that, HomeKit is now more useful than ever before, especially for things like quietly turning out the lights at night. But even two years in, it still requires a hodgepodge of apps to set things just right.

This is my Pokéjam.

iOS 10 hasn't been billed as a major interface redesign, but it's definitely accelerating change away from the ultra-wispy, radically flat design of iOS 7. At the WWDC intro of iOS 10, these changes were demonstrated mainly in two apps: Music and News. When I saw the slides, I thought, "OK, this is an interesting, bold new direction for the interface." When I first used Music, I thought, "Wait, did some accessibility setting get turned on?"

No sooner had I thought that than I realized what it meant. For those of us with perfect vision, hearing, motor skills, etc., Accessibility just looks like the extra-fiddly settings section. But for many, those settings are the only thing that makes their Apple devices usable. I shouldn't be shocked at a slightly larger text size in one of the cornerstone apps on iOS. While I fortunately don't need it yet, I would guess that there are tens of millions of older iOS users who have increased their default text size just because their eyes are aging. Frankly, that means that my expectations were reversed. Nice, large, readable text should be the default — as it is now — with an option for the eagle-eyed to shrink it down to increase information density.

Of course, it's still incumbent upon Apple to arrive at a sensible default, especially if it can't be changed. One area of question is the lock screen. I think it's more or less properly proportioned on the iPhone, but Stephen Hackett recently shared a comical iPad lock screen. He's apparently listening to one of his favorite podcasts, "ow with John Gruber" and the latest episode features "uest Glenn Fleishma". (It also features a bug with the playback indicator and times over one hour, which has carried over from iOS 9.)

Can we talk about how huge this text is? pic.twitter.com/1n7Oxv2iim

On the iPad lock screen, the default is clearly wrong; the average user should be able to read more than two and a half words in that space. I expect a sensible revision there, similar to how the Notes app in macOS Sierra finally has moved in the opposite direction, away from a tiny text default. These are both proof that good design is iterative (and the beta period is the perfect time for quick iteration). The drive behind that design has to be that Apple products are no longer for "the rest of us"; with a billion iOS devices in the world, they're for all of us. Out of the box they should be accesible to as many as possible and, with a few changes in settings, accessible to the rest.

Few things in the Apple universe provoke such strong reactions as clicky keyboards, both physical and virtual. Some people demand silence, while others want their clicks to be as loud and satisfying as possible. I vacillate: I've used an Apple Extended Keyboard II this decade, but I've turned off the keyboard clicks in iOS.

Or I had, until I installed the iOS 10 public beta, which restored the default setting, turning them back on. Those with an ear for detail also noticed that the click sound has changed. It's softer, more of a pop than a click, and this too has its supporters and detractors. I like it a little better — it's more subtle and refined — but that's not the reason I decided to leave the sounds on.

@viticci keyboard sounds on is the new pineapple pizza cc:@ismh, @imyke I’m sorry Federico I side with Myke however I love pineapple pizza

I have keyboard clicks enabled on my phone now as a sort of early warning system. There are vanishingly few times when my phone should not be set to silent, especially while I'm at work. The worst way to discover that the mute switch got flipped is by accidentally blasting some silly video from your Twitter feed in the middle of a quiet office. Leaving keyboard clicks on lowers that chance. The instant I hear keyboard feedback, I know to enter silent mode. But the soft pock pock pock sound of the keys, especially just for a few seconds, won't cause anyone around me offense.

I have to draw the line somewhere.

I employ a similar strategy on the Mac, although it allows me to be even quieter. By default, Mac OS plays sounds when changing the volume using the media keys. This can be temporarily disabled by holding the shift key, or the behavior can be reversed in System Preferences. This lets me quickly tap the mute button to check my current volume without creating any sound. And when I put on headphones and want to do a practical volume check — because three clicks on my Sennheiser headphones is several times louder than three clicks on EarPods — I simply hold shift to get the necessary feedback.

Perhaps my stance on keyboard clicks will just be temporary, and they'll begin to drive me insane. Or who knows, maybe with the new sound I'll come to actively like them. Even then, I would try to keep them confined to my headphones; the goal is still to keep my devices' sounds from bothering those around me.

I keep an informal running list of potential topics for Picomac. There's one that's been in there for months, but I've avoided it because my opinion just seemed too negative. It reads: "data detectors are as dumb as a box of rocks".

Data detectors have been around for a long time on both the Mac and iOS. They first appeared in Apple's Mail apps, doing helpful little things like highlighting addresses or phone numbers so you could act on them quickly. Those data types made sense for such a feature; if pressed, I could probably write a quick and dirty regular expression that would match them just about as accurately as the detectors do.

But highlighting phone numbers wasn't what provoked my ire. It was the overgeneralization of data detectors into Messages, which led to lots of annoying clutter. In an effort to be helpful, Messages would take phrases like "what are you making for dinner?" and underline "for dinner", offering to create a calendar appointment. I hope the day never comes that I need to make a record of what time I will eat a meal in my own home.

Monday was my first full day with iOS 10 and it was also a rough day personally. I was not up for cooking dinner. I got a text with some suggestions: "We could go to Zingerman's roadhouse or jolly pumpkin or something." The two restaurant names were underlined. (And "for dinner" was not!) I tapped on each name and a full page of relevant info popped up: location, phone number, photos, and other info sourced from Yelp. Dumb old data detectors have grown up. First, they're location-aware; if you're not in Michigan, the words "jolly pumpkin" mean nothing with respect to dinner plans — especially if they're written all in lowercase. Second, they're more subtle; instead of looking like an ordinary hyperlink, the underline beneath the text is thinner and lighter — just enough to signal that you can tap on it.

Highlighting local restaurant names is just one new trick that data detectors have learned, and I expect to discover more. It gives me hope that someday it will be an OS-level feature to perform more complex data detection, like taking an email signature block and automagically parsing it into a full contact card. (That's best done by third-party apps like Interact today.) It's also promising for Apple's ability to do smart things with "proactive" or context-sensitive data on the fly. If data can be detected an acted upon instantly, perhaps someday Siri will no longer have to say "let me check on that" in response to very simple queries. And whatever future data detectors bring, one thing is certain: I won't be rolling my eyes at texts about dinner anymore.