Does AirDrop seem to hang when you're sending photos from your iPhone to your Mac? Welp, add "Bringing Devices Together" (I think where you can AirDrop by proximity between two iPhones) to the Apple Fail archives.

After an Apple Support chat session, the agent mentioned something about "bringing the devices together" - I think they assumed the transfer was between 2 iOS devices.

iOS device > General > AirDrop > Bringing Devices Together

I believe it is on by default when upgrading to whichever iOS release contained NameDrop. I manually & specifically turned OFF the setting because of recent "security" articles about the new NameDrop capability

I had this setting turned ON, specifically because I did a contact transfer a week or 2 ago. And accidentally left it on.

Toggling it off, retrying the AirDrop, and it worked.

Seriously, who is in charge of QA/QC at Apple? How is sending photos from an iPhone to a Mac not on your integration test list?

Labels: airdrop, apple fail, qa

Can StackOverflow leave nothing untouched? 🙄😉

Maybe some UXer can explain why arrows with circles around them are better than the old vote buttons with just arrows.

Has this been around for a while and I just missed them? 

Well, at least I now know it happened between now and 2020.

I worry that some UI changes are made just to keep people employed and busy. I'm sure there's a good argument or 15 to change it. I'm not sure they're always good reasons.

I still use a version of SourceTree on Windows from 2015 when I'm on Windows. There's nothing wrong with it. I prefer it. I had a coworker see it on a screenshare and say, "Where can I get that theme?" 

What if your redesign resources had been spent on anything else? How many sprints saved? How awesome would your app be? 

Again, not that a redesign is bad. In many markets, simply refreshing the page will drive sales. Just keep in mind the opportunity cost. I realize SourceTree's users are probably more "aged UI tolerant" than most (see my previous post where I admint to using kdiff3), but... 

How much better has SourceTree's core UX experience really gotten in the last six and a half years? What percentage of their storypoints went to it? Worth it? Idk. (But my guess is heck no. Also note that they've worked through several UI iterations since then. Remember when they used a diamond ring for Commit? And people liked it? /cringe twice. Brah culture much?)

In other SO news, I did hit 15k and can protect questions now. I expected to be more impressed when I hit it the way I was with 10k, but... not so much. It's cool, and I'm happy some answers continue to help folks, but I really need to find another semi-obscure but useful tag to sit on.

EDIT: Here's some description. There is a comment that this makes the page more accessible for the visually impaired. I'd like to know how. Does that mean I don't see the improvement? (no pun intended) Yeah, but that's the point of asking. Honestly, what's the improvement?

Maybe down/up/votes are clearer?

There's also a comment that the design doesn't really meet WCAG compliance after all. Apparently they didn't QA dark mode. 🤦

Labels: development, qa, sourcetree, stackoverflow, UI, UX

Apple Inc. is overhauling how it tests software after a swarm of bugs marred the latest iPhone and iPad operating systems, according to people familiar with the shift.

Test software got so crammed with changes at different stages of development that the devices often became difficult to use. Because of this, some “testers would go days without a livable build, so they wouldn’t really have a handle on what’s working and not working,” the person said. 

Labels: apple, applefail, qa

I don’t know why they moved this up, but if they’re really shipping it on Tuesday, just five days from now, I don’t understand why they’re releasing 13.0 at all. The iPhones 11 already have it installed, of course. But for upgrades I don’t see why Apple is releasing it.

Labels: apple, applefail, qa

Labels: apple fail, qa

From macrumors.com:

macOS Sierra 10.12.1, released yesterday, includes hidden Apple Pay images that depict the brand new MacBook Pro with an OLED touch panel that's set to be announced by Apple on Thursday, October 27.

In addition to confirming that such a product is in the works, the images give us our first full look at the redesigned MacBook Pro ahead of its launch. An OLED touch panel is located on top of the keyboard, where the function keys would normally be placed, and it very clearly supports Touch ID, as it is seen used with Apple Pay.

When I've talked about Apple having poor QA before, this is the sort of thing I'm talking about.

Let's give them the benefit of the doubt and say that there are thousands of images in the 10.12.1 update. There's still not so many you can't still divvy them up and have three sets of eyes look at each one. It took the Mac press all of 14 hours to come up with these images.

Could there be mitigating circumstances? Sure.

