Make Wooden Toys

Like many developers struggling to make a living in the increasingly price-sensitive, App Store-influenced market, I was somewhat discouraged by Rene Ritchie’s excellent “What no indie developer wants to hear about the App Store.”

Rene argues that the app economy is moving towards cheap, mass produced, bargain-priced software that is simply not suitable for sustaining small-time indie software businesses. He adopts a beautiful metaphor, borrowed from his own childhood: the classic wooden toy.

When I was a child, all my favorite toys were wooden, painstakingly carved by artisans who ran the store near my home. I cherished them. Today those kinds of toys are all but gone, and that business model is no longer viable in the mass market.

Ugh. He’s right. Everything is cheap plastic, nowadays. Or is it?

If I pull up a mental inventory of my own kids’ playroom, there are indeed a ton of cheap, plastic toys. But there are also a good number of, wait for it, quality wooden toys.

Wooden toys are still being made! Shout it from rooftops, my indie brothers and sisters! If your inspirations and ambitions were flayed by Rene’s dose of reality, perhaps this will serve as an inspiring salve: do a Google image search for “wooden toys“. Those aren’t antiques…

I remember when my kids were younger, marveling at the powerhouse of wooden infant toys, Melissa & Doug. If you have a baby and are part of a socioeconomic culture that can sustain it, you have seen these toys. They are everywhere. And they are far from cheap.

So? Make wooden toys. Metaphorically speaking, I mean. (Unless, like Gus Mueller, woodworking has been your backup plan all along.) Make software that is inspired by wooden toys. Although the market is dominated by cheap plastic, there is real money for thoughtful, careful developers in the market that favors charming, slightly overpriced throwbacks to another era. Make wooden toys.

Selectively Smart Typography

OS X offers a system-wide feature to “Use smart quotes and dashes” when typing text. The option can be enabled or disabled in the System Preferences “Keyboard” pane, inside the “Text” tab:

Keyboard

This essentially ensures that when you rattle off a bit of prose, any quotation marks will be “smartened” so that they curl inwards towards the quoted phrase, and sequences of double-hyphens will be converted to typographic dashes.

It’s a good thing.

However, the feature can be vexing when typing in contexts where typographic beauty is clearly not the priority. For example the behavior would not make sense in a code editor like Xcode or BBEdit. These apps are more often used to write text that will please a programming language compiler or interpreter, where a string for example must be enclosed by "straight quotes", and “smart quotes” would only lead to a syntax error.

Apple actually makes it possible for developers to control the behavior of this smart typography on a very fine-grained basis. For example, my own app MarsEdit features an HTML text editor in which it makes sense to support smart quotes and dashes, but not within markup tags. Because the app is aware of when the user is typing within a tag or not, it simply disables the functionality as appropriate for the context.

Depending on the apps you use, and what you use them for, you might find yourself vexed by the unwanted conversion of quotes and dashes. You could turn the feature off at the System Preferences level, but what if you want to keep it in all the other apps where it works just as you want it to?

Thanks to the flexibility of Apple’s “user defaults” system for registering preferences on a system-wide and app-specific basis, you can impose override preferences for these options on the specific apps of your choosing. I was inspired to write this article by Jesse Atkinson, who complained on Twitter that the behavior was meddling with his code snippets in Slack:

So, here’s a general recipe for overriding the settings in any app:

  1. Quit the app.
  2. Determine the “bundle identifier” for the app. Slack’s, for example, is “com.tinyspeck.slackmacgap”.
  3. Open the OS X Terminal app.
  4. Type the following commands to impose overriding defaults for the pertinent features:
    defaults write com.tinyspeck.slackmacgap NSAutomaticDashSubstitutionEnabled -bool NO
    defaults write com.tinyspeck.slackmacgap NSAutomaticQuoteSubstitutionEnabled -bool NO
    
  5. Reopen the app.

You should now find that this specific app behaves as though the system-wide setting for these features were turned off.

If you want to undo your handiwork, just delete the overrides you put into place:

  1. Quit the app.
  2. Open the OS X Terminal app.
  3. Type the following commands to delete the overriding defaults:
    defaults delete com.tinyspeck.slackmacgap NSAutomaticDashSubstitutionEnabled
    defaults delete com.tinyspeck.slackmacgap NSAutomaticQuoteSubstitutionEnabled
    
  4. Reopen the app.

