Apple Pencil: Too much information

I own a first generation refurbished Apple Pencil. I bought it when I picked up the new 5th gen iPad mini. It’s a delight. I use it for freehand note-taking when I don’t want to tip-tap into the onscreen keyboard or lug around my folding bluetooth keyboard. I use it doodle and draw. I use it to annotate PDFs. I especially love  how it knows what is the pencil and what is my hand so I can rest against the screen and still get work done.

My pencil keeps its charge for days with light use. When I need to top it up, I can stick it into my iPad’s lightning port. In under 10 minutes it goes from flatline to 100% charge. Yes, it looks a bit odd sticking out like that, but it isn’t for long and it’s easy enough to rest the iPad on a desk until the charge is complete.

Keep track of your current pencil charge in your iPad widget gallery. The Batteries  section shows how much juice is currently available:

When talking about charging, you should think about that tiny cap at the end of the first generation pencil. Fortunately, there are many extremely useful and inexpensive helpers for keeping track of the cap and the charging adapter, the short flat item at the bottom of this picture. It’s used for charging off a USB lightning cable by providing a female-to-female connector between the cable and the pencil:

Many third party gizmos service these tiny pieces. You can purchase replacement magnetic caps that better stick to your pencil and replacement charging adapters for when you lose them. If you’d rather not lose them in the first place, consider a simple holder set like this one. Mine is clear silicon and did not include the tip that covers the nib. The holders make sure the two tiny pieces aren’t easily lost, and that they’re kept along-side the equipment that uses them:

In addition, I purchased a magnetic sleeve to attach my pencil to my iPad and/or its smart cover when not in use. Again, this helps ensure I don’t lose the things I need. I roll the flat part away from my hand and find that it doesn’t interfere with holding the pencil or writing with it.

I use the Selvy PenScript keyboard plug-in to convert handwriting to text. It’s available from my normal keyboard. I tap-and-hold the globe to select it. Make sure when installing that you enable it in Settings > General > Keyboards.

As you see from this screenshot, I also installed the Kaomoji.HW keyboard that allows me to draw emoticons. It’s not very good at its job but it’s pretty hilarious to play with.

The SelvyPen keyboard is surprisingly useful across apps. It’s as easy to enter a URL as it is to type free text.

If you’re looking to enter large tracts of text by hand, Nebo does a great job with handwriting-to-text conversion, allowing you to enter information into notebooks using your pencil. Notice how the app keeps track of the ongoing interpretation in light gray just above the handwriting:

Use the ellipsis (3-dot) menu on the right to convert paragraphs to text and remove the handwriting entry. The accuracy is surprisingly good.

For annotating PDFs, I use Notability. I admit that it’s mostly because I already own it and it’s a great app. There are many other excellent options on the market. I’d love to hear what else you recommend. I apologize for all the blurring but I was reviewing someone else’s work and I wanted to respect their privacy:

For presentation, I have a half dozen apps of varying quality and I can’t really recommend one or the other as being particularly outstanding:

What other apps, tweaks, and gadgets have you found to enhance your pencil-using experience? I love my pencil and am always looking for more ways to get the most from it!

Reader recs:

  • Many readers agree with my use of Notability
  • Mike recs Concepts. “I use it as a vectorized infinite whiteboard for sketching and note taking.”
  • Teddy likes GoodNotes, “which will hide the UI when projecting to an external screen. Also has a nice laser pointer with a trail so you can make temporary markings as you go” and PDF Viewer for annotation.
  • Paper by WeTransfer gets a thumbs up from Paul.

The knee-jerk else-clause

I’ve gotten into several heated discussions recently (I wouldn’t call them arguments or fights as no blows were exchanged and we departed as friends) about whether an if-statement should always include a balancing else clause in languages where it is not mandated by a ternary if form.

My feeling is a firm “no”.

Let me attempt to represent the opposing viewpoint. As far as I can tell, the “yes” faction believes that as proper diligence, an else clause should always be added to address both truth scenarios, even if the clause is populated with nothing other than a comment saying “this clause intentionally left blank”. It promotes a consistent inspection of all possible cases, on par with a switch statement requiring full coverage.

