The NSTextInputClient protocol has a classic example of this problem. Take some time to read the reference, and see if you can spot the hole. Go ahead. Take your time. I'll wait.

Did you spot it? No? OK. Try this:

1. Make sure you have the Kotoeri input source enabled (System Preferences/Language & Text/Input Sources; check Kotoeri and at least the Hirigana sub-item). You'll also want to check the "Show Input menu on menu bar" check box.
2. Launch TextEdit
3. Go to the Input menu (a US flag if you're a US user), and select "Hiragana"
4. Type "sa"<return><space>"sa"<return>"
5. Back up a character, without selecting it, by pressing the left arrow key
6. On the Input menu, under Kotoeri, select "Reverse Conversion"

At this point, you'll get a popup menu that provides a number of alternative characters to be inserted instead of the default "さ" that was inserted in place of the second "sa" that you typed in step 4.

What just happened? Well, you asked the Kotoeri IME (Input Method Editor) to try to reconvert some text in the document. At that point, Kotoeri needs to figure out what text you want to reconvert. Now, put yourself in the place of someone who's implementing this feature in Kotoeri. Go back to the reference for the NSTextInputClient protocol, and ask yourself, how do I implement this feature?

Well, the first thing you'll do is, see if the user has any text selected, because that's a pretty clear indication of exactly which text the user wants to reconvert. So, you'll call the selectedRange method. If the selected range isn't empty, then you'll just call attributedSubstringForProposedRange:actualRange: passing the selected range you just got from calling the selectedRange method.

In the steps above, however, the user selection is an insertion point. The selectedRange method returns an empty range. Now what? You'll need to probe the document content to figure out what text to reconvert. But, the insertion point can be at the end of the document. As a Kotoeri implementer, the first question you're likely to ask is, how long is the document? Unfortunately, there's no method in the NSTextInputClient protocol that provides a direct answer to this question. Thus, the glaring hole in the protocol.

At this point, as someone who is implementing an input method editor, you have two options. You can create a reasonable range of text to probe based on the location of the insertion point, and call attributedSubstringForProposedRange:actualRange: paying attention to the actualRange value that you get back. Or, you can simply call the attributedString method, and get the length of the result.

It's possible that the Kotoeri IME has been revised for Lion, but, as of Snow Leopard, Kotoeri actually uses the second option. And, note that the attributedString method is optional. If you've written an application that implements the NSTextInputClient protocol but have omitted an implementation for the attributedString method, then nothing will happen if the user selects "Reverse Conversion" in the above scenario.

OK, so what's the big deal? The protocol does provide a solution to the problem from the IME's perspective, so everything's fine, right? Well, not quite. Let's put our end-user hats back on. Some users have documents that are thousands of pages long. You do not want to implement the attributedString method in a way that simply returns a standard NSAttributedString, or even just a regular NSString. Both the performance and the memory usage is not likely to lead to a satisfying end-user experience for people who spend their days editing long documents.

Careful readers of the NSString class reference will figure out a reasonable solution to this problem, but a more robust design for the NSTextInputClient protocol might have obviated the need for applications developers to pay such close attention. Having said that, it's probably not fair to either Apple systems engineers or the folks who implemented the Kotoeri IME to argue that they should have thought of this. Anticipating this kind of corner case is something even very smart people will miss.

Rick

Currently playing in iTunes: Days Is Almost Gone by The Derek Trucks Band

Steve's contribution to the industry I think is epitomized in this video:

As Nadyne might say, there are really two parts of user experience: aesthetics and functionality. Aesthetics is about your emotional reaction to using a product--a certain joy or excitement. It's what people are really talking about when they refer to the "cool" factor. Functionality is what a product helps you to achieve. Does it relieve you of mundane tasks, thereby allowing you to focus your energies on your own creative output? How does a product help you achieve your goals?

Aesthetics leads you to want to break with the past. Functionality leads you to want to build on the past in ways that don't leave people stranded. There's always a certain level of tension between the two, and the amount of emphasis you place on one over the other can lead to some widely divergent design decisions.

Steve placed far more emphasis on aesthetics than the rest of us did. He always thought that if people didn't experience joy in using his products, then he'd failed in some important and fundamental way. The rest of us generally focused on functionality. The one quibble I have with Steve's criticism is this: it's not a question of whether or not we had any taste. It's more a question of whether or not we thought it was an important place to focus our energies. Steve thought it was. We didn't.

But, the key insight that I think is missing in most of the tributes being paid to Steve is that both of these aspects of user experience are important. I truly believe that Steve understood this. He was, after all, the one who had said, back in the dark days of the early 90's, that Apple couldn't survive without Microsoft. He took a lot of flack from people in the industry for that stance, but I think he understood, at least intuitively, Apple users needed our functional focus just as much as they needed his aesthetic focus.

Steve's true contribution to the industry, then, is the way he married both of these concerns. He and Apple set the aesthetic parameters that determined the boundaries in which those of use who developed software for the Mac would fill in the functional aspects of user experiences. That combination leads to some fascinating synergy that began with movable-modal dialog boxes and combination edit/drop-down menu controls in Mac Word 4 all the way on up to how we did the ribbon in Mac Office 2011. If there is any legacy of Steve's that I would hope this industry could cary forward, it's this balance between aesthetics and functionality.

Rick

Currently playing in iTunes: Wayfaring Stranger by The Tierney Sutton Band

The problem with Pierre's discussion of usability is that it's completely devoid of any discussion of user tasks. Pierre never talks about why a user would want to know what styles are applied to a given location in the document, and how the presentation of that information simplifies common user tasks. Had he done so, he would quickly realize that Pages' solution to some key user problems isn't as elegant as Pierre would have us believe. Indeed, there's one key problem where Pages offers no effective solution at all.

People use styles for two general reasons that are not incompatible with one another: to denote structure in the document, and to maintain a consistent look throughout the document. A common task associated with both goals is to review the document for consistent usage, and it's worth noting that the person doing the review is often not the same person who originally wrote the document.

Note that I've used the word "review," and I've done so for an important reason. A review might involve a scan of the document, but that's not always the case. Indeed, one of the more important questions users ask is, where are certain styles used within the document? Both Word and Pages have a rather quick way to answer that question via the "Select All" or "Select All Uses..." menu options on the individual style items in either the styles pane in Word or the styles drawer in Pages. Though, here, I would argue that Word's solution is better in two ways. First, in Word, you can filter the list of styles to only those styles in use. In Pages, you have to scan a list of styles looking for styles that are in use. Second, in Pages, you have to select the entire document. In Word you don't.

So, think about the work flow for reviewing the use of several styles in a document. In Word, you'd filter the styles list to styles that are in use, then choose "Select All" on the style item menu for each style you'd want to review. In Pages, you first have to select the entire document, then scan the styles drawer for the style you're interested in reviewing, and then choose "Select All Uses" from the style item in the drawer. To review the next style, in Word, you just choose the "Select All" item for the next style you want to review. In Pages, you have to reselect the entire document and then repeat the scan through the list of styles. In this case, Word's UI allows the user to complete the task in less time and with fewer steps.

Now, that covers how users would answer the question, "Where have I used this style?" There are times when the user will want to ask, "What styles are used here?" For character styles, Pages is marginally better than Word. Pierre is correct in noting that Word currently does not give the user a way to answer that question for any arbitrary sub-section of the document. On the other hand, in both Word and Pages, you still need to click around in the document in order to see what styles have been applied in particular locations, and it's not at all clear how seeing the styles used in an arbitrary selection simplifies the overall task of reviewing a document for style consistency.

Moreover, with Pages, the user is still saddled with having to scan a list of styles in order to see which ones are applied. And, as a side note, the two different style menus do not provide a particularly elegant solution either. The little "-" sign next to the style items is difficult for some users to even see, and the fact that the user has to drop two menus to find the relevant information adds yet another step to any user task in which the user seeks to answer the question, "What styles have I applied here?"

A far better solution would be to provide visual cues in the document itself showing what styles have been applied. For paragraph styles, Word has long had this feature in draft view. On the "Word" menu, select "Preferences" and then click on the "View" icon. In the "Window" section, you'll see a "Style area width" edit item.

But, that's not an ideal solution either. First, there's no information about character styles. Second, the user has to switch document views. For Word 2011, we've come up with a better solution. You'll likely see a post on Mac Mojo talking about the work we've done here, but it's a far better solution than those offered by either Pages 2009 or Word 2008. No selection required, no need to drop a menu or scan through a list of styles in the styles drawer. In order to see what styles have been applied, the user will merely need to scroll through the document.

Now, we've talked about two different questions that users often ask: "Where has this style been used?" and, "What styles are used here?" There's a third question that users ask, and it's often more important than the other two. That question is, "Where has direct formatting been used when a style should have been used?" The goal, here, is to correct these cases; to replace the direct formatting with the styles that should have been used in the first place.

Pages currently offers no real solution to this problem. At present, Word does have a solution, but it still requires the user to scan through the document and click where the formatting appears to be different from the underlying style. Though, to Word's credit, the "Current style of selected text" control in the styles pane gives the user a way to select all instances of that combination of style + direct formatting in the document, at which point the user can then simply apply the style that ought to have been applied in lieu of the direct formatting.

As with the "style area width" feature in Word, this is also not an ideal solution to the problem. We can do better. Indeed, perhaps there's a solution that allows the user to merely scroll through the document...

When it comes to usability, it's not enough to just "think different." You have to think about what users are trying to do and what tasks they need to perform in order to achieve those goals. Ultimately, if your "usability" does little to shorten the amount of time it takes for users to complete important tasks, then it really has nothing to do with "usability" at all.

Update: I couldn't talk about the work we've done when I first posted this, but here's a nice screen shot of Word 2011's Styles Guides:

The full article is here, and I'm particularly fond of Edward Mendelson's description of this feature:

The other terrific new feature is the Styles Guide display. When you turn this on, a color-coded column appears (on screen only) in the margin of your document. Each block of color has a number, and the colors and numbers match colors and numbers in the styles menu, so you can see at a glance which styles are attached to every paragraph. This is impossible in all other versions of Word, and all other word-processors. Another option, also available from the Styles menu, turns on a "direct formatting indicator" that outlines in blue all the text in the file that is formatted directly from a menu with (for example) italics or bold, instead of being formatted with a style. I only hope that Windows users will get this terrific feature before too long.

If you look closely at the left-hand document, near the bottom, you'll see a bluish "9" box to the right of the yellowish "7" block. That means there's a character style applied within that line.

Notice, also, that the "7" is drawn black while the "9" is drawn white. I'm proud to say that I came up with the algorithm for figuring the color for the number based on whether the human eye would perceive the background color as being "dark" or "light".

And, by the way, that entire Styles pane is done completely in Cocoa. So, it has some nice animation features when you change the "List:" menu to change the collection of styles that's shown in the list.

Was it John Gruber who said something about attention to detail when he linked to Pierre's original post?

Rick

Currently playing in iTunes: I've Been Working by Van Morrison

There are a couple of other ideas to keep in mind.  Brent's further bifurcation of code into Foundation and UIKit sub-sections is a good idea. Indeed, it's not a bad idea to start thinking of the relationship between your app and the OS as being the meat (tofu for the vegans out there) in a sandwich. The Foundation code is the bottom slice of bread, and the UIKit/NSFramework stuff is the top slice of bread.

However, I'd take it a step further and break the code up into functional units. In Brent's case, I'd imagine that there's a networking stack, some XML parsing/XML RPC code and some data store manipulation just in the Foundation tree alone. I'd keep those separate from each other.

I'd also reconsider the idea of building static libraries. The shared code, along with the unit tests and any other acceptance testing code, should be in at least one separate project, but it's even better to have each functional unit of code in its own project. The linker should be able to dead-strip anything that any given client doesn't use, especially if these are static libraries, and having separate projects ensures that the code is always built the same way regardless if which client is using it. Managing the build settings for one shared project is much simpler than trying to ensure that the build settings are consistent across all the projects that use the shared code.

If debugging is a problem, then create separate build and debugging/development projects. The latter can help reduce the time required for the edit/build/debug cycle to complete, yet still retain the functional separation that is beneficial to code that's shared.

Once you've separated pieces out into projects according to functional units, have each project build a framework that exports the symbols that are "public" for that shared piece. You can still link the static libraries for actual distribution bits. Indeed, the target that builds the framework should have a single, dummy source file while the framework links in the static library that's actually shared.  Doing this will tell you what the interdependencies are between the various functional units. You'll discover whether or not some circular dependencies have crept into your code, and those will almost certainly end up causing you headaches in the future (if they aren't already causing you headaches now).

