Easy one-handed Control Center and Notification Center access on iPhone 12/11/X

 I finally opened up my wallet and replaced my aging iPhone 6S -- fare ye well, headphone jack -- with a new iPhone 12. It's my first purchase of a brand new iPhone since buying an iPhone 5S, all the way back in 2013. (I had bought the 6S secondhand, via a seller on Swappa.)

While I'm finding the 12 to be a nice upgrade, one big usability regression jumped out at me in the early going: The difficulty of activating Control Center. (That's the screen where you can adjust volume and brightness, enable/disable wi-fi and Bluetooth, and so forth.) 

On the 6S, activating Control Center was easily done while holding the phone in one hand, via an easy swipe up from the bottom of the screen. On the 12 -- which has no Home button -- that gesture now navigates to the Home screen. Control Center is now activated via a swipe down from the top-right corner of the screen. 

The 12's larger size makes that gesture difficult to perform one-handed. Compounding the problem, although I'm right-handed, I use my left hand when operating the phone one-handed -- so that top-right corner is unreachable without substantially shifting my grip on the phone (which increases the risk of fumbling it).

With its generally very good support for accessibility features, I figured Apple would provide a simple option somewhere in Settings to swap that top-right-corner gesture for the top-left-corner. Unfortunately -- at least as of iOS 14 -- there is no such option.

The solution

To the rescue comes a configurable accessibility gesture pointed out by @temptertemper: The "Double Back Tap". Under Settings → Accessibility → Touch → Back Tap, you can set a firm "tap tap" performed on the back of your phone to perform one of a number of options -- including bringing up Control Center!

That double-tap is easily done with an index finger, while still securely holding the phone in a one-handed grip. In the early going, I've found the double-back-tap to be a much easier-to-perform alternative to the stock swipe-down-from-top-right-corner gesture.

Triple-back-tap is also assignable from the same place in Settings. I've assigned that to bring up Notification Center, which is also by default activated by a swipe down from the (distant) top of the phone screen.

Thanks to @tempertemper for this great suggestion, which I expect to be a nice quality-of-life improvement in daily use of my new iPhone!

Chrome Browser Deal-Breaker: Ctrl+Tab behavior

Depending on who you ask, Google Chrome is the world’s most popular browser here in mid-2012.  It’s fast, lightweight, and standards-compliant.  However, Chrome has one major (for me) issue that will prevent me from ever using it as my primary browser: The lack of any way to modify the behavior of the Ctrl+Tab keyboard shortcut to switch between tabs.

Like the other leading desktop web browsers Firefox and Internet Explorer, the default behavior of the Ctrl+Tab keyboard shortcut in Chrome is to switch between tabs in left-to-right order.  I’ve believed for years that this behavior is inefficient at best, and the default switch order for Ctrl+Tab should be most-recently-used (MRU) order. The default left-to-right Ctrl+Tab switch order makes it impossible to quickly use the keyboard to toggle back and forth between two tabs when there are multiple tabs open.  Left-to-right order is also inconsistent with the long-established MRU order for the keyboard shortcut for switching between open applications (Alt+Tab in Windows and many Linux distributions; Command+Tab in OSX).

Unlike Firefox and Internet Explorer, however, Chrome offers no way to change the default Ctrl+Tab behavior, even via add-ons / extensions.  To compare the three leading desktop browsers:

• Firefox: Has an excellent addon called LastTab which has a great implementation of MRU Ctrl+Tab behavior (including an Alt+Tab-like preview window of the tabs arranged in MRU order);
• Internet Explorer: Has a “Use most recent order when switching tabs with Ctrl+Tab” checkbox in its Advanced Options settings;
• Chrome: There’s no configuration setting to change the Ctrl+Tab behavior.  The Ctrl+Tab key combination apparently is defined as “reserved,” so extensions can’t change its behavior either.

There’s a long-standing (2008) Chromium bug, Issue 5569, logged for Chrome’s Ctrl+Tab behavior; however, it was marked as “WontFix” shortly after it was opened.  Google does acknowledge the demand for MRU switching behavior in a brief statement on the Chromium project’s User Experience > Tabs page:

Ctrl+Tab, Ctrl+Shift+Tab, Ctrl+PgUp and Ctrl+PgDn can all be used to switch back and forth between tabs. While there is great demand for an MRU-ordered switcher, we've so far been unable to find an MRU switcher that makes sense beyond the first three most recent tabs, or one that works well with background-created tabs.

I’m somewhat bemused by this statement; there are many good reference implementations of MRU switching order available.  One specific example is the LastTab Firefox extension mentioned above; I’ve used that for years and have been very happy with it.

If you’d like to add your vote to this issue, feel free to head over to Chromium Issue 5569 and “star” the issue and/or leave a comment.

This issue is a deal-breaker for me to consider adopting Chrome as my primary desktop web browser – Chrome’s benefits don’t outweigh the potential several-times-per-day productivity hit of not being able to rapidly and easily toggle between two specific browser tabs.  In the meantime, I’m happy to continue using Firefox as my own primary browser. 

In occasional situations where I do need to use Chrome and have multiple web pages open, going old school and opening each web page in its own browser window (instead of using multiple tabs) is a tolerable workaround (since that lets me use the operating system’s MRU window switching behavior to rapidly toggle back and forth between two windows as needed).

Middle-click taskbar button to close application – Windows 7 edition