Maybe some of these are stored inline rather than as discrete files, unlike png/jpg files found within an app (or some other sort of) bundle. It could've been a nice inline image, perhaps.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAzQAAABjCAIAAADCc9LyAAAd0klEQVR4nO3df2wT5/0H8CdfIZAGBLGqRRgyX5sgplK16Yqi...

Maybe MacRumors didn't find them in just 14 hours. Maybe they found the images in a beta and stayed quiet until the embargo was off.

Maybe folks were told the OS would be released concurrent with the new hardware, and that proved untrue (highly unlikely, but as long as we're maybe-ing... Didn't iOS 10 predate the iPhone 7, for instance?).

But even in one of these most favorable contexts for Apple, not to have every image pass in front of enough eyes to catch something the press does this quickly is insane.

Let's be clear: This isn't the Alcatraz level snuck into N64's San Francisco Rush or Warren Robinette's name in the Adventure for the Atari 2600. These images were meant to be consumed by users. Every user-facing image should have been QA'd. Unlike those games' Easter Eggs, this content wasn't hidden, and that QA should've been planned.

Actually, there is one "maybe" that could excuse Apple: Maybe this was a planned leak to stoke some excitement in diehard fans.

You know, I might've been tempted to believe that if...

1. Internal leaks about hardware were common at Apple
   • I'm still flabbergasted by the ATi backlash over 16 years ago, though that's not so germane now.
   • Still, you get my point. How about the Mac Pro's trashcan? Complete surprise, iirc.
2. Apple hadn't become so bad at QA recently (see above).

Oh well. I'll admittedly be watching Thursday. As bad as it is, I still want to [finally] add a new horse to my Mac stable. My current Macs (ones that are powered on) are an old mini and a, I kid you not, 2009 MacBook upgraded to an SSD.

I waffled thinking they'd release something new this March, but finally decided not to get the updated 12" MacBook or wait for a MacBook Pro. Instead, I bagged a $700 14" Lenovo Y700. I thought that I'd regret that purchase quickly when new Macs came out in a month or so afterwards. That didn't happen, natch.

Looks like a portable workstation with a i7-6700HQ for $700 ($850 with SSD & 24 gigs of RAM) was a pretty good deal after all. Wonder what I'd get for it with those upgrades on eBay now, and what percentage of a 13" MacBook Pro it'd cover... ;^)

Labels: apple, apple fail, hardware, macbook, qa

From daringfireball.net:

Mossberg:

For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer.

Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone.

These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, they stop trying.

Exactly right. I've had it do the same thing when I ask Siri to give me directions home, usually because I want to know if there's enough traffic to go an alternate route, and I get the same, "Who are you?!" complaint. But if I open Maps, "Home" is usually the first location listed.

QA sucks at Apple. I'm no longer politely questioning it.

Spend ten million (he said figuratively) and get the best QA staff in the business, and make sure there's no silo making QAing app interactions an issue. If Maps borks like this, the QA team "for Maps" has to be able to hold Siri and Contacts (or whatever else) accountable. No software ships until this blocking bug is fixed.

Good QA will think of and try these sorts of pretty obvious, yet creative, use (not edge, simply "use") cases before you ship.

Pitiful. Seriously pitiful.

Labels: apple, applefail, coding, qa, quality, siri

Gruber weighs in on the rumored iTunes reboot:

What do you see when you open the Spotify or Pandora apps? Just the streaming music you have access to. That makes them less complicated, by definition. “Everything you see is in the cloud, and you have access to it because you are a subscriber” is easy to understand. “Some of this is in the cloud, some of this you own” is more complicated.

He's joining a reasonably long list of Apple pundits with the request to split Apple Music into its own app, the most recent I can think of offhand was Jared Sinclair, whose step two of four ways to reorg Music was, "Bye, Bye, iPod - Break out all the legacy iPod features into another app."

The worst part is that, sort of like the Big Jennifer Null stuff I've mentioned recently, the iTunes confusion really was preventable.

Gruber leaves the door open on the preventable part, saying,

Maybe there’s a way to design “all your music in one app” that is completely clear, convenient, and obvious.

The four sets of Apple Music

Well, the idea Apple had was bang on. It shouldn't matter where your music lives, you should be able to sync it all. There are really only four sets of music files from iTunes' perspective:

1. Files that you brought to Apple music (no DRM)
2. Files Apple thinks it's matched from 1.) on another of your devices (no DRM)
3. Files Apple didn't match from 1.) and allows you to copy to your other devices via their cloud (no DRM)
   • This is really another version of 1, just copied to a new device.
4. Files you've only ever gotten from an Apple Music subscription (DRM)

Apple should keep 1.) around like those files are gold. Never let the user whack those without going through some sort of "locked button with cover" removal process. As Jason Snell points out, there's a real UI issue here, but also a serious functional one. "Remove download" should never throw your original files in the trash. Warn that those are files that you brought to Apple Music, and that deleting them will irrevocably remove the originals. And even then, after they're deleted, make sure users can redownload matched versions at the worst, if they were matched, without DRM, until their subscription lapses. Better is to immediately create a backup of that original file, though I realize there are cases where the user might really rather that original disappear immediately.

Files from 2.) should similarly always be downloaded without DRM. There should also be the possibility of saying, "That's a bad match; give me my original file." Maybe in version two you let the user pick from other possible matches, and then you cloud source the right matches after you get a better idea what goes where.

Files from 3.) are pretty simple. You didn't match 'em, so you let folks copy them anywhere they are logged into iTunes. It's pretty much what Dropbox does.

For the fourth, well, the only real gotcha is when they really do match something from 1.), and Apple mismatched it. But then you've already got both files. If someone tries to delete their original because it's now "duplicated", you should send them through that "locked button cover" process, and possibly have a, "duplicate match" reason there. Then you should delete the file from 4, not 1.

Note that there's another category that we're going to ignore to make things simpler -- things that should be matches that aren't matched. I'd provide a mechanism to say when something's mismatched, but if there isn't a match found and should've been, having the original file from 1.) on another machine isn't too bad. That is, there's Category 5: Things Apple should've matched with AACs they have on file and didn't. Instead of providing a way to say so in order that you get more 2.), just leave them in Category 3 until you get everything else straight. That often happens now, and it's fine.

When your Apple Music subscription lapses, you should probably also be given a final download session (that could take weeks to finish), possibly even on more than one device. "Your Apple Music subscription has ended. Would you like to download your matched and/or original files that are currently missing on this Mac/PC?"

Notice that the first three categories make up iTunes Match.

iTunes Match should've let Apple know that they weren't doing a great job of providing its eponymous function -- matching -- and they really needed to make sure they could get 1.), 2.), & 3.) right before going whole hog into a unified Apple Music. But it's still just a database management problem. They "simply" should have been much more defensive with Apple Music for when matching failed. If your user doesn't have a file three places, don't delete it.

But as long as you have a space for a flag on each file to say which it is -- an unDRM'd original*, an unDRM'd "likely match", or a DRM'd file that's never been matched -- you don't have this trouble.

It takes some great QA, but it's a straightforward, at worst tedious, process. I could make such a system without the issues Apple's seen in, let's say, six months, and I could recommend a good five or so folks that could as well.

• "UnDRM'd" could also included files purchased before iTunes removed DRM.

Labels: apple fail, Apple Music, coding, fail, gruber, iTunes, qa, rdbms

John Gruber on Om Malik on ads in Instagram:

UPDATE: My best guess, and a few readers have made the same guess, is that I don’t see ads on Instagram because I don’t have a Facebook account.

Strikes me as an odd missed use case, unless it's more happy-path-only QA testing we've unfortunately come to expect from Apple too often lately.

I mean, honestly, picture viewing can be used are just like any other set of data points. If he's viewed pictures by anyone else who is Facebooked in, you've got a good starting place. If he's in his own Facebookless circle of schmoes, just drop in adverts for Coke or something similarly universal-ish.

Weird. Can you really inhabit a set for which Facebook has no targeted ads? Did they really not have any concept of untargeted ads to serve up for the null set? Hard to believe.

Labels: business, facebook, gruber, instagram, qa

Stephen Hackett posts another Apple Fail to 512 Pixels:

Here's what the Erase sheet says:

Erasing "Time Machine" will destroy of all the data stored on it. Enter a name, choose a format.

In addition to the text being so brief it feels incomplete, it has two grammatical errors...

I emailed him that Apple's QA is to blame, with a laundry list of the stuff I've pubbed here and pushed to Twitter. Honestly, Apple, you've got to do better than this.