Remember, agile programming isn't about you being agile. It's about making your code agile. And, if you're sharing code, it really needs to be agile enough to work in the variety of contexts in which its shared.

Rick

Currently playing in iTunes: Lost In the Flood by Bruce Springsteen & The E Street Band

I'm also amused at a number of the comments on that post. It's a product of my age. Not only do I remember a time when floppy disks really were floppy, my experience with them dates back to high-school when I had the, um, pleasure of doing accounting on an old IBM work station connected to a computer housed in a semi trailer that seemed to use up half the back parking lot. Those were 12" floppy disks, and they didn't hold very much data.

But neither my age nor floppy disks address the overall point I was trying to make; a point that commenter Michael McWatters, stated very succinctly:

As in most things UX-related, there can be no immutable laws, only best practices and context-sensitive design solutions.

"UX" stands for User eXperience. It goes beyond just usability, and involves a systematic effort to understand how users feel when they use something. It's applicable outside the world of software, but it's becoming increasingly important in the software industry. In my previous post, I linked to this Wikipedia entry, which gives the ISO definition of user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service."  You'll also see the word "affective," in the psychological sense, used to describe these feelings.

User experience is inherently subjective. Indeed, it's about as far to the subjective end of the objective-subjective spectrum as you can get. We can't measure it directly, but we can take a look at the factors that determine a user's perceptions and responses. The user's past experience, for example, is one of these factors. Another factor is what the user wants to achieve--the user's goals. Yet another factor is the user's aesthetics.

