Archive for the ‘Grumpy UX Feedback’ Category

Trackpad dragging the easy way

I’m surprised it took me as long as it did to discover that there’s an accessibility alternative for dragging. In System Preferences, visit Accessibility > Pointer Control > Mouse & Trackpad.

Click on Trackpad Options, enable dragging, and choose three finger drag from the pop-down.

I’ve been using three finger dragging for about a week now and it’s been a vast improvement over my attempts to drag items the normal way. Yes, I still end up running out of trackpad room as I always do, but using a finger from the other hand to nudge things where they need to go does the trick for getting my dragged items to their destinations.

I am using this almost entirely in Finder, although the same approach should work for moving words in a document or views in IB.

My enemy the Minimap

The minimap is one of Xcode 11’s starring features. I know many people were excited for it at its debut but after months of exposure, I now just disable it in the Adjust Editor Options menu (the five horizontal lines of unequal width indicating the contents of the primary editor) and grab back that room on my screen:

I’ve spent some time recently considering exactly why it is I hate the minimap so much. It’s not just that it takes up valuable horizontal space (although to be honest, it’s mostly that). If it did a better job to help me navigate or conceptualize my code, I wouldn’t resent that space. Rather, I get little out of it and it’s a blurred colorful distracting mess for me.

In theory, the minimap is a specialized scrollbar for code. It highlights where are you with respect to the file. You hover the cursor over it to view tooltip details. Upon finding a section,  you can quickly jump to it. Hold the command key down and all the tooltips appear at once for a quick and actionable  overview. All contextual bookmarks are larger sized so technically “legible” although I can barely read them with my bad eyes.

I don’t care where I am physically inside my file, so the scope highlights don’t offer much. I care where I am conceptually. My jump bar gives me the same overview as the minimap (using the command key) without stealing screen space or distracting me with extra pointless blurry information.

What I am at a loss to figure out is how the minimap does that better than my beloved jump bar or why people prefer having the big jumble on-screen. As far as I can figure, the overview (whether jump bar or minimap command key) provides the most powerful tool because it relies on recognition of the details you’re looking for. But most of the minimap is designed around recall: where you are in the file, what the shape of your code is like, etc, which is a far weaker place for cognitive support.

So what am I missing? Why should I love the minimap? Please help me figure out what I am not understanding here and help me turn the minimap from an enemy to a friend.

Falling back to an older MBP

I just recently switched from a 2018 15″ MBP back to my 2015 13″ and I thought I’d share some of my reactions to the change. My meandering and unstructured thoughts follow.

Unexpectedly, on returning to the 2015 MBP, I didn’t suddenly go “omgomg the keyboard is amazing again”. The older style was never amazing compared to any good mechanical keyboard. I adapted to the new keyboard just fine, even though my hands never really were big enough for it to be truly comfortable.  Yes, the older keyboard’s keys really are less of a stretch but it wasn’t that much of a hardship either way.

The basic truth for me is that both keyboards are fully usable and that having the dedicated escape key (or not) was never a big deal. The virtual one did the job just fine. That’s something I never expected to admit but it’s true. I may not love MBP keyboards but they work.

I will admit the older dedicated function keys are slightly better, especially given how I’ve rebound them using Keyboard Maestro, but not an order of magnitude more usable. Just…better. Not way better.

The trackpad feels old and quaint in comparison to the newer one. I miss the 2018 trackpad more than I expected, especially given how I’m an admitted trackpad hater. Moving documents has become again slightly more difficult on the older MBP, so there’s that.

My 13″ screen now feels cramped and tiny, as expected. But I once again appreciate how clean and beautiful the Retina display is, as I compare it to my one-older-purchase, the non-Retina MBA. The 2015 13″ is a great laptop, even if it feels chunkier and less streamlined than the 2018. You can tangibly feel the design differences between the 3 years as well as the battery improvements.

On the other hand, moving back from USB-C to all these wonderful ports is delightful. My 2018 was always an octopus, and I had to carry around a bag of hubs and adapters. (I even have one on my keychain, which I probably don’t need anymore.)