Labels: apple fail, qa

I don't know, seems like another QA fail at Apple, doesn't it?

From Six Colors:

Last night my iMac’s Ethernet port stopped working. Turns out it seems to have been because of a bad, silent security software update from Apple. Just delightful.

More info here and on this MacRumors thread—the update seems to have been pulled and the fix appears to be to reinstall /System/Library/Extensions/AppleKextExcludeList.kext from a backup.

Who is in charge of QA at Apple again? (Past posts on Apple QA (and other) fails here with lots of overlap and perhaps one or two additional posts on QA here).

Labels: apple fail, qa

One of the serious disadvantages of having alpha software is that you need to already start dogfooding it. So if you're, say, writing a Markdown editor, you need to start using it to write you blog posts.

This is great until you find that you'd like to make a change to the app's behavior, which turns a quick 15-30 minute blog post into 15-30 minutes of blogging plus 90 minutes of feature refactoring.

Oh well. That's what you've got to do. I didn't like the way I was inserting quoted text or, rather, marking up a block of text as a quote, so I rewrote it for this post. Fun times. But wow, it's nicer. I like having elegant white space in my files, and now the app will ensure you have two newlines before and after a blockquote in your markdown. Simple enough, if it wasn't for insane UWP TextBox newline management. I completely rewrote how I was handling that so that I could access SelectedText, SelectionLength, and SelectionStart, etc with new properties in a subclass of TextBox instead of post-processing the wacky, non-platform native newlines in code outside of the TextBox.

And though this blog's "main" topic is related, let's move on...

Was checking out Rachel Andrew's free chapter from her book, The Profitable Side Project (hint #1: A Markdown editor probably isn't going to lead to Hats of Cash), which quoted this MVP (minimum viable product) definition from Jon Radoff from 2010:

The goal of a startup is to find the sweet-spot where minimum product and viable product meet

Obvious, it seems, but I think it's worth looking at "minimum" and "viable" on their own terms as independent characteristics of a product, and know that mvp isn't some concept that exists on its own. It is the intersection of these two sets, as his Venn diagram depicts:

I think Apple's completely lost the ability to do this, btw. Read through Michael Tsai's run-down of recently reported problems with Apple Music combined with his run-down of Mossberg's post and reactions to see what I mean. Apple's stopped making viable software, and has grossly overemphasized minimum.

This bit from Jason Snell that Tsai points out is my "favorite", insomuch as a report of a horrible user experience can be a favorite:

First iTunes threw up a dialog box saying that the amount of iTunes credit had changed, so I would need to click OK and try my purchase again. (It’s a free app, so this entire experience is already pointless, but whatever.) I clicked OK and the Free button was now inactive. I typed Command-R to see if that would reload the iTunes page—no normal user would do it, but it worked because the App Store and iTunes is more or less a disguised web page—and then was able to click Free and download the app.

At some point in this process, the song I was listening to finished and another song began to play. It was a randomly selected track from my entire music library. The act of viewing the App Store had destroyed my music shuffle.

I really do think this is, as I've mentioned before (with all "Apple Fails" I remember to tag here), bad QA work at Apple. Nobody seems to be testing the edge cases. And when QA drops back this far, you won't get viable software.

At best, Apple is getting its dogfooding completely wrong. It's really sad how far quality has dropped in the race to be minimum everywhere. They've substituted Jobs', "We'll only support doing it our way, and we don't care who is inconvenienced," which allowed Apple to drop support for legacy techs and hardware at the drop of a hat for, "We simply won't care who is inconvenienced."

Folks, it has to be viable first... as Radoff says, that means a product that will "get people to fall in love with you". It's not something "crappy" that "nobody wants to use". The "Apple Way" used to mean they'd do it right -- loveably well -- no matter what. Man, I loved using MacWrite on OS 7 and 8. OS 8.1 was a great OS, even though it was so old you couldn't help looking at it and wondering when you'd have to put it down. But using it was great. That love isn't there with Apple software now for too many of us.

Anyhow, back to work before I start fixing bugs on my app again...

Labels: apple, apple fail, indie, qa, testing

It’s easy to pick on iTunes, but this is pretty egregious.

Labels: apple fail, iTunes, qa

Labels: apple fail, fail, iTunes, qa, testing

Labels: apple fail, qa, testing