I firmly disagree. In my opinion, if-statements boil down to three scenarios:

  • Special CasingAction that applies solely to certain logic conditions, where the absence of those conditions has no effect in the logic. In such case, I recommend to skip the else. There’s no point to it as the flow of execution continues past the additional steps introduced by the if-statement. Adding an else statement removes the clarity of the step-by-step logic and reduces the weight of the special casing in understanding the code.
  • Either-Or: Separate actions of approximately equal weight that apply to both outcomes. If statements are naturally biased towards the positive clause. If both statements are weighted the same, consider refactoring to switch. Even if the switch is ordered (as it must be in some fasion), a switch-statement reduces the emphasis given to either outcome. If both cases are quite large, consider breaking out functionality to dedicated methods. Further, if the logic overlaps between both cases, consider localizing the conditions closer to the differences, even if the test may be applied several times.
  • One case complex, one case simple: Actions that are of disparate impact or weight, where one clause greatly exceeds the complexity of the other, I always place the more complex clause first when used in an if-statement to emphasize the positive path. At the same time, if the simple case is non-trivial, this is an opportunity to consider whether the logic should be broken up or refactored in some way. If an if-clause is so significantly big that it takes up the majority of a method implementation, perhaps you should be using early return for the lighter condition and promoting the more complex logic to the main method body. To me, a heavy complex if-clause usually signifies an opportunity to refactor.

Given these styles, I don’t see any reason, whether from code-reading clarity or a strict adherence to potential future expansion, to automatically include else-clauses as a mandatory part of a coding style. They add heaviness without real functionality and speak to a philosophy of form weighed over functionality. Code should be light, clear, and direct. Mandatory-else is none of those things.

Am I wrong? Go ahead, convince me otherwise. I’m listening.

Lightweight To-Do list formatting

I recently ran across the todo.txt format project, which allows use to use plain text action item lists to create and manage your projects. I love the simplicity of the idea but there were a number of items that prevented me from wholeheartedly adopting it.

First, I think it’s really ugly. It’s hard to scan, especially when there are lots of things to do. I know that the idea is this is an intermediate representation but that representation is visually heavy.

Second, it’s missing notes. Freehand notes are an important part of task management, whether noting down the phone number for the car place when you need to get your snow tires put on.

Third, it’s order dependent, with a left-to-right layout that really doesn’t work for me.

Fourth, I don’t think the (A)-(Z) priority format is particularly readable.

Even though I do like the +Project and @Context annotation, I feel like todo.txt is a few steps  short of a much more flexible and readable intermediate form.

So I started brainstorming on how I might tweak this concept to be more flexible. For one thing, I think the example strains to make the project and context “fluent” in a way that they don’t have to be. Yes, you may want to query to see “what are all the projects I am working on?” and “what contexts do I work in?” so I can support differentiating them but I don’t think they need to be integrated into the to-do text.

What follows is a very lightly-considered redesign that I have pulled entirely out of thin air. I did not spend much time on this and I’m sure there are better ways to redesign this to support text-based lightly annotated human-readable to-do lists. I’m throwing this out there as a starting point in case any of you want to carry this discussion further. It’s a design exercise for me, one that allowed me to take some of these thoughts out of my head and throw them into a blog post. So take this for what it is.

Imagine tagging that looks like more like this, depending on whether you’re annotating project or context values. Part of me pushes back at the notion of the two types of tagging but I appreciate that you might want to query “show me all my projects” and “show me all my contexts”, and I recognize the value in that:

@(tag) or +(tag)
@(key: value) or +(key: value)
@(priority) or +(priority)

A priority can be as simple as a number, which I think people would process better than “A”, “B”, “C”, etc. As a pattern of (0-9)+, it would also allow easy differentiation in parsing between a tag (arbitrary text) and a priority. Priorities would range from 0 (highest priority) to any arbitrary number (lower priority). I doubt people would use more than two or three priority levels (low, medium, high), if they use them at all.

Because dates are critical for todo deadlines, you could pull them out with NLP or be more explicit: @date(due: 2019-05-02). The single keyword would allow you to parse a date with more flexible keys and disallow an explosion of keywords you might encounter by trying to pre-design specific scenarios like @due(2019-05-02), @checkin(next Tuesday), etc.

Relative dates would need a creation date, which if you’re using an editor rather than the raw format could be injected as @date(created: 2019-05-02). The second you do that, though, you’re moving away from the idea of human-readable, simple annotation, tool-consumable.

In my head, a better system would not be single-line. Adding blank spaces between items significantly increases vertical space so python-inspired indentation can avoid that:

Set up appointment for snow tires
  Call and talk to Judy 505-555-1212 # comments are always great
  She says to contact them at least one thursday before the weekend you want # Not thrilled by the manual line breaks here
  to bring the car in.
  @(home) +(winterizing) +(2) @(before: 2019-12-01)