We use the word "context" to refer to the collective set of factors that determine a user's perceptions and responses to using a system, hence Michael's use of the phrase "context-sensitive design solutions."

And it's the user's context that matters, not mine or John Gruber's, or yours unless you're a user. Even then, as an individual user, your context only matters to the extent that your context shares elements of the contexts of other users. That last statement is important, because users aren't homogeneous. The "average" user is as much of a statistical fiction as is the "average" household that, at one point, had 2.5 children and 1.5 cars.

Users don't all have the same shared context. A couple of comments on my previous post help to illustrate this point.

One commenter pointed out that, for Mac users, the use of a floppy-disk icon seems to be unique to Office. Let's take that as true. However, we've already had to limit our user population to Mac users. Furthermore, given the history of Mac Office, the use of a floppy-disk icon is part of the context for existing Mac Office users--the people most likely to use newer versions of Mac Office.

Another commenter suggested doing away with the save operation altogether. We actually did that once, not with Mac Office, but with another app. We were quite surprised to see the number of users who were disturbed by their inability to figure out how to save their work. It never occurred to them that the app was saving their work as they went along.

Since applications inherently target different users, the archetypical context for one app won't be the same as that for another app. Hence, a particular design decision that makes sense in one app, e.g. using a floppy disk as the icon for a save button, wouldn't make sense in another app.

