Favorite quotation: Before you criticize someone, you should walk a mile in their shoes, that way when you criticize them, you're a mile away and you have their shoes. - Jack Handey

Thursday, February 25, 2016

Why Apple vs. FBI is No Contest, and Why Tim Cook is Right about the Danger of Leaving Vulnerabilities Open

On the air today, Lars Larson asked me whether, if I was the CEO of Apple, whether I would order my engineers to unlock a would-be terrorist's phone if I was told that stopping something like 9/11 was on the line.

I said no, but I have been thinking about it. It's a very tough question. Of course I would want to stop any such horrific attack.

Also, I am pro-law-enforcement, and I support the police. I have many relatives who served in the military. I work with ex-Marines every day at the software startup I work for. We talk about all these issues. We know the FBI trying to just do their jobs, and it's for our protection.

However it's impossible to explain the cybersecurity landscape in the context of a radio show phone call, as I had wanted to try to do.

So I am writing this blog.

Imagine if Apple complies and creates the malware suitable for hacking the dead terrorist's phone (and the 12 others that the FBI wants them to hack, and however many others they will continue being asked to hack).

To comply with the court order by creating this malware, Apple's engineers must first identify a vulnerability in their hardware and software—both of which are specifically designed not to have such vulnerabilities. Then Apple must write malware that depends entirely on the existence of that vulnerability, and keep that malware around indefinitely into the future for the FBI.

Even if Apple never releases this malware, or tells anyone about the vulnerability, or how they exploited it, Apple must still leave open the vulnerability that they found, so that their malware hacking tool they made for the FBI will continue to work.

Now, let me put that into the context of today's cybersecurity landscape.

Apple, Google, Microsoft, and other major tech companies are constantly searching for security holes in their own and each others products, then quietly and quickly patching those exploits. As soon as a loophole is found by the "white-hat" security researchers (i.e. good-guy hackers), then the security flaw gets patched as quickly as possible. Quite often, these exploits get published online in the CVE database. For example here is the current CVE list of known iOS vulnerabilities and the current CVE list of known Android vulnerabilities.

More often than not, Apple is not the party who discovers the newest iOS vulnerability. (If they knew about it, then it would not have made it into iOS in the first place!) So as soon as these vulnerabilities appear, then Apple (and Google and Microsoft) quickly cat to patch the vulnerabilities because they are now in a race with cybercriminals to identify ways to exploit those vulnerabilities.

All too often, before anyone patches them, these sorts of loopholes get exploited by cybercriminals and hackers. If the cybercriminals win the race, then hundreds of millions of peoples' payment information, medical records, and extremely private personal information get put at risk. In other words, peoples' identities and lives are put at risk.

Everyone believes that Apple is technically capable of making the kind of malware weapon that the FBI and court are demanding that they make. However, Tim Cook has called it "dangerous" and not just for marketing reasons—the FBI are proposing that Apple create a tool that relies on the same kind of vulnerability that, eventually, cybercriminals (or security researchers at another company) will discover and publish or exploit. Then, hackers can exploit this by creating their own version this malware, probably without Apple's knowledge.

Because Apple would have no way to know when or if cybercriminals had managed to find the same loophole that Apple used to create malware to hack phone for the FBI, then by the time they found out, it would probably be far too late. Not only would people's devices get hacked, but also, Apple would be responsible, because they would have known about the exploit well in advance of it being taken advantage of. Ironically in that inevitable situation, the FBI themselves would be the ones enabling cybercriminals to hack everyone's phones.

The Nature of the Risk

You should also realize that such a malware, if it came into the wrong hands—whether by being leaked from within Apple, or because Apple kept the exploit open for the sake of law enforcement—could easily be used against the United States by its enemies—and used more effectively than it probably could be used by the FBI to stop them.

To use such an exploit the FBI needs to have the device and its owner in its custody... otherwise the owner can wipe the device from remote. The FBI then must take the time to get a warrant and send the device to Apple, etc.

However if cybercriminals have the exploit (unbeknownst to Apple or the FBI), they can exploit it as soon as they get a device, before the owner knows it's missing, and possibly without the device even going missing. Its owner will not be a criminal that (if they were smart) didn't keep anything sensitive on it; they'll be an American citizen, who, thinking the device to be secure, kept all sorts of things on it that would be damaging if they fell into the wrong hands.

Suppose that a nuclear plant worker plugged his phone into a compromised charging terminal at an airport. Cybercriminals use this backdoor to plant secret spyware on his phone and use it to get inside the secure systems at the nuclear power station when he connects to its WiFi using his phone. Such a technique could also be used to get into the WiFi network of an airplane, which is one theory behind what happened to the Malaysia Air flight that went missing.