Put snow scraper in car
  @(car) +(winterizing) @(done) # yay me!
Get flu shots for Bob and Francis
  Already got them for Fred and Mary
  @(family) +(health) +(season) +(Costco) +(1) +(shopping) # It's a shopping run, even if it's not strictly buying something

This is rough, obviously, but I think it’s a bit more readable than blockiness of the current format and a bit more flexible:

If working with an editor tool, I’d prefer if done items were automatically moved down to the bottom or maybe removed entirely or added to a different “done.txt” list.

Also, once you have the power of full tagging and categorization, a well built tool should allow you to pull on each of those to view related items in more structured ways. The format is simple but the way you present tagged information doesn’t have to be.

Anyway, those are my thoughts. I see a project with good bones that misses out on a bunch of human factors. What kind of changes would you make to turn this into a more usable and universal approach? Or would you just say “plain text is not really appropriate here” and use OmniFocus or Things instead? I’m curious as to what you think.

Update: Readers mention:

Flipping the switch and the 32-bitpocalypse

I think I’m ready to upgrade my Mac mini to Catalina. I know, I know: “But the 32-bitpocalypse! Are you ready to lose all that investment?” I think I’ve worked through that. Haven’t I?

The last few weeks I’ve been busy. I bought a smallish (0.5 TB) external SSD drive and backed up a good chunk of my Mac mini to it. Today I’ve been running tests on how it works booting on my MBP, not my mini. That’s because my underpowered mini just isn’t strong enough either in boot speed or  running off the external drive to make this a reasonable approach.

On the MacBook, however, the SSD responsiveness is pretty fine. Once booted, I’ve tested Office, Photoshop, and a bunch of other 32-bit apps and while they’re not going to win awards for speed, they run and appear to be stable.

That leaves me with the dilemma. Do I flip the switch? Do I go full Cat on my main work machine? It’s been a reasonably time since release, so what mine fields should I expect to encounter? I honestly don’t want to upgrade and then have to start restoring from Carbon Copy Cloner backups from regret. (My backups are run nightly so they’re there if I need them.)

What do you think? Pull the switch or walk away? I hate being out of step with the latest OS, even if I do have Cat installed on my MBP and am happily using it there. Give me your advice. I’m not ready to walk away from so many apps that I still use many times a week but I don’t want to freeze my mini in the past. Thanks in advance for your advice and suggestions.

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.

Xcode: Basics of the four-block wonder

The official name is “Navigate to Related Items” but to me, it’s the four block wonder, a menu button that sits at the top left of the Xcode editor. With this menu, you can hop between file counterparts (for example, .m/.h, or .swift/generated interface, which is what a lot of people use it for). But there’s so much more.

Set the cursor on a type, and you can view or navigate its superclass, subclasses, or siblings, as well as the protocols, extensions, and categories it connects to. A single click navigates you to the interface or implementation in question:

Use the cursor to establish the context for the menu, otherwise you’ll only see a smaller subset menu options, such as recent files. The callers option shows you your clients, and callees the items your code is calling — all specific to the current cursor context.

One of my favorite tools in the four-block menu is Generated Interfaces, which allows you to view an item’s Swift interface or see how it translates to Objective-C. For example, if you use an obvious preposition label, the ObjC generated interface subsumes it into its selector:

With this, you don’t have to wonder if your selector is specified right and you don’t have to override the selector with objc. You just look up the definition and you’re good to call.

In addition to contextual helpers, the four-block lets you select recently viewed files and, when using version control, recent files that have been locally modified and not yet committed (basically the ones showing the “M”-for-modified).

The four little squares may be tiny but it is a powerful tool in your Xcode arsenal.

Update: Lilly reminds me that you can bind the related items menu. I have mine bound to ^1 but I don’t remember if that’s something I did or something that is default. If you want to add or change, visit Preferences > Key Bindings and search for “related”.

Mac Dictation 101

Dictating to text is one of the great things that macOS gave us a few years ago. In both Mojave and Catalina, you enable dictation in System Preferences in the Keyboard > Dictation Pane.

I use the “double-command” shortcut to enable dictation but I also find it helpful to set up the Mac version of “Hey Siri”. To start, hop over to Accessibility > Dictation (Mojave) or Accessibility > Voice Control (Catalina) to extend your interaction. Enable dictation or voice control, as supplied. On Catalina, you may need to download additional elements which takes a moment or two.