As an exercise, go back and read Apple's HIG in light of this idea of "context." Do those guidelines favor certain user contexts over others? Might there be some users for whom the target context inherent in Apple's HIG wouldn't be appropriate?  Why, indeed, are they called "guidelines," and not "rules"?

I'll leave you with that thought for now. In an upcoming post, I'll talk a bit about how we break down user contexts into relatively homogeneous groups, and how that helps us prioritize the work we've done on Mac Office.

Oh, and John, if you're still paying attention, the next time someone asks you what icon they should use on a "save" button, tell them to use a piggy bank.

Rick

Currently playing in iTunes: I'd Rather Be Blind, Crippled and Crazy by The Derek Trucks Band

Couple of problems with this. First, the question is about icons, not labels. In the vast majority of cases, the label for a save button at least includes the word "save". There are, however, legitimate cases where you'd want to have an icon as well, so suggesting that developers not use any icons at all isn't really a viable choice.

Second, text in an icon violates one of the cardinal rules of localization. Once you put text in an icon, you then have to have a version of the icon for every language you want to support.

John closes his remarks by saying, "I can’t think of a single floppy-disk-for-save button anywhere in Mac OS X or iPhone OS..." Well, I can think of three: Word, PPT and Excel use a floppy disk as the icon. It's the icon we've been using for "Save" since back when having a floppy disk for that icon actually had meaning.