Yes, I still use some adapters like my HDMI to Thunderbolt 2, so I can have two monitors running from the 2015 laptop, but that lives on the HDMI cord, not with my laptop.

I have a bunch of extra file space with the built-in SD card reader with my computer-flush reader adapter so it looks built in. The two standard USB ports are so convenient. I have an entire bag of USB-C gizmos that I’d carry around with the 2018 machine that I dumped into my USB box-of-everything for now.

On the other hand, I do miss the fingerprint reader. My experiences unlocking with my watch are hit and miss. Sometimes it works great. Sometimes it doesn’t. I can’t really figure out when it will and won’t: it’s not just after restarts or a long time between use. In contrast, the fingerprint reader absolutely rocks on the 2018, even if I had to remove a bunch of items from the touch bar because sometimes I’d turn on Siri or mute my audio when I thought I was still unlocking.

Speaking of the touch bar, I don’t miss it at all. As a touch typist I was always a little stunned to discover that it had relevant information on it that I never looked at. If the touch bar had important stuff, it should have been on the screen and my screen should have been touchable all over. As someone or other said (I forget exactly who — sorry!), it’s a keyboard when it shouldn’t be and a touch screen where it shouldn’t be. I’m paraphrasing from memory.

Every one of you who develop content for the touch bar, bravo. I am glad of how you are helping the user, especially the user who can see the touch bar and interacts with it. I don’t want you to change a thing. Instead, I want Apple to step up and get that material integrated with the main display so I can take part too.

I’m holding off on upgrading a lot of things right now. I’m still using my iPhone 6+, my 2012 Mac mini, my 2015 MBP. They all work and get the job done and nothing yet has really given me the motivation to push forward to new hardware. The iPhone 11 is lovely but I don’t really take many pictures. The new mini isn’t self serviceable (at least to a klutz like me) and I honestly don’t want to leave Mojave on it and lose my 32-bit apps. The 2015 (running Catalina) is still a really great laptop.

I’m waiting to fall in love again, the way I did with the 5th gen iPad mini, which swept me off my feet early this year. I adore the mini. Revised and supporting the pencil, it gave me new ways to use it, better user experiences, and a solid beautiful form factor making it a natural upgrade from the 2nd gen.

I want my next hardware purchases to have that same passion instead of incremental utility.

What are you buying and what are you holding onto waiting for the right moment? Let me know.

UX fail: Logging into Apple TV

My son brought a new (which is to say, an old) Apple TV into our lives yesterday. He picked up a 2nd gen unit from Goodwill for under ten bucks in excellent condition. We were delighted.

Even older Apple TVs, a couple of generations before the app store hit, allow you to share music from the family library, watch shows and movies, project from hand-held devices, and use TVs as wireless extra displays.

We immediately began setting it up. The first issue at hand was to log into my Apple ID, so the unit could see my account, purchases, and home share.

I use long passwords. I recommend long passwords. Entering long passwords on a 2nd generation Apple TV using a remote is…well, it’s pretty horrible. Even though I’m a bit proud of my remote skills (for example, press-and-hold to access upper case letters from the lower case screen, or using hold-to-slide for quick letter navigation), it still takes a significant amount of time to enter my password.

And, when I had done so, and counted off the number of dots and confirmed they matched the right number of password characters, I expect that I was done with setup once I clicked the continue button.

Nope, not so quick.

It wasn’t until after Apple TV asked me whether to store my password for purchases (no thank you), and had moved onto yet another screen, that it stated I could not log in at this time. Something something about verification.

I assumed I entered the password wrong but I was a bit befuddled that it didn’t tell me that right away. I had already moved a couple of screens forward before it rejected my entry. What was going on?

After a few times through the process, I knuckled down and hit the web to search for “Apple TV verification”. That’s when I discovered that I needed to generate a verification code and add it to my password (one after the other, all in text in a single privacy-protected box) to log into my iTunes account.