In Mojave, you can set a dictation keyword. I go with “Computer”, because it sounds very Scotty from Star Trek TOS. I prefer to enable sound feedback so I know when my command has been picked up properly.

To ask Siri about the weather, I say, “Computer. <beat> Open Siri. <wait for tone> What is the weather for today?”. There’s a definite pause needed after “Computer”.

Catalina offers an always-on version when you enable voice control.

This little control panel lets you sleep or wake your mike:

Once in place, you can say “Open Siri”.  Confirm that you want to enable Ask Siri and you know that employees or contractors somewhere — I believe it was Ireland — will be laughing at you, but privacy is an illusion these days. Search for articles similar to “Apple Resumes Human Reviews of Siri Audio With iOS 13.2 Update” for more details. As with Mojave, you’ll need to develop separate dialects for iOS and Mac for controlling your system, with significant pauses to let the OS catch up with you.

Always-on dictation seems to send my MBP into windtunnel spasms, so you may want to use those keyboard shortcuts instead.

Once on, you can request “What can I say” and a list of commands pops up. It’s pretty basic and uninspiring as a support doc goes but it’s a start and the commands are quite extensive.

For example, say “Open TextEdit <pause> New item (assuming you don’t have TextEdit setup to create one on launch).”

Next, try dictating. I recommend opening a browser tab apart from TextEdit and just speak from a reference document. For example:

Listen my children and you shall hear
Of the midnight ride of Paul Revere,
On the eighteenth of April, in Seventy-five;
Hardly a man is now alive
Who remembers that famous day and year.

You’ll immediately see some of the weaknesses involved in dictation.

Starting over, I’ve used some dictation-fu. For example, when “here” is mispelled, I used “correct that” and “choose 1”.

“New line” gets me to the second line. “Select word” highlights the most recent and “Capitalize that” changes “revere” to “Revere”. The next line after that is just ridiculously hard. I’ll leave that one as an exercise for the reader. Finish it off with “semicolon. press Return key”.

The rest is easy, particularly because TextEdit did the uppercasing on my behalf. Don’t forget to insert a new line and say “period” (Or, I suppose, full stop. Hi Paul.) at the end of the sentence.

As with iOS, Catalina appears to be using a scaled down version of Dragon Dictation so it’s always helpful to be able to use the Dragon documentation, even when you run up against some pretty hard edge cases.

It’s honestly not the worst dictation system but I prefer the one on iOS.

 

 

 

Fun with Xcode Search Domains: Excluding match text

Most Xcode users quickly become familiar with the basics of the Find Navigator panel.

With it, you can find text, regular expressions, and perform search-and-replace, whether matching or ignoring case. But that’s just scratching the surface of the Find Navigator.

I thought I’d drop a few words today about search scopes. Controlled from the bottom left,  under the search field, you can create narrowed searches. This enables you to, for example, search only in Swift files or exclude files containing the word Test.

To get started, click the icon (two lines with three squares on a line between them) and then New Scope (the plus icon). Here, you can name the scope, limit the search extent, and add criteria for exactly which files should be included or not.

The logic is straightforward. You choose where to look (the project, a folder, or through the entire SDK), and whether to include all conditions or some conditions:

Each condition is based on the file name, path, extension, UTI (the kind of file, like image which is useful for finding vector assets), Workspace location (namely groups), or source control status (handy for finding newly applied changes.)

Most of my conditions are file-name-based. And for those, you get the following matching conditions. The “ends with” is an obvious win for extensions (although you can also use UTIs for that), and “starts with” can help for projects organized in hierarchical ways.

Now, interestingly enough, this list fails to offer “does not contain” but that’s fairly easy to work around. Since Xcode supports regex matching, you can easily replicate “does not contain” with an appropriate regex:

Change the file name to a path to exclude source file directories.

You can create as many search domains as you like. At least, I haven’t found an upper bound yet. I haven’t found a way to reorder the find scopes, although if you’re really controlling about this, you can pop into  your workspace (ProjectName.xcodeproj/project.xcworkspace/xcuserdata/username.xcuserdatad), convert your UserInterfaceState.xcuserstate to xml (plutil -convert xml1), and hand-edit it the way you need.

There are lots of wonderful little Xcode tweaks like these throughout this monster of an IDE. What are some of your faves? If I have time this week, I’ll share some of mine, such as the four-square — another of my favorite tools — and a few great ways to connect your editor to the navigator.