Now, this does raise a rather interesting question for apps that have been around the block a few times. Do you change an icon which has a rather established meaning for current users when the nature of changes in computing have stripped some of the meaning from that icon? Personally, if we were doing Mac Office for the first time today, I'd much prefer something like Mars Edit's document-into-a-folder icon. But, for an icon that has an established meaning, the "right" answer isn't obvious.

For any app that gets past version 1.0, this general question is a constant issue. We face it so often, that we've expanded user experience (UX) as an engineering discipline within MacBU. We've made it coequal with the development, testing and program management disciplines, and are increasingly incorporating a variety of UX design techniques, not just usability testing, into our development process.

As I find time, I hope to be able to talk a bit more about what this means, but, if you're interested, the Wikipedia entry isn't a bad place to start.

None of this, though, actually highlight's John Gruber's mistake. What was that mistake? Never get snarky in a blog post that includes the phrase, "I can't think of."

Rick

Currently playing in iTunes: It's Only A Paper Moon by The Tierney Sutton Band

The problem with blogging is really finding something to talk about.  Well, there is a lot that I could talk about, but there's this fine print in my employment contract that leaves quite a bit of what I'm working on off the table.

For example, I could talk about the travails of transitioning from Carbon to Cocoa, but it doesn't take a rocket scientist to put two and two together to figure out that Microsoft is moving Mac Office to Cocoa. And, of course, the more details I discuss, the more people can figure out just how far we have progressed along that transition.

I see comments on various blog posts where people ask or this or ask for that, and I want to say, "Guess What!" But, I can't! And it's horribly frustrating.

So, am I back? I don't know. I'm contemplating. In the mean time, Red Sweater has released Mars Edit 3.0. So, I'm taking it for a spin. Now, if I can only remember where "Currently Playing in iTunes" is.  Ah, yes...

Rick

Currently playing in iTunes: Change It by Stevie Ray Vaughan

One of the things I love about this job is tracking downinteresting bugs.  It’s like readinga good who-done-it, complete with plot twists, multiple potential suspects and a fascinating array of characters. Late last September, Craig Eisler submitted a bug that had all of these elements.

Now, when your general manager submits a bug, you don’t necessarily have to get on it right away. But, it’s not a good idea to let it linger for too long.  So, after this bug had been on the list for about a week or so, I decided it was time to figure out what was up.

The bug involved a document Craig had been editing with revision marking turned on.  He’d made some changes to the document, saved it, quit Word and, when he opened the document back up, some of the spaces between words were missing.

With a bug like this, the first thing I do is open it up in Win Word.  If the problem appears there, then there’s a strong likelihood that the bug is in the code that writes the file.  If the bug doesn’t appear in Win Word, then I know to start looking at the code that reads files.  In this case, the problem appeared in Win Word, so my first suspect is going to be somewhere in the save code.

Also, the missing spaces seemed to be in or around areas of the document where revisions had been made.  So, the first suspect was somewhere in the code that writes revisions.  I created a document, added some text, turned on revisions made some changes and saved the file stepping through the code that handles revision marking.

Nothing.  Everystep along the way, everything was happy. The code was writing all the appropriate XML tags, and none of the text was missing.  Of course those two sentences summarize about two-three hours of sleuthing, after which I was able to exclude the revision marking save code as a suspect.

Well, maybe it’s something that only appears to be related to revision marking.  Let’s take two files, one that exhibits the problem and one that doesn’t, and compare the contents (much easier to do now that the document content is XML).

