For the second time in as many weeks, I was driving north on 85 to the Googleplex, lured by the promise of free food and insight into the Android platform. This event was held by the Silicon Valley Google Technology User Group; I'm not familiar with them, but they seem to be a new group with loose ties to Google proper. Unlike the earlier Campfire session, this was a slightly larger affair, a bit more structured, and felt less under-the-radar.
200 people had registered for the event, and a good chunk of them showed up. We were in the Tunis room in building 43 - a different location from Campfire, but the same place I went about half a year ago for the forum on mobile advertising. Food wasn't as interesting as at the Campfire, and there was no open bar this time around, but it was more of a meal - various kinds of pizzas, lasagnas, and a green salad. The meet and greet lasted from 6 until 7, and we'd been warned by email to arrive early to avoid long security lines, so I had close to an hour to kill before the talk officially started. I got into a nice chat with Julian and Richard, two other attendees who had recently started work on Android. They haven't done a lot of mobile development in the past, so I got to put on my explainer hat for a while... I still hesitate to call myself an "expert," even after three years in the field, but times like this make me amazed at how much more I know now than when I first started this gig. I feel like the more I learn, the more I take that information for granted, and erroneously assume that everyone knows it. Shades of the "Curse of Knowledge" from Made to Stick, I suppose.
There was a round of early introductions that clarified exactly who these people were and how the night would be structured. I realized that the people running the event were not Google employees, but the main speaker was. I'm embarrassed to admit that I am not familiar with him; it sounds like he's a pretty big player in the Java world. Anyways: Dick Wall runs with the Java Posse and is currently working for Google... I THINK he's one of their Developer Advocates, but I could be confused about that, as I will explain below. Bonus: he's English!
The first part of the night was focused on a slideshow presentation Dick Wall gave. After the first five minutes or so I was feeling a bit dejected - I had come to the event hoping to learn more about Android, and so far it seemed to just be re-hashing the official documentation on the Web. After a while, though, I started to perk up as I heard information I hadn't encountered before (or else had forgotten). He ran an interactive talk that was regularly interrupted by questions, and a few rambling declarations, which was both good and bad. It led to some good points being made, but at the same time it would occasionally derail the talk and led to a lot of comments like, "We'll be talking about that soon."
The first big "Aha!" moment I had was with the lifecycle of an Activity, which I thought I totally understood. One thing I just realized a few weeks ago was that multiple Activities can run in the same process. What I didn't know until last night, though, was that an activity's onFreeze method will only be called if it is going away due to another process. For example, if I navigate from a main menu Activity in my app to a Help Activity that is also in my app, I will receive an onPause in my main menu but not an onFreeze. However, if my Help screen is interrupted by an incoming call, then both the onFreeze and the onPause will be called.
The consequence of this is that you only need to bundle up your temporary data if you're moving to another process. This is because Android can silently kill your process when another Activity runs out of resources, and will resume your process when it's ready to be shown again. It's a cool system, and I now understand it better than before. That alone was worth the price of admission. (The event, by the way, was free. Worth the price of gas, I guess.)
One thing I meant to ask but never did: in the above example, would only the Help screen's onFreeze get called? If so, is there any way to capture the current state of the main menu Activity? Unless I misunderstand how this works, only the top-active Activity in your application will be notified that it is in danger of being destroyed.
UPDATE: The above 3 paragraphs are incorrect. See the bottom of this post for details.
I won't rehash the whole talk here - about 80% of it comes from the official documentation, which is much better than I'd be able to produce. I'll just call out a few things that I thought were interesting.
He seemed pretty dismissive of the need for threads. We didn't get too deep into this, but he did say that you generally don't need to make them. This seems in keeping with my experience - stuff like Handlers let you omit many uses for them, and for the long run you'll often want a Service - but it was the most explicit word I've heard yet about threading. I assume you'd still want to spawn threads for network connections and medium-length processing. This is probably another area where we'll be seeing Best Practices come out in the near future.
He confirmed my suspicions about Bundles by saying that they're basically just Maps, with a few changes, and pointed out that you can store Bundles in Bundles. This is something people have commented on before: Android terminology can sometimes be confusing. (He also pointed out that what Android calls a "View" is what most people would call a "Control.")
Some of the early Android hardware will have 3D acceleration hardware. I heard some audible laughs, but was not surprised... it isn't something you see in America, but Japan has had phones with these capabilities for years. If you don't believe me, look for videos of FF Before Crisis (two years old!) and the like. I don't think we'll be seeing killer 3D apps at launch, because they tend to require resources beyond what an individual developer would be able to contribute.
The first big bombshell of the night: XMPP is going away in the next version of the SDK! I was stunned and relieved. Stunned because I know that a lot of people are working on apps for the challenge that rely on XMPP for their data interchange. Relieved because I haven't spent much time at all with it, and so I don't feel I've wasted my efforts there. Still, I can see another backlash coming.
At the end of the talk, Dick demoed a cool little app he wrote called WikiLinks. (I think that was the name... WikiNotes, maybe?) He said it will be made available on Google Code in a few weeks. Anyways, it's a tight-looking simple app that lets you edit pages, scans them to find Wiki links, and lets you follow those links to other pages. The app demonstrated how efficient Android is when working with Intents and Activities. Each time you clicked on a Link, it creates a new Intent and fires it. Every Intent maps to the same Activity - the WikiLink. However, even if you are clicking 40 links in succession and creating all these Intents, during the whole time you're using a single process - Android is re-using its resources while maintaining its open, pluggable interface. It was a cool demonstration that should help alleviate some skepticism over performance.
Speaking of which, the most encouraging thing I heard all night was that performance on the emulator is a good predictor of performance on the device. This is very different from my experience with BREW and J2ME, where applications that run well on the emulator can crawl once you get on the phone. Dick said that, in general, applications will run at least as fast on the phone, and maybe a bit faster... in particular, text input is less laggy on the phone. Anyways, I was delighted to hear this; it's something I've been worrying about.
There was a long run of questions before the break. A few interesting things came out here. First, support for touch was added recently to Android. The current SDK has some controls you can click on. Upcoming SDKs will enhance this support. However, true multitouch like the iPhone is a trickier problem. Dick didn't want to go into specifics, but it sounds like there might be some patent issues or other legal considerations in play.
One of the GTUG folks asked about J2ME support. I often think that questions like this miss the point, but there's a lot of people who understandably are reluctant to surrender years of development work. In the past, some OHA affiliates have expressed an interest in adding this support. The bottom line, though, is that Android will be open-sourced, so if anyone wants J2ME, they can make it.
They cut off the talk and took a break. During this time they ran a nice raffle, using a cool application based on Java FX that looks a lot like Wheel of Lunch. It spun and spun, people came up to claim their swag (Google thermoses, T-shirts, etc.). And - wait for it - I was a winner! My name was the last called, and I took my prize, a black T-shirt. It was labeled "Google Developer Days", which was clearly a lie. It was also labeled "Large", which I also think is a lie, but will need to wear the shirt before making sure.
Afterwards we had breakout sessions. The vast majority of people moved to the front of the room for the Android session with Dick, but other GTUG people ran sessions on other technologies... there was one for Maps, another for Gears, one for Open Social, and possibly more. They introduced Ash, an Android Champion, who will be running the sessions on Android in the future. A Champion is someone who promotes a technology and facilitates learning, and I think is an awesome name. I'll now have to decide whether to come to their monthly meetings for the Android sessions... I kind of doubt I will, but it is tempting.
The breakout was pure Q&A. I tapped out some notes on my iPhone, so I'll dump those in here. Here we go!
The first question was about the backlash against Android and the bad press it's been getting. Dick listened sympathetically. He explained that, more than anything, Google was just surprised by the amount of excitement Android generated, and wasn't prepared to deal with it. In the first 24 hours after the SDK was released, it was downloaded over 10,000 times. A chunk of these started doing serious work and posting on the discussion groups with questions. He said that they had 5 people to handle all of this, and just couldn't keep up. I don't think he meant they had 5 people on the dev team - that seems way too small - so I'm guessing he's referring to the Developer Advocates or other people meant to directly communicate with the community.
The overall response could probably be summed up as, "I feel your pain, but I don't want to apologize." They've been very busy, and they're focused on getting the next version of the SDK out, improving the state of Android, and while they want to help people, they just don't have the resources and it isn't their only priority. This matches my experience on the group - I asked a question about support for hybrid maps a few weeks ago and still haven't gotten a reply. I don't blame the Googlers - hackbod, Dan M, romain guy, and anyone else who chimes in. They always give great answers, and the group is quickly becoming a useful resource to learn about how to use something, or what doesn't work. But there's just a lot more activity on the group than they can keep up with. Dick says that they've been trying to hire more people, but it hasn't been working.
The worst news I heard all night: porting to the new SDK "will be painful." They aren't just fixing bugs and adding features; they're also changing APIs and removing things. I think XMPP is probably going to have a lot of fallout. Dick also specifically mentioned that the Content Provider system is going to be changing a lot. He said that WikiLinks took a few hours to port from Version 3 of the SDK to Version 5, so I'm shuddering at the thought of how long it will take to port a more complex app. That said, he hopes to write a porting guide that will explain how to make this shift.
Once again, his tone was sympathetic without being apologetic. They want to focus on making the SDK as good as they can, even if that means breaking things. After Version 1.0 comes out and the first phones ship, they'll be tamping things down, but up until then, anything should be fair game.
On a related note, he explained a bit more about the status of the challenge, and specifically the controversial decision to extent it. Background: they initially set a deadline of early March, which was heralded as a "firm date." They now have pushed it back to the middle of April to give people more time to submit. A lot of developers feel betrayed: they have devoted a lot of time and energy trying to meet the deadline, and now that Google has yanked it back, their chances of winning will diminish due to the increased number of entries, plus they will need to re-write their applications to make them competitive with whatever the latest version of the SDK ends up being. As Dick explained it, there were a lot of problems with the current version of the SDK, and some developers were frustrated because they couldn't make the apps they wanted to on it. The plan had been to release version 4 in enough time for everyone to switch to it before the deadline. However, they (Google) missed their deadline for version 4. Version 5 will be released in the very near future, and just leaving a few weeks before the deadline wouldn't be enough time for people to take advantage of it. So, they moved it back.
For the record, I'm disappointed in this decision, but it isn't my choice to make... it's Google's money, their contest, and they can do whatever they want. It has certainly not endeared them to the early adopters, however.
Talking generally about the challenge, Dick said that it hasn't exactly gone as planned. On the one hand, it sparked a great deal of interest in Android and got people looking at it, which has been Google's goal all along. On the other hand, the competitive nature of the contest has made people more inclined towards secrecy, less likely to share what they have learned or talked about ideas. If they had it to do over again, they might not have done the challenge at all.
There has been a lot of concern on the groups over the Terms and Conditions for the challenge, which (at least as of this writing) includes some very distressing statements such as "You agree that you will not be entitled to any rights in, or compensation in connection with, any such similar or identical applications and/or ideas." Basically, any member of the OHA is free to take your idea (whether or not you win the contest) and make that exact same application without paying you a dime. Again, there was some concern that people won't submit their apps, instead waiting until phones ship so they can sell them without worrying about "stealing." Dick was actually surprised to hear about this. The one thing he said was, "Google doesn't have a history of screwing people over." This is in keeping with the semi-official responses on the blog, which boil down to "We are running this contest to generate goodwill towards Android, and it would be stupid of us to ruin all that goodwill." He said that, if Google really wanted an app that you wrote, they'd be more likely to hire you than steal your idea. (Good answer!)
Someone asked about development in C++. My impression here has been that it's currently not supported and might possibly be in the future. It turns out that, while that's the official story, the reality is that some people have been getting C++ code to work on Android. The Google team is aware of these efforts, and, unofficially, think it's great. They can't support it, since their hands are full with the official Java SDK, but they aren't going to stop it. Also, the SDK will be getting support for JNI, at which point it will become possible to call C++ code from the Dalvik VM.
Someone asked about distribution. This still hasn't been decided, but Dick mentioned that there had been some talk of doing a vending machine, like for iGoogle gadgets. Google could be a (not the only) clearinghouse: you send your app to Google, Google sells it to people and gives you a cut of the money. This is the first time I've heard that suggested, and it's an exciting possibility: it gives a chance to really make a business from this while hewing to the open philosophy of Android and breaking out from a Qualcomm-style tight control. That said, the team's current focus is on finishing Android itself - "We're very busy" was a common refrain this night. These sorts of questions will be answered later on.
Along the same financial lines, another person inquired about advertising. Dick laughed. Everyone wants to know about ads, and everyone cares more about it than Google. He dismissed the rumors that, when you make a call on an Android phone, you will need to listen to a 30-second advertisement. Google's official position, the reason why they are doing Android, is to use it as a tool for keeping the Web open. There are more cell phones than computers in the world, and Google has a vested interest in making sure that all of them will be able to get on the Internet and browse freely, without being locked down in a walled garden. That's the big picture, and Google isn't interested in nickel-and-diming users. As he put it, his boss had told him, "Your job is to help developers make money." Google isn't after a slice of the pie, they just want to make sure everyone has access to the pie.
Will Android run on non-phone platforms, like GPS units or set-top boxes? Not at first, but after it's open-sourced, it will probably be ported everywhere. When will it be open-sourced? Google doesn't own all the code in Android - some is contributed by OHA partners - so it can't open source it all now. But, the agreement signed by OHA members says that all the software will be released when the first phone ships. So, we'll have access to it soon!
We don't know if there will be SyncML in the next SDK. It's a popular technology, but Google isn't sure yet what the syncing story for Android will be. Again, they want to get it right, not necessarily fast.
The main focus now is just on making it work and getting it done. Because of that, they aren't as devoted to standards as other players. Earlier in the talk, Dick had said that while J2ME was a great technology for its time, devices have now advanced to the point where its design is too limiting, giving Android a great opportunity to rethink how to do mobile development. If this includes breaking standards, so be it. Google is aware of the pain that this can cause developers, but believes it's important to make software better. (As an example, think of Google Docs. By releasing this tool for free, Google killed off some companies who were charging for similar services, but the market as a whole got stronger. Again, after Android is released they'll be able to focus more on standards, but right now, it's intentionally being kept quite fluid.)
The Google philosophy, in case you can't tell yet, is "Have a very long beta period." During that beta, they're free to tinker, and users are rewarded with improved products, but nobody should expectit to be stable.
The browser is built on Webkit and is comparable to the iPhone browser. People have had good experiences getting iPhone web apps to run on the Android browser. There will inevitably be some quirks, but so far, they appear minimal.
He isn't sure how judging for the Challenge will work. Ash, the Champion, said that he has heard that each OHA member will judge all the applications, using whatever criteria they want, and the winners will be determined based on that consensus. Also, Dan Morrill is in charge of the challenge, which was news to me but makes sense. I imagine there's a lot of pressure when you're responsible for distributing millions of dollars!
Finally, someone said, "When can I buy a gPhone?" "There is no gPhone!" was the immediate and correct response. As Dick said, Google has no interest in getting into the hardware game; they want others to get into the game, and want to help them succeed. As for Android devices, they will be shipping in the second half of 2008 - they still don't know exactly when.
At this point, they started to yell at us to leave, so we did. I was pretty impressed... it was already 9:30, but the last three and a half hours had flown by. It was a great evening for me, a chance to dig deeper into Android and, even more interesting, peek behind the Google curtain to learn more about what is actually happening on Android.
On my way out, I stopped and chatted in the parking lot with a fellow GTUG attendee. It turns out that he works for Yahoo, and as I drove home that night, I reflected yet again on how awesome Silicon Valley is. Just think about it! Google and Yahoo are, by all appearances, each others' biggest competitors (though even there, there is more friendliness than you might expect). And yet, an employee from one company could waltz into the other's campus and spend a night getting information from Google on its technology. Not only that: Silicon Valley is also the place that attracts people who, after working a full day creating technology for a tech giant, would voluntarily surrender an evening learning about different technology for another tech giant. We're all nerds, and we all get along. I love this place!
UPDATE: After testing out the onFreeze/onPause thing myself, I need to correct my above statement. I thought Dick had said that onFreeze will only get called if Android needs to recreate the Activity later (i.e., because another process is taking over), but I must have mis-heard. As I had previously thought, onFreeze ALWAYS gets called before onPause.
That returned me to my earlier confusion - why on earth have two methods for this, when they will always be called in combination? I haven't found an explicit explanation, but I think it may be just to simplify Activity design. Conceptually, onFreeze is responding to your transition to another Activity by storing persistent state; this state will later be passed to onCreate if the Activity was killed by Android. On the other hand, onPause is responding to your transition to another Activity by cleaning up non-persistent resources: reclaiming threads, canceling network activity, and surrendering any resource locks; these resources will be reclaimed in your onResume call, whether or not the Activity is still running in this process.
Continuing that thought: onFreeze can be omitted altogether if there's no state to restore. It isn't that Android doesn't call your method, just that you the developer don't need to do anything. In this case, your onCreate will always do the same thing.
Again, I'm not sure about all of this since I feel like I'm making it up, but it fits in with what Dick was describing and what I'm seeing in the emulator. If so, it's a keen design. I may need to revisit some of the Activities I've written in the past - I have been playing loose with the difference between onCreate and onResume, and between onFreeze and onPause, since they always seemed to move in lockstep (well, except onResume, which can happen every time you return to a screen). It will take a bit of work, but should make them more robust, and better citizens in Android!
UPDATE 2 3/17/08: Either I'm going crazy or this actually changed between M3 and M5. I'm now seeing the behavior that I thought Dick had originally described - when navigating from one Activity to another in the same application, only your onPause will get called, not onFreeze.
In practice, one thing this means is that I can't rely on onFreeze as a good place to store preferences, like I did in M3. I'll need to either move this to onPause or start updating preferences whenever they change.
I swear, one day I'll understand how this all works...
Showing posts with label google. Show all posts
Showing posts with label google. Show all posts
Thursday, February 07, 2008
Thursday, January 24, 2008
Campfire Headphase
I like mobile development. I like Google. I love free food. So, it should come as no surprise that last night found me lurking once again on Google's campus as I attended their first campfire session for Android.
From what I can tell, this is the second "Campfire" that Google has held. It's kind of a cross between a barcamp and a typical product venue... Google hosts it and makes team members available for direct Q&A, but doesn't have much of an agenda and pretty much lets developers drive the action.
It was scheduled to run from 5-8, with refreshments, Q&A, and the chance to meet other Android developers offered as an incentive. After years of attending Mobile Monday I'm used to these things starting fashionably late, so I didn't exactly hurry over to Mountain View, and pulled into the parking lot around 5:30. By the time I checked in and got upstairs, the meeting was well under way, with all the chairs occupied and some heated debates under way. I grabbed a Guinness from their excellent hosted bar and floated in.
Even though most people in the room were developers, publishing concerns dominated the official Q&A (at least the portion that I saw). The reason why should be obvious to anyone who has worked in this space: carriers are the mortal enemy of the mobile developer, and while everyone's excited about Android, they are worried that all the same wounds will be re-inflicted, and it will become yet another platform to support that doesn't offer any greater stability. People repeatedly asked how Google would make sure that carriers did not cripple the available APIs, whether developers would be able to distribute their apps without going through a carrier portal, and how much control carriers would have over approving software.
Hosting these questions was Dan Morrill, a Developer Advocate at Google who has been a great and helpful presence on the official developer group. It didn't matter how many times he explained that he wasn't in a position to answer those kinds of business questions; they just kept on coming. I think this shows the depths of frustration mobile developers have with the current ecosystem, and if Google is smart they'll pay attention and use their weight to make sure that this time it works right. In retrospect, it probably would have been good to bring in someone who would be able to speak semi-authoritatively on those topics.
As it was, Dan could only speak vaguely, but he did explain that the entire purpose of the OHA is openness, and that their partners would not have joined the OHA if they intended to violate its spirit. This was a good answer, but I still remain skeptical. I can't help but wonder if wireless players are embracing openness in the same way that power companies are embracing greenness: they use it to promote their brand and improve their image, and take some symbolic steps, even as the core of their business remains firmly rooted in the opposite of what they claim to support. Specifically, I wonder if some of the players (Verizon in particular) are making a big show of openness prior to the upcoming wireless spectrum auction, and if we'll see backpedaling once that is complete.
We did get into some good technical talk, including a review of the Android security model and a developer update on how users will be able to install applications through the browser. Dan encouraged us to end the Q&A and move towards a more informal meeting with the advocates. They did that while I went to get food.
In keeping with the "campfire" label, the room we met in was made up as a faux camp. Instead of the standard Google chairs we got fun little fold-up camping chairs. A roaring fire was projected on two screens, but even cooler was a manufactured "fire" made from logs, light, a fan and ribbon. It would have made a great art project. And there was a giant "tent", inside which the food was served. I always wax eloquent about Google's food, so I should do the same here: they had "pigs in a blanket", which were petite hot dogs wrapped in pastry; baked beans and vegetarian chili; hot cider and hot chocolate; and, as the piece de resistance, "S'more cake", a fanciful treat that layered chocolate and marshmallow on a soft and airy cake with a subtle graham cracker taste. Altogether, while it wasn't the best-tasting meal I've had at Google, it may have been the most creative.
The coolest feature of the night, though, was definitely the seven-foot-tall Cylon Centurion. It stood just behind the speaker's podium, stock still, its single red eye balefully sweeping back and forth over the huddled programmers. That made my night.
(For those of you who haven't used Android yet: in the current SDK, when the emulator first starts and the kernel is booting, you see a red dot sweeping back and forth across the screen. A lot of people have commented that it looks like the Cylon eye, but until seeing the statue I had assumed it was just a coincidence... don't ask me why!)
The rest of the night was pretty low-key but interesting. I chatted with a few other developers who were there. I was struck by the non-mobile people who were there, which was cool... I'm used to working in my own little corner of the development world, without a lot of connection to those on the outside, and here it looked like Android was opening the gates a bit and letting more people in. Which I'm all for, of course. Now, some of that might just be Google's cachet, but still, it's a fun thing to see.
I also briefly chatted with one of the Advocates, and eavesdropped on a few more. It was impressive to hear how on-top of the platform some of them were... one developer was complaining about how difficult it was for a Service to determine which of several Activities was in the foreground, and that he had to broadcast Intents to all of them and then have them decide whether to react. This woman, whose name I forget, briefly explained how using an IntentReceiver would work in that situation, leading me to think, "Oh, of course!"
On the whole, I've been really impressed by the way Google's been proceeding with Android. Compared to other mobile platforms I've worked with, I think they "get it" and hopefully that will result in a superior product. Specific things I like include:
From what I can tell, this is the second "Campfire" that Google has held. It's kind of a cross between a barcamp and a typical product venue... Google hosts it and makes team members available for direct Q&A, but doesn't have much of an agenda and pretty much lets developers drive the action.
It was scheduled to run from 5-8, with refreshments, Q&A, and the chance to meet other Android developers offered as an incentive. After years of attending Mobile Monday I'm used to these things starting fashionably late, so I didn't exactly hurry over to Mountain View, and pulled into the parking lot around 5:30. By the time I checked in and got upstairs, the meeting was well under way, with all the chairs occupied and some heated debates under way. I grabbed a Guinness from their excellent hosted bar and floated in.
Even though most people in the room were developers, publishing concerns dominated the official Q&A (at least the portion that I saw). The reason why should be obvious to anyone who has worked in this space: carriers are the mortal enemy of the mobile developer, and while everyone's excited about Android, they are worried that all the same wounds will be re-inflicted, and it will become yet another platform to support that doesn't offer any greater stability. People repeatedly asked how Google would make sure that carriers did not cripple the available APIs, whether developers would be able to distribute their apps without going through a carrier portal, and how much control carriers would have over approving software.
Hosting these questions was Dan Morrill, a Developer Advocate at Google who has been a great and helpful presence on the official developer group. It didn't matter how many times he explained that he wasn't in a position to answer those kinds of business questions; they just kept on coming. I think this shows the depths of frustration mobile developers have with the current ecosystem, and if Google is smart they'll pay attention and use their weight to make sure that this time it works right. In retrospect, it probably would have been good to bring in someone who would be able to speak semi-authoritatively on those topics.
As it was, Dan could only speak vaguely, but he did explain that the entire purpose of the OHA is openness, and that their partners would not have joined the OHA if they intended to violate its spirit. This was a good answer, but I still remain skeptical. I can't help but wonder if wireless players are embracing openness in the same way that power companies are embracing greenness: they use it to promote their brand and improve their image, and take some symbolic steps, even as the core of their business remains firmly rooted in the opposite of what they claim to support. Specifically, I wonder if some of the players (Verizon in particular) are making a big show of openness prior to the upcoming wireless spectrum auction, and if we'll see backpedaling once that is complete.
We did get into some good technical talk, including a review of the Android security model and a developer update on how users will be able to install applications through the browser. Dan encouraged us to end the Q&A and move towards a more informal meeting with the advocates. They did that while I went to get food.
In keeping with the "campfire" label, the room we met in was made up as a faux camp. Instead of the standard Google chairs we got fun little fold-up camping chairs. A roaring fire was projected on two screens, but even cooler was a manufactured "fire" made from logs, light, a fan and ribbon. It would have made a great art project. And there was a giant "tent", inside which the food was served. I always wax eloquent about Google's food, so I should do the same here: they had "pigs in a blanket", which were petite hot dogs wrapped in pastry; baked beans and vegetarian chili; hot cider and hot chocolate; and, as the piece de resistance, "S'more cake", a fanciful treat that layered chocolate and marshmallow on a soft and airy cake with a subtle graham cracker taste. Altogether, while it wasn't the best-tasting meal I've had at Google, it may have been the most creative.
The coolest feature of the night, though, was definitely the seven-foot-tall Cylon Centurion. It stood just behind the speaker's podium, stock still, its single red eye balefully sweeping back and forth over the huddled programmers. That made my night.
(For those of you who haven't used Android yet: in the current SDK, when the emulator first starts and the kernel is booting, you see a red dot sweeping back and forth across the screen. A lot of people have commented that it looks like the Cylon eye, but until seeing the statue I had assumed it was just a coincidence... don't ask me why!)
The rest of the night was pretty low-key but interesting. I chatted with a few other developers who were there. I was struck by the non-mobile people who were there, which was cool... I'm used to working in my own little corner of the development world, without a lot of connection to those on the outside, and here it looked like Android was opening the gates a bit and letting more people in. Which I'm all for, of course. Now, some of that might just be Google's cachet, but still, it's a fun thing to see.
I also briefly chatted with one of the Advocates, and eavesdropped on a few more. It was impressive to hear how on-top of the platform some of them were... one developer was complaining about how difficult it was for a Service to determine which of several Activities was in the foreground, and that he had to broadcast Intents to all of them and then have them decide whether to react. This woman, whose name I forget, briefly explained how using an IntentReceiver would work in that situation, leading me to think, "Oh, of course!"
On the whole, I've been really impressed by the way Google's been proceeding with Android. Compared to other mobile platforms I've worked with, I think they "get it" and hopefully that will result in a superior product. Specific things I like include:
- Giving an early look at the SDK to developers - even though they don't use the phrase, it's basically an alpha right now. This lets them collect early feedback before it's launched and make appropriate adjustments BEFORE phones start shipping. (Anyone else remember MIDP 1.0?)
- Coming up with solid API code samples. All the forums I frequent for mobile development are filled with annoying posts saying things like, "Please give me a code example of drawing a square on the screen. This is urgent!" The examples Google gives aren't 100% comprehensive, but they are much better than anything comparable I've seen.
- Along the same lines, having top-flight sample code. This is often handed off to interns, who come up with mediocre designs and style that is then adopted as gospel by the development community. This is crucial to get right early on, since those of us who are working with the platform now will be teaching others how to do it a year from now. Google is teaching us how to be better teachers.
- The developer challenge, because it drives the earlier three points and lets Google get full advantage. They could have released the SDK when they did, but without the ADC, only a handful of super-geeks would have bothered using it before phones were announced. This builds adoption momentum AND encourages early adopters to learn how to use the tools properly.
- Good tools support. I love Eclipse, and their plugins for it have been high-quality. Their emulator is also much better than some others I could name. Actual device simulation - who would have thought it?!
Friday, July 28, 2006
Act Locally
I'm never on top of the latest breaking news, but at least a few of you also didn't know about this yet, so I figured I'd pass it on.
Google has released an updated version of its Google Maps application for mobile phones. If you haven't seen the previous version, you're in for a treat. Google has done a phenomenal job of converting its excellent mapping software to the mobile phone. They got everything right: it's feature-rich with items taken from the web version (including searching, getting driving directions, zooms, satellite imagery), and is well adapted to the constraints of a mobile device (easy and clear step-by-step driving directions, jumping between search results on the small screen). The number of cool use cases is pretty impressive. I open the phone, and it remembers where I was using it last, bringing up the Los Gatos area map. I type in "burger" to search and get back a bunch of results. I find Main Street Burger, and then press the "Call" button and instantly initiate a phone call to them.
I've been geeking out on this application for a while now; the new version adds even more to amaze. The single coolest addition is real-time traffic information. Just press # on your keypad, and your local highways receive another overlay: green for running on time, yellow for running slow, and red for backed up. Even more amazing, this is integrated into the routing algorithm: your driving directions now include up-to-the-minute traffic estimates.
So that's incredibly cool, although it isn't something I'll use that often (seeing as how I rarely drive to work and, when I do, it's almost always a smooth commute). Traffic info has a high wow factor, but I'll get the most mileage out of an improved favorites feature: the previous version had the standard "recent searches", which was nice, but this one lets you bookmark and name common addresses. Then, it's just 1 touch to center on that bookmark. It's not just locations, though: you can also bookmark routes! I could see myself, for example, bookmarking the route from home to SFO, then checking it to see whether I'm better off going up on 280 or 101 on a given day.
Anyhoo, cool stuff. It's available on Sprint and Cingular; if you have a data plan, it's totally free to download and use.
Some inside-the-beltway-commentary: obviously I'm a BREW guy, do or die, but I'll really miss things like this when I switch over to Verizon. The carriers who don't offer this generally have one of two reasons: either their technology doesn't support it (that is, they use BREW phones instead of J2ME), or their network doesn't support it (that is, T-Mobile has awful awful data channels).
The argument about technology not supporting it is a bit facetious, though. Yes, Verizon sells BREW phones, but the reason why is because they want to have total control over the programs run on their phones. This all goes down to the bottom line: Verizon would rather sell 1000 copies of Verizon Navigator for a monthly fee than have 1000000 copies of Google Maps running for free. I shouldn't complain, since that business model supports my salary, but it can feel frustrating to operate in a nickel and dime economy. Sprint takes the broader view, hoping that people will like the free stuff so much that they'll shell out $15 a month for the data plans. (And some people will pay even more for the premium games and applications.) Time will tell which strategy ultimately wins out. Personally, I'd be delighted to see a future world where free J2ME programs run on the BREW platform. The technology is already there to do it; it's a question of courage on Verizon's part, and I think it would be a shrewd move as well. Few people who haven't previously experienced mobile applications will shell out money for them; free high-quality applications like Google Maps are a great way to get people used to using their phones like computers, and once they make that transition, far more of them will convert to data users who want Verizon's BREW content.
And what does Google get out of all this? First off, remember that Google has never been reluctant to offer free services while experimenting with new products and technology. In the long run, it will probably support this through advertising. It'll be interesting to see how that happens - obviously, you won't have as much screen space to support ads as you do in a web browser, but then again this could be a place where Google's text-only ads really shine. I can imagine me typing in "burger", and along with my results having a tiny crawl at the bottom calling out a local burger restaurant I haven't been to yet. It's a brave new world out there.
Download the application by opening your phone's web browser and going to http://google.com/gmm. If you'd like, you can take a tour of the application online - keep in mind, the interface is much nicer in the palm of your hand than the end of a mouse.
Google has released an updated version of its Google Maps application for mobile phones. If you haven't seen the previous version, you're in for a treat. Google has done a phenomenal job of converting its excellent mapping software to the mobile phone. They got everything right: it's feature-rich with items taken from the web version (including searching, getting driving directions, zooms, satellite imagery), and is well adapted to the constraints of a mobile device (easy and clear step-by-step driving directions, jumping between search results on the small screen). The number of cool use cases is pretty impressive. I open the phone, and it remembers where I was using it last, bringing up the Los Gatos area map. I type in "burger" to search and get back a bunch of results. I find Main Street Burger, and then press the "Call" button and instantly initiate a phone call to them.
I've been geeking out on this application for a while now; the new version adds even more to amaze. The single coolest addition is real-time traffic information. Just press # on your keypad, and your local highways receive another overlay: green for running on time, yellow for running slow, and red for backed up. Even more amazing, this is integrated into the routing algorithm: your driving directions now include up-to-the-minute traffic estimates.
So that's incredibly cool, although it isn't something I'll use that often (seeing as how I rarely drive to work and, when I do, it's almost always a smooth commute). Traffic info has a high wow factor, but I'll get the most mileage out of an improved favorites feature: the previous version had the standard "recent searches", which was nice, but this one lets you bookmark and name common addresses. Then, it's just 1 touch to center on that bookmark. It's not just locations, though: you can also bookmark routes! I could see myself, for example, bookmarking the route from home to SFO, then checking it to see whether I'm better off going up on 280 or 101 on a given day.
Anyhoo, cool stuff. It's available on Sprint and Cingular; if you have a data plan, it's totally free to download and use.
Some inside-the-beltway-commentary: obviously I'm a BREW guy, do or die, but I'll really miss things like this when I switch over to Verizon. The carriers who don't offer this generally have one of two reasons: either their technology doesn't support it (that is, they use BREW phones instead of J2ME), or their network doesn't support it (that is, T-Mobile has awful awful data channels).
The argument about technology not supporting it is a bit facetious, though. Yes, Verizon sells BREW phones, but the reason why is because they want to have total control over the programs run on their phones. This all goes down to the bottom line: Verizon would rather sell 1000 copies of Verizon Navigator for a monthly fee than have 1000000 copies of Google Maps running for free. I shouldn't complain, since that business model supports my salary, but it can feel frustrating to operate in a nickel and dime economy. Sprint takes the broader view, hoping that people will like the free stuff so much that they'll shell out $15 a month for the data plans. (And some people will pay even more for the premium games and applications.) Time will tell which strategy ultimately wins out. Personally, I'd be delighted to see a future world where free J2ME programs run on the BREW platform. The technology is already there to do it; it's a question of courage on Verizon's part, and I think it would be a shrewd move as well. Few people who haven't previously experienced mobile applications will shell out money for them; free high-quality applications like Google Maps are a great way to get people used to using their phones like computers, and once they make that transition, far more of them will convert to data users who want Verizon's BREW content.
And what does Google get out of all this? First off, remember that Google has never been reluctant to offer free services while experimenting with new products and technology. In the long run, it will probably support this through advertising. It'll be interesting to see how that happens - obviously, you won't have as much screen space to support ads as you do in a web browser, but then again this could be a place where Google's text-only ads really shine. I can imagine me typing in "burger", and along with my results having a tiny crawl at the bottom calling out a local burger restaurant I haven't been to yet. It's a brave new world out there.
Download the application by opening your phone's web browser and going to http://google.com/gmm. If you'd like, you can take a tour of the application online - keep in mind, the interface is much nicer in the palm of your hand than the end of a mouse.
Thursday, June 15, 2006
Whither Photos?
I think the set of people interested in viewing my photos online is entirely contained within the set of people who read this blog. If you aren't in the former set, you can skip the remainder of the post.
For the rest of you: I have received an invitation to participate in Picassa Web Albums, which is basically Google's attempt to compete with Flickr. I've played around with the service a bit, and I like it, with one big exception: it only provides 250 MB of storage space. It can be upgraded to 6GB with a payment of $25/year, but (a) I'd eventually fill up that, too, and (b) I don't want to pay money if I don't have to.
When you have a few minutes, please take a look at my current photo dump - Timmy's House of Incandescent Sprinkles - and my potential new photo dump. Then, please answer these questions (either online or off):
1. Do the new features in Web Albums look useful to you as a user? These include commenting on individual photos, downloading entire albums, and slideshows.
2. If I switched to Web Albums, I would eventually need to cycle off old albums as new ones came on. Do you anticipate that you would want to search and view photos of mine, say, a year after they were first posted?
3. Please compare this set of photos with this set. Do you notice a big difference in quality? If so, is it big enough that the other would annoy you?
Thanks for your time. The two methods are roughly equal in difficulty as far as I'm concerned (more work up front on Blogger, more work later on for Web Albums), so my decision will be largely based on any input you may have.
For those who are curious, here's some background:
In the old days, when I was actively running a server, I rolled my own photo sharing: I just copied the photos to the correct directory on my hard drive and wrote up HTML pages for them. This was kind of nice in that I could have full-resolution photos online, but it was tedious work and I didn't bother very often. (I also didn't take many pictures.)
There are a lot more options these days, and I started playing around with them when I got my new camera. Nothing gave me everything I wanted. There's a lot I like about flickr: it has a great interface, I like the way it handles albums, it automatically picks up captions, and allows for comments on individual photos. Two things made me a little leery: by default, all flickr albums are totally open so anyone can search them, and the free account is a little limited (20MB uploads per month [but unlimited storage], photostream only holds most recent 200 pictures). They have a variety of ways to upload photos, which is cool, but the one I tried (uploading directly from Explorer) was annoying - it took forever, and silently skipped a bunch of my pictures without telling me.
Whenever I have a choice of products I tend to go with Google, so I also looked at their offerings. Google didn't have a single product; rather, there were three programs that sort of worked together. One was Picassa, which I love: it's a simple, clean, decently powerful program that lets you import and organize pictures; it'll pull them off the phone, timestamp and label them, and let you put in captions. It integrates with another program called Hello, which is designed to let you share photos with other Hello users; you can easily send a single picture, a whole album, or just a collection of images. However, I use Hello to communicate with BloggerBot, which allows you to create posts with your photos.
In theory, this was all wonderful. In practice, there are quite a few annoyances. One of the most glaring: captions you insert in Picassa are not passed along to Hello or Blogger; even though they freakin' display in Hello, you need to manually type (no copy-paste!) them in again. That's aggravating. Second, by default BloggerBot will create a whole new post for every single image you send it, which is obviously unwieldy - imagine 25 posts swarming your RSS feed every time I take a hike. After hunting through newsgroups online I found a way to get around this - you need to put in "||" at the end of each caption, which tells BloggerBot to queue them up - but once again this is annoying, and if I accidentally leave the "||" off halfway through, everything I've done so far will get posted. Finally, I haven't been able to find a way to give a title to posts created this way, either before or after. That means I sort of shoehorn a title into the very first photo's caption, since that will serve as a substitute title.
When Pat told me about Web Albums yesterday I was initially intrigued, then dismissive; it feels odd that, when GMail gives 2GB for email, they'd skimp on storage space for photos like this. The upgraded Web Albums costs the same as Flickr Pro, but Flickr's package is better - unlimited storage for life is far better than 6GB. I'd hope that Google would bump up the sizes on both the free and upgraded accounts when they move from "Test" to "Beta" to "Released." As is, the basic storage is enough for about 1000 images at highest (1600) resolution, more than that at lower (1024) resolution. My initial dream was to have permanent searchable and shareable online storage, and it doesn't look like that will be possible; sooner or later I'll need to move my stuff off their server. Still, that wouldn't be a huge problem. I have plenty of space on my own hard drive and plan on keeping all the originals - if anyone every wants a high-res version of a picture, no matter when it was taken or how I put it online, just ask.
UPDATE 6/21/06: I haven't heard any strong preference for either Blogger or Web Albums, so I think I'll go with the Albums. I like the way it syncs with Picasa, and Google has been pretty good in the past about improving their offerings so I'll hope that they do something about the storage situation. I've already uploaded about 1/5 of my available space, which does not bode very well.
For the rest of you: I have received an invitation to participate in Picassa Web Albums, which is basically Google's attempt to compete with Flickr. I've played around with the service a bit, and I like it, with one big exception: it only provides 250 MB of storage space. It can be upgraded to 6GB with a payment of $25/year, but (a) I'd eventually fill up that, too, and (b) I don't want to pay money if I don't have to.
When you have a few minutes, please take a look at my current photo dump - Timmy's House of Incandescent Sprinkles - and my potential new photo dump. Then, please answer these questions (either online or off):
1. Do the new features in Web Albums look useful to you as a user? These include commenting on individual photos, downloading entire albums, and slideshows.
2. If I switched to Web Albums, I would eventually need to cycle off old albums as new ones came on. Do you anticipate that you would want to search and view photos of mine, say, a year after they were first posted?
3. Please compare this set of photos with this set. Do you notice a big difference in quality? If so, is it big enough that the other would annoy you?
Thanks for your time. The two methods are roughly equal in difficulty as far as I'm concerned (more work up front on Blogger, more work later on for Web Albums), so my decision will be largely based on any input you may have.
For those who are curious, here's some background:
In the old days, when I was actively running a server, I rolled my own photo sharing: I just copied the photos to the correct directory on my hard drive and wrote up HTML pages for them. This was kind of nice in that I could have full-resolution photos online, but it was tedious work and I didn't bother very often. (I also didn't take many pictures.)
There are a lot more options these days, and I started playing around with them when I got my new camera. Nothing gave me everything I wanted. There's a lot I like about flickr: it has a great interface, I like the way it handles albums, it automatically picks up captions, and allows for comments on individual photos. Two things made me a little leery: by default, all flickr albums are totally open so anyone can search them, and the free account is a little limited (20MB uploads per month [but unlimited storage], photostream only holds most recent 200 pictures). They have a variety of ways to upload photos, which is cool, but the one I tried (uploading directly from Explorer) was annoying - it took forever, and silently skipped a bunch of my pictures without telling me.
Whenever I have a choice of products I tend to go with Google, so I also looked at their offerings. Google didn't have a single product; rather, there were three programs that sort of worked together. One was Picassa, which I love: it's a simple, clean, decently powerful program that lets you import and organize pictures; it'll pull them off the phone, timestamp and label them, and let you put in captions. It integrates with another program called Hello, which is designed to let you share photos with other Hello users; you can easily send a single picture, a whole album, or just a collection of images. However, I use Hello to communicate with BloggerBot, which allows you to create posts with your photos.
In theory, this was all wonderful. In practice, there are quite a few annoyances. One of the most glaring: captions you insert in Picassa are not passed along to Hello or Blogger; even though they freakin' display in Hello, you need to manually type (no copy-paste!) them in again. That's aggravating. Second, by default BloggerBot will create a whole new post for every single image you send it, which is obviously unwieldy - imagine 25 posts swarming your RSS feed every time I take a hike. After hunting through newsgroups online I found a way to get around this - you need to put in "||" at the end of each caption, which tells BloggerBot to queue them up - but once again this is annoying, and if I accidentally leave the "||" off halfway through, everything I've done so far will get posted. Finally, I haven't been able to find a way to give a title to posts created this way, either before or after. That means I sort of shoehorn a title into the very first photo's caption, since that will serve as a substitute title.
When Pat told me about Web Albums yesterday I was initially intrigued, then dismissive; it feels odd that, when GMail gives 2GB for email, they'd skimp on storage space for photos like this. The upgraded Web Albums costs the same as Flickr Pro, but Flickr's package is better - unlimited storage for life is far better than 6GB. I'd hope that Google would bump up the sizes on both the free and upgraded accounts when they move from "Test" to "Beta" to "Released." As is, the basic storage is enough for about 1000 images at highest (1600) resolution, more than that at lower (1024) resolution. My initial dream was to have permanent searchable and shareable online storage, and it doesn't look like that will be possible; sooner or later I'll need to move my stuff off their server. Still, that wouldn't be a huge problem. I have plenty of space on my own hard drive and plan on keeping all the originals - if anyone every wants a high-res version of a picture, no matter when it was taken or how I put it online, just ask.
UPDATE 6/21/06: I haven't heard any strong preference for either Blogger or Web Albums, so I think I'll go with the Albums. I like the way it syncs with Picasa, and Google has been pretty good in the past about improving their offerings so I'll hope that they do something about the storage situation. I've already uploaded about 1/5 of my available space, which does not bode very well.
Friday, January 27, 2006
Goooooooooooooooooooooooooogle
This isn't a topical blog. Well, except when I write about Civ IV, in which case you're treated to a virtually real-time explanation of my activities. But in general I will think about something, it'll sort of percolate for a week or so, I'll forget about it, I'll start writing a post, and several days later throw it up. This isn't a big deal when I'm talking about a concert or a book I read, but I get the feeling it doesn't lend itself well to current news events. Anything I share will be out of date and quite possibly irrelevant by the time it goes up. Any day now I'll probably post my recommendation on whether to vote for Bush or Kerry.
With that out of the way, let's talk about Google!
First, I must admit I am biased. I love Google. From the day I found out about them they're the only engine I've used, simply because their results are more useful than anyone else's. The more I learn the more I like them: I appreciate their culture, the wonderful way they treat their employees, their simple and flat corporate hierarchy, their fun and quirky holiday doodles, and their amazing stream of new products. I love the way things are in "beta" for over a year, to the point you don't even think about it any more, until one day they're suddenly official and even better than before. When I left my prior employment, they were the first company I applied to, and the only one who actually sent me a rejection letter (later rescinded, but that's another story, and in any case I deeply appreciated the courtesy).
On the other hand, I hate invasions of privacy and John Ashcroft, so you can guess where I'm going with this.
Before that, though, we should probably clarify a few misconceptions I've heard a lot. First, this isn't exactly a privacy case; the government is requesting a list of terms searched, results returned, and pages on the Internet. Google retains information that could potentially link those searches back to individuals, but the government isn't looking for them. Secondly, Google isn't opposing the subpoena on privacy grounds; rather, they are arguing that the subpoena would cause undue hardship and that it could reveal trade secrets.
These clarifications aside, however, make no mistake: while this particular battle is being fought with issues of scope and authority, the underlying issue is privacy. The tension here is about what much data the government can collect from private entities. Obviously, there is a sliding scale involved; more information needs to be shared if there's an imminent threat facing the nation than some midlevel bureaucrat wanting information on his political enemies. Everyone watching this scene wonders, will the government ever see my Google searches? This may range from an embarassing thought (now they'll know about that rash) to alarming (I KNEW I shouldn't have done that research paper on modern Islam).
As I said, for years I've only used Google, and after learning that AOL, Microsoft, and Yahoo! all rolled over for the subpoena, I'm more committed to them than ever. Again, there's that question: suppose the DOJ wants a list of all IP addresses who searched for "parts to make a nuclear bomb." Now, I happen to just be curious what kind of information is available, but I'd rather not have to explain that to the FBI. Based on past behavior I expect to get better protection from Google than any other search engine.
Now, don't think that everything you type into Google is safe. The company's terms of use clearly state that they can and will turn records over for lawful legal purposes. If the FBI determined that an individual was in an al Qaeda and wanted to learn what he was thinking of doing, Google would most likely turn over the relevant logs. If you're seriously concerned about the possibility of being tracked, use an anonymizer, or your neighbor's unsecured wireless access.
I guess I look at this situation the same way an NRA member looks at a bill banning automatic guns. The typical NRA member doesn't own a machine gun any more than the typical Google user looks for porn. But he does have a hunting rifle, and he knows that as long as AK-47s are legal, nobody will try to take his deer shooter. In a similar way, by holding the line on a relatively harmless invasion of its records, Google is protecting against future aggressive surveillance, the kind that could turn this nation into an electronic police state. Google has no interest in being a research arm of the government like the NSA, they just want to write software and change the world. I for one am cheering them on.
(Oh, two final clarifications. The Bush administration is pursuing this, but don't be confused, the original [bad] law was signed by President Clinton and is one of the big reasons why I don't like him except in comparison to our current leader. COPA, the Child Online Protection Act, was been invalidated by the Supreme Court and this battle is attempting to revive it. Secondly, the administration is always very careful to use the words "children" and "pornography" together when talking about this issue, leading casual observers to believe that this bill aims either to protect children from online smut or to oppose online child pornography. It does nothing in regards to the latter; that is already the most illegal thing there is and there are plenty of tools to fight it. Nor does it exactly do the former. The heart of the bill is to forbid web sites from making "indecent" content "accessible to minors." The Court was absolutely right in striking this law down because it is too broad. Remember that a minor is practically anyone under age 18; it would therefore make it illegal for a 16 year old to research information on birth control or sexually transmitted diseases or whatever else Alberto Gonzales decides is "indecent." And the only mechanism in wide use for determining someone is an adult is to use a credit card. This is both laughably ineffective and ominously chilling. Ineffective because many teens have a debit or credit card held jointly with their parents, and even if not they know where their mom's purse is. Chilling because people don't like to provide information that can be traced back to them. Do I want to leave behind a record for the time I wanted to learn more about chlymidia? And to I really trust some website to use my card for identification purposes only? Adults with legitimate reasons to pursue content on the sites will be scared off and so a great benefit of the Internet will die. Worst of all, the Bush administration is chasing down this broken law instead of pursuing the remedy actually suggested by the court of providing filters parents can use to control their children's browsing. Have any of you seen how well Google's "Safe Search" works? If I was in charge, I'd be welcoming Google as a provider of useful new technology and not fighting them to rescue a bad law.)
With that out of the way, let's talk about Google!
First, I must admit I am biased. I love Google. From the day I found out about them they're the only engine I've used, simply because their results are more useful than anyone else's. The more I learn the more I like them: I appreciate their culture, the wonderful way they treat their employees, their simple and flat corporate hierarchy, their fun and quirky holiday doodles, and their amazing stream of new products. I love the way things are in "beta" for over a year, to the point you don't even think about it any more, until one day they're suddenly official and even better than before. When I left my prior employment, they were the first company I applied to, and the only one who actually sent me a rejection letter (later rescinded, but that's another story, and in any case I deeply appreciated the courtesy).
On the other hand, I hate invasions of privacy and John Ashcroft, so you can guess where I'm going with this.
Before that, though, we should probably clarify a few misconceptions I've heard a lot. First, this isn't exactly a privacy case; the government is requesting a list of terms searched, results returned, and pages on the Internet. Google retains information that could potentially link those searches back to individuals, but the government isn't looking for them. Secondly, Google isn't opposing the subpoena on privacy grounds; rather, they are arguing that the subpoena would cause undue hardship and that it could reveal trade secrets.
These clarifications aside, however, make no mistake: while this particular battle is being fought with issues of scope and authority, the underlying issue is privacy. The tension here is about what much data the government can collect from private entities. Obviously, there is a sliding scale involved; more information needs to be shared if there's an imminent threat facing the nation than some midlevel bureaucrat wanting information on his political enemies. Everyone watching this scene wonders, will the government ever see my Google searches? This may range from an embarassing thought (now they'll know about that rash) to alarming (I KNEW I shouldn't have done that research paper on modern Islam).
As I said, for years I've only used Google, and after learning that AOL, Microsoft, and Yahoo! all rolled over for the subpoena, I'm more committed to them than ever. Again, there's that question: suppose the DOJ wants a list of all IP addresses who searched for "parts to make a nuclear bomb." Now, I happen to just be curious what kind of information is available, but I'd rather not have to explain that to the FBI. Based on past behavior I expect to get better protection from Google than any other search engine.
Now, don't think that everything you type into Google is safe. The company's terms of use clearly state that they can and will turn records over for lawful legal purposes. If the FBI determined that an individual was in an al Qaeda and wanted to learn what he was thinking of doing, Google would most likely turn over the relevant logs. If you're seriously concerned about the possibility of being tracked, use an anonymizer, or your neighbor's unsecured wireless access.
I guess I look at this situation the same way an NRA member looks at a bill banning automatic guns. The typical NRA member doesn't own a machine gun any more than the typical Google user looks for porn. But he does have a hunting rifle, and he knows that as long as AK-47s are legal, nobody will try to take his deer shooter. In a similar way, by holding the line on a relatively harmless invasion of its records, Google is protecting against future aggressive surveillance, the kind that could turn this nation into an electronic police state. Google has no interest in being a research arm of the government like the NSA, they just want to write software and change the world. I for one am cheering them on.
(Oh, two final clarifications. The Bush administration is pursuing this, but don't be confused, the original [bad] law was signed by President Clinton and is one of the big reasons why I don't like him except in comparison to our current leader. COPA, the Child Online Protection Act, was been invalidated by the Supreme Court and this battle is attempting to revive it. Secondly, the administration is always very careful to use the words "children" and "pornography" together when talking about this issue, leading casual observers to believe that this bill aims either to protect children from online smut or to oppose online child pornography. It does nothing in regards to the latter; that is already the most illegal thing there is and there are plenty of tools to fight it. Nor does it exactly do the former. The heart of the bill is to forbid web sites from making "indecent" content "accessible to minors." The Court was absolutely right in striking this law down because it is too broad. Remember that a minor is practically anyone under age 18; it would therefore make it illegal for a 16 year old to research information on birth control or sexually transmitted diseases or whatever else Alberto Gonzales decides is "indecent." And the only mechanism in wide use for determining someone is an adult is to use a credit card. This is both laughably ineffective and ominously chilling. Ineffective because many teens have a debit or credit card held jointly with their parents, and even if not they know where their mom's purse is. Chilling because people don't like to provide information that can be traced back to them. Do I want to leave behind a record for the time I wanted to learn more about chlymidia? And to I really trust some website to use my card for identification purposes only? Adults with legitimate reasons to pursue content on the sites will be scared off and so a great benefit of the Internet will die. Worst of all, the Bush administration is chasing down this broken law instead of pursuing the remedy actually suggested by the court of providing filters parents can use to control their children's browsing. Have any of you seen how well Google's "Safe Search" works? If I was in charge, I'd be welcoming Google as a provider of useful new technology and not fighting them to rescue a bad law.)
Thursday, December 08, 2005
Above us, only sky
Two things:
First, you may have seen this already, but another innovation has emerged from Google Labs: Google Transit. I've wanted something like this for a while, it's basically Google Maps but for public transit. So far it only covers Portland, OR, but they will be adding more cities. Most major transit sites already have "trip planners", but tend to be difficult to navigate and customize, so I'm looking forward to seeing that functionality unified under the user-friendly Google imprimatur.
Secondly, there was an excellent interview with Stephen Colbert on Fresh Air yesterday. I should probably warn you that it isn't very funny, but it is an excellent out-of-character conversation that really highlights Stephen's intelligence, his plans for the show, and his thoughts on the media.
First, you may have seen this already, but another innovation has emerged from Google Labs: Google Transit. I've wanted something like this for a while, it's basically Google Maps but for public transit. So far it only covers Portland, OR, but they will be adding more cities. Most major transit sites already have "trip planners", but tend to be difficult to navigate and customize, so I'm looking forward to seeing that functionality unified under the user-friendly Google imprimatur.
Secondly, there was an excellent interview with Stephen Colbert on Fresh Air yesterday. I should probably warn you that it isn't very funny, but it is an excellent out-of-character conversation that really highlights Stephen's intelligence, his plans for the show, and his thoughts on the media.
Tuesday, October 11, 2005
Breaking news
Go to Google Maps. Search for a city in Latin America, like Caracas. Looks like something's going on! I bet we're in the process of seeing another region of the world being added.
Andrew points out that you can search for it in Satellite mode and get a result. So maybe they have the coordinates plugged in but are missing road data.
Now that I'm typing this up, I'm guessing this is old news. I'm still going to click "Publish Post," though.
Andrew points out that you can search for it in Satellite mode and get a result. So maybe they have the coordinates plugged in but are missing road data.
Now that I'm typing this up, I'm guessing this is old news. I'm still going to click "Publish Post," though.
Subscribe to:
Posts (Atom)