If you’re a Slack user who has also been annoyed by the smart quotes and dashes functionality, the above may prove helpful to you. If you’re not, maybe a similar situation will arise where you can use the power of OS X’s default registration system to fine-tune the behavior of your favorite apps.

Update: My old friend Chris DeSalvo, who also happens to work at Slack on the Mac Slack app points out that there is a much simpler solution for Slack in particular:

I just confirmed that this seems to work well with Slack! So was this whole article for naught? In my experience, toggling the Substitutions flags as Chris describes only changes the setting temporarily. This is because those menu items within an app are usually configured to communicate directly with the text field you are focused on. A developer has to go out of her way to intercept and persist such a toggle, to ensure that it “sticks” the next time the app launches.

So! If you have this problem with Slack, just toggle the setting in the Edit -> Substitutions menu. With most other apps? Perhaps the technique outlined above will help.

Call To Action

Twitter just announced two new features aimed at facilitating customer service across the service:

      A custom link format for inviting customers to initiate a direct message.
      A method for soliciting feedback from customers about quality of service.

Of the new features, only the first is available immediately to all Twitter users. I was intrigued by the feature because I imagined it eliminating the uncomfortable process of businesses either having to ask customers to follow, or setting their direct messages to be “open” to anybody. Unfortunately, the feature does nothing to empower direct messaging between two consenting parties. It serves only as a shortcut for initiating a DM that would already be permitted:

Using this new feature is easy. It requires that your Twitter account settings are set to “Receive Direct Messages from Anyone”…

I guess being open to “direct messages from anyone” is a viable approach for some businesses, and maybe it is even the right choice for any business wanting to remain completely accessible to customers. But my experience turning the feature on for my private account was that it led to unwanted solicitations. Although I generally want to remain accessible to people, it was an invitation for nuisance inquiries.

I hoped upon seeing the news of this feature, that it might have been a feature that allowed a temporary, targeted permission to DM. This would be useful for businesses but also for individuals who are hesitant to either follow a person or open up DMs completely, but nonetheless wish to communicate privately for a short time.

My vision for the feature is close to what Twitter has announced: you would still tweet a “magic URL” to somebody empowering them to open up a DM conversation, but the very act of sending that URL to a person’s (@-messaged) account would open a hole in your DM permissions allowing them to reach you even if you neither followed them nor had completely open DMs turned on.

I imagine a scenario where the presence of such a link implied consent to DM for 48 hours or so, and where every response by DM to that user would extend the consent for another interval of time.

This would facilitate more direct, nuanced conversation between Twitter users, without forcing them to choose whether to be completely vulnerable to the world, to establish unwanted, short-term follower connections, or else more likely, avoid the interaction altogether.

iGotYourBack

I have been an ardent Apple fan since 1993, when I got my first Mac: a PowerBook Duo 210. From then, to the day I joined Apple in 1996, to the day I left in 2002, to present day, one thing has always been true about Apple: they are not a typical tech company. Pushing against the status quo has in many respects been a defining characteristic of the company, through down times and up times. Apple does what it thinks is right for itself, for its customers, and to some significant extent, for the world at large.

Tim Cook shared yesterday in A Message to Our Customers one example of Apple’s atypical attitude rearing its beautiful head. In response to the FBI’s demand that Apple supply custom software that would allow the agency to unlock an iPhone held as evidence, Apple tendered its refusal:

Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.

The news has split public sentiment in predictable ways. There will always be a contingent that believes law enforcement should be aided in any feasible manner, regardless of long-term implications for individual privacy or civil liberties. And there will also be people so cynical about government and the police, that even Apple’s cooperation thus far, handing over information that it does possess, is viewed as a betrayal of customer rights. And of course, there is a massive group of folks in the middle, who aren’t sure where the line should be drawn.

Apple has a clear sense of where the line should be drawn, and they have stated it: they will not weaken the security of their products for the benefit of the FBI or (presumably) any other agency. Although the current request from the FBI only applies to an older iPhone model, whose security is easier to circumvent than later ones, the point Apple emphasizes is that complying with the order would be a terrible precedent for putting the needs of government ahead of the personal security of end-uers.

To my mind, this is a fine place for Apple to draw a line.