Again, nothing. Other than a few gratuitous differences (revision save ID’s, for example, which are uniquely generated every time new text is saved in a document), everything in and around the missing spaces was identical.  Another couple of hours spent cracking open various documents and comparing the XML, and I still haven’t a clue whothe real culprit is.

Well, but, if the documents are identical, maybe the problem happens when we read the file.  So, I set a breakpoint on the code that handles runs of text from the XML parser, and, sure enough, our “characters” callback wasn’t getting called for just the missing spaces.  Hm…  Progress.

About another hour or so, I had tracked it down to some general XML parsing code we’d ported from Win Office.  One of the problems with writing filing code that’s intended to handle future situations is that, when you write the code, the future hasn’t arrived yet.  Well, for Win Office, Mac Office represented the future, and some of the stuff we’d added exposed a subtle bug in the code we’d ported (note: the problem has been fixed in WinOffice before Mac Office shipped, so people shouldn’t run into this at all).

By the time I had finished all of this, implemented a fix and verified the fix, it was about 1:30 in the morning.  When I get engrossed in a good mystery, I sometimes find it difficult to put the book down.  Same thing goes with good mystery bugs.

And, the bug being a good mystery bug that geeks like Craig and I appreciate, I sent off an e-mail to Craig outlining the basic nature of the bug and the fix (which turned out to be just a couple lines of code—this is almost always the case with a good mystery bug).  This being in the middle of the FIFA Women’s World Cup, I ended the mail by saying that I was going to go home, drink some coffee, and stay up to catch the USA match (I forget who the opponent was).

The next day, I got a response from Craig with some questions about the bug.  I replied to Craig’s questions and, at the end of the e-mail, lamented over the fact that, after all that effort and all that coffee to stay up to watch a soccer match, our local cable company saw fit to pre-empt the last 30 minutes of the match with a taped question-and-answer program starring Mike Holmgren, the Seahawks coach.

For a born-in-Green-Bay, prick-me-and-I-bleed-green-and-gold, Packers fan like me, having a soccer match for which I’d stayed up all night to be able to watch be preempted by Mike Holmgren is seriously rubbing salt into the wound, and I conveyed my displeasure at this to Craig by saying that the only reason we still have a working television in the house is the fact that there were people asleep in the house at that time.

What ensued was a series of e-mails between Craig and I with a dual thread about the bug he’d reported and my television set.  His response to my previous e-mail was to suggest that I should have taken the TV outside and smashed it there.  Wake up the neighbors instead of the kids, and I get to vent my hostilities.

In my reply, I explained that this was not an option giventhe size (36”) and weight (over 260 lbs) of my TV set, to which Craig replied, “A CRT!?  How quaint!  Do you get slivers when you go to the bathroom after watching that TV?”

Having an uber-geek general manager is cool.  You get great bug reports, and he likes to hear about the nature of the bug and the fix.  Just be a little careful when you talk about the technology around your house.

Rick

Currently playing in iTunes: New World Blues by Gov't Mule 

"Don't put your lips on it!"

Rick

Currently playing in iTunes: Afternoon by the Pat Metheny Group

"Trading fours," or "trading eights," is a jazz term that refers to one or more soloists taking turns in a solo.  The idea is for each musician to pick up where the previous one left off, as if the alternating musicians are really playing the same solo.  It takes an enormous amount of skill and practice to pull this thing off.

Below is a video from a 1989 concert involving members of Dizzy Gillespie's "United Nations Orchestra"--an all-star group of musicians who are, today, very prominent in Latin jazz. This particular number is a medley of Seresta, a duet between clarinetist Paquito D'Rivera and pianist Danilo Perez, that segues into a full orchestra performance of Samba for Carmen.

The latter opens with long solos by trombonist Slide Hampton and trumpeter Claudio Roditi, but closes with a round of trading fours where D'Rivera, Hampton and Roditi work the idea to perfection.

As something of a side note, it wasn't until I'd seen this video that I realized that D'Rivera had put down the clarinet and picked up his alto sax for the round of trading fours--such is the mastery of the instrument's range that D'Rivera exhibits in this piece.