Tip: Google Apps/"One or more of your accounts cannot be transitioned at this time"

Discovered, finally, why I couldn't transition my main Google Apps account to the new infrastructure. It turns out that if you set up another Google account as having your apps account as an alternative email address (say, for password reminders), the accounts become "linked" and the GA account email address becomes associated with an ordinary Google account.

Confused? Don't be, you probably have one other Google account, like "myname@gmail.com", and you've probably linked them in some way in the past. Do the following:

1. Log into that account, say, in gmail. Go to "Account settings"
2. Under email addresses, check to see if your GA account is listed.
3. If so, click edit, and remove it!
4. Retransition. If you've already tried to transition your entire domain, your only option is a hack. Go to https://www.google.com/a/cpanel/{yourdomain}/GoogleAccountUpgrade (where {yourdomain} is your domain, eg https://www.google.com/a/cpanel/example.com/GoogleAccountUpgrade
5. The warning will probably still appear that some of your accounts cannot be transitioned, but you should find that your account has been. If it hasn't, well, the issue lies elsewhere.

To the best of my knowledge, Google doesn't document this anywhere, and worse still their "help" on the subject is utterly useless and wrong. You can't get into the transition wizard when you transition your entire domain, and step three doesn't have the options they claim.

Hat tip to PageError, here.

Is Honeycomb ready for prime time?

It doesn't sound like the Google tablet operating system is quite there yet.

Reading BGR's review of the T-Mobile G-Slate, it sounds like the overall design of Android Honeycomb, the user interface concepts, etc, are great, but the system itself is poorly implemented. When I tried using the system under the Android SDK emulator, I found it unbelievably slow but put that down to the hardware I was running it on. Apparently though, it is slow even on high performance hardware, and it shouldn't be.

I was holding off buying such a thing because of the uncertainty about the state of Honeycomb's openness (see my blog entry on the supportability of proprietary vs open software for more details on why I'm not going to hop on to a "new", minority system that isn't free and open source) but it's beginning to sound like waiting is a good strategy anyway. The system needs to be fixed, and I suspect that's the real reason why Google is sitting on it.

Platform fragmentation

There was a time, fairly recently in fact, where it was possible to target a single platform for all new development. That "platform" was the web. As long as you conformed to certain standards, and didn't make too many reaches in terms of how you expected your application to behave, there wasn't a problem. Applications would load into IE or Firefox, appear on a largish display with the user interacting with them using a mouse and keyboard, and, well, that was it.

And then, suddenly, here is the explosion of so-called smartphones, and now tablets. Both require subtly different ways of interaction, which means designing a user interface intended for a 1024x768 screen is likely to cause usability issues for those using smartphones and tablets. In some ways, developers were forewarned: portable devices that browse the web have been available for a while now, and anyone who used, say, a stylus-based user interface like a Nokia 800 knew that there were going to be big problems if and when we moved away from mice.

So suddenly we're at a stage where developers really do have to design their applications to run on multiple platforms - not similar platforms that merely differ in terms of how you write to a file, or receive a button down event from the user, but platforms that work in such radically different ways a developer has to think about designing entirely different user interfaces for each.

Is this a step back? I don't think so, we've been down this route before, when the great migration of text-based user interfaces to WIMP (Windows, Icons, Mice, Pointers) in the mid-eighties. The difference then was that the latter actually won out, whereas I have no idea whether future user experiences will converge on a single type in the near future.

It's nice, however, to finally see some excitement in the computing world after decades of stagnation.

CyanogenMod 7

Well, CM7 has finally been released. I'd love to be running it but I'm relying on my phone for Internet access, as I'm temporarily without DSL at home (due to the impending move...)

In the mean time, I honestly haven't seen any problems with CM7RC1, with the possible exception of some things I suspect are application errors not OS errors (The Twitter app has some awful quirks, for example.)

For my view on RC1, try my brief look at CM7RC here. I also posted some general comments about CyanogenMod, and how Google's decision to make Android an open operating system has real world benefits for everyone.

More thoughts on IndexedDB and Web SQL Database

I've been reading the latest thread discussing the W3C's decision to deprecate Web SQL Database, and it isn't pretty. Key take-away? Web developers don't want IndexedDB, web browser writers don't want Web SQL Database. The major sticking point concerning the latter is the dependency of the spec on SQLite.

Some random thoughts, in no particular order:

1. SQL is the storage lingua-franca of the World Wide Web, for better or worse. Back-end code is generally discouraged from using custom storage solutions, with access to a database with a SQL API more common, and SQL is even built-in to systems like ColdFusion (not that that's an endorsement...) as an alternative language for accessing internal data structures. No serious web developer can work for very long without a basic understanding of SQL.
2. SQL's use has not been without criticism. See "NoSQL".
3. SQL is the only "standard" language for relational database access that has widespread familiarity. Alternatives, such as the proposed RelationalDB Javascript API, are entirely new, unfamiliar, APIs that developers may eschew by default. They are also re-inventions of the wheel.
   
4. It's very hard to implement a good SQL engine even if you have a good library of low level table management code.
5. Abstraction is nice in theory, but has a tendency to be overdone, leading to overly complex, bloated, code that requires huge amounts of memory and CPU usage.
6. The W3C isn't very good at putting together useful standards. CSS is a disaster - poorly defined concepts leading to multiple ways to "do" the same thing, few of which work. All W3C standards for storage, thus far, have been supremely unpopular. HTML5 introduces the second iteration of multimedia systems which, despite heavy support from Google and Apple, are highly unlikely to achieve universal usage due to still unresolved functionality and standardization issues.
7. IndexedDB is touted as a replacement for Web SQL Database but does not contain the same functionality. Web SQL Database is a relational database access system. IndexedDB is an indexed table system. Both are "storage", but are no more related than BerkleyDB and Pilot Analysis Server.
8. It is not clear what the use case for IndexedDB is, aside from being a last resort way to store data. At no point did anyone apparently say "I'm a web developer. I have to store persistent data for my application" and determine what the developer would want or need.
   
9. There's a view that IndexedDB can replace Web SQL Database if third parties create a SQL library in Javascript that uses IndexedDB as the back-end. This is a horrible, horrible, idea and the people proposing it are horrible, horrible people.
10. Those who promote the notion that someone can always write a SQL library in Javascript would, to my mind, have to concede that there's no reason why it would be impossible to implement SQL within the browser.
    
11. Web SQL Database doesn't have to be the only way to implement SQL storage within a browser. If the API is flawed, a replacement that has the same positive features, but few of the negatives, ought to be proposed.
12. I agree that SQLite's implementation of SQL should not be "the standard". It creates dependencies that should not exist, not just on SQLite, but on the technology stack SQLite is built upon.
13. SQL is a living standard, despite the best efforts of ANSI. While this is promoted as a disadvantage by Web SQL Database's critics, it's actually an advantage if you're trying to build SQL into a web standard. It means you can define a subset/superset of SQL that benefits from SQL's familiarity but is suited to the task at hand, without having to worry that your subset/superset will be unfamiliar, or that there'll be an argument about your variant not being some arbitrary version that doesn't really fit what you're trying to do.
    

At the end of the day, I don't necessary disagree with the deprecation of Web SQL Database. It is, however, a good prototype, and its indicative of what developers actually want. So the question I have to ask is why is the W3C even bothering with IndexedDB, let alone actually defining it as a formal standard that every browser will need to support? Is it really that likely that the API will get any serious level of usage?

Would it not make more sense to start over, look at what web developers actually want, and try to put something together they'll use?

Blog housekeeping: Taking a break

There's a reason I've been posting at least one article a day since the beginning of March - I need to brush up on my own skills concerning web traffic, advertising, and other issues my clients need. Some conclusions?

• Advertising is pretty close to not worth it. There were over 500 hits on my site during March, and several clicks on the ads (I believe the Adsense T&Cs say I can't say how many - what I will say is that the number was on the lower end of the range other websites say is normal, but within the range.) At this point, Adsense is estimating a dollar figure for these ads so low it'll be years before Google mails me a check. And that's the estimate, the amount of verified "revenue" for July 2010 - February 2011 is less than 1% of the estimate for those months! I'm going to keep the ads up for one more month, and I'll review what happens after that.
• Google provides some useful tools, including Analytics and Webmaster, to help content makers look at how their sites are accessed. Webmaster concentrates on the "Google" side - what's driving traffic to your website? How does it appear on the web? I actually noticed that some times people were hitting my site after making queries that I didn't directly answer, but were asking things I was interested in writing about. So I wrote articles on those subjects.
• Analytics focuses on how users use your site. Behind the scenes it tries to identify specific users so that it can provide more accurate stats than, say, Blogger's "Stats" dialog. While Blogger might say you had 25 hits in one day, Analytics may report that only four people visited your site, but they each visited an average of six pages, and were on the site for an average of 10 minutes, etc. Like Stats, it also provides information broken down by how people reached the page. Analytics is, unfortunately, easy to block and frequently is, but it certainly gives you a lot of useful information anyway.
• Other useful tools? Feedburner - It's a Google thing and entirely integrated with Blogger, and has features like the ability to set up an auto update of Twitter. Feedburner basically takes over your RSS feed, providing a customized version for those who want to subscribe using RSS.

In the end though I learned that not a lot of people are interested in this blog, that on occasion you'll have a hit (one article, unfortunately one of my flamebait ones, generated about 12% of the traffic last month) but most will be largely unread. But, on the positive side, Google seems to trust blogs a little more than other websites when coming up with search results, which means if you're just out to amplify your point of view, well, they're a great way to do that. I'm going to blog more lightly this month. But I hope to be setting up a useful HOWTOs site in the next few months that'll be more than just a bunch of opinions. Talk soon, Paul