Posts Tagged ‘mac’
The unreasonable effectiveness of mice
July 28th, 2010 at 8:30 pm
I don’t want to turn this into an input devices blog, but Andy Ihnatko’s post on the Magic Trackpad—which, curiously, didn’t show up in my RSS reader until this morning—got me thinking. I still don’t think the Magic Trackpad is right for me (see this discussion), but he does identify an interesting niche for it. And I started wondering why I feel certain I—and most other people—will be sticking with a mouse.
Here’s the key paragraph in Andy’s post:
AppleTV just got realllllllllly interesting. Existing AppleTVs — the one Apple product you’ve forgotten about, the one that sits at the back of the class and never raises its hand — are MacOS devices. They’re controlled via IR remotes and thus they require line-of-site between the device and the operator. With the Magic Trackpad in the product lineup, Apple could completely reinvent the AppleTV as a device that hides somewhere behind your TV, runs a new flavor of iOS, and ships with a Magic Trackpad instead of a clickybutton remote.
A Magic Trackpad—small(ish), wireless, and with no need for a surface to sit on—would be a great input device for AppleTV. You’d need to have the Tap to Click feature turned on because normal clicking is done by depressing the trackpad’s feet, which wouldn’t work if you’re on the couch or sitting in your recliner.1
I’m skeptical that the next AppleTV will be an iOS device, though. I know this is a popular rumor, but I don’t see it. Apple’s stated roadmap for iOS is to unify it over the 4.x series, eventually getting the iPhone, iPod Touch, and iPad all running the same version. Making an iOS-powered AppleTV would throw a monkey wrench into that plan, because it would require an onscreen pointer. Current iOS devices don’t need a pointer because your finger is right there touching the screen. When you’re operating a TV, and your finger is on a trackpad on the other side of the room, you need to see something on the screen that mimics the motion of your finger. I don’t believe Apple wants to put a pointer in iOS.
Regardless of the underlying operating system, with the right UI software, a trackpad would be a great TV input device.
So why don’t I think a trackpad will be great computer input device? I can’t quite put my (ahem) finger on it, but I think it has something to do with levels of abstraction.
When the Mac first came out, much was made of the notion that you used the mouse to manipulate items in your computer directly. This wasn’t true, of course, but it did make you feel closer to the machine because your previous computer work had been mediated through a keyboard,2 typing in cryptic commands. The mouse was, in fact, just another type of mediation, an abstraction. You were moving this plastic brick around on your desk to get an arrow to move around on the screen.
Despite the abstraction, there was something very right about the mouse. In a short time, mice were a common sight. Even before Windows was usable,3 people were using mice with character-based DOS shells like Norton Commander. Sometime in the early 90s, it became unthinkable for a desktop personal computer to ship without a mouse.
Other pointer devices have come and gone, but the mouse has stayed around in basically the same form it started with over a quarter of a century ago. Switching from mechanical to optical encoding was a big improvement in reliability, but it didn’t change how you used the mouse. The proliferation of buttons and the addition of a scrollwheel, no matter how successful they may have been, were really just tweaks.
Manufacturers have tried to come up with something better than a mouse. Graphics tablets have had their niche among artists and designers for years, but if they were going to spread to the general user, they would have done so by now. Laptop computers have seen the most experimentation with mouse substitutes, for the obvious reason that it’s really hard to use a mouse on your lap. Everyone seems to have settled on the trackpad as the best laptop pointer device—and it is much better than what came before—but most people still prefer to use a mouse when they can.
If you believe that removing layers of abstraction between the computer and the user makes for a better interface, you would think the trackpad would come out ahead of the mouse. With a trackpad, your finger is moving the onscreen pointer; the motion isn’t being mediated through a plastic brick. Why, then, the continued success of mice? Why isn’t Logitech in the trackpad business?
I think the problem with the trackpad is that it falls into a sort of uncanny valley between the touchscreen and the mouse.
With a well-made touchscreen, the behavior is almost physical. You touch the items and move them around; you pinch and pull to resize. In every case, you see your fingers right on the thing being manipulated, and it seems natural.
With a mouse, your hand is off to the side moving an object around on your desk to change things up on the screen—the whole business is more abstract. But somehow, the unrealistic motion of your hand matches up with the fact that the effect it’s having is a foot or two away. I can’t say that this feels natural, but it does feel right.
The trackpad uses the touchscreen’s natural finger movements, but has them tied to a screen some distance away. It works OK—I’m using a trackpad right now, and it’s just fine—but its mixture of the real and the abstract isn’t quite as good as the mouse’s more fully abstract behavior.
I don’t want to come off as a trackpad hater; I’m not. At the moment, it’s the best pointer device we have for laptops. I just don’t see it replacing the mouse on my desktop.
-
Prepositions are funny, aren’t they? If I had written in the couch or on the recliner, you’d have done a double-take. With a chair, you can sit in it or on it—in is more common, but on is common enough—but when that chair turns into a recliner, you have to be in it. ↩
-
Yes there were mice before the Mac, but they weren’t in wide use. Joysticks were also used to move onscreen pointers around, but they didn’t have the direct feel of mice. ↩
-
That joke is too easy; don’t bother. ↩
Markdown footnotes bundle for TextMate
July 28th, 2010 at 8:11 am
There was a recent discussion on the TextMate mailing list about automating the creation of TextMate footnotes. Stephan Hugel, who started the discussion, likes having his footnote text at the bottom of the document and wanted some command/snippet/macro system that would do most of the fiddle work for him. I pointed out my Markdown reference link system for TextMate and suggested how it could be modified to do what he wanted. You can read about it by following the discussion thread. I won’t recapitulate it here, because that particular way of doing footnotes isn’t to my taste. I do, however, have a couple of footnote-making automations that I’d like to share.
First, you should recognize that footnotes aren’t a part of the official Gruber Markdown. They are, however, included in several Markdown variants/extensions, including Michel Fortin’s PHP Markdown Extra and Fletcher Penney’s MultiMarkdown.
Here’s an example of footnote syntax:
* First, it's kind of backwards. You do the footnote text first,
then set the position of the marker. I find this perfectly natural,
but you may think it's weird.
* Second, it replaces whatever was on your clipboard with the
marker. This doesn't bother me because I use [Jumpcut][8], a
[multi-clipboard tool][9] that saves the last 40 text clippings.
If you don't use a utility like Jumpcut, you'll find this
behavior *really* annoying.[^multiclip]
[^multiclip]: But you really should be using a multi-clipboard tool.
It makes working with text so much easier.
The footnote marker is placed where the [^marker] is, and the text of the footnote is the paragraph that starts with [^marker]:. The footnote text can go anywhere in the document; it can even be intermixed with reference-style links down at the bottom, although in my opinion that makes for an unreadable mess. I tend to put my footnote text just after the paragraph with the corresponding marker.
To semi-automate the insertion of footnotes, I use a snippet and a macro, which you can download in this zipped TextMate bundle. The source code of the snippet is just
[^${1:marker}]$0: ${2:Footnote}
The marker (default value: marker) is the first tab stop and the footnote text (default value: Footnote) is the second. Tabbing a third time puts the cursor at the end bracket of the marker, which is where the macro expects to start. The Tab Trigger for this snippet is, in a nod to LaTeX, fn.
The macro is similarly trivial. It selects the text from the current position (just after the marker’s end bracket if you invoke it right after the snippet) to the beginning of the line (just before the marker’s start bracket), copies it to the clipboard, and sets the cursor at the beginning of the footnote paragraph. The marker is now on the clipboard, ready to be pasted wherever I want to put it. The Key Equivalent for this macro is ⌃⌥⌘F.
You should note two things about this method of doing footnotes:
- First, it’s kind of backwards. You do the footnote text first, then set the position of the marker. I find this perfectly natural, but you may think it’s weird.
- Second, it replaces whatever was on your clipboard with the marker. This doesn’t bother me because I use Jumpcut, a multi-clipboard tool that saves the last 40 text clippings. If you don’t use a utility like Jumpcut, you’ll find the loss of your previous clipboard really annoying.1
If these caveats don’t bother you, install the Markdown Footnotes bundle and give it a try. If you do a lot of footnotes, it can save you some time.
-
But you really should be using a multi-clipboard tool. It makes working with text so much easier. ↩
Magic feet?
July 27th, 2010 at 10:10 pm
From Dan Frakes’s article on the Magic Trackpad (via Daring Fireball):
My favorite Magic Trackpad design feature? While the Magic Trackpad may not appear to support physical “clicking,” it indeed does: The two nubby, rubber feet on the bottom, along the front edge, actually have buttons built into them. When you press down on the trackpad surface, the feet “click,” giving you the same tactile sensation as you get with Apple’s current MacBook trackpads. Very clever, and a welcome Apple touch—no pun intended—for those who hate touch-tapping.
Putting the sensor in the feet is indeed clever, but it’s not an “Apple touch.” As explained in excruciating length in this post, my several-years-old Conair bathroom scale has not just simple click sensors, but true force gauges in its feet. All four of them.
And it comes with its own display, runs for years on a couple of button batteries, and probably cost less than $69 back whenever the hell it was we bought it.
Magic, Inc.
July 27th, 2010 at 6:06 pm
I know it’s wrong to judge a product before using it, but I can’t help thinking that Apple’s new Magic Trackpad is a cool accessory that I will be avoiding like the plague.
In the first place, I don’t understand the appeal of a trackpad on a desktop computer. On laptops, they’re certainly they’re an improvement over the old PowerBook scrollball and the ThinkPad clitoris, but they’re not nearly as good—not nearly as tactile—as a well-designed mouse. Whenever I need to do a lot of work on my old iBook, I bring out a mouse and plug it in. It’s just better than a trackpad.1
The rollout of the Magic Trackpad and my painful experience with the Magic Mouse last year lead me to wonder whether Apple will ever again make a pointer device that I can live with. I actually like the Apple (née Mighty) Mouse,2 but I’m afraid its days are numbered as Apple slowly turns its entire product line iPhonesque.3
-
Yes, I know the newer trackpads are much more capable than the one on my iBook G4. I’ve tried the new ones; they’re still not as good as a mouse. The Touch interface is great when your fingers are on the screen with the objects you’re manipulating—not so good when they’re two feet away. ↩
-
I know most people hate the Apple Mouse because its scrollball attracts debris and is a pain in the ass to clean. There’s no question but that Apple should have made it cleanable. Still, I find it a pleasure to use and, before the Magic Mouse was introduced, had some hope that Apple would fix its problems in a later revision. Now it’s the redheaded stepchild of the Apple lineup and will probably be dropped as the company goes all Touch. ↩
-
Despite my tendency to wander off on tangents, I believe this is the very first post in which my footnotes are as long as than the body text. ↩
Updated Flickr URL script for TextExpander
July 26th, 2010 at 11:50 am
Last week I wrote a little Python script that printed out the URL of a Flickr image when that image’s page is currently showing in Safari. I used that script with TextExpander to automatically type out the URL when I needed it without having to dig in a couple of levels to get the image URL by hand. I’ve since improved the script to be more flexible and easier to modify.
I won’t go through my motivation for writing the script; it’s laid out in last week’s post. I’ll just point out that there were two problems with the script as it was originally written:
- “Special” strings, like URLs, were buried in the code instead of defined at the beginning.
- It worked only when the current page in Safari was the main page for the photo. It failed when the current page was, for example, one of the “sized” pages for the image.
Both of these problems have been fixed with this new version.
1: #!/usr/bin/python
2:
3: import appscript
4: import re
5: import sys
6: from urllib import urlopen
7:
8: # The basic URL format for photos.
9: baseURL = 'http://www.flickr.com/photos/%s/%s/'
10:
11: # The regex for extracting user and photo info.
12: infoRE = r'flickr\.com/photos/(.*)/(\d+)/?'
13:
14: # The various image URL suffixes.
15: suffixes = {'master': '_m.jpg',
16: 'original': '_o_d.jpg',
17: 'large': '_b_d.jpg',
18: 'medium640': '_z_d.jpg',
19: 'medium500': '_d.jpg',
20: 'small': '_m_d.jpg',
21: 'thumbnail': '_t_d.jpg',
22: 'square': '_s_d.jpg'}
23:
24: # Get the URL of the frontmost Safari tab and extract the photo info.
25: thisURL = appscript.app('Safari').documents[0].URL.get()
26: info = re.findall(infoRE, thisURL)
27:
28: # Download the main page for that photo and get its "master URL."
29: # Use the master to generate the URL for the medium500 image
30: # and print it.
31: try:
32: user = info[0][0]
33: id = info[0][1]
34: pageURL = baseURL % (user, id)
35: html = urlopen(pageURL).read()
36: imageURL = re.search(r'<link\s+rel="image_src"\s+href="([^"]+)"', html).group(1)
37: imageURL = imageURL.replace(suffixes['master'], suffixes['medium500'])
38: sys.stdout.write(imageURL)
39:
40: # Print an error message if there's any problem.
41: except:
42: sys.stdout.write("wrongpagewrongpage")
Lines 8-22 pull all the special strings out to the top of the code, where they can be seen (and adjusted if Flickr changes its URL format). The new suffixes dictionary included all the size possibilities, so it would be a simple matter to change the code to return, say, the Thumbnail URL; just change medium500 in Line 37 to thumbnail.
In the previous version of this script, the URL of the current Safari page would be downloaded and searched for the special <link rel="image_src" > tag. The problem with this was that some Flickr image pages—in particular, the pages associated with “sized” images—didn’t have this tag, so the search would fail. This version defines the baseURL for the photo, and downloads it instead of the current Safari page, insuring that the <link> tag will be present.
Errors are now handled through exceptions instead of an if/else test. This allows us to handle a multitude of errors with a single error message.
As before, I have this script saved as a Shell Script in TextExpander and tied to an abbreviation of ;500. Now it’s a snap to enter Flickr image URLs wherever I need them.
Safari text rendering problem
June 28th, 2010 at 1:15 pm
I’ve been noticing recently that text is sometimes rendering poorly in Safari. At first, I thought it was deteriorating eyesight. Then I thought it was the Retinal display on my iPhone causing me to see pixels on every other screen. but now I’m sure there’s something else going on.
The problem seems most common when I’m reading RSS feeds in Google Reader. Reader uses a smaller font than I like, so I bump up the font size one step with ⌘+. Here’s a snippet of a post1 that rendered poorly earlier today but then rendered well when I returned to it later. The screenshot starts with the bad version and shifts to the good version when you roll your mouse over it.
Do you see the difference? Look in particular at the word “enactment” near the center of the image and at the two links. Once you see the difference in those places, you’ll start seeing it everywhere. Everything is just a little more pixelly in the bad version. It doesn’t seem like much, but it wears on you when reading long passages.
I don’t know what’s going on here. Obviously, the text isn’t always rendered poorly—otherwise, I wouldn’t have been able to get the “good” screenshot—but it happens often enough to be noticeable.
I haven’t noticed this in any other program, just Safari. I can’t say it definitely started with the recent upgrade to Safari 5.0, but that’s my suspicion.
Update 6/29/10
My suspicion was wrong.
I’m pretty sure now the problem was an extra copy of Arial. I went into Font Book and saw the little yellow caution signs by all the Microsoft core fonts, indicating duplicate copies.
I used the Select Duplicated Fonts and Resolve Duplicates commands in the Edit menu, and the fuzzy text problem hasn’t arisen since.
Honestly, I’m sure I’ve removed duplicates of these fonts before; I don’t understand why they came back.
This was obviously a system-level problem and had nothing to do with Safari per se. Safari was the only application I saw it in because it’s the only application that uses Arial or the other MS core fonts.
Update 6/29/10
My belief that my suspicion was wrong…was wrong.
The duplicate fonts are gone, but the crappy looking text is back. Sometimes reloading the page fixes the problem, sometimes it doesn’t. I’m confused and annoyed.
-
From Lawyers Guns and Money. ↩