Terrorists could also use cybercrime to steal identities of people traveling abroad, then infiltrate the country using the medical information and payment methods on their phones to completely impersonate them.

These are, sadly, very real types of threats. If there's a way to create this hack, you can be sure that the cybercriminals and hackers will (sooner, not later) figure create the hack themselves—*whether or not* Apple creates this tool.

The only line of defense we have against cybercriminals and hackers in this world is the sort of encryption which the iPhone has. On the other hand, as you point out, it could also be used by terrorists to keep certain secrets.

The Surveillance State Is Not The Real Problem

On the air with Lars, I said this issue is about freedom and privacy vs. living in a surveillance state. However, while I was upset to learn of the NSA spying on American citizens without warrants, I also feel that the real threat is not from our government spying on us, but from cybercriminals and all the enemies of the United States who are, every day, already using the type of malware against us that the FBI wants Apple to create and leave the vulnerability open for.

Lars makes a good point, which is that a threat like 9/11 is also very real. However, it seems to me that 9/11 happened only because the FBI and CIA failed to do their jobs properly. It had nothing at all to do with a lack of access to information, but everything to do with the FBI and CIA being dysfunctional organizations much in the same way that the Challenger disaster was a product of NASA's dysfunction. Not listening to subordinates, and lacking interagency communication, led to the hijackers falling through the cracks of the agencies who were supposed to be protecting us.

Of course, CIA and FBI have made many changes in response to that dysfunction since that time, and the Dept. of Homeland security was also created in response to it. These interagency communication improvements are good, but we should not have needed to lose two space shuttles and two WTC towers to get people to wake up and do their damn jobs right.

So... as someone who watched the towers fall and the Challenger blow up, I have a very hard time siding with the FBI when I know if they just did their jobs right, then it would not have been a problem. However I also think we should support the FBI and NASA more now than ever, because the missions of both these agencies transcends their past mistakes. Nobody is perfect, least of all me, and if we can't persevere then how can we take pride in the USA?

So I commend the FBI for being worried about stopping terror attacks, but they need to let Apple be worried about stopping legions of cybercriminals and hackers who are working day and night towards stealing hundreds of millions of people's entire lives that they keep on their phones, including medical records, payment information, and private information related to their jobs, etc.

If Apple can't be allowed do its job in the war against cybercrime,  then there will be a lot more dead terrorists with phones that the FBI needs Apple to yet again hack, because the criminals will just find other forms of encryption to lock up their sensitive data. However regular American citizens will be put at risk.

Cybercrime Is A Greater Threat Than Terrorism

I believe the threat of terrorists being able to use encryption to keep secrets is a much lesser threat over-all than that of cybercrime, due to the huge and immense scale of cybercrime, and the fact that it can be done to anyone at any time anywhere in the world. You have not seen the server logs that I've seen... you can't have a server online for more than 15 minutes before the hack attempts start. It's crazy out there.

You might think that Apple could create this malware, and keep it safe, keep it secret. However, by doing this, they would be taking on an incredibly huge liability. Since that could potentially do irreversible harm to their business, Tim Cook is, technically speaking, legally required not to take that action. However, the reason it would harm their business is because it would harm their customers.  If they create this tool, history tells us that someday it will escape into the wild, or evolve in the wild on its own. No one will know that it exists in the wild until it's much too late.

And guess what? We've already been down that road, several times. There were a number of high-profile encryption backdoors that seemed awfully conveniently left in place, like Heartbleed, which the NSA knew about for years before it was eventually discovered by hackers, then used against lots of businesses and innocent people, with losses well into the billions at the high profile big banks and government agencies being hit particularly hard.

These are also the exact same kinds of exploits that have lead to the theft of military aircraft schematics from the defense department—do you understand what I'm saying?

The Catch-22 Of Data Security: The FBI needs to actually be intelligent.

It's a horrible catch-22, but if we're going to have security, the simple fact is that government agencies like the FBI and NSA need to do their jobs without relying on companies like Apple to leave security exploits open.

They need proactively and work on its interrogation techniques and ways of detecting threats before they happen, and not just relying on companies like Apple to enable them to hack the phones of people in their custody who are uncooperative due to death or other reasons.

The FBI needs to be watching potential terrorists who have immigrated recently from countries that are known to spawn terrorists. They need to surveil those people using the myriad of techniques that exist today.

Frankly with all the crazy tech that's available to the FBI for surveillance now, it's almost a joke that they would need Apple to hack someone's phone. They can follow them 24/7 with drones and use special lasers pointed at windows to pick up every single thing they say in their home. They can also tap their conversations. It's kind of crazy that we are even talking about this.