This design shocked me. There was exactly no information listed on the enter password screen suggesting you need to not only enter your password but also append a six digit two-factor code to your password. There was no information guiding users through the steps to generate that code. There was no support for automatically sending a two-factor request to other registered devices, the way it normally works with my browser. Instead, you must generate a verification code on an another device using the same Apple ID.

I use two primary Apple IDs: one is for iTunes purchases and is shared with my family. The other is for my development work. All my mobile devices are signed into both, but you can only generate a verification code for your iCloud ID. You cannot for your iTunes ID.

I had to go through the hassle of picking a victim iDevice, logging out of iCloud, including disabling Find My iDevice and deleting all local iCloud data, just so I could log in using my iTunes account to generate my 6 digit time sensitive verification code. (Settings > iCloud > username > Passwords & Security > Get Verification Code)

It took me quite a bit of time to get a device to the point where I could do that. Wisely (but really just luckily), I left the device logged in to the iTunes iCloud account. I had not realized I’d need to authenticate in several places on Apple TV. The first time accessed my purchased content. The second time enabled home sharing. Again, without any hints about extended passwords and 2FA.

Fortunately, I targeted an aging iPod touch as my sacrificial victim, which, while running the latest iOS release, is not a heavily used dev system. I have not yet moved it back to my main iCloud account  just in case I have to go through this nonsense again.

Once I had my six digits, I had to add them to my password entry. Since timing is critical, I had to type out the password first, fetch the code, and then enter the verification code on my  Apple TV, which had gone into screen saver mode due to the delay. I added the digits to the end of the password (none of which are readable, it’s all dots), and hoped that it took.

All of this took place without any textual or visual indication to set user expectations that the password needed extra characters at the end to begin with.

This is probably the worst design for 2FA anyone could have come up with and I’m baffled at how this got past any level of management to be presented in Apple deployment. It feels like the first iteration of a solution offered by a summer intern before anyone with sense got involved.

I’d imagine that the second you enter an Apple ID, the device is fully capable of determining whether 2FA is needed. If so, it should guide the user how to obtain that information. Add some text, show a video, do whatever is needed, but contextualize!

Assuming that people know how to create the code and then append the code to the password is asinine. It’s also bad design. Make the 2FA code a second screen, for heaven’s sake. Lead users through the process. And for all that is good and holy, don’t make the user pass through one or more screens after the failed password before informing them that (1) the password didn’t take and (2) a validation step is needed and should have been done several screens earlier.

In the best of all worlds, just allow the 2FA code to auto generate and notify the way it does with Safari. Manual generation should be the fallback position only if associated devices are not available.

Every week or two, I have to re-enter a code to access Apple’s developer site. My office rings with the various beeps and whistles of 2FA. Every device helpfully shouts out its association with the iCloud account and provides a six digit key for me to use right away.

Having to laboriously set up a device and then manually generate a code is nonsense. Differentiating the main iCloud account and the iTunes account, both of which have been authenticated, is also nonsense. If a device is signed into both, it should produce 2FA codes for both.

The screen that most offended me was the one interspersed between the “enter your password” and “you need a verification code”. Who gave the okay to continue on with the “use this password to authorize purchases” screen before confirming 2FA? It’s just insane.

In the end, a process that should have taken 5 minutes max stretched to nearly 90. If someone comfortable with problem solving and web searches was this put off by the anti-intuitive UX design, imagine how Apple’s core customer base will react.

This is the furthest I’ve ever gotten from “it just works” in Apple’s ecosystem and a user experience that gives me great pause.

That darn Maps app

Dear Maps team,

Please don’t route me onto a dirt road again. It was super un-fun. I ended up going back up to I-80 and heading over to Wyoming from Nebraska, adding another state and about 5 hours to my trip including the not-joy of I-25 rush hour traffic instead of the much quieter I-76 through Fort Morgan.

It was impossible to get any live data from said dirt road so I just went with my gut until I could get directions again, which took about 2 hours, placing me just outside Cheyenne.

