….Why don’t I just bill the user via email using something like PayPal? Think about it, the user enters their email and phone number on their phone, promises to pay the 99 cents when they get to a real computer and that’s it. Done. No middle man, no carriers, no aggregators, no e-wallets, nothing. Just an old fashioned billing system….there will be lots of people who will never pay. Fine….Some will gladly pony up for the convenience, others will try to ditch the cost because they’re like that…. If they lie about their email or SMS, then they don’t actually receive the answer…. Bill My Email. Quick, easy and simple. via [Russell Beattie Notebook]
Not the first really good idea from Russell.
Apparently some top Xbox execs are quietly confirming that the Xbox 2 isn’t going to be backwards compatible with original Xbox games. via [Engadget]
MSDN Magazine: 2, Raymond Chen: 0!!!!
On rereading Joel’s article, I think his argument boils down to:
He’s not denying the need to rely on “external dependencies,” he’s advocating that such dependencies be localized. Why? Because when there are several external dependencies, they have a tendency to have internal dependencies, and you tend to need a very specific set of versions and it’s a source of complexity and, therefore, application brittleness.
Hiding multiple dependencies behind a single dependency is A Good Thing. This is what I was getting at in my previous post about “touch once, fix everywhere.” But I still don’t see how this supports his thesis that Microsoft lost the API war, since API dependencies still exist. And it only supports the “Web Apps will rule” conclusion to the extent that the client value really doesn’t depend on an external service (API). If you need to make music (which is only a shorthand for “things which, for connectivity, computational, security, or resource issues make sense to execute locally”), you’ve got to have a local API.
Corporate development choices are driven by the imperative to rapidly deliver customer value. Developers have their own values (language preferences, philosophical agenda, etc.) which sometimes conflict with this imperative but when push comes to shove, a CTO’s job is to “get it done.”
The great advantage of Web Apps for corporate development, and to a slightly lesser extent for ISVs, is the “touch once, fix everwhere,” deployment model. The hyperlink and button Web UI paradigm has a “don’t make me think” advantage and is easy to develop, but really, what makes the Web ideal for corporate development is that because corporate apps evolve in a much-less disciplined manner than commercial software, Web-based deployment can get a fix “into the field” in a matter of hours.
Visual Studio Tools for Office gives a hint of how Web-based deployment can be combined with the ultimate fat client: Microsoft’s Office suite. The problem is that even VSTO does not yet have an appealing solution for bestowing trust. There needs to be an easy yet completely trustworthy rights-granting process: in a completely trustworthy manner, the publisher identity and a comprehensive list of security requests must be presented to an administrative actor (either a sufficiently trustworthy end-user, a remote operator, or a system process). Basically, .NET’s got the publisher-identity stuff down, but the list of security attributes and process by which rights are granted are too obscure.
You need something along the lines of a firewall: I was just configuring a system for my sister and got an alert that something called “Backweb” was trying to access the Internet. I Googled for it and found that it was the result of having just installed a Logitech device: okay. Remove the step of having to manually Google for an explanation and extend the firewall-like “Allow, Allow once, Block once, Block forever” across all security attributes and you’ve got the type of UI I’m talking about. Modify it so that instead of my sister getting the message I could set up her system to pass the security request to me (her sysadmin) for either manual or automated decision-making.
Short of that type of capability, the fat-client model will always be less appealing than Web Apps on the deployment front.
Joel Spolsky’s (why hasn’t Software Development hired him as a columnist?) Microsoft Lost the API Wars has a series of solid observations and at least one brilliant construction (“Chen v. MSDN”), but I’m afraid his title and conclusion aren’t supported by his arguments.
He hoists himself on his own petard when he says “The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing.” You need a media API to sing. Maybe not Redmond’s mciSendString, but whatever you choose, HTML isn’t a complete platform. You still need data access, networking, and threading. Initialization and configuration customization. Error handling and recovery. Logging. File system access. Email. Messaging. Globalization. Security, encryption… Well, I’m just running through namespaces now.
Where have Web Apps and thick clients gone head-to-head? Email. Personal finance and tax software. It seems way premature to announce the thick client dead based on those markets. Anywhere else?
I’m not discounting the benefits of Web Apps, which make form-based UIs as easy to construct as in Visual Basic (you want to say “even more”? Fine, I’ll posit it.) and, therefore, vastly easier than with Win32 APIs. Even more importantly, Web Apps are great for occasional use (love that hyperlink!) and are “touch once, fix everywhere.” But on the other hand, media clients require fat clients.
You can’t get away from the need for lots of APIs when developing applications. That Microsoft APIs must now compete for favor with APIs from Palo Alto, SourceForge, or where-have-you is true, but that’s vastly different than losing. The game is barely afoot.
Oof! I woke up this morning to find my Inbox filled with “gotchas”. My latest SD Times column claims that Microsoft “got the Tablet PC right the first time.” Conveniently forgetting PenWindows and WinPad. No way to finesse my way out of this one: just a stupid statement on my part.
These guys have patented a gadget for stabilizing your Tablet PC in an ergonomically correct way. Not in production, and it doesn’t look like it holds the Tablet PC in a natural position (it looks like it requires your elbow to be thrust out too far), but I was thinking that there needs to be a solution for writing in hand beyond “grip the far side with your fingers and rest the inner side on your forearm.”
That’s it: I’ve just unsubscribed from Scoble’s link blog (headlines from 1400 feeds). Whatever the solution is to post-linking while maintaining credit / click-through, titles are insufficient. Scoble generally posts in batches of several dozen things he finds interesting. I’ve said before that I’m skeptical of linking without commenting, but even if I might accept the value of a “human aggregator,” without editorial comment, there needs to be some hint beyond the title.