However the FBI and Homeland Security allowed a terrorist to immigrate from a known terrorist threat nation. They let her set up shop, stockpile weapons, and go on a shooting spree. Their demands to Apple frankly seem to me like a way for them to deflect questions off of themselves for failing to properly identify the threat posed by the San Bernadino terrorists prior to the attacks.

So it is from that perspective that I responded to Lars Larson's question of whether, if I was the CEO of Apple, and the FBI came to me with a phone and said, "we need you to crack this to stop a major terrorist attack," I would say "no." Because there is a lot more at stake than I think you are giving Tim Cook credit for realizing.

What's more, Apple cannot hack a phone if the owner is still at large, because they could just wipe it from remote. That means, the only time the FBI will need Apple to open a phone is when they already have the suspect in custody or they're dead. The likelihood that the FBI would already have a  suspect in custody and yet their phone is only key to stopping a major attack seems very low to me.

What seems more likely is the FBI will be asking Apple to hack phones potentially full of HIPAA-protected medical records for suspects who already pleaded guilty or who pleaded the fifth. At that point, is the FBI likely to have no other leads that it is intelligent enough to use to stop whatever pending attack the phone might hold the key to?

To ask Apple to betray any of its customers' trust, especially a customer who (more than likely) will not even have been proven guilty yet and may be pleading the fifth, is tricky.

Then there's the fact if a loophole exists to hack an iPhone, there's no way to know that Apple's the only one who has that loophole. That, in turn, casts a reasonable doubt upon the authenticity of any information that could be found on that phone, since it could have been planted there by a hacker.

In Conclusion

I appreciate your willingness to read this. It's just my perspective on it as someone who has worked in computer programming and network administration (and thus, cyber security) in the past.

I'm sorry to Lars that I wasn't able to make this point more clearly on the air. It is a complex issue.

But I don't feel this should be a political issue; I think it is clear cut and we should all agree that a free and secure society based on the Constitution comes with certain risks.

The legal issue of whether or not the court should legally be able to tell Apple what to do, is a sideshow to the real issue of whether Apple, if it discovers a security loophole, should leave it in place and hope no hackers find it. Because, hackers WILL find it.

Wednesday, July 09, 2014

How to Fix iOS Upgrade Issues

For those who are having problems. I have been an iPhone beta tester and I am a developer as well. We run into tons of problems doing over-the-air updates in the iOS 7 beta tests. The problem has to do with certain database files that get corrupted in the iOS system directories. These databases contain, among other things, information about your iCloud account credentials and certificates used to validate your device to the servers. When the DB gets corrupted, it can cause issues with these services. We saw a lot of issues with iMessage for example.

Here is a method that I found works well to resolve issues.

Before you start, make sure you have at least as much free HDD space on your computer as your iPhone's capacity. Ideally more. If you don't, and you're on Mac, then use the nifty app WhatSize on your Mac to find big files on your computer and delete them to free up space.