Other tech companies with huge investments in the consumer market should be lining up behind Apple in defiance of the FBI. To do otherwise, whether by explicitly defending the FBI’s demands, or by implicitly approving in silence, would be a betrayal of their own customers. It would be wrong both from an ethical perspective with respect to their duty to protect customer data, and from a PR perspective with respect to the public’s perception of their managing that duty.

If a couple other large companies, say Facebook and Google, come to Apple’s side, it will send a powerful message to the FBI and the rest of government. If a dozen large companies do, it will create a firewall that will be difficult for government to dismantle without very publicly reiterating and reaffirming its disdain for personal privacy.

I think it’s best for all parties if the “firewall” scenario comes to pass. The stage is set for a civil rights showdown, and while we need to speak out as individuals, we can also benefit enormously from the powerful voices of these tech giants.

But if other companies don’t step up, I’m not sure all is lost. Apple, as the largest American tech company, which also has the largest cash reserves, is well-suited on many fronts to fight this battle. Alone, if necessary.

People have criticized Apple for amassing a giant pile of money while never giving completely convincing explanations for what it plans to do with it. When your modus operandi is not only to push the leading edge of personal technology, but also to defend your customers’ personal data, and to possibly help establish the legal precedent that will defend the customers of all tech companies for decades to come, you never know when having $200B to “spare” might come in handy.

As a stockholder I don’t relish the idea of Apple burning through all that money just to defend their right to protect customer data. Although it’s arguable that it would be money well spent, it’s not an obvious, ideal use of shareholder equity in a public company. Luckily, I don’t think the cash will be spent. The $200B serves mainly to fortify Apple’s resolve in defying the FBI. Apple’s courage in the face of threats to its pro-consumer security policies is bolstered by the strength of those massive cash reserves.

Some may see this confrontation between Apple and the FBI as an industry vs. government dispute, but it’s far more than that. As personal technology and the internet permeate almost every aspect of wider society, the “tech industry” is indistinguishable from society as a whole. The right to defend our personal information, and the rights of companies to act on our behalf in that pursuit, are completely and inexorably tied to our rights as members of society. Eventually, we must win the right to protect our data from government. Apple, Google, Facebook, and other tech giants can step up to help us secure these rights today, or we’ll have a longer, harder fight ahead of us in years to come.

Lazy Password Storage

When you run an app on your Mac that connects to a secure web service, how confident are you that the password will be treated with care, and protected from prying eyes?

As a rule, Mac developers are pretty responsible about storing passwords and other private data in the OS X system keychain but, of course, there are exceptions.

I found a handy trick for uncovering passwords stored insecurely by applications directly to their preferences storage. The trick takes advantage of a cool functionality of the OS X “defaults” command line tool, which you can run from the “Terminal” app:

'defaults' [-currentHost | -host ] followed by one of the following:
  [...]
  find <word>     lists all entries containing word

How convenient: a simple command line tool to search the entirety of all the preferences stored by all of your apps. So, a good first step would be to simply search for “password”:

defaults find password

On my Mac, this yields an overwhelming number of matches that includes a lot of false positives such as, for example, the preferences pertaining to 1Password, preferences pertaining to apps’ password dialog windows, and other innocuous uses of the term.

It occurred to me that most developers storing passwords insecurely in preferences would probably store the value either under the key “password,” or some variation such as “twitterPassword”. So I tweaked the command line to try to filter out these results. The “defaults find” command doesn’t take any options, but I can winnow the results using grep:

defaults find password | grep -i -E "password\"? ="

This grep invocation searches for case insensitive matches for “password”, optionally followed by a quotation mark, then a space and an equal sign. In other words, examples where a key that ends in “password” is being assigned a value.

This actually did reveal some problematic password storage on my Mac, but the grep is so good at filtering out the results, I can’t see which app to blame. I need to match ALL the lines that pinpoint the app, and all the lines that looks like they store a value into a password. Add an | (or) case to the grep expression to match for the tell-tale signs of the lines that summarize findings per-app:

defaults find password | grep -i -E "password\"? =|keys in domain"

Here I find a neat summary of potentially problematic password storages. Some of them remain false positives, but the list is now small enough to easily interpret. Any example where the app is something I plan to use again, I’ll be in touch with the developer to encourage them to improve the password storage security. Any example where the app is nothing I’ll ever run again?