Navigation through Nebraska is always horrible horrible horrible, usually just blank tiles until I hit either Colorado or South Dakota. When going state to state, I’d like to cache tiles along several possible routes because with so much highway construction, I don’t want to be caught with blank tiles in the middle of Nebraska when I have to go twenty or forty miles off to the left or right to avoid a road that isn’t roading at the moment.

Caching tiles and directions along many possible routes would have helped the whole dirt road fiasco. The no-data-no-tiles-no-rerouting trap is both unsafe and unpleasant. Plus it made me miss Sidney, NE, with the only truck stop I’ve ever encountered in the United States that offered bidets (!) in their bathrooms. A true tourist’s experience.

While I’m venting, please respect my wishes about “No tolls” or “No highways” for my entire trip, even if I take a slight detour to avoid traffic. Forgetting “Show me how to get to [Someplace] avoiding tolls” when I reroute cost me  unnecessary funds recently by putting me onto 470, aka the hell road. I was properly billed (thankfully!) and paid immediately but no one voluntarily drives on E470.

Maps folk, please let me say “Show me how to get to Colombia, MO avoiding tolls and dirt roads” and remember that request until I’m safely at my destination. And let me add those requests as I’m driving. During rush hour, let me say “Hey, let’s get off the highways until I’m close to 225”. That’s totally doable from a programming point of view.

Speaking of slight detours, I generally know better than Maps how to tweak directions within the first few miles of my home. For example, I prefer to take the relatively quiet 13th and 14th streets from downtown instead of Colfax or 6th. There’s an incredibly unsafe left turn near our house that Maps always recommends. I drive a little further and make a safe U-turn at a light with a dedicated left turn signal.

I do these tweaks near my home all the time and Maps shouldn’t be fighting me on this, announcing updated directions every single block. I’d like a setting that limits any directions at all (after the initial announcement) for the first, say, mile or two or three away from my home or other “known” starting points that I could add to a list.

In fact, I know how to get to many major milestones within the greater Denver metropolitan area like 225 and Vasquez, and Hampden and 25, and Colorado and 70. I’d like to be able to have navigation kick off once  I’m near a known point or I’m close to the highway or fairly far along towards my destination. That shouldn’t be too hard to develop and customize, requiring no in-car interaction so it’s safe.

In many cases, I only need last mile assistance when driving in-city, including other cities I’m familiar with like Colorado Springs and Fort Collins. I wish I could ask for a “guide me when I’m close to” setting for these kinds of navigation requests.

Thank you all. You know I appreciate everything you do!

Making @KeyboardMaestro work in Mojave

Unfortunately, Apple seems to have messed up assistive apps like Keyboard Maestro in Mojave and if you depend on macros, that’s a very bad thing indeed. I upgraded to Mojave late last week (even though it is still not theoretically a GM) and found that although some actions still worked without problem like app launching others (specifically my universal Emacs key equivalents for arrow moves) did not.

I found this thread about the issue on a Keyboard Maestro forum. The hints on that thread helped me work out this solution to the Mojave problem. Note that you may have to repeat steps after rebooting your Mac.

  1. Copy /Applications/Keyboard\ Maestro.app/Contents/MacOS/Keyboard Maestro Engine.app to /Applications.
  2. In Terminal, kill the Keyboard Maestro and Engine processes.
  3. Open System Preferences > Security and Privacy > Accessibility. Grant privileges to both apps: Maestro and the copied Engine. (I also granted privileges to Finder and Safari, which probably wasn’t necessary.)
  4. Launch the Engine from /Applications. Check the process list for /Applications/Keyboard Maestro Engine.app/Contents/MacOS/Keyboard Maestro Engine and test your macros. You may have many types of macros and you’ll want to hit as many bits of the OS as possible when ensuring that each kind of macro is properly launched and executed.

 

My Mac mini, kernel_task, and dusty hardware: Bring back my mini’s zing

Over the past few weeks, my Mac mini has been getting less and less responsive. The kernel_task has been spinning up taking up ridiculous amounts of CPU time and dragging my system to its knees.

