I have become slightly obsessed with the idea of using an iPhone as a bike computer. What follows will be of little interest to anyone except gadget-nerd cyclists.
I have become slightly obsessed with the idea of using an iPhone as a bike computer. What follows will be of little interest to anyone except gadget-nerd cyclists.
Years ago, Apple promoted the Mac as a “digital hub” for media. Today we take for granted that computers can be used as hubs for media.
Two of the numerous points covered in Apple’s recent demo of version 3.0 of the iPhone OS was that Apple was finally giving developers access to the port, as well as unblocking bluetooth. These points have largely gone unremarked, but in the long run, I suspect they’ll be especially significant. I think Apple is positioning the iPhone to be a mobile hub.
Right now, the iPhone/iPod Touch has a sharper display, more processing power, and better input affordances than many of the gadgets that we deal with on a day-to-day basis. I predict that some manufacturers will take note of this and start producing headless products that will only work with an iPhone snapped onto the front to take care of these functions and/or provide new functions. This could be a nice moneyspinner for Apple, because of their “iPod tax” on products marked as compatible, and because it would make the iPhone that much more appealing, thus increasing demand for it. It could also be a profitable niche for manufacturers to exploit, since they could sell a product that is more functional than conventional equivalents but cheaper to build.
What is not clear so far is whether a new port connection can trigger an app on the iPhone. This would be helpful—if not necessary—to create a seamless experience. Ideally one would simply snap one’s phone onto one’s car stereo in order to put it into car-stereo mode—the phone would recognize what it was connected to, and an application would have been registered to automatically launch when that connection is made.
Looks like I’m not the only person to think about this. See iPhone 3.0 As the Accessory to …? and PC 1.0, iPhone 3.0 and the Woz: Everything Old is New Again
Gwen recently got a new Macbook, and I’m thinking mighty hard about getting a new iMac. One controversial feature of both is the glossy screen.
These days, most laptops and many desktop monitors have glossy screens—Apple held the line for a long time, but has gone over to the shiny side (with the exception of the 17″ Macbook Pro, where the anti-glare option costs $50 extra). Glossy screens look great—better than the anti-glare screens—but only when there’s no glare. That’s an environmental condition that is hard to control, especially when out and about with a laptop. In the presence of direct light, the glare from the screen can make the screen image almost invisible, and generates a lot of eyestrain. Add-on anti-glare films do exist, but seem to get negative reviews, and strike me as an imperfect solution.
There is another way, and I’m surprised nobody has tried it yet: museum glass. This is a specialty product that I’ve only seen at framing shops. Its appearance is startling: the glass is just invisible. No glare, no visible matte coating, nothing—the only way you can tell it’s there is by poking at it and getting fingerprints on it. It’s worth going to a framing shop just to check it out. As far as I’m aware, it’s never been used for computer monitors, and I don’t doubt it would be a somewhat spendy upgrade, but it’s one that I suspect many buyers would gladly spring for—I know I would.
I know that the glass on the iMac is removable, with some difficulty. I wonder if it would be possible to get a piece of museum glass cut to fit it.
Alex Payne’s post is ranty and prescriptivist, but there’s a nub of a good point buried in there: “Computers work best with structured data…With an Everything Bucket, you … miss out on opportunities to do interesting things with data”
What Alex Payne means by an “everything bucket” is a notebook-style application that you dump all your random notes, clippings, web links, pictures, etc into. There are a lot of independent software developers making interesting apps that fall in this general category. I don’t use one myself, mostly because I don’t need to manage big piles of notes.
I’ve always gravitated towards structured data—I put my contacts’ info in my address book, my links on delicious, and so on. And this can pay dividends—on a Mac, if you use the Address Book, other apps know where to look for your contact info and can do “interesting things” with it—like sync it to your phone, or check whether incoming e-mail is from someone you know. That’s what Alex Payne means by “interesting things.”
Here’s what’s funny, though: the distinction between the everything bucket and structured data may be a false dichotomy. That is to say, there’s still a difference in how you would get to the endpoint, but you’re still getting to the same endpoint of being able to do interesting things with your data. Those two paths are what Mark Pilgrim referred to as million-dollar markup vs milllion-dollar search.
Macs today (and also about ten years ago, right before the switch to OS X) come with “data detectors,” which will notice when a chunk of unstructured text contains something that looks like, say, a date, and will offer to create an iCal entry based on it.
Long before that, Simson Garfinkel wrote an app called SBook that looks like an everything bucket, but also attempts to do interesting things with your data. This is pretty much limited to contacts and related notes, but the idea is there.
Google searches can recognize mathematical formulas to give the results, personal names to give their contact details, musical groups to give their discographies, and so on.
If the software is smart enough—perhaps with a little coaxing from a person—to recognize the structure into which a chunk of data might fit, it shouldn’t really matter whether everything gets tossed into an everything bucket or meticulously sorted into multifaceted, hierarchical, schematized structures. The tools aren’t quite there yet, but there’s no technical reason it wouldn’t work.
Right now, though, it doesn’t work, and the benefits of those interesting things outweigh whatever cognitive load is associated with context-switching between different containers for different kinds of data.
@brandelune do not like omegaT. really only works with plain text. ugly. burdened w/ typical java on mac shortcomings. not customizable.
That barely begins to cover what I don’t like about OmegaT. I’ve been thinking about what I would like in a translation tool for a while now. My desires break down into two categories: the translation-memory engine, and the environment presented to the translator.
I’ve been looking for a good job-tracking and invoicing program for a long time. I’ve looked at just about everything, and nothing suits my particular needs. My needs are a little different—almost none of my work is billed by time but piecework instead (support for this kind of thing is often an afterthought) and I need support for multiple currencies (this is rare).
I’ve tried using Apple’s Numbers spreadsheet app. Spreadsheets in general have one big thing in their favor: they impose no assumptions on you. The flipside of that is that you have to build everything from scratch. There are a few aspects of job tracking where you’d prefer for your program to have made those assumptions for you. A bigger problem I had with Numbers in particular is that it corrupted my job log spreadsheet, which is a colossal PITA. A more philosophical problem is that spreadsheets are basically flat-file databases, and a proper job tracker really needs a relational database behind it.
Watching Gwen figure her work on a letterpress printing project was a lesson in how very different the job-tracking requirements for two solo freelancers can be. Ideally, one app would have the flexibility to meet these different needs. I’ve been giving the subject some thought, and what follows is my attempt to crystallize them.
Check out the two screenshots crops above. Observe that in each, one instance of the word has been flagged as misspelled, and the other has not.
I ran into this problem while working on a translation job. The client had instructed me to overtype an existing Japanese document in order to preserve the formatting. After nosing around for a minute, I discovered that the upper line was marked as US English, and the lower line was marked as UK English (I prefer the UK spelling in this case). Not sure how those language settings got into a Japanese document.
iTunes is overloaded.
iTunes first came out in 2001. At the time, you could use it to rip CDs, burn CDs, play ripped files, and organize those files. You could also use it to copy files to an MP3 player (the iPod didn’t exist at that time).
The personal computing landscape has changed a lot since then, and so has iTunes. It’s being called on to do a lot more.
I’ve said before that the Mac works best when you “drink Apple’s kool-aid,” that is, organize your contacts in Apple’s address book, your appointments in iCal, etc, because these apps act as a front-end to databases that other apps can easily tap into. The same goes for iTunes: Apple nudges you into using it to organize not only your music, but also your video files, and the iTunes database becomes almost like a parallel file system for media files. iPhoto is the manager for, well, photos.
When I first got an iPod a couple years ago, it seemed a bit odd that I could sync my contacts and calendars to it—through iTunes. While it makes sense to manage one’s iPod through iTunes, there was already a subliminal itch of cognitive dissonance.
With the iPhone, that cognitive dissonance is breaking out into a visible rash. The media types that it manages now includes applications for the iPhone. iPhoto is the mechanism for selecting photos to copy to the iPhone, and either it or Image Capture is used to download photos taken with the iPhone’s camera. Curiously, there’s no way to get photos off the iPhone within iTunes; this feels like an oversight, or perhaps someone in Apple was feeling a bit of that itch as well, and felt unwilling to load up iTunes with another function even further from its central purpose.
While I’m not aware of any yet, at some point there will be apps from independent developers that need to exchange files between the desktop and the iPhone other than those handled by iTunes—it’s easy to imagine word-processing files, PDFs, presentation decks, etc, being copied back and forth. It’s not clear how that will happen. It could all happen via the Internet, although that would be indirect both physically and in terms of the user’s experience. For large files, it would be annoying, and for people without unlimited-data plans, potentially expensive. Apple does offer programmers a bundle of functions called “sync services,” but this requires the desktop application be written to support syncing in the first place. For a lot of the file transfers I envision, syncing wouldn’t be the appropriate mechanism. There’s not even a way to get plain text files from Apple’s own Notes app off the iPhone. It’s widely speculated that cut and paste are absent from the iPhone because Apple hasn’t figured out a good interface for it. I suspect it’s the same thing here: they haven’t figured out a good, general mechanism for moving files between iPhone and desktop.
At some point, Apple is going to have to re-think the division of labor in its marquee apps, to separate organizing files from manipulating or playing them.
I don’t expect to do a lot of Japanese text entry on my iPhone, but I’m glad that I have the option, and I’ve been enjoying playing around with that feature.
Any Japanese text-entry function is necessarily more complex than an English one. In English, we pretty much have a one-to-one mapping between the key struck and the letter produced. Occasionally we need to insert åçcéñted characters, but the additional work is minimal. In Japanese, the most common method of input on computers is to type phonetically on a QWERTY keyboard, which produces syllabic characters (hiragana) on-screen—type k-u to get the kana く, which is pronounced ku; after you’ve typed in a phrase or sentence, you hit the “convert” key (normally the space bar), and software guesses what kanji you might want to use, based on straight dictionary equivalents, your historical input, and some grammar parsing. So for the Japanese for “International,” you would type k-o-k-u-s-a-i; initially this would appear on-screen as こくさい, and then after hitting the convert key, you would see 国際 as an option. Now, that’s not the only word in Japanese with that pronunciation—the word for “government bond” sounds exactly the same and would be typed the same on a keyboard. To access that, you’d go through the same process, and after 国際 appeared on-screen, you’d hit the convert key again to get its next guess, which would be 国債, the correct pair of kanji. Sometimes there will be more candidates, in which case a floating menu will appear on-screen.
The first exposure most English speakers have had to the problem of producing more characters than your input device has keys has come with cellphones. T9 input on keypad is a good analogue to Japanese input on QWERTY: you type keys that each represent three letters, and when you hit the space key, T9 looks up the words you might have meant, showing a floating menu.
The iPhone, of course, uses a virtual QWERTY keyboard for English input, which is pretty good, especially considering the lack of tactile feedback and tiny keys. It guesses what word you might be trying to type based on adjacent keys. It does not (as far as I can tell) give multiple options, and isn’t very aggressive about suggesting finished words based on incomplete words. For English, at least, I’m guessing Apple decided that multiple candidates for a given input are too confusing. In general, the trend for heavy English text input on mobile devices seems to be towards small QWERTY keyboards, despite the facility some people have with T9. I’m wondering how many people are put off by the multiple-candidate aspect of T9, and if that’s why Apple omitted that aspect, or if it’s simply that not enough English-speakers are accustomed to dealing with multiple candidates.
Japanese input on the iPhone is different. It is aggressive about suggesting complete words and phrases. It does show multiple options (which is necessary in Japanese, and which Japanese users are accustomed to). In fact, it suggests kanji-converted phrases based on incomplete, incorrect kana input. Here’s an example based on the above:
Here, I typed k-o-k-u-a-a-i (note the intentional typo), which appears as こくああい. It shows a bunch of candidates, including the corrected and converted 国際, a logical alternative 国内, and some much longer ones, like 国際通貨基金—the International Monetary Fund. Since it has more candidates than it has room to display, it shows a little → which takes you to an expanded candidates screen. Just for grins, I will accept 国際通貨基金 as my preferred candidate. Here’s another neat predictive trick: immediately after I select that candidate, it shows sentence-particle candidates like に が, etc.
Let’s follow that arrow and see what other options it shows:
I’m going to select を as my candidate. It immediately shows some verbs as candidates:
Here, 参ります is a verb I used previously, but 見 and 食べ are just common verbs—I’m guessing they’ve been weighted by the input function as likely for use in text messages (the phrase 国際通貨基金を食べ is somewhat unlikely in real life, unless you are Godzilla).
The iPhone also has an interesting kana-input mode, which uses an あかさたな grid with pie menus under each letter for the rest of the vowel-row. It looks like this:
To enter an -a character, just tap it:
To enter a character from a different vowel-line, slide your finger in the appropriate direction on the pie-menu that appears and release:
You can also get at characters from a different vowel-line using that hooked arrow, which iterates through them. I haven’t figured out what that forward arrow is for. It’s usually disabled, and only enabled momentarily after tapping in a new character. Tapping it doesn’t seem to have any effect.
This method offers the same error-forgiveness and predictive power as Japanese via QWERTY. I don’t find it to be faster than QWERTY though, but perhaps that’s just because I’m not used to it.
One thing I haven’t found is a way to edit the text-expansion dictionary directly. This would be very handy. I’m sure there are a few more tricks in store.
Also, a fun trick you can use on your Mac well as on an iPhone to get at special symbols: enter ゆーろ to get €. Same with ぽんど、やじるし、ゆうびん, etc.
Apparently the mysterious forward-arrow breaks you out of iterating through the options under one key, as explained here. Normally if you press あ あ, this would iterate through that vowel-line, and produce い. But if you actually want to produce ああ, you would type あ→あ (Thanks, Manako).
The day after the iPhone 3G was released, I got one. So did Gwen. It’s very nice. I feel like I’ve entered the future. It’s not fair to compare it to any other cellphone I’ve ever used—the difference is almost as stark as the one between the Mac I’m typing this on and a vintage 1983 DOS computer. I played with a friend’s Palm phone recently, and that was perhaps on the order of Windows 3.1 by comparison. Others have spilled gallons of electrons writing about this thing, so I’ll just offer a few random observations.
Out of the box, it is the source of enough wonder and delight to keep you going for quite a while, but the big deal now is that there’s an official path for independent developers to put software on it, which multiplies its value. The fact that these apps will be able to tie into location data, the camera, the web, etc, suggests any number of interesting possibilities. More than any other gadget I’ve played with in a long time, the iPhone seems full of promise and potential—and not just through software. Having a nice screen, good interface, reasonably powerful processor, and interesting ancillary functions suggests all kinds of hardware hookups to me. Two that I would really like to see:
One of the glaring problems everyone mentions with the iPhone is the lack of cut-and-paste. This is a problem, but another one that sticks out for me is the lack of a keystroke expander. There’s already predictive text input built in, so this wouldn’t be a new feature–there just needs to be a front end to the predictive-text library so that users can set up explicit associations between phrases and triggers. If any developers out there is listening, I’ve got my credit card ready.
Here’s a little interface quirk with the iPhone: One of the few physical controls on the device is a volume rocker switch. When viewing Youtube videos (which are always presented in landscape view), the rocker is on the bottom, with down-volume to the right, up-volume to the left. Check out this screenshot of what happens when you change volume using the rocker switch:
The volume HUD appears, showing a volume “thermometer” on the bottom. Here’s what’s quirky: as you press the left rocker, the thermometer advances towards the right, and vice versa. This is counter-intuitive. The obvious way to avoid this would be for Youtube videos to be presented 180° rotated from their current position (that is, with the rocker on top), but for whatever reason, they only appear in one orientation. This is an extremely minor issue, but it stands out when the interface generally shows great attention to detail and emphasis on natural interaction.