defaults delete com.example.lazyapp

And the insecurely stored password is obliterated from my preferences.

Obviously this trick won’t match all the careless password storage that apps on your Mac may be committing, but I suspect it will root out a good number of them. Experiment with the grep commands to filter out based on different, less restrictive matches. You might also have some luck searching for examples of apps that store other sensitive information such as credit card numbers, secret questions and answers, etc.

Living Room Engagement

I am home from Apple’s New York “Apple TV Tech Talks.” These events are always a joy to attend, because they combine some of the high quality preparation and delivery that we’ve come to expect from WWDC, with the refreshing brevity and focus of a one day event. Oh, and they’re totally free, apart from the transportation and lodging you might need to pay for.

I went to the event with some uncertainty, because I am skeptical about my prospects developing for the Apple TV. The platform inherits many of the pricing and marketing challenges of iOS, with the added constraints of working with a shared-user ownership model, limited user input, and a bias towards entertainment software suitable to somebody reclining on a couch.

Although I didn’t come away from the tech talks with a clear inspiration for a “killer app,” I did think a bit about the high-level classes of app that are likely to be successful on Apple TV. This is somewhat off the cuff, so I might be missing something big, but I think Apple TV apps will fall into these main categories:

  1. Passive entertainment. This is the obvious, classic use case for television. To succeed with this model, you will probably need to have access to your own library of streaming media. Past and present episodes from a network television company are a canonical example for this kind of app. Indie app developers are unlikely to succeed in this realm, except as consulting engineers for media companies.
  2. Games. When the earliest video game consoles came out over 40 years ago, they introduced interactivity to the previously passive experience of using a television. It seems appropriate then that on the Apple TV, interactive entertainment in the form of games will remain a top-tier use case for the device. This is great news for indie developers who happen to be interested in game development, but for those of us who have tended to focus on productivity or creative software, there is little to lure us here, either.
  3. Interactive entertainment. In addition to the passive video programming that we associate most closely with television, there is an opportunity to engage users with the level of interactivity found in games, but with an aim to educate or entertain in a non-goal-oriented sense. For example, an app that makes it easy to kick back on the couch and subject oneself to a never-ending supply of dictionary definitions, or Wikipedia articles, would fit in here. Indie developers may have opportunities here because or the large amount of open sourced or government owned data that could be leveraged to build apps that present this data in novel and engaging ways.
  4. Interactive construction. The default input device for the Apple TV, the Siri remote, is pretty limiting for tasks like text input and other productivity-oriented tasks that we take for granted on a computer or iOS device. But what it lacks in precision it makes up for in crude expressiveness. Imagine apps that leverage the expressiveness of the remote’s touchscreen, or its ability to reckon its ever-shifting position in 3D space. Imagine a family gathered around the dining table, with a large blank piece of butcher paper and a variety of creative tools on hand. What does the family do to the paper? Anything you can imagine that empowers a family to be collaboratively creative on the screen, as they would otherwise be on that paper, is a potential hit for the Apple TV.

What am I missing? I know there must be huge categories of Apple TV app ideas that are going to be obvious in retrospect. Two years from now, we’ll look back at a hopefully robust catalog of Apple TV software and find many examples of classic “if only I had thought of that!” ideas. I’m still fairly skeptical that I’ll be one of the developers who stumbles on groundbreaking ideas for the platform, but I credit the Apple Tech Talk with at least getting my thinking moving in the right direction.

Medium Permalinks

I was intrigued to read that Basecamp’s (née 37 Signals) Signal v. Noise blog has moved to Medium. David Heinemeier Hansson argues that Medium is “just the right mix of flexibility and constraint,” celebrating its web-based editor, the network of users, Medium’s demonstration of concern for its customers, and Basecamp’s admirable desire to get out of the business of maintaining their own blog-hosting software.

Hansson lists the ability to use one’s own custom domain among the user-friendly changes Medium has made. “By offering custom domains, we’re ensured that no permalink ever has to break, even if we leave the platform.” Indeed, this is a valuable improvement. But it got me thinking: for a blog like Signal v. Noise, with hundreds of posts spanning more than a decade, how would Signal v. Noise’s existing permalinks be preserved? Does Medium offer some fancy permalink customization for imported posts? Is there some ability to upload static HTML content to reside alongside newer, Medium-native posts? Surely a company as obsessed with the web as Basecamp would be concerned about this. How did they solve it?