I did what anyone would: I ran hardware diagnostics (passed). I ran SMART diagnostics (passed) and then I web searched the hell out of the interwebs, and there I found an unusual suggestion. Several sites suggested that I may have built up dust accumulation in my mini and that the fan control was trying to mitigate this.

Fortunately, I’m one of the lucky ones (for very low values of “lucky”) with a self-serviceable 2012 Mac mini instead of the upgrade a few years later that removed the service hatch. (*shakes fist*. *darn you Apple.*)

I opened it up and sure enough it was pretty dirty in there. I vacuumed and then I used compressed air to finish (after finding the child who had “acquired” it for an “important project” several months ago and never returned it). I performed a thorough vac and dust of the work area where it rests along with my many backup and external data drives.

Plugged it back in and for nearly a week so far I have not had the same issues reoccur. It seems a tiny bit black magic but it also seems to be working (fingers crossed).

I thought I’d write up a quick post to share my experience and see if anyone else has been through this and has advice or suggestions. For me, it’s like having my Mac back again. I still need a refreshed mini (hint Apple hint) but I have serious concerns about buying one without a self service hatch.

Apple’s move away from self-service products has cemented its appeal as a “computing appliance” provider but it also means expensive service calls for any problem. Much as I’d like them to give us a Mac Pro Lite, at a lower price point than the Pro and a higher one than the mini, with lots of configuration options,  I just cannot see that kind of product ever existing in today’s Applesphere.

A lot of us mini owners cling tenaciously to our six-year-old hardware (or, for some, 4 year old), but I’ve seen no indication that the mini has a future at all in the lineup. If it’s not a product appealing to the BMW owner set or essential for internal Apple use, I don’t really see it having a place in Apple’s marketplace.

One indication against this gloom is Apple’s magnificent iPod line, which has at least gotten semi regular updates. The iPod touch is about the best value you can buy with an Apple logo on it outside of the core iPad released this past March. Both fit into if not BMW owner appeal, then at least BMW owner’s kids appeal. I just don’t see the Mac mini doing that.

Is the mini dead forever? I’m not sure. I like bringing my own displays, my own mechanical keyboard, and thousands and thousands of dangled USB add-ons. That’s what a desktop does for me and why the (self service) mini is the perfect fit.

If you want to point at one change Apple made that said to me: “No mini for you, move to the left!” a la that Seinfeld episode, it was the death of the escape key. The escape key philosophically services a self-reliant power user. And I’m just not sure that Apple is in that market anymore.

Will I get my mini pro? Probably not. Will there be a paradigm shift so profound that customized dev systems can co-exist with mechanical keyboards using a new desktop system? Maybe. What do you think? Are you a mini devotee? Share your thoughts.

Apple vs my daughter’s iPad: Part II

I just got off the phone with Apple, after speaking to a point person on the executive relations team. Isabella G offered to set me up with an escalated support member. I thanked her (and accepted) but said that my concern in this matter went wider than my specific case.

I explained that a no-reason account lockdown was a much broader and much more important issue to me. Our device was not stolen. My daughter did not enter bad passcodes or wrong passwords. There was no reason that the lockdown should have happened and no way for Apple Support to explain why it did  happen. If it could happen to us, it can happen to anyone and potentially at any time.

That my daughter had forgotten her security recovery information, too, led to a much broader issue. She was young, foolish, and feels sorry for her choices. At the very least, she should have changed her email when the provider shut down its services. But having an outdated email and no memory of security questions isn’t limited to her specific situation.

Consider the elderly or those who otherwise struggle with recall. They may be able to, as she was, know their passcode, account, and password but not be able to recall the specifics of the security questions or know where they had placed the documentation for the exact phrasing used when answering those questions the first time. They too may have clung to existing account names even if their email has changed over time.

The core problem isn’t that my child made regrettable decisions. She did. It’s that a lockout happened without explanation and without recourse. Something triggered the lockout. And, it clearly was something that fell outside the scope of where we, as customers, would want or accept that the lockout should occur.