STEP 1: back up any existing versions of important apps that are in your iTunes folder on your computer in /Users/You/Documents/iTunes/Mobile Applications/. (Time Machine already does this, so if you're using that, then you should be fine, but I burn them off to Panasonic 50-year Archival Blu-Rays to protect them from ever getting purged as old data from my Time Machine drive. That way if a developer updates an app and it sucks, I can downgrade back to a previous version of that app.)

OPTIONAL STEP: If you have a lot of photos and movies taking up space on your phone, I recommend that you download all the contents of your Camera Roll (photos and movies) to your computer, then create a second back up to Time Machine or an external drive, then delete them off of your phone. This will greatly speed up the backup/restore process (in the next steps).

OPTIONAL STEP: If you have lots of big recorded data files in other apps, such as Garage Band recordings, etc., it will also speed up the backup/restore process to transfer them off of your device to your computer using iTunes file sharing or a third-party utility like PhoneView/iFunBox that lets you copy files in and out of application-specific directories on the iOS file system. (You can always put this data back later.)

STEP 2: Connect the iPhone to your computer and launch iTunes. Right-click the device and select "Transfer Purchases". Let that finish up. It can take awhile, especially if you've never done it before.

STEP 3: Click "Back Up Now" under "Manually Back Ups and Restore" to create a full, current backup of your iPhone to iTunes on your computer. (If you don't do this on a regular basis, now is the best time to start!) This takes a fair amount of time. It may take a really really long time if you have not done the OPTIONAL STEP(s) above and your iPhone has lots of data on it.

STEP 4: Back up your latest back up, iOS apps, photos, etc. If you use Mac and have a Time Machine drive, then do "Back Up Now" from the Time Machine menu and wait until it completes. (That way if your HDD fails during the next step, you won't lose all the data from your phone.) If you don't use Time Machine and/or Mac, then find an alternate way to back up your iTunes backups. The easiest way is to simply copy the /Users/You/Library/Application Support/MobileSync/Backup/ directory to an external volume (USB stick, hard drive) or burn it to Blu-Ray (this is the ideal solution since BD-R can last 50 years even through a major solar flare). (If you use iCloud Backup from your phone, this can also serve as a secondary backup, but I do not trust clouds. Clouds can evaporate.)

STEP 5: Click "Restore iPhone..." and proceed. This will erase your iPhone and rebuild all databases, restoring everything to factory defaults.

STEP 6: Set up your iPhone as a New iPhone. Enter your iCloud information and get yourself to the point where iMessage is working, phone is working, text messages are working. If they still aren't working then you have a hardware problem with your phone: take it to Apple. But 99% chance these services will be working fine. Test it with your e-mail servers too if that was causing you some problems, just make sure to set up with IMAP and don't delete things of your e-mail servers.

STEP 7: Now, click "Restore Backup..." and restore the previous backup you made in STEP 3. This will start from the newly-rebuilt databases and import your settings from the previous backup. This takes awhile.

STEP 8: Your phone should be working now. Use it. Don't forget to make regular back-ups!

Monday, May 12, 2014

Safari Annoyances

Visit a page (lets call it Page X). Two weeks later, view its tab (Tab X) and read it for an hour. Then click a link on that page—a link pointing to Page Y. This causes Tab X to now display Page Y. Now you thought that it opened in a new tab so you close the tab—then you realize that it actually had not opened in a new tab. How do you now get back to Page X? It is not in your recent History because it will only appear in the point of your History's timeline when you originally navigated to it two weeks ago... nevermind that you just spent an hour today reading Page X! Ugh now I have to sift through weeks of history to find that.

Worse, the page is like this one so even if you find it, good luck remembering which section of that page you were viewing.

Solution: History should make Page X float to the top if I just looked at Page X (but still remember also when I first went to it, where I came from, and where I left to). It should also remember where on Page X I last was as part of the history—perhaps even remembering the series of scrolling actions I've taken on that page as part of my history at it.

Sunday, April 20, 2014

Skeuomorphism Revisited

I was highly critical of iOS 7's new UI when it came out: I hated on the stark white look, trashed the sub-minimalist approach, belittled the conflicting design principles, and called it downright Microsoftian.

I am simply a Mac lover and an iOS lover and I liked the fact that iOS had a similar look and feel to OS X. iOS was originally marketed as basically "OS X on a phone" where you could view "the real internet" (instead of the gimped, mobile versions of sites that other phones were limited to). It really lived up to this feeling.

I also loved many of the skeuomorphic apps from Apple and third-party devs. Sure there were some horrific atrocities like the old Game Center, but looking back on it, I think for the most part skeuomorphic design is superior.

There are two primary advantages of skeuomorphism that I have not seen discussed anywhere else, and which I wonder if Apple even considered in the absence of Steve Jobs:


One is that it makes each app feel much more distinct.

An example: one of my favorite third-party apps, Grafio, had this beautiful design with wood textures. When I was in Grafio, I knew I was in Grafio. But the new version of Grafio removed all that nice design and replaced it with stark black icon bars and thin little 'minimalistic' icons. However now, when I'm switching between apps, iPhoto and Grafio look very similar and I just don't feel a distinct difference.

By giving a photo-relasitic look to textures, tools, buttons, it lets app designers take full advantage of the beautiful retina displays we now have to make their app feel totally distinct. Yet so many apps that previously had such interfaces have ditched them and have all gone to the same stark look. The more I use all these apps the more I miss the old distinctness. When I go back to my iPad (which shall always remain on iOS 6, sorry), suddenly each App now has that distinct feeling again; each one is its own little work of art :D

Sure, there is nothing in iOS preventing custom UI; but for some reason many developers ditched their custom UIs anyway. Perhaps that's because now, it seems like it might be easier to make your app not look like a system app yet still use the canned UI of iOS 7, because you can customize the color scheme better than you could with the canned UI of iOS 6. However there are only so many color schemes that look good, and many third-party apps gravitate towards the same ones.

The only thing that sets them apart from each other now is the use of different icons, but due to how thin and slight they are, again it just doesn't feel like there's a lot of distinctness between them.



Two is that skeuomorphism fools the brain. It gives a feeling of physicalness and playfulness to things. It subconsciously makes you want to touch things to see what their texture feels like. It naturally inspires curiosity and inspection.

Like it or not, we do still live in the physical world. Our brains evolved over millions of years to distinguish things from each other by texture and feel. There are more neurons in the brain dedicated to the nerves in the finger tips and the visual system than almost anything else. Two of the chief things that makes us human are our superior color vision and extreme manual dexterity.

Vision and touch in fact tied together: "eye-hand coordination" goes far beyond just being able to coordinate action. It also entails Hebbian adaptation: the ability to "feel" a touch sensation *before* you have actually touched something. Seeing a texture anticipates feeling it; this predictive ability of the imagination and subconscious is evolution's solution for the problem of lag: by feeling something before it is touched you can avoid touching something bad before you already have, and it's too late. (Touch a hot stove.)

All sensations of texture take place fully in the mind. Sensory data from the fingers (touch) can be one source of what causes the mind to perceive a texture, but sight data from the eyes can also trigger it, as can memories. Just as you can imagine touching a leaf and remember the feeling of it, so also you can see a picture of a leaf and reach out to touch it, and even if it's behind some glass, just the action of doing this can cue your mind to "feel" the leaf more realistically than if you closed your eyes and just tried to imagine it.

On a certain level, you don't need to actually feel "real" (physical, mechanical) haptic feedback to have haptic feedback, because to quote Morpheus, "Your mind makes it real." You just need realistic, familiar textures and realistic-looking skeuomorphic design, and boom, you have haptic feedback -- probably better haptic feedback than if you actually had whatever crappy haptic feedback we'll likely see whenever the physical kind finally comes out. On a subconscious level, your brain anticipates feeling the textures it sees; then it anticipates that feeling even if the neural impulses don't actually come from the fingers.

Steve Jobs understood this. He famously said regarding OS X's Aqua interface, "One of the design goals was when you saw it you wanted to lick it." Steve understood there is a subconscious element to things and that a good UI ought to leverage all the processing power not only of the computer, but of the user's subconscious mind.

After all, Neo, what's the difference between something that tastes like chicken, and "real" chicken?


So why did Apple give up that technology in iOS 7? I would argue that they were forced to, and it was not necessarily by choice. They realized that in order to migrate iOS to a variety of screen sizes, they could not keep kicking the pixel can down the road.

The only legitimate problem with skeuomorphic design is that it's highly reliant upon bitmaps. We saw with the iPad Mini that the UI simply shrank, something Jobs wanted to avoid because the original iPad UI was designed to be just the right physical size for actual fingers to use. However some people have better manual dexterity and close-up eyesight than others, and Apple sells plenty of iPad minis as a result. I don't see a problem there.

But on the iPhone, Apple knows that it can't just decrease the screen DPI and make it bigger, while remaining competitive. They want to make a UI that will scale properly across devices while remaining the same physical size.

That's why in iOS 7 they got rid of so much UI chrome, because they want the UI to be solely based on vector graphics elements (like fonts and lines) that can scale perfectly if the screen size changes. That's why they are pushing developers to use the "AutoLayout" constraints, which are a series of rules that defines where on the screen each element gets drawn according to its distance from other elements or the screen boundaries, instead of just a position on a grid of coordinates that is directly mapped to a pixel grid.

I've been in favor of a fully vector-based UI for OS X and iOS for many years, since in a world of varying screen sizes and varying screen DPIs it would be the only way to have a truly resolution-independent, WYSIWYG UI.

However even though Apple said several years ago now that they would move to a vector-based UI for OS X, they never did because it would have been too much to ask everyone to convert all their UIs into to vector-based ones. Every app would have to get redone. It's a monumental undertaking, and Apple did not have a way to force developers to do things. Besides, it's not like you can't just change your screen resolution on a Mac if you want the UI elements to look bigger, or use the zoom-feature. Also, apps run inside their own windows on the Mac, so it doesn't matter if that window gets smaller.

Now on iOS, Apple does have the ability to force developers to do things. That's good because it means they can require the use of APIs like AutoLayout and TextKit to make apps that will scale to differing screen sizes. This becomes a manageable task when you can stop worrying about scaling textures and design all your icons as vector-based ones. You can use a desktop-publishing style approach to design now and achieve a nice look through alternate means than skeuomorphism.


But have we lost something important with the move away from skeuomorphism? I'd argue that perhaps we have. How can we get back there and strike more of a balance between resolution independence, and psychohaptic feedback?

One idea would be to use dynamically generated textures based on fractals or other forms of procedural math, or leverage OpenGL to scale bitmapped textures in a way that looks better using bump-mapping and dynamic light sources linked to the accelerometer.

This is where I think we are ultimately headed, probably not as soon as iOS 8, but somewhere down the road.

Check out the new Frax app for iOS to get a sense for what kind of real-time textures can be possible:

The issue of course right now is battery life; you have processor-expensive textures everywhere and it just kills you. However if the textures are not updated in real-time, but simply rendered once upon determination of the screen size, and then cached, it doesn't kill you.

Apple has a lot of ground-work to do before it can realize something like resolution-independent skeuomorphism in a battery-efficient way through system APIs with fractal textures and OpenGL, etc. However I would not rule out the possibility or assume that they went away from skeuomorphism on purpose.

Because if you look closely skeuomorphism is still present in certain places in iOS 7: the look of frosted, translucent glass in Control Center and Notification Center; the light paper texture of Notes app. It's present in things things that can scale independent of resolution, as one might predict if I'm right, and they haven't completely eschewed skeuomorphism but rather been forced away from it in order to migrate to a variety of screen sizes.

I do not think Jonny Ive doesn't understand the value of psychohaptic feedback in places, but I think they wanted to make a bold move and push the envelope in a new direction to freshen things up. That's not to say the pendulum couldn't swing back the other direction towards a method of implementing psychohaptic feedback via skeuomorphism in places where it really does help the interface feel more interactive and draw the user in more.

So I am highly critical of iOS 7's notion that all of a sudden, these sorts of skeuomorphic cues are no longer useful, now that we've been using touch interfaces for a couple of years. Sorry, but it just seems idiotic to me to arrogantly assume that after just a few short years Apple might have undone millions of years of evolution and fundamentally changed human nature. Sorry, but I'm right.


Problems with the Deference Edict

Another aspect of the iOS 7 design principles that has hurt apps has been the "get out of the user's way" bit. "Deference" was the buzzword Apple chose for this idea: "The UI helps users understand and interact with the content, but never competes with it."

This is why the UI of Safari hides from you when you scroll around. I won't argue that it's great when used right: Safari uses it right (although I think Safari's UI is too 'thick' when it is on the screen). Deference is something that great UIs have always featured, going back throughout time. The original WriteNow for Mac had a ruler that "hid" behind the text window to maximize the text area on the old Mac's 9" screen.

Yet do the the deference edict, many app designers have felt compelled to make their UIs smaller and more cramped. This has resulted in buttons that are too close together. Where previously controls were well-placed for one-handed thumb use, now several of my favorite apps demand that I use my index finger to carefully push tiny, thin buttons. Grafio is a good example of this; it used to have sidebars that reduced the visible canvas area a bit, but made it much easier to select the tools with my left thumb.

However the fundamental problem with "deference" is that it's hard to use correctly. Let me explain.

Prior to the "deference" edict, in iOS 6 and earlier the primary consideration of UI design on iOS was the physicality of using it. I.e., if I'm holding the device in my hand, and using this interface, where should the buttons be in order for them to be in the most ergonomic positions when I'm using this device with one hand? How about two? The best UIs were the ones that placed the controls in a manner that made it easy to reach them and reduced the likelihood of pressing the wrong button. They often accomplished this by using the easiest types of gestures like swipes to reduce the number of buttons necessary on the screen at any given time.

However under the "deference" edict, the general MO of the UI designers became, "How do we reduce 'clutter' off the screen"? So they started to ask questions like, "Why is this sidebar here, can't we just move this icon down to the bottom bar?" Someone might respond, "But sir, then all the buttons would be pretty close together down there." Yet they would end up doing it anyway because, well, ergonomics must be sacrificed to free up a bit more screen real-estate for 'content.'

That's forgetting of course that these apps are *tools*, not just *content consumption portals*. Tools should be ergonomic. Form should follow function. 'Content' is important, yes, but just like with minimalistic furniture, what good is a chair that is not comfortable? A couch that hurts your back? Who cares what it looks like if you don't want to sit in it?

Most of the attempts at "deference" I've seen in the apps I use have just resulted in the cramming together of icons along the bottom row (when perhaps they used to be in a side-bar or side panel) or interface elements that annoyingly flit away with no obvious way to get them back. The eBay app is the worst example of this; they hide the most useful options until you push a button to "see more". Now I have to spend more time tapping and less time using. I don't care about the fact that when the menu is on the screen it conceals less of the 'content'; it always conceals some of it, and now it's there for longer than I wanted because it takes me longer to tap more.


Reservation of basic gestures

Despite the fact that Apple wanted "deference" out of developers, on the other hand Apple reserved for system functions the most useful basic gesture that could have allowed us to get rid of interface elements: swiping. Facebook app for example used to have a great tray that popped out when you swiped from left to right, but now since that's the "universal back gesture" they had to add yet another button to their UI. I did not see this as an improvement, not that it was Facebook's fault.

Even worse now the system swiping competes with other swiping like swiping to scroll. Often when I'm trying to scroll around on a page, I inadvertently activate the "back" or "forward" gesture. It's just annoying.

I do like the universal back and forward gestures, don't get me wrong; I just don't think they helped developers implement "deference" and I think there it has definitely lowered the percentage of times where my attempted gestures are interpreted correctly in several types of situations.


Removal of features

All you have to do is read the Apple support forums about Numbers, Pages, iMovie, etc. Many important features that people relied on were simply removed.

What's the problem? Why remove critical features?

Surely not budget; Apple, the richest company in the world, can afford to hire however many developers it wants to make sure that every useful feature gets included in its apps. Surely not capability; Apple has no lack talent in-house.

No, I think it's something deeper. I've noticed it with video game companies, I've noticed it with application developers. I think it's a kind of trend in software development and release that's developed ever since cloud-based distribution became common.

It's the feeling that you can always update it later so it's OK to just release something in an unfinished state. It's skipping a true beta test and just releasing beta software that's missing core features from previous versions.

Was an order given out to each team at Apple that said: pick five features to ditch from your app? I don't think so. I think it's more that when they change lots of fundamental frameworks and shift to 64-bit and enforce iCloud compatibility, they have to basically re-do the entire app from scratch anyway. It's a major, huge code refactoring job. In order to hit release deadlines they had to pick some things to leave out.

But you see Apple's culture of secrecy means they don't tell any of us WHY they did it. We just have to speculate. It leaves users frustrated and they don't understand how an "upgrade" could remove features. Apple needs to be more transparent about these things and let its flock know, "Hey, if you need feature X, Y, or Z, then don't upgrade yet, because that won't be out for awhile yet."

Take iMovie for example: many people didn't find out until after updating that the latest version of iMovie for Mac cannot import projects from the latest version of iMovie for iOS. You have to downgrade both in order to have compatibility. But how do you downgrade both once you've already upgraded? It's a very complicated procedure, and it's only possible if you had the foresight to keep regular backups of all your iTunes .ipa files.

The forces of capitalism aren't going to directly force Apple to keep its iLife or iWork customers happy: if people feel burned by these apps then Apple doesn't instantly go out of business. An app developer whose sole income is from a certain app, on the other hand, has a direct motivation not to piss off its customer base.

Apple must therefore really go out of its way to make extra efforts to listen to customer feedback and ensure that its customers remain satisfied.

However I've noticed an alarming trend among people who work in software, where they think they know better than their customers. This has really become part of Apple's corporate culture and it's really annoying. Everyone starts thinking they are Steve Jobs and they can remove some core feature as if it was the floppy drive and their product is the iMac. I must point out that just because you remove a core feature from a product and customers complain about it does not automatically mean that it's a good idea, simply because one time in the 1990s Steve Jobs removed the floppy drive from the iMac.

The floppy drive took up physical space in the iMac and added to the cost each unit would take to produce. However in software removing a core feature might save developer costs up front, and possibly speed up development, but it won't make each copy of the app cost more to produce. If it results in fewer people purchasing the app or recommending it to others however, it will negatively impact sales, which will greatly lower the profit earned by the app.

The more customers you piss off, the fewer people recommend you to others, and the more haters you gain. It won't be noticed in the short term, especially with bundled apps like iMovie, but in the long-term it will cause your product line to lose its competitive edge and erode your profit margins.

The thing is, I honestly believe Apple does not intend to upset its customers in this way. I just think there is something wrong in their product planning and testing that is leading to this sort of thing happening. Maybe they don't interview enough users of the actual products to find out how they actually use them. Maybe they rely too much on usage data provided and there is something faulty about this. Perhaps they don't do enough open public betas where real actual users test the new version and report on how well it continues to meet their needs.

Whatever the case may be I sincerely hope that Apple is making changes to address this issue because there are a lot of other ways in which I feel they are not listening to their customers, that have caused people I know to switch platforms and give up on Apple.

One problem I see is that Apple does not interact with people on its support forums. It should take a page from what many other companies do and keep closer tabs on this. It should have a team of people who communicate with users and relay the complaints and concerns from users back to the engineering teams, just like they do for their phone lines. Customers expect this. They don't understand how they could post a problem on the forums and then nothing gets done about it.

They should make bug reporting and beta testing more open and available to non-developers. Frankly the feedback portal they have is just too inadequate. You can't file a ticket and keep up with the progress. You feel like you're just pissing in the ocean. I know Apple listens to the feedback they receive but users never get the sensation that they really do.

One of the worst things is that since developers are the ones doing all the beta testing for new iOS releases, and when we install the update we're told to backup, and install it in a very particular way, then who outside of Apple is beta testing the "normal" update and install procedures that users will be doing? Nobody. So is it any wonder that over-the-air updates and "non-clean" installs typically have so many problems? Those procedures never get beta tested! But they could, if Apple had a corps of real-user testers.

Ultimately no company is perfect but periodically I must issue a rant. I love many things Apple is doing but I'm not here to talk about that stuff today. I'm a hardcore lifelong Mac user and developer and none of that will ever change. I'm just stating my opinions in the hopes that it might inspire some debate and I can refine my views if I'm wrong about something. Then I can send that refined view to Apple as properly considered feedback.

Monday, March 10, 2014

No Thanks for iOS 7.1

Great, they made the button to answer calls smaller, so it's even harder to press while driving. Thanks, Apple. Thanks for not fixing the fact that in the app-switching screen, if the tiles are moving, you can't swipe up on them. Thanks for not fixing the fact that all the interface customizability options are buried deep inside the "Accessibility" options, as if you must be handicapped or retarded if you want to change how the thing looks and feels. Thanks for not adding a night mode, just insulting us with a "less bright" white mode. Give me a break. This is a slap in the face.

Way to show you were wrong in the first place by adding back button outlines. Either you were right, and buttons don't need outlines, or you were wrong, and they do, and it was a waste of time to remove them pointlessly in the first place. Protip: you were wrong.

I sure hope you fixed the crashing of WebKit-based browsers in apps, like Safari and FaceBook and Mail and everything else, where right when I want to watch a crucial video or browse to a crucial page, the app randomly quits and when I re-open it, the page I was at is not there (though the other 15 browser tabs still have THEIR pages). I sure hope you fixed the fact that when I plug in my car stereo to my headphone port, the phone switches my phone calls to the headphone jack instead of my bluetooth, even though my car stereo does not have a mic, and is turned off when I make calls.

I sure hope you fixed the fact that the App Store has no way to search for apps by what country they were made in, or when they originally came out, or how much (or little) they cost, but that we're forced to sift through apps like idiots with the worst search filtering system I've ever used in my entire f(*&ing life.

Thanks for making the best product simultaneously the worst product and wasting countless hours of your developers' time changing around icons that were already ugly (and still are) instead of fixing interface flaws, the App Store, iTunes store, or the fact that Podcasts ALWAYS asks me if I want to turn Cellular Data on -- even though I *do* have it turned on, AND I have unlimited data!


PS -- I sure hope you added WiFi calling, because after months of trying I had finally convinced my boss to get an iPhone 5S. But when he took it home to his place in the boondocks, he couldn't get any reception. So he switched back to Android, because he can get phone service over WiFi with his Galaxy S4 on T-Mobile. I sure hope you are actually interested in implementing features that will save customers, and not just stuff that will stroke Johnny Ive's already over-inflated ego an sense of self-importance.

Friday, March 07, 2014

Find Any File

Thomas Tempelmann's Find Any File is an awesome file-finding utility that does not rely on Apple's annoying Spotlight technology. Instead it uses unix's find command that is built into OS X. It can even search your bootcamp drive and you don't have to read a confusing man-page!

Thursday, February 20, 2014

Spotlight is a piece of crap

Spotlight is a piece of crap. There, I said it.

My computer should run super fast. But if spotlight randomly decides to start indexing, suddenly everything slows to a crawl. Why can't it wait until I'm not doing something important?

I would update to 10.9 to fix this, but according to coolestguidesontheplanet, the spotlight woes persist in 10.9. They simply recommend deleting the spotlight index, which of course requires rebooting your machine.

What's more, spotlight has never worked well for me. When I search things from it, it wants to search every email I've ever sent. It defaults to searching the contents of files, so when I want to find Word, it pulls up every e-mail and PDF on my computer that has the word, "Word," in it, and since there is sooo much stuff on my computer, it slows down the search process significantly.

There's no clear way to tell spotlight to only search filenames by default, nor to ignore contents of files by default. You can't tell it to ignore groups of folders on searches performed from the spotlight menu; you can only take the draconian approach of removing certain folders entirely from its index. But then, what if I want to search those non-indexed areas?

Further if you turn it off, it breaks a lot of stuff, since Apple's system internally relies on spotlight to do things, often with horrific results. For example, one time it used spotlight to identify which volume to erase during a Bootcamp install, but since one of my drives was set not to index, it thought that was the drive, and this caused the Bootcamp Assistant to reformat my external USB hard drive rather than the USB stick that I wanted to make the Windows installer on! Sigh.