It took a little poking around and scratching my head to realize that solved the problem in a novel way that doesn’t exactly get them out of the blog-hosting business. Signal v. Noise is now hosted on two domains:

  1. https://signalvnoise.com/ – The previous home of the blog, hosted and managed by Basecamp themselves, continues to host the backlog of archived posts.
  2. https://m.signalvnoise.com/ – The new home, hosted by Medium.

So when any new Medium post is linked, it points directly to the “m.signalvnoise.com”, and is handled by Medium. When any older post is linked, it goes directly to “signalvnoise.com” and is handled the same as ever. The one change? When the main page at signalvnoise.com is visited, it redirects with a “302 Found” response to the Medium site, getting a casual visitor on track to viewing only the latest posts.

I continue to admire a lot of the work Medium is doing. I agree with the Basecamp that their web editor is among the best I’ve used. For my tastes, it can’t touch the experience of a native Mac app, but of course I’m biased. Hopefully Medium’s API will continue to evolve and make Medium a more viable platform for folks who share my preference for a desktop editor.

Hey Siri, Don’t Trivialize My Timer

Siri’s dictated timers are a feature I use all the time. Especially given my propensity to be distracted and lose track of short-term time commitments, the ability to blurt out in the kitchen: “Hey Siri, set a timer for one minute,” has saved many a pancake from being burned.

Something that has bothered me about this feature for a long time is the determination Siri has to be lighthearted and downright goofy when creating the timer, when the timer is for a specific time such as one or three minutes.

“Hey Siri, set a timer for three minutes.”

Siri's visual response when asked to set a three-minute timer.

Ha. Ha. Yeah, I’m always cooking an egg when I set a three-minute timer. By contrast, a request to set a two-minute timer is always met with a curt, yet still humanized, “Two minutes and counting.” If you set a timer for one minute? Whoo-ee, you’re in for some sass. Sometimes Siri just says “Your timer is set for one minute,” but more often you’ll hear a quip like “Remember, a watched iPhone never boils.”

I’ve been more irritated by this cuteness after years of using the feature and, I suppose, the frequency with which I set one and three-minute timers. It’s mostly a passing exasperation for me, but it strikes me as an example where emotionally charging a software interaction is a risky proposition.

My one-minute timers are usually for something trivial like pancakes, but what if I were using them in a more fraught scenario? What if one-minute timers play a serious role in the administration of care to a loved one? What if it’s a key interval in a CPR procedure? One of Siri’s cute quips is “The suspense is killing me.” What if the suspense really is killing somebody?