I’d like to find out what that was, how Apple can prevent it from happening in the future and how they can offer remedies given the consequences of both losing information and device utility.

Update: Support call went nowhere but our support person was as usually thoroughly professional and nice. Other theories about what might have happened are “haven’t logged in for a long time, which could have activated the lockdown” (his) and “possibly the privacy act stuff this week bouncing back from a dead email” (mine).

Auto Layout, Playgrounds, and Xcode

Today, someone asked what the easiest way was to center a view (specifically a UIImageView) inside a parent view with minimum offsets from the top and sides.

Because you’re working with image views, it’s important that you first set the content mode. For insets, it’s almost always best to go with a “fitting” aspect-scale, which preserves the entire picture even if it has to pillarbox or letterbox. (Pillarboxing adds extra spacing to each side for tall images; letterboxing adds the top and bottom for wide ones.)

// set content mode
imageView.contentMode = .scaleAspectFit

Make sure your view can squish its content by lowering its compression resistance:

[UILayoutConstraintAxis.horizontal, .vertical].forEach {
    imageView
        .setContentCompressionResistancePriority(
            UILayoutPriority(rawValue: 100), for: $0)
}

You must preserve your image’s aspect ratio. Calculate your target ratio by dividing its width by its height:

let size = imageView.image?.size ?? CGSize()
let aspectRatio = size.width / size.height

Add strong constraints that preserve the aspect, and make the view smaller than its parent using inset values you supply:

let insets = CGSize(width: 20.0, height: 32.0)

let constraints = ([
    // Preserve image aspect
    imageView.widthAnchor
        .constraint(equalTo: imageView.heightAnchor, multiplier: aspectRatio),
 
    // Make view smaller than parent
    imageView.widthAnchor
        .constraint(lessThanOrEqualTo: parentView.widthAnchor,
                    constant: -insets.width * 2),
    imageView.heightAnchor
        .constraint(lessThanOrEqualTo: parentView.heightAnchor,
                    constant: -insets.height * 2),

    // Center in parent
    imageView.centerXAnchor
        .constraint(equalTo: parentView.centerXAnchor),
    imageView.centerYAnchor
        .constraint(equalTo: parentView.centerYAnchor),
])

If you want to be super cautious, keep the aspect and two center constraints at 1000 and bring the width and height ones down to 999. You can install the constraints as you create them but I prefer to break that part out so I can tweak the priorities for each constraint group:

constraints.forEach {
    $0.priority = UILayoutPriority(rawValue: 1000)
    $0.isActive = true
}

I always mess up with the signs (positive or negative) of the constants. It helps to test these out in a playground rather than going by memory because the signs aren’t always intuitive. Even better, write routines that automates your Auto Layout tasks because if you debug once (and add proper tests), you never have to think about it again.

Mac playgrounds are inherently superior to iOS ones as they don’t run a simulator and are faster and more responsive. That is to say, you don’t have to quit and relaunch Xcode quite so often. If you are debugging iOS layouts though, and your playground hangs when starting the simulator or running your code, learn to quit, kill the core simulator service, and relaunch Xcode. It will save you a lot of time.

I have a one liner in my utilities to deal with the service:

% cat ~/bin/simfix
killall -9 -v com.apple.CoreSimulator.CoreSimulatorService

Most of the time a single quit, simfix, and launch will get things moving again with recalcitrant iOS playgrounds. Be aware that malformed format strings and other auto layout issues won’t produce especially helpful feedback, especially compared to the runtime output of compiled projects. If you know what you’re doing, you can set up a simple layout testbed in playgrounds with less overhead and time than, for example, a one view project but at a cost.

Stick to projects, and avoid playgrounds, when testing even mildly complex code-based layouts. You cannot, at this time (at least as far as I know), control which simulator will be used in the playground so it’s not great for checks on a multitude of simulator geometries. The tl;dr is that playgrounds work for general layout routines. Prefer compiled projects for specific tasks.