As I’ve previously posted for Windows XP, a user interface convention that I really wish would become a universal standard for applications that support multiple tabs (such as modern web browsers) is upon middle mouse button click on a tab, the application would close that tab.  This is the standard behavior in Firefox, Internet Explorer 8, and Chrome (and probably other browsers, too).

I also wish Microsoft would match the IE8 behavior and make “close application” the default behavior for a middle-click on an application taskbar button in Windows, since the Windows taskbar is essentially just a tab bar for open applications.  Unfortunately, in Windows 7, middle-click on an application’s taskbar button is mapped to “launch new instance of application,” not to “close application.”  Furthermore, there seems to be no out-of-the-box way to change this behavior.

To the rescue: 7 Taskbar Tweaker by “RaMMicHaeL.”  Among a few other available features, this utility does exactly what I’m looking for: On a PC running Windows 7, it remaps a middle-click on a taskbar application button to close that application.  I’ve been using version 1.1 of the utility on my primary home PC running Windows 7 for months now, with no problems at all.  Highly recommended if you’re a fan of the middle-click-to-close UI convention!

How to prevent a web site from stealing the focus in Firefox

At work, for a while now, I've had my Firefox 3 browser homepage set to a particular page in our internal Confluence wiki.  This page is specially designed to be a "start page," consisting solely of a series of links to commonly-used internal applications and documentation, plus a few search fields allowing common searches to be performed (of the wiki; of the employees database; of the Internet via Google).  I also have the New Tab Homepage Firefox add-on installed, so this homepage appears when I open a new tab in Firefox.

This setup works great, with one glaring exception: The page takes a couple of seconds to load, and Confluence automatically sets the focus to the first search field on the page when it completes loading.  The result of this is whenever I opened a new browser window or browser tab and started typing a URL in the address bar to manually navigate to a page (which I actually do fairly frequently), typically halfway through my typing in the address bar, the web page would steal the focus, and the second half of the URL I was typing would appear in the search field on the page instead of in the address bar.

This problem isn't necessarily limited to a Confluence page set as a browser homepage; it could potentially occur with any web page that is coded to set the focus to a particular UI element on the page, such as the Google homepage.  Here's what might happen if I opened up a new browser window with the homepage set to Google, and started trying to type "http://localhost/" in the address bar as the page loaded:

Note that half of the "http://localhost" text appears in the address bar, but (in this example) after the "a" was typed the script web page made a call to the Javascript focus() method to set the focus to the search field, and Firefox honored this; as a result, the remainder of the typing appears in the search field -- the Google page managed to steal the focus.

I went about searching for a solution to this problem, and ended up finding one in a post on Kam-Hung Soh's blog.  Kam-Hung's post has instructions on how to disable a particular Javascript method for a particular web site. 

I followed the instructions, and added the following to my Firefox user.js file:

user_pref("capability.policy.policynames", "noinputfocus");
user_pref("capability.policy.noinputfocus.sites", "www.google.com");
user_pref("capability.policy.noinputfocus.HTMLInputElement.focus", "noAccess");