(Radar #23776483)

Siri’s Headphone Tax

I wrote earlier today about Siri’s impressive, instant attentiveness on the iPhone 6s. I remarked that although I had set out to report a bug to Apple, I discovered it was actually a very awesome feature.

Unfortunately, I still have a Siri-related bug to file today. Armed with my knowledge that, as a rule, Siri will begin processing instructions at the moment the home button is pressed, I have been exercising it quite a bit. But after I popped on some headphones and headed out for a walk, I discovered an unfortunate shortcoming: Siri’s instant attentiveness is thwarted by the presence of headphones.

For some reason, if headphones are plugged in, iOS goes through the old-and-busted delay in which you must wait for the audible signal that Siri is ready to listen. The result is that, having gotten used to it being instantly ready, you will push the home button and start talking, only to hear the tell-tale audio signal and realize that it hasn’t actually been listening yet.

I’m hoping this is a bug in which the old mechanism is simply being inappropriately activated while headphones are plugged in. I don’t think there’s anything about activating the audio out through headphones that should inherently limit Siri’s ability to be instantly attentive. In fact, with headphones plugged in I can still get an instant response when I use “Hey Siri” to precede my request.

In summary: Siri starts listening instantaneously on an iPhone 6s, whether you’re in silent or non-silent modes, provides you haven’t made the mistake of plugging in headphones. Filed as Radar #22881933

If It Ain’t Fixed, Break It

I have always kept my phone on silent, and thus come to depend on vibration feedback for a lot of workflow tasks. One such task is invoking Siri by holding the home button, to make a quick inquiry or request.

On my iPhone 6, long-pressing the home button always resulted in a short pause before a pleasant vibration indicating that Siri was ready to listen. I trained myself to wait until that vibration was felt before bothering to speak, lest Siri miss anything important.

On my iPhone 6s, however, there is no such feedback. Apple “broke” it. I was all in a huff this morning to file a bug about this, sure in my knowledge that the usability of the phone had been diminished by removing this feedback. Every time I invoke Siri now, in the absence of vibration feedback, I wait to see the tell-tale animated sound wave detector. I’m never quite sure when Siri is ready for me.

I complained on Twitter about the problem, hoping there was a secret setting that I had missed when restoring my phone. I got lots of commiseration from folks who also miss the feedback, and assurances from others that I simply needed to set my “vibrate on ring” or “vibrate on silent” settings correctly. I appreciate the responses, but they were all wrong. And I’m wrong. We’re all wrong.

Apple “broke” the haptic feedback associated with invoking Siri, by “fixing” the problem that there had ever been any latency before. Have an iPhone 6s or 6s Plus? Go ahead, I dare you: hold down the home button and start talking to Siri. You will not escape its attention. It’s ready to go when you are, so it would be obnoxious of it to impose any contrived delay or to give taptic feedback that is uncalled for. Siri has become a more perfect assistant, and we have to change our habits to accommodate this.

The elimination of latency in Siri’s attentiveness seems related to the fact that Apple have added dedicated functionality to the phone’s M9 chip to allow Siri to remain efficiently at attention:

The integrated M9 works so efficiently and intelligently that Siri is always on and waiting for your voice commands. You can easily activate Siri by saying “Hey Siri” whenever your iPhone 6s is nearby.

The lesson is that sometimes our instinct tells us something has been terribly broken, when it has actually been gloriously fixed. Now you can quickly dictate “Hey Siri remind me to file a bug about Siri feedback,” before quickly amending yourself: “Hey Siri delete the reminder,” and dismiss any perceived obligation you felt to tell Apple just how “buggy” the iPhone is.

Familiar Spell Checking

Even if you’re a great speller, automatic spell checking provides a valuable safety net, often preventing us from sharing with the world our own individual ignorances of the languages we communicate with.

For years, spell checkers of all kinds have relied upon word databases to determine that a word has been misspelled. I’m sure it’s at least a little bit more complicated than this, but in a nutshell: if the word you’ve just typed is not in this enormous list of words, then it’s probably a misspelling, and is marked as such.

Thus as you type your master works, when you either flub your typing or can’t recall the correct spelling, most modern editors will flag the word in question, for example by showing a red squiggle below it.

One challenge, though, is that for any individual, a number of words that are spelled correctly may nonetheless be absent from spell checker’s enormous database. One great example of this is the variety of proper names we deal in that may not happen to be included. For example, if I were a Boston Red Sox fan I might type Dustin Pedroia’s name often, and at least OS X’s built-in spell checker would mark it as incorrect. The workaround for these situations is to control-click the word and, from the popup menu, select “Learn Spelling” to avoid future flagging of the item.

The problem can be especially annoying when the OS repeatedly flags the names of people in your own family. For example, my own last name, “Jalkut,” is incredibly uncommon and would be flagged as a misspelling by most spell checkers in the world. However, on my Mac it is not, even though I’ve never asked the system to “learn” the spelling. In fact, none of the names of my family, friends, or business associates are marked as misspellings. How does this work?

Apple’s engineers realized that they could spare you the hassle of “learning” these spellings, since they already have access to a massive database of proper names that matter to you. Your Contacts database. If you’re on a Mac right now, open up the Terminal application and paste in the following line:

/System/Library/Services/AppleSpell.service/Contents/MacOS/findNames

The result that should come flying down the terminal window are the proper names of everybody and everything in your Contacts database. Specifically, Apple consults every entry in your database for the following attributes:

  • First Name
  • Middle Name
  • Last Name
  • Nickname
  • Maiden Name
  • Organization
  • Address
  • City

Each of these words, if present, is used to augment the already-massive list of correctly spelled words. So if you happen to know somebody named Frenk Xssl, who lives in Cwmystwyth and works for Infinitea, you can write all about them and their work, and never be bothered once by the tell-tale red squiggle of a word misspelled.