Things Google speech recognition came up with when I tried to search for “The Lost Bean” (an independent coffee place in Tustin):
After three tries I gave up and searched for something else in the same strip mall. Oddly enough, it had no trouble figuring out Nieuport 17. 😕
So, Twitter blocked access from Twidroyd and UberTwitter today, citing acceptable use policy violations, then classily pushing their own apps. IMO this would be similar to Google blocking Internet Explorer or Firefox from accessing their services, then telling people “oh, you can use Chrome.”
UberMedia has made some changes to appease the Twitter TOS guardians, and expects to be un-blocked soon.
Anyway, onto the accusations:
These violations include, but aren’t limited to, a privacy issue with private Direct Messages longer than 140 characters, trademark infringement, and changing the content of users’ Tweets in order to make money.
This is the most I’ve been able to find. Let’s break it down:
a privacy issue with private Direct Messages longer than 140 characters
“Privacy issue” is a pretty strong accusation (not that it seems to have actually hurt Facebook).
Here’s a thought: Twidroyd has built-in support for TwitLonger, which will let you route a longer message through a third-party service and then post it as a shorter tweet with a link to the full message.
My guess: this was enabled for all outgoing messages instead of just public tweets, including direct messages. This would make the message (a) visible to Twitlonger itself, and (b) potentially visible to anyone who obtained the URL to that message.
trademark infringement
According to UberMedia, they’ve been working on a name change for UberTwitter for the past three weeks. If that’s the case, it sounds like Twitter is just padding the accusations.
changing the content of users’ Tweets in order to make money
This is a serious accusation, if true. The whole purpose of a communication platform is for one person to convey a message to another person. If that message is altered in transit, it undermines the whole purpose.
But here’s the question: What do they mean by content? Do they mean the exact characters typed in? Do they mean the words? If Twidroyd shortens a URL so that it fits in 140 characters, does that count as changing the content? How about that twitlonger support?
If Twidroyd or UberTwitter prefers a particular URL shortener in exchange for money (just as desktop web browsers prefer a particular search engine), does that count as “changing the content of users’ Tweets in order to make money?”
Isn’t that essentially what Twitter plans to do by forcing all URLs (even those already shortened) through its t.co URL shortener in order to collect data which it can then…*gasp*…monetize?
Edit: And just as I finish the post, I find a post explaining exactly what the issues were. I was right about the privacy issue, though it was with tmi.me, not twitlonger.
As for changing content, the claim was that UberCurrent (the third app whose name I kept forgetting) was changing affiliate links to point to their own affiliate links instead of the author’s. UberMedia says that they “don’t currently do this,” implying that they may have at some time in the past, or may have been considering it. In any case, that’s a jerky thing to do, if not quite as severe as altering the meaning of a message. I remember a Firefox extension that would let you raise funds for an organization by changing Amazon links to use their affiliate links (eventually discontinued due to Amazon TOS violation), but I think even that made a point of not altering existing affiliate links.
Anyway, It’s a good thing they’re using the Android and Blackberry markets. I expect I’ll see an updated Twidroyd later today (or whenever it is that the phone checks for new apps). From what I’ve heard about the iPhone iOs App Store, it could take as much as a week to get the fixed version approved and out in the hands of its users.
Maybe “Sent from my iPhone/Droid/whatever” is worth including…as a spelling disclaimer. (Sent from my G2)
I’ve never been a fan of actually using GPS navigation. Sure, I’ve always thought it was insanely cool that it was possible, I just didn’t want to use it myself. For unfamiliar destinations I generally prefer researching a route first, and for familiar ones I generally prefer just relying on my local knowledge. But I’ve found something that I do like using it for: Traffic.
I recently started a new job, exchanging a fairly short commute for a ~40-mile trek across the Los Angeles freeway system. Under ideal conditions, it’s about 45 minutes. When the freeways are bogged down (i.e. when I’m actually going to be driving), it can take an hour and a half or more.
When I landed the job, I replaced my phone with a G2. It’s a heck of a lot faster than my old phone, plus it can handle newer software…like Google’s turn-by-turn navigation app for Android. After trying a couple of different routes the first few days, I tried it out…and discovered that it factors in live traffic data when calculating the remaining time.
The upshot: I can walk out the door, start up the app, and figure out which of three main routes will get me there fastest. (Well, least slowly, anyway.)
Of course, it’s not perfect. It’s based on traffic now, and over the course of a predicted hour-plus, the route could easily get more congested. That’s not even counting potential accidents. It does seem to update frequently, though, and knowing I’ve avoided a 100-minute drive in favor of 70 minutes really outweighs the annoyance of a mechanical voice telling me how to get to the freeway from home.
I do have to remember not to rely on it too heavily at the end of the trip, though. I left it on by mistake after selecting my route to the LA Convention Center for Adobe MAX this morning, and instead of turning it off, I let it direct me straight past the parking garage.
Oops.
A few years ago, I tried to give some of my most-used websites a nice, clean look on mobile browsers by adding a stylesheeet with the “handheld” type. Then the iPhone came out and ignored them, and everyone copied that behavior, making it useless.
Somewhere along the line, I revisited the same CSS techniques, but used the “max-width” media query to change the layout on smaller screens. This seemed even better in the long run, since screen size matters more than whether a device is a desktop computer or a handheld computer. (The iPad was nothing but a long-standing rumor in those days, but demonstrates this clearly.)
The raw screenshots (click to view) are slightly larger, but since mobile devices often have denser screens, if you’re reading this on a desktop, it’s probably about the same physical size.
That worked great on the iPhone, and on the G1, which I updated through Android 1.6. I stopped testing it after a while, and no one commented on it, so I figured it was still working. (Reminder to self: that’s always a mistake.)
Last week I got a G2, which came with Android 2.2. Last night I visited one of my websites, and was presented with this shrunken, unreadable mess…because Android doesn’t actually use the real screen size anymore. It pretends it has a bigger screen so that it can present a desktop-like view and then let the user zoom around. Mobile Firefox does the same thing.
<rant>Why is it that every time I find a clean technique to use the same markup on both desktop and mobile devices, some browser manufacturer decides to bypass it in favor of giving the user a clunky imitation desktop view instead of one optimized for their experience?</rant>
*ahem*
Anyway, it turns out it’s possible to fix this problem with the <meta viewport tag> as shown here:
<meta name="viewport" content="width=device-width">
So I can provide nice, clean small-screen layouts again…after I add extra markup to every single page that uses these stylesheets.
Problem solved!
Well, almost. It fixes the layout…but it also prevents the user from zooming out for quick scrolling, which can be awfully useful on a long page.
Screenshots of the Barry Allen Flash profile, taken using the Android SDK emulator with stock Donut and Froyo images.