(In my case, I used the URL of my team's internal Confluence wiki site instead of "www.google.com").

After doing this, I was all set!  I no longer had my focus stolen after opening a new browser window or a new tab. (Thanks, Kam-Hung!)

Obviously, these instructions are Firefox-specific, and therefore aren't helpful for addressing this issue in other browsers.  However, when I tried to reproduce the issue in Internet Explorer 7, I was unable to do so -- in cases where I had started typing in the address bar as IE7 loaded the page, the web page never gained the focus.  Perhaps IE has some intelligent logic where it will ignore focus() calls made by the web page in the case where the user has already started typing something in the address bar?  It would be really nice to see all browsers implement such a feature, to avoid the need for workarounds such as the one described in this post.

Update 2/4/2009: I took a look, and there is in fact a bug in the Firefox Bugzilla database for this issue. It was initially reported back in 2002, though, so I'm not super optimistic about the bug being fixed in the near future. :-)

UI Annoyance: Unselectable text in a disabled form field

A usability annoyance that I've encountered on a few occasions is a disabled field on an desktop or web application form which doesn't allow text in the field to be selected, and therefore, prevents the value in the field from being copy & pasted to another location.  (This side-effect of not allowing a clipboard copy of the field's value may or may not be above and beyond the developer's intention of simply not allowing the contents of the field to be modified).

For example, the web application server WebLogic Server 9 (WLS9) includes a web-based administrative console where database connection strings and other settings for hosted applications can be defined.  In the WLS9 console, one user at a time can obtain a lock on the console, preventing other users from concurrently making conflicting changes; when the current user does not have the lock, all editable fields are disabled.  In this state, field values can't be selected and copied to the clipboard.  This effectively prevents the user from doing things like copying settings from admin console form fields to another WebLogic instance, or copying a hosted application's settings from the console to document them in the application's internal documentation. 

There's no reason that the WLS9 console needed to be coded to prevent clipboard copying of values in this way; after all, the disabled field values are still visible, and the user can always just manually read and retype them elsewhere.  It's just an annoyance for the user to have to do manual retyping of values (such as long, complex database connection strings) when they could be using a clipboard copy to get the values.

HTML form fields: Disabled vs. Readonly

In HTML, an input type="text" field can be set with the attributes disabled or readonly.  The attributes have similar behavior; both prevent the field contents from being modified.  One key difference, though, is that the readonly attribute still allows the value in the field to be selected (and copied to the clipboard); the disabled attribute may prevent the value from being selected and clipboard copied, depending on the client browser's implementation.  (For example, Firefox 3 prevents the value from being selected; Internet Explorer 6 does allow the value to be selected.)

Try dragging with the mouse inside each of these fields, to see what behavior your browser allows:

<input type="text" value="Try selecting this text" readonly> :

<input type="text" value="Try selecting this text" disabled> :

Conclusion

Web application developers, before using the disabled attribute on a text input field on a web form, consider whether your users may ever want to clipboard copy the value in cases when the field is disabled.  If so, consider using the readonly attribute instead.

The same principle holds true for desktop application developers as well.  Consider whether your users will ever want to clipboard copy values from your disabled form fields when defining the behavior of whether the field values can be selected or not while disabled.

Excel tip: Shift+F2 = Edit Cell Comment

A quick tip for Microsoft Excel that I've just found, and is currently making my life easier: Shift+F2 jumps to editing the cell comment (note / annotation) for the current cell.

This is a lot nicer than having to go over to the mouse and right-click on a cell, then choose "Edit Comment" (or "Insert Comment" in the case of a cell that doesn't have a comment yet) from the context menu when doing heavy editing work on an Excel sheet.

This works in Excel 2003; it might also work in other Excel versions as well.

Bonus tip: F2 alone (without holding Shift) edits the existing value in the current cell.  This is another time-saver that allows you to edit the value in a cell without having to move over to the mouse. 

The use of F2 to mean "edit the current value" is a semi-standard that works in many other Windows applications as well.  For example, F2 in Windows Explorer begins editing the name of the selected file or folder (to allow the file or folder to be renamed).

Don't treat Underscore as a word separator character on double-click

In just about all modern text-reading and text-writing applications, a double-left-click with the mouse on a word in the text causes that word to become selected.  Double-clicking a word in this manner is handy for quickly selecting a word in order to copy-and-paste or cut-and-paste it elsewhere, or to just delete the word.  (If you've never used double-click in this way before, go ahead and give it a try on one of the words in this post, right here in your web browser.)

I've recently noticed that not all applications handle double-click-selection of words that contain an underscore character (the character "_"; also called "underbar") in the same way.  Such words are frequently used by software developers for naming such things as variables and database fields; examples are max_records and customer_id. 

In some applications, double-clicking on any portion of a word containing an underscore results in the entire word being selected.  This is the behavior I want, since it lets me easily cut or copy the entire identifier elsewhere.  (For example, taking the example of the max_records identifier, if I double-click the word, it's far more common that what I'm trying to do is select and copy "max_records" for pasting elsewhere, rather than just "max" or just "records".)  The text editor Notepad2 works this way (shown here after a double-click on the word "max"):

The problem is that in some applications, double-clicking a word containing an underscore results in just the clicked portion of the word becoming selected; the underscore gets treated as a word separator character (like a space character would be treated).  Firefox 3 works this way (again, shown after a double-click on "max"):

Since typical (non-developer) users are seldom or never going to be working with documents with words that include underscore characters (and therefore aren't affected one way or another by what the behavior is), I think that the default behavior across all applications should be to select the entire word when a word including an underscore character is double-clicked.  The underscore should not be treated as a word separator character for the purposes of an application's logic that selects a word on a double-click.

It still might make sense for underscore characters to be treated as word separator characters in some other cases.  Such cases might include an application's spell check logic; another case might be the handling of navigating through a document a word at a time via the Ctrl+LeftArrow and Ctrl+RightArrow shortcut keys.

A few applications that get this behavior "right" (double-click selects an entire word with an underscore; not all other punctuation characters are specially handled this way):

• Visual Studio 2008
  
• Eclipse 3.3
  
• Notepad2 (2.1.19)
  
• Microsoft Excel (2003)

A few applications that don't get the double-click behavior "right" (double-click selects only the portion of the clicked word up to the underscore character):

• Firefox 3
  
• Internet Explorer 6
  
• Toad for Oracle (9.0.1.8)
  
• Microsoft Word (2003)
  
• Acrobat Reader 7

Developers of this latter set of applications: If you agree, please go forth and effect positive change!  :-)  Developers of new applications, please keep this issue in mind when coding up the mouse click UI behavior for your new app.

Update 4/4/2011: There is an existing, long-standing (March 2003) Mozilla (Firefox) Bugzilla ticket for this: Bug 196175 - underscore should be part of word, not punctuation. As discussed in that comments on that ticket, though, it isn't clear that special-case logic should be added for the underscore character, since behavior from application to application even on a single platform is inconsistent (as I noted above for Windows applications). I voted for the ticket, but I'm not going to hold my breath at this point for it to be addressed soon!

The "red squiggle" and user-entered filesystem paths

Wouldn't it be nice if the "red squiggle" that appears under misspelled user-typed words in many applications these days (such as Microsoft Word and Firefox 2) would also appear under mistyped portions of a filesystem path in "Open File" dialogs and other places where the user can manually type in a path, such as the Start | Run dialog, and the address bar of a Windows Explorer window?

Look closely at the highlighted section in the above Open dialog.  The last word in the path name entered by the user, "mircosoft," is a nonexistent file/directory name, and so a "red squiggle" appears under that portion of the entered path.

The image above is just a mockup; Windows XP doesn't actually do this.  Are there any current operating systems out there that do?

This would be a nice additional UI cue to the user that they have misspelled or mistyped something.  Currently, the only such cue in Windows XP that the user gets is that intellisense suggestions (suggested path/file names) stop showing up under the input field.

Tip: Expand your Windows Taskbar

A quick tip to make your Windows Taskbar a lot more usable is to expand its area and make it two rows high instead of one.  A pair of pictures are worth 2000 words:

These two images show the same Windows XP Taskbar with 12 applications running, and a bunch of icons in the system tray.  The difference is that in the second image, the Taskbar has been expanded to be two rows high instead of just one.

With the increased area available on the Taskbar, it's much easier to read the text that accompanies the icon on each application button, making it a lot easier to find (for example) a specific Firefox window or Word document.

To increase the number of rows in the Taskbar in this manner, just use the mouse to drag the top edge of the Taskbar upwards.  (You'll need to temporarily unlock the Taskbar first if you have it locked: Right-click an empty portion of the Taskbar, and uncheck the "Lock the Taskbar" option from the context menu that appears.)

Increasing the Taskbar area to two rows has a few other benefits as well:

• The system tray icons are grouped into three rows instead of just one, saving a lot of horizontal real estate on the Taskbar.  As a result, there's even more room available for application buttons to be shown.
• Windows shows the day and date in addition to the time on the right edge of the Taskbar; no need to hover over the time display with the mouse to see that information anymore.
• Although it isn't shown in the screen cap above, I've found that the bit of empty space below the Start button is a great place to tuck a SlickRun command line into.

With the large screen resolutions (and hopefully, multiple monitors) available on modern machines, the additional screen real estate consumed by increasing the Taskbar size to a second row is trivial compared to the usability and productivity gains realized by doing so.

(You might also note that I have the "Group Similar Icons" option from the Taskbar's Properties dialog turned off.  That option does save some Taskbar real estate, but at the significant cost of not being able to identify or access specific application windows from the Taskbar with a single-click.  Again, with the large amount of screen real estate available on modern systems, I don't see the benefit in ever having that option enabled.)

Utility of the day: Ditto

In most of today's major operating systems, the built-in clipboard has a significant limitation: it can hold only a single item a time. If you cut or copy a second item onto the clipboard, the first item is gone, with no direct way to recover it. Jeff Atwood posted about this issue recently in more depth on his excellent Coding Horror blog.

From the comments on Jeff's post, I learned about an excellent Windows utility that addresses this problem: Ditto. Ditto allows you to use a configurable system-wide hotkey (I'm currently using Ctrl+Alt+v) which brings up a "history browser" with all items that had been recently copied to the clipboard. Ditto automatically takes care of saving clipboard items, so that older items are no longer lost when a new item is copied to the clipboard.

Since installing Ditto on my machine, I've found myself using it more and more. In addition to being able to easily paste items that I know that I had on the clipboard recently, avoiding having to re-copy or retype them, Ditto enables me to in some cases plan ahead and do things more efficiently. For example, say that I have a large text document open, and I want to copy two nearby (but not adjacent) snippets of text from a location near the beginning of the document, and paste each of them to a location near the end of the document. With just basic operating system clipboard functionality, I'd need to:

• Copy item 1;
• Scroll to the end of the document;
• Paste item 1;
• Scroll back to the beginning of the document;
• Copy item 2;
• Scroll back to the end of the document;
• Paste item 2.

With Ditto, I can achieve the same end result more quickly:

• Copy item 1;
• Copy item 2;
• Scroll to the end of the document;
• Paste item 2;
• (Using Ditto) Paste item 1.

Ditto is written in C++, and is free and open-source. You can download it from the Ditto Homepage.

Utility of the day: Taskbar Shuffle

A user interface convention that is emerging as a standard for applications that support having multiple pages or documents open in tabs, such as web browsers (including Firefox, Internet Explorer 7, and Opera 9) and IDEs (including Visual Studio and, in an upcoming version, Eclipse), is the ability to click a tab with the middle mouse button to close the tab. This is useful for several reasons: (1) It's easier to position the mouse cursor over a tab than on a small button on the tab; (2) it prevents accidental closing of a tab with the left mouse button (when the close button on the tab is left-clicked inadvertently instead of on the remainder of the tab area); and (3) optionally, it allows the close button each tab to be removed (resulting in more available space on the tab for displaying the name of the tab's document).

I always thought it would be nice to be able to apply this same UI convention to Windows Taskbar buttons. After all, what is the Windows Taskbar but a tabbed view of all open applications? The ability to middle-click a Taskbar button to close it would be much nicer than having to right-click an application's Taskbar button and choose "Close" from the context menu that appears. (Trying to close many applications in quick succession in this way can be particularly aggravating when closing an application that doesn't follow the common convention of having the "Close" option as the bottom option in the context menu, such as cmd.exe command prompt windows – you end up having to hunt for the "Close" option among the other options, instead of just clicking the "Close" option immediately.)

I recently came across a free utility that allows a middle-click on a Taskbar button to close the application: Taskbar Shuffle by Jay E. The primary purpose of Taskbar Shuffle is, as its name implies, to allow Taskbar buttons to be reordered via a simple drag-drop. However, Taskbar Shuffle does also implement the middle-click-to-close functionality. Very cool!

I was initially a bit leery of installing a utility that hooks directly into Windows' explorer.exe (as I presume that Taskbar Shuffle must do in order to provide the functionality that it does), for fear that the utility could potentially bring down Explorer itself if something were to go wrong. However, I searched around for comments on the application, and found many very positive comments (including on the app's own forum) about the app, and no negative comments, so I took the plunge and installed it. I'm glad I did; on my machine (running 32-bit Windows XP Pro), Taskbar Shuffle is rock-solid stable! I've found it to be one of those extension-type applications that is just so useful, you wonder why its functionality isn't built into the base product itself (in this case, Windows).

One caveat: Apparently the current version (v2.2 as of this writing) doesn't support 64-bit versions of Windows yet. A 64-bit version might be on the way, though; the application appears to be actively developed, and some text near the download link notes "hold tight for 64-bit".

Update 7/1/2009: A 64-bit version is now available! Go check it out.

Go get Taskbar Shuffle from Jay E.'s website, here.

Mapping "Find Next/Previous" to F3/Shift+F3 in MS Word

Earlier today, after years of using Microsoft Word, I finally decided that I'd had enough of reopening the Find dialog every time I want to do a "Find Next" or "Find Previous" – that is, to have Word search up or down from the current caret position to find the next (or previous) instance of the string that I had most recently searched for via the Find dialog.

Visual Studio comes with this functionality by default, mapped to F3 for Find Next and Shift+F3 for Find Previous. Some other applications including Firefox and Notepad2 (Florian Balmer's excellent lightweight Notepad-like text editor) support these keyboard shortcuts as well. (Regular old notepad.exe supports F3, but not Shift+F3.) I'm very accustomed to using F3/Shift+F3, so I set out to get my copy of Word to support these.

(Update 4/28/2009: Jeff Cogswell commented with a much better solution to this problem that doesn't involve writing a custom macro, as detailed in this post -- see the comments on this post below for his solution!)

A search revealed that Microsoft Word supports a "Find Again" function, mapped by default to Shift+F4 and to Ctrl+Alt+y, but that isn't what I was looking for; I wanted to be able to easily search in either direction without having to open up the Find dialog and alter the setting of the search direction option.

So I ended up writing a couple of simple VBA functions using Word 2003's integrated Visual Basic Editor to do what I was looking for:

Sub FindNext()
  
   DoFind True

End Sub

Sub FindPrevious()
  
   DoFind False

End Sub

Sub DoFind(findDirection As Boolean)

   'Save the initial Find direction in order to restore it when we're done,
   'so that we don't alter the current "Find Up" setting in the regular Find dialog.
   Dim initialFindDirection As Boolean
   initialFindDirection = Selection.Find.Forward

   'Do the Find in the requested direction.
   Selection.Find.Forward = findDirection
   Selection.Find.Execute
  
   'Restore the initial Find direction.
   Selection.Find.Forward = initialFindDirection

End Sub

I determined that the Selection.Find.Execute statement was the key to getting Word to repeat a Find operation by using the Tools | Macro | Record New Macro functionality to record a macro of the built-in Ctrl+Alt+y "Find Again" shortcut, and then inspecting the resulting generated code in the VBA editor. Using the editor's intellisense functionality, it was simple to determine that the Selection.Find.Forward property was what controls the direction of the Find.

At first, I just wrote the FindNext and FindPrevious methods, setting Selection.Find.Forward to the appropriate value, and then calling Selection.Find.Execute. When testing those methods, though, I noticed that the setting of the Find direction carried over to be the new initial value for the Find dialog; i.e. after running the FindPrevious method, the next time the Find dialog was used, it would be set to find in the Up direction by default. I added the DoFind method to handle this issue, by temporarily setting Find.Forward to the necessary value, doing the Find, and then setting Find.Forward back to its original value.

To use these FindNext and FindPrevious functions yourself in Word 2003, paste the code above into the VBA editor (Tools | Macro | Visual Basic Editor), and save them. Then, map the F3 and Shift+F3 keys (or other keys of your choice) to FindNext and FindPrevious respectively by using the Customize Keyboard dialog (Tools | Customize, then click the Keyboard button at the bottom of the Customize dialog).

I would imagine that these functions should be similarly usable under Word 2007 as well, but since 2007's menu system and customization interface have changed, there are likely to be some changes to the steps necessary to enter the functions and map them to the F3 and Shift+F3 keys.

Email client usability: Replying to your own sent items

Here’s a scenario that I think is fairly common: I’m having an email conversation with another person (“Melissa” in this example). I reply to Melissa’s email; then, later, before I’ve gotten a new reply back from Melissa, I come across additional information that I want to send to her as part of the same email conversation.

To do this, I could just re-reply the most recent message that I got from Melissa – the one I already replied to earlier -- but in that case, my earlier reply would be dropped from the conversation when Melissa responds and the conversation continues:

What I really want to do instead is to reply to my own latest message in the conversation, so that the entire thread of the conversation will be preserved in the message:

Unfortunately, some modern email clients do not have very good support for this scenario, including (as I write this) the latest versions of Microsoft Outlook and Novell GroupWise.

• In Outlook (versions 2003 and 2007), if you Reply to a message in your Sent Mail folder, Outlook populates the "To" field with your own address, instead of populating it with the address (or addresses) of the other conversation participants. If you "Reply to All", both your address and the other participants' addresses are populated in the "To" field. In both cases, you need to fix the "To" field manually to make it have only the recipient(s), and not yourself.
• In GroupWise (version 7), the application doesn't permit to you do a Reply on items in the Sent Items folder at all! (The menu item Actions | Reply is disabled when an email message is selected in Sent Items.) Instead, you are obliged to use the Forward feature instead, and then clean up the header fields of the new message by deleting the "Fwd:" that automatically gets prepended to the subject line, and manually re-entering the address (or addresses) of the other conversation participants.

Gmail does handle doing a reply to a sent item correctly – good job by the usability guys at Google! Some other, older, mail clients may have handled this correctly as well; thinking back to my time at Michigan, I'm fairly sure that the now-venerable Pine email client handled this case properly.

It would be nice if Outlook and other mail clients that behave similarly would put the other conversation participants' addresses in the "To" field (and the "cc:" field when applicable) instead of your own address when you reply to an email message in your own sent items folder.

Tip: Poor man's text bookmarking

Many IDEs and text editors support a “bookmarking” feature, which will let you set a bookmark at a particular line of code or location in a document (generally through a menu pick or a shortcut key, which will bring up a prompt to enter a name for the bookmark), and then return there later (generally either through a dialog which allows you to pick a bookmark that you set previously, or though a Go To Next Bookmark / Go To Previous Bookmark shortcut key).

However, there currently isn’t any standard convention among Windows applications for the shortcut keys and menu options that are used to set and navigate to bookmarks. Visual Studio 2005, Eclipse 3.2.1, and Word 2003 (to name three applications that support mid-document bookmarking) all use completely different methods for setting and accessing bookmarks.

I’ve come up with my own trick for setting temporary bookmarks in a document. When I’m at a place at a document that I want to easily be able to return to a little bit later, I enter the string $$$ in the document. (If I’m writing code, I’ll enter it as a comment so that the code will still compile.) Then, later, I just use the editor’s Find feature to search for the $$$ to return that spot. When I’m done working with that area of the document, I delete the $$$. It’s also easy to do a multi-file search for “$$$” to find and remove any bookmarks that I might have set and then forgotten to clean up (prior to checking in a set of code changes, for example).

I chose the string “$$$” because it doesn’t tend to appear anywhere else in the types of documents that I work with, so when I go back and search for "$$$" later, my bookmark is the only match. It's also easy to type and easy to remember.

This technique is nice because it can be used in any text editor, regardless of the particular editor’s own convention for accessing bookmarks. As a sort of poor man's bookmark, it can be used even in editors that do not support bookmarking at all.

Tips from TweakUI

Earlier today I was using Microsoft’s TweakUI utility for Windows XP to make some changes to the settings on my new laptop, when I started going through the utility's "Tips" section. I picked up some interesting tricks that can be filed under "things I didn't know Windows could do"! I thought a few of the tips were interesting enough to be called out here, to spread the word about them.

Tip: You can simultaneously select multiple items (running applications) in the Windows Taskbar (at the bottom of the screen) by holding Ctrl and right-clicking them.

There are a couple of interesting uses for this trick:

• Tile 2 or more specific applications

Holding Ctrl, select 2 or more applications on the Taskbar, then right-click one of them. On the context menu that appears, select Tile Horizontally or Tile Vertically to have the applications' windows be positioned side-by-side on the screen, filling all of the screen's entire viewable area.

• Close 2 or more applications at once

As above, select the Taskbar buttons for 2 or more applications and right-click to bring up the context menu, and select Close to close all of the applications at once. I haven't played with this a lot yet, but this may be a faster method of closing many applications (right before shutting down a machine, for example) then individually right-clicking the Taskbar button for each app and selecting Close, or clicking the "x" button on each application's window.

Tip: In Internet Explorer's address bar, press Ctrl+Enter to have the browser automatically prepend "www." and append ".com" to the typed address.

I've been using this one for a while now (as I've mentioned previously), but it's enough of a time-saver that it's worth another mention. You can, for example, type google in the Internet Explorer address bar and press Ctrl+Enter to be taken directly to http://www.google.com, instead of having to type out www.google.com. (Credit to Jeremy for originally showing me this!)

This Ctrl+Enter shortcut works in Firefox as well!

Tip: In Internet Explorer, hold Shift while clicking the "Organize Favorites" menu pick to open the Favorites folder in Explorer.

This is a lot nicer than using IE's built-in Organize Favorites dialog -- which is kind of weak from a UI perspective -- which normally gets activated when the "Organize Favorites" menu item is picked.

Tip: In Internet Explorer, hold Shift while scrolling the mouse wheel to go Forward or Back.

You can also go forward/back without using the mouse by using Alt + Left Arrow (back) and Alt + Right Arrow (forward).

(Idle speculation: Are the functionality Alt + Left Arrow and Alt + Right Arrow shortcuts reversed for users of versions of Windows installed with a right-to-left language (as opposed to a left-to-right language like English)?)

You can hold the Ctrl key while scrolling the mouse wheel to increase or decrease the size of the text on the page.

These shortcuts all work in Firefox as well.

Press Win (Windows Key) + L to lock the computer.

This is useful to do when stepping away from your desk at work. (I'm not sure what, if anything, this shortcut does when Windows is configured not to prompt for credentials at startup.)

Thanks to the folks behind TweakUI at Microsoft for these great tips!

Office 2007 Ribbon: A step backwards in keyboard usability?

I've had a few more chances to play with Office 2007 since installing it from MSDN a couple of weeks ago. Although I'm still getting used to it, I like the mouse UI that the new Ribbon interface presents. What I'm having a lot more trouble working with is the keyboard interface.

I'll confine my comments here to Word 2007, which aside from Outlook (which doesn't use the Ribbon in its main window) is the Office 2007 app I've had the chance to use most so far. I'm a big fan of using keyboard shortcuts to execute frequently-used commands in applications, so in my work with Word 2007 so far, I've tried to continue and use the keyboard shortcuts that I'm familiar with from Word 2003. However, although Office 2007 is advertised to support Office 2003 keyboard accelerator sequences, I have run across a couple of instances already where the Word 2003 keyboard accelerators are altered or broken in Word 2007.

Office 2007 also doesn't provide any "forward breadcrumbing" for Office 2003 keyboard accelerator sequences. For example, if I want to do the Office 2003 command "Table | Insert | Row Above", and I know that the 2003 accelerator sequence starts with Alt+a (Table), I (Insert), but then I'm not sure which letter of "Row Above" is the final step of the sequence ("r"? "a"? something else?) then I'm out of luck in Office 2007; Office 2007 shows the keystrokes of the sequence I've typed so far, but provides no feedback regarding the available keystrokes to continue the sequence.

Using a Word 2003 keyboard accelerator sequence in Word 2007

(In Office 2003, the menu would have opened along with my typing so that I'd be able to glance up and see the underlined letter in "Row Above" which is the correct final keystroke for my command. It turns out to be "a" in this case, in case you were wondering.)

So today, I tried to start using (and memorizing) the new keyboard accelerators built into Office 2007. 2007 does provide nice "forward breadcrumbing" for its new keyboard accelerators; when the Alt key is first pressed, the available shortcuts corresponding to each visible Ribbon option are displayed, and new available options continue to be displayed as you progress through the keystroke sequence.

My problem with the new 2007 accelerator sequences is that in general, they don't seem to lend themselves to memorization very well at all. In Office 2007, the accelerator sequence for "Insert Table Row Above" is alt+j, l, a. (Alt+j, l brings up the Layout ribbon section; a does the Insert Above.) There doesn't seem to be an "obvious" mnemonic for this sequence. (I found myself thinking "Justice League America!" for this particular sequence, but I'd hate to try and extend that paradigm to all 2007 accelerator sequences...)

Most 2003 sequences corresponded fairly well to the command you were executing, making them easy to remember. (Alt+e, f for Edit | Find, for example.) Even the 2003 sequence for Table | Insert | Row Above (alt+a, i, a) was pretty good when you remember that alt+a was the accelerator for the Table menu (alt+t being used for the Tools menu).

The "Insert Table Row Above" is actually not too bad as 2007 accelerator sequences go, either. The 2007 accelerator sequence for the basic "Find" operation is Alt+h, z, n, f, d, f -- 6 keystrokes! And not terribly intuitive, the most questionable sequence being "z, n" to open the "Editing" item on the "Home" ribbon.

The Word 2007 Ribbon after pressing Alt+h. "z, n" is the accelerator key sequence for the "Editing" item.

(You can, of course, alternatively use the Ctrl+F keyboard shortcut to bring up the Find dialog, but many commands don't have a simple Ctrl-key shortcut that can be used for quick access.)

Another point about Office 2007 keyboard accelerator sequences is that they will switch the active (visible) section of the Ribbon; so if you were working with the Home section of the Ribbon, and then type the 2007 "Insert Table Row Above" accelerator sequence, the Ribbon switches to make the Layout section visible, and you need to subsequently manually switch the ribbon back to the Home section (either by clicking it with the mouse or with the accelerator sequence alt+h, Esc, Esc) to make the Home icons visible once again.

My (early) overall impression is that the Office 2007 Ribbon is a nice step forward in UI design for novice/intermediate users (who will normally be activating commands by using the mouse, as opposed to the keyboard) and for the activation of seldom-used commands, but it is in some ways a step backwards for "power users" who prefer to activate frequently-used commands via the keyboard.

Ctrl+LeftArrow and Ctrl+RightArrow broken in VS 2005 Watch window

In the Visual Studio 2005 Watch window (where values of variables or expressions can be monitored during a debugging session), while editing a value in the Name field (where the variable/expression to be monitored is defined), support for the Ctrl+LeftArrow and Ctrl+RightArrow keyboard shortcuts isn't implemented properly.

In text-editing applications, the keyboard shortcuts Ctrl+RightArrow and Ctrl+LeftArrow commonly have the functionality of moving the caret (insertion point) to the beginning of the current word or the end of the next word. In the VS 2005 main code window, there is very good support for these keyboard shortcuts: in an identifier with several parts separated by period characters (such as System.Drawing.Rectangle.Empty), the insertion point is moved to before and after each period character on successive uses of the shortcut, making it easy to quickly navigate to either the beginning or the end of each component of the identifier. The insertion point also stops at other common code "punctuation", such as the [ and ] characters.

However, while editing a value in the Watch window, the Ctrl+LeftArrow and Ctrl+RightArrow shortcut behaviors follow a different set of rules. When these shortcuts are used in the Watch window, the insertion point bypasses most common code punctuation characters, and instead stops only at space characters. (A bit of additional testing I did shows that certain punctuation characters such as ? and ! are also treated as stopping points in the Watch window.)

Interestingly, this behavior appears to be a regression from Visual Studio 2003; in VS 2003, a quick test shows that when doing a Ctrl+LeftArrow / Ctrl+RightArrow in the Watch window, the caret does indeed treat a "." character as a stopping point. Possibly this is a result of a rewrite of the Watch window to implement one of the very nice new features introduced in VS 2005: Intellisense being enabled and usable when editing a value in the Watch window.

Firefox Find Next/Prev shortcut keys

Firefox provides pretty nice hotkey support for the "Find Next" / "Find Previous" functionality of its incremental find/search feature. For the "Find Next" feature, several hotkeys are supported:

• Alt + n - Displayed on the Firefox Find Bar
• F3 - Standard in many Windows applications (Visual Studio, Word, notepad.exe, but not IE)
• Ctrl + g (Find again) - Displayed in the Firefox Edit menu; used by a few other apps

For "Find Previous", Alt + p, Shift + F3, and Ctrl + Shift + g are supported, which nicely mirror the "Find Next" shortcuts.

I like this broad hotkey support for these functions; I think the (arguable) inelegance of the redundant hotkeys is outweighted by the usability benefit of having whichever common Find Next hotkey combination that is intuitive to a particular user be supported.

The incremental find feature itself and its benefits have already been covered pretty well by Jeff Atwood -- head over there to read up if you aren't familiar with the feature.

IE7: Microsoft's Ctrl+Tab behavior rationale

Earlier today, Aaron Sauve from Microsoft's Internet Explorer 7 team made an interesting post to the IE Blog covering the IE team's rationale for the various default behaviors in IE7 with respect to multiple tabs.

As of the latest IE7 beta (beta 3), the default behavior when using the Ctrl+Tab keystroke to switch to the next tab (or Ctrl+Shift+Tab to switch to the previous) tab is to define the "next tab" as the tab to the right of the current tab as the tabs are displayed along the top of the IE7 window.

An alternative behavior, available via a checkbox in the Advanced tab of IE7's Internet Options dialog, is to have the Ctrl+Tab switch to the most-recently-used tab instead of the "next" tab. This is how the Alt+Tab application-switch keystroke works in Windows: pressing Alt+Tab once switches you to the application you were using most recently (not the application to the right of the current application's button in the Taskbar).

As I've blogged previously, I feel pretty strongly that the "most recent" tab switching order should be the default behavior for Ctrl+Tab. It's more powerful than the "left to right" behavior, as it can be used to quickly toggle back and forth between any two open tabs.

The reasons that Aaron gives for the "left to right" order being the IE7 default are:

• We value predictability over the more focused compare scenario.
• We want to be consistent with other apps that use tabs throughout the system.

Regarding the predictability issue: Let's go ahead and assume for the moment that the "left to right" behavior is in fact more predictable. However, I would expect that the Ctrl+Tab keystroke would be used most frequently by more experienced users. Less experienced users would probably be most likely to activate a tab by clicking the desired tab with the mouse. Given that keystrokes such as Ctrl+Tab will most often be used by "power users," I would argue that the fact that the "most recent" switching order behavior taking a bit more time to "get the hang of" is a lesser concern.

Regarding the issue of being consistent with the behavior of other applications, I went ahead and briefly tested a few other Microsoft apps that I have on my system. Of the applications I tested, Microsoft Excel was the only application that has a "left to right"-like behavior on a Ctrl+Tab press, in this case to switch between open workbooks. (And even this example is questionable, as Excel displays open workbooks in multiple Taskbar buttons, not in multiple tabs.)

On the other hand, Microsoft Visual Studio 2005 provides an excellent implementation of "most recent" order switching on a Ctrl+Tab press, switching between open windows which are displayed in tabs near the top of the window. Visual Studio even provides an "Alt+Tab"-like window that appears while the operation is in progress showing all of the available open windows that can be switched to.

As I noted in my previous post, the most prominent app that I use currently that by default provides "left-to-right" Ctrl+Tab switching order is actually Firefox! Having a better Ctrl+Tab order by default could be nice differentiator for Microsoft.

Given that "most recent" Ctrl+Tab switching order provides more powerful behavior, and that it will be primarily "power users" using the Ctrl+Tab keystroke, I would encourage Microsoft to reexamine the decision of whether to have the "most recent" behavior checkbox under IE7's advanced options be enabled by default.

A minor formatting nicety in Visual Studio 2005

While working in Visual Studio 2005, I noticed a cool Autoformat-like behavior provided by the IDE.

I was working in a class that had a private class constant declared that I wanted to change to have public instead of private visibility. The original code looked something like: private const int MaxItems = 5; I used the ctrl+rightArrow keyboard shortcut to select a nearby instance of the keyword public, and then hit ctrl+c (Clipboard Copy), so I ended up with "public " (including the trailing space) on the clipboard.

I then double-clicked the instance of the "private" keyword that I wanted to replace to select it, and pressed ctrl+v to do the paste.

After the paste, the result was: public const int MaxItems = 5; This struck me as odd for some reason. After thinking about it briefly, I realized that I should have been left with an extra space after "public", due to the trailing space that was present on the clipboard: public  const int MaxItems = 5;

However, Visual Studio recognized what I was doing, and automatically removed the extra space for me, saving me a press of the Delete key after the paste. I tried pressing ctrl+z (Undo), and Visual Studio restored the removed space; a second ctrl+z press rolled back the Paste operation.

A very minor feature, but also indicative of the great attention to detail that Microsoft has put into the Visual Studio IDE. Pretty nice!