Posts from January 2010
- All (10)
- Entries (3)
- Links (7)
- Photos (0)
Future Shock
Fraser Speirs argues that most of the anti-iPad sentiment is “Future Shock”:
For years we’ve all held to the belief that computing had to be made simpler for the ‘average person’. I find it difficult to come to any conclusion other than that we have totally failed in this effort.
Secretly, I suspect, we technologists quite liked the idea that Normals would be dependent on us for our technological shamanism. Those incantations that only we can perform to heal their computers, those oracular proclamations that we make over the future and the blessings we bestow on purchasing choices.
Steven Frank's Thoughts on the Future of Computing
He nails it. While an iPad wouldn’t be my computer of choice (at least in its current form), I could certainly see it being the perfect device for the less tech-savvy audience. This could be the perfect product for my grandparents, for instance.
Also of note was one of Steven’s proposed improvements for the iPhone/iPad platform:
A way of sharing data between applications. Something like the clipboard, but bigger. This is not a filesystem, but a way of saying “bring this data object from this app to this app”. I’ve made this painting in my painting app, and now I want to bring it over here to crop it and apply filters.
I really like how Android has approached this problem. If, as a developer, you want to create image editing software, you don’t have to know how to access images from other applications, but rather, you just ask the OS for a list of all files that match a certain type (an image, a video, etc.). Then, the OS knows which programs store files of that type and it returns a nice, condensed list of all of them. The user never has to worry about exactly which app stored the image, because it’s all taken care of for him.
NASA's Budget
The average American thinks NASA’s spends 25% of the total U.S. budget. It’s actually 0.58%.
iPad Keyboard Fragmentation
As usual, I enjoyed reading John Gruber’s musings on the iPad. I was intrigued most, however, by his thoughts on the iPad’s support for hardware keyboards:
Having used the hardware keyboard yesterday, though, it is clearly a secondary form of input. You cannot even vaguely drive the iPad interface by keyboard alone. […] There are some glaring holes. For example, in iPad Mail, when you start typing in the To: field to address a message, and the iPhone-style autocomplete suggestion list appears under the field, you cannot select from it using the keyboard. You have to touch the screen. […] It just seems like it’s not finished yet.
What struck me as interesting is how similar this is to Android development’s biggest drawback: hardware fragmentation. Due to the vast array of Android devices, app developers have to consciously design their apps to support several different input methods. This may seem fairly trivial, but it is actually a fairly significant problem, especially for games and more complex UIs. In the Android Market, some games and applications just don’t work without a hardware keyboard, likely because the app developer didn’t take the time to consider touchscreen input. Apple seems to now be encountering this problem as well.
Maybe John’s right, and this is a rough edge that will be smoothed over when the device launches. But, there’s more to it than just fixing iPad Mail. What about the 140,000 apps in the App Store? They certainly weren’t built with any considerations of keyboard navigation, so the experience is likely to be sub-par, unless the developer has taken the time to support an input method that he or she might not even have access to (assuming he or she doesn’t own an iPad).
If keyboard support is solely intended for text input, as John suggests, a lot of users will be confused. Standard operations, such as tabbing between fields and navigating via arrow keys, are expected behavior when a user is given a keyboard. It would be frustrating to have that taken away. Certainly, Apple could fix this issue by the time the iPad hits the market, but for a platform that preaches ease-of-development due to the uniformity of its hardware, it’ll be interesting to see how it’s handled.
John Gruber's Thoughts on the iPad
I especially liked this bit:
Used to be that to drive a car, you, the driver, needed to operate a clutch pedal and gear shifter and manually change gears for the transmission as you accelerated and decelerated. Then came the automatic transmission. With an automatic, the transmission is entirely abstracted away. The clutch is gone. To go faster, you just press harder on the gas pedal.
That’s where Apple is taking computing. A car with an automatic transmission still shifts gears; the driver just doesn’t need to know about it. A computer running iPhone OS still has a hierarchical file system; the user just never sees it.
Three Weeks with Swype
Roughly three weeks ago, I stumbled across the Swype for Android preview. My first impressions were very positive, and over the last three weeks, I’ve been using Swype exclusively on my Droid. If you’re not familiar with Swype, it’s a new method of typing on a touchscreen device, from the inventor of T9. Instead of tapping out each letter, you just drag your finger across the keyboard, hitting each of the letters in the word in sequence. I recorded a short video showing its basic features:
What I Liked
What really surprised me about Swype was how quickly I was able to get the hang of it. When I watched demo videos, it seemed like it was overly-complicated, but once I used it myself, I couldn’t believe how simple it was. For some of the less intuitive features (such as capitalization, which requires you swipe above the keyboard), I had to run through the built-in tutorial, but after that, I could swipe very easily. One big perk with Swype is that it’s actually pretty easy to use without looking, once you get the hang of it. I found that I could type reasonably well without ever looking at my fingers, something I would have no chance of doing with the standard keyboard.
Drawbacks
My biggest gripe with Swype is it’s just nowhere near as polished as the built-in keyboard. For starters, it’s much more difficult to access symbols, and numbers are laid out pretty strangely. Also, there’s a complete lack on auto-completion for text fields that support it. For instance, if you’re typing the name of a contact in landscape view, the regular Android keyboard will have suggestions below the field that will allow you to select the person without typing their whole name. Swype does not seem to support this at all, which is really pretty annoying. In addition, it’s difficult to type out words normally, if they do not exist in the Swype dictionary. When tapping out letters, Swype tends to interpret your taps as swipes, adding unnecessary spaces between letters. Once you type an unknown word the first time, however, you never have to do it again, because it gets added to the dictionary, which is pretty nice.
In addition, I’ve found that the sensitivity of the keyboard can be a little strange when swiping quickly. Many times, it won’t recognize that you’ve stopped a word and started a new one (which is indicated by lifting your finger up), so it won’t recognize what you’re trying to input at all. In the options panel, there are ways to adjust the sensitivity, but I’d rather these settings were hidden away from users, because it seems like a bit of a cop-out. Swype should instead learn how you type, adjusting its algorithm as necessary.
Conclusions
While there certainly are some issues with the Swype build I used for this review, pretty much all of problems are fixable, and I’m excited to see what the final version turns out to be. They’ve got a really great concept that, with tweaking, could become the best way to input text on a touchscreen mobile device, especially for those who aren’t very adept with traditional on-screen keyboards. I’m not sure what Swype’s strategy is going be with regards to pricing: whether it will be a free app, or if you’ll have to pay for it. Personally, if they’re able to fix my issues above, I would be happy to pay $5-6 for it, and maybe even more, because it really is quite incredible. Even if you can type well with the standard keyboard, definitely give Swype a try.
Rendering a web page - step by step
Pretty amazing all of that can happen in under a second.
Four weeks with a Droid
Matt Haughey goes through his thoughts on the Motorola Droid, the Nexus One, and Android in general. Lots of good stuff here, and his thoughts echo a lot of mine. Android as a platform has a whole lot of promise, and I’m really excited to see where out it goes from here.
A Geotagged Vacation
Over the holidays, my family and I took a three-day trip to Chicago, and because I had left my charger for my Canon Powershot G9 at home, I was stuck taking pictures with my Droid’s built-in camera. I thought it would turn out to be a disappointing endeavor, but it actually got me really excited about the future of internet connected cameras.
My least favorite part of photography has always been all of the work afterwards to get it online. I have to take out the SD card, copy the files to my computer, edit them, and then post them to Flickr. When I was taking photos with my Droid in Chicago, I loved how easy it was to instantly post photos online. Using Twidroid, I was able to easily upload photos to yFrog, tweet the link, and have it all geotagged, almost instantly. It allowed me to share what I was doing with my friends as I was doing it, something I could never do with my G9.
The quality of the photos certainly isn’t anywhere near what I could accomplish with a better camera, but that really didn’t bother me too much. As the quality of phone cameras improves, this will become less and less of an issue. Since I had a limited amount of time in the city, I was more concerned with sharing snapshots of where I was (like at the “Bean”) than with creating works of art. On a longer trip, where I have the ability to take my time and set up shots, I’m sure I would want to have a nicer camera along, but for a quick 2.5-day trip to Chicago, my phone worked pretty well.
There are certainly areas where this method of taking photos could improve, however. Like I said before, the quality of the camera is a drawback, but it was one I was willing to accept. Beyond that, I was a little disappointed by the geotagging abilities of Twidroid. If I took a picture of something inside (like the Apollo 8 command module, cool!), the coordinates would be way off, since it couldn’t get a good GPS signal. I would have preferred to be able to pick the Museum of Science and Industry as my location, rather than relying on what the GPS picked out for me. This is something that appears it would be relatively simple to fix. The Google Maps 4 Twidroid source code is available online, so I might try and update it myself to use places (using Google’s local search API or something similar), or at the very least it could allow you to check back into a previous location. I am also hoping Twitter releases more features related to geotagging on their site. Right now, coordinates are only visible through the API, so unless you’re viewing my tweets in a geo-enabled Twitter client, you won’t see my location.
I certainly could use a service such as Brightkite to fix some of the issues above, but I really want to stick to just using Twitter. It’s become clear to me that Brightkite really isn’t pushing the envelope any more as a service, and there really is little incentive to post there. I definitely agree with Colin Devroe that their future should be to act as a Twitter client, rather than as their own community, since I really don’t see them being very successful otherwise.
Clearly, the future is bright for geotagging, and I can’t wait for the day when I can have a high-quality camera in my pocket that allows me to do everything my Droid does on vacation. While I’m not someone who likes broadcasting my location constantly, it’s a nice ability to have while travelling, to both share your trip with others, and to be able to look back at what you did. Hopefully the tools will continue to improve, and they’ll be more and more universal, because I think this is something everyone could enjoy.
The Interpreter
A fascinating look at the language of the Pirahã tribe in Brazil.