Long ago, in the mid and late-90s, the mobile device market was a bit different from today’s. Palm led the PDA category, with monochrome devices that operated offline, until the Palm VII and its ultra-slow Internet service came out. The Palm VII was all the rage amongst early-adopters…I even bought the erstwhile publisher of Visual Studio Magazine’s predecessor one and shipped it to him, because they were available in New York, but not in the Bay Area, where he was.
Then a Canadian company called Research In Motion came out with the Blackberry. It was also monochrome, and its form factor was that of an alpha pager. It was not a phone. But, with proper configuration, it could get your email over the air, in real-time, sometimes even before the message showed up in Outlook. And it had a wonderful QWERTY keyboard, that somehow made thumb-typing feasible. It could also sync your calendar and contacts over a USB cable, just like the Palm PDAs. I had one and it was pretty cool. Click here for a picture of that model.
To counter Palm, Microsoft came out with their PocketPC platform, appearing first on Compaq’s iPaq device. A color screen, a workable on-screen keyboard (versus Palm’s “Graffiti” stylus gesture input) and a Windows-derived software platform made it a compelling product. And with WiFi options, the thing count be nicely Internet connected, at reasonable speeds.
When Pocket PC morphed into “PocketPC, Phone Edition,” the PDA platform became the first version of Windows Mobile, the one people now love to hate. Some said WinMo devices were just little PCs that could make phone calls, but when Phone Edition came out, that was literally true.
By this time BlackBerry units had also grown into phones, and Redmond’s competitive sights slowly shifted away from Palm in Silicon Valley up north to RIM in Canada. Microsoft knew that RIM had two things they were missing: push email and physical keyboards. But those two things could be crafted by Microsoft and its OEMs, respectively, and given that a majority of RIM devices were in any case syncing against Microsoft’s own Exchange Server, that meant Microsoft could provide the entire solution.
Microsoft was able to build its own Over-The-Air (OTA) sync technology, to which it applied its usual nomenclature savvy, christening it Exchange Sync. They then partnered with various handset OEMs, ironically starting with Palm and its 700w unit, to produce WinMo phones that featured the technology. Other phones followed, including the Q from Motorola and various units from HTC and Samsung.
This was (and is) a really competitive offering, but Redmond, with its business model, became its own worst enemy. The first problem was the then-current versions of Exchange and Windows Mobile did not ship with support for Exchange Sync. Exchange admins could install it though, without too much hassle. On the handset side, certain OEMs shipped their first units without the Exchange Sync client, promising an in-store flash ROM update to add it later on. Between the server and client, you had to be really determined to get Exchange Sync to work, and that was a pity.
Eventually, the releases Exchange 2007 and WinMo 6 came, and both had Exchange Sync support built in, making provisioning much simpler and, finally, delivering a push email platform that avoided the expense of BlackBerry’s Enterprise Server (BES) product. Sync fidelity was really good too, eventually allowing users not just to accept appointments, but to check for conflicts before doing so. Microsoft’s ducks were finally in a proverbial row. And Redmond was ready to beat RIM and own the phone space.
And then, as if from nowhere, the iPhone came out. The holy grail for mobility shifted from keyboard and OTA push/sync to UI elegance. The first iPhone wasn’t much for push email, but the second one was. In an ironic twist of fate, Apple added its own (licensed) support for Exchange Sync and, while not as good as WinMo’s implementation (even now), it was good enough for many. Add to that the innovation of the AppStore, and Microsoft’s ducks moved out of row formation and went every which way. Then Android came out and made the competition even worse; Google too has licensed Exchange Sync in order to make its mobile platform business-friendly.
Exchange Sync was important, and it still is. It remains the only communication technology that provides a mainstream alternative to BlackBerry (solutions like those from Good provide alternatives too, but they’re just not mainstream). Apple and Android have Exchange Sync (and GMail even implements it on the server), but their implementations are less complete than Microsoft’s. That can become a vulnerability if players like RIM and Microsoft can achieve something like parity on the touch-screen and user interface side.
RIM has tried to do this with BlackBerry OS 6. Reviews are mixed, and the company may be headed to a slow decline. With Windows Phone 7, Microsoft is also trying to keep the sync fidelity and pair it with a great consumer-acceptable UI experience.
RIM tried to revamp their OS. Microsoft decided to build a completely new one. RIM’s approach seems like it might not have worked, and I actually think Microsoft’s looks pretty good. After spending some more time with a WP7 phone today, I believe that even more.
And because of all this, although Microsoft is not marketing WP7 to the RIM customer demographic, I think that demographic is where it’s going to get significant market share. RIM’s customers are more churn-prone right now than are Apple’s or Google’s. And they need the quality Exchange Sync experience that only Microsoft seems willing to implement. They want fun apps, and they want to spend more of their phone time using them. But they need what they do with their phones today to keep working. They may not talk about it, or lust after it, but they need it. If it were gone, they’d be outraged. And that means, if they jump ship from RIM, they’re going to need WP7.
This may sound boring, or anti-climactic. It may be tempting to dismiss it as “one dying dinosaur benefitting from another that is dying more quickly.” But I think that misses the key point. Microsoft has focused on messaging for a long time. Exchange Sync made for a really good client play and the licensing of Exchange Sync to Apple and Google has helped Exchange become an even more entrenched standard for corporate email and groupware. Now a new Microsoft mobile device, with consumer credibility, may show how important the message/sync focus was. If this works, then Microsoft can focus on Android and iOS afterwards.and we’ll see if the RIM-ex-pat momentum helps.
This past Wednesday, Beta 1 of Visual Studio LightSwitch (VSLS) was be made available to MSDN Subscribers. On Monday, it will be made available to the general public, at http://www.msdn.com/lightswitch. Even in advance of Monday, that site is already making useful content available. Specifically, a Channel 9 video called “Visual Studio LightSwitch - Beyond The Basics” is well worth the viewing time. In it, Beth Massi (Program Manager on the Visual Studio Community Team) interviews Joe Binder (a Program Manager on the LightSwitch team) and the conversation is a revealing one.
The two start of with what is emerging as the standard demo of VSLS: creation of a simple SQL Server database, with hierarchical relationships between tables, and some attractive screens with which to view, enter and maintain the data. VSLS is a new product, and Massi and Binder have to start with this demo.
But they then go past that simple scenario and bear out, in a practical demo, what Redmond folks like Dave Mendlen and Jason Zander have been saying for the last three weeks: enterprise developers can extend the standard functionality delivered by VSLS. As it turns out, Mendlen and Zander haven’t just been nursing their talking points…if anything, they’ve been understating VSLS’ virtues.
Joe Binder showed how VSLS extensibility works. He did so in a matter of fact way: he simply built a Silverlight control, and then used it in his LightSwich app. He then built a RIA Service, plugged it into the VSLS project, and almost instantly built a screen on top of it. The Silverlight control was built in a standard Silvelright project, and the RIA service was built in its own standard project type as well. The only “twist’ was that the Silverlight code could reference objects in the VSLS project and bind to one of its collections automatically.
What we learn from this video is that (1) LightSwitch projects can be extended in a serious way; (2) instead of building a bunch of new interfaces and special objects, VSLS extensibility is done with standard .NET technologies; and (3) that synergy between a new framework and standard, existing technologies, is additively augmented with (and not replaced by) VSLS APIs. VSLS pros can do what they do while teaming with .NET Enterprise devs doing what they do. That’s low on disruption and high on added value. And beyond that, each one can learn a bit more about the other’s discipline and make the result richer still.
I think this is how software should work. I think developers should be productive quickly and then have the opportunity to learn more and do even better. In other words, the skill levels should be Good and Better, rather than Bad and Good. LightSwitch makes that possible. Which means, despite fears out there which are utterly to the contrary, that LightSwitch helps .NET, and it helps .NET developers.
The team behind LightSwitch derives from the teams that built many of the Visual Studio data tools and data binding technologies, as well as from Visual Basic itself. They’re wonderfully pragmatic, if you ask me, and they fought hard to get this product out there. Lots of people, including folks at Microsoft itself, were skeptical of this product, and these guys got it done.
Version 1 won’t be perfect. Version 1 is never perfect. If things go well, Version 1 proves a point, and does it well enough for people to make a switch (as it were) and use the product in their work. I hope things go well. LightSwitch needs to succeed and so do the people who need it.
In this blog and in my column, I’ve written a lot lately about new technologies from Microsoft that seek to make software development easier. Technologies like ASP.NET Web Pages, Razor and WebMatrix, Access Web Databases and Visual Studio LightSwitch. Each of these technologies, I believe, is bringing much needed accessibility to programming on the Microsoft platform.
I’ve also written about Windows Phone 7 which, despite extreme skepticism in the press and analyst communities, has the potential to be an excellent SmartPhone platform. And I’ve explored rather deeply HTML 5, a technology that I believe poses an existential threat to Windows and to Microsoft itself, if Redmond’s inertia of the last several years persists.
As I consider all of these technologies, something emerges that, with hindsight, is frightfully obvious: they need to coalesce, unify, and harmonize. LightSwitch, which produces Silverlight forms-over-data applications, needs to target Windows Phone 7. Access Web Databases, which deploy as forms-over-data SharePoint applications, should perhaps have some conformity with LightSwitch, and vice-versa.
LightSwitch targets SQL Server Express by default. WebMatrix targets SQL Server Compact. Access Web databases target SharePoint lists and SQL Server Reporting Services. In other words, each of these exciting new tools targets SQL Server in some way (SharePoint lists are stored in SQL Server tables), but none of them targets the same edition of the product. I guess that’s OK for the first versions of each of these tools, but I hope these anomalies are addressed in v2 releases. Microsoft likes to talk about impedance mismatches in data access technologies, and I think they’ve created a massive one of their own.
What about HTML 5? Its threat could be blunted if Microsoft confronted it head-on. The version of Internet Explorer on Windows Phone 7 should be HTML 5-compatible. LightSwitch v2 should target HTML 5 as an alternate rendering target, which would enable LightSwitch apps to run on devices other than those running Microsoft operating systems, or the Mac OS (on Intel-based Macs). I wouldn’t mind seeing SharePoint get more HTML 5 savvy itself. It would enhance SharePoint’s richness, in every single browser, including those that run on mobile devices.
To me, the biggest downside of HTML 5 is the relative dearth of good developer tools for it, and the JavaScript heaviness it can bring about. But I would think that the HTML helpers in Razor and ASP.NET Server Pages could be a huge help there. Is Microsoft working on HTML 5 Razor helpers now? If not, why not? And WebMatrix aside, it should add good IDE tooling for HTML 5 in the full Visual Studio product.
Microsoft’s got a lot of good answers to a great number of important software development questions. Now it just needs to make those answers coordinated and consistent. If it can really integrate these tools, then it should. Divided, some or all of these tools will fall. United, they might stand. They could even soar.
At VSLive today, I had the pleasure of introducing Microsoft Corporate VP Jason Zander. And he had the pleasure of introducing Visual Studio LightSwitch. Pleasure is a theme here, because the product, to me at least, looks great.
LightSwitch is a .NET based environment, hosted in Visual Studio, that allows developers to build business apps. Quickly. It harkens back, with pride, to tools of old, like VB6 and FoxPro, that made data, and data maintenance UIs, first class citizens. These tools also treated line-of-business developers as VIPs, not as the great unwashed.
LightSwitch builds Silverlight applications. They can run locally (in or out of the browser) and they can also run on Windows Azure. They can work with any database, but the development environment makes it very easy to create SQL Server databases, and can then deploy them to SQL Azure. The stock UIs look very Microsoft Office-like, but third parties can build alternative skins/themes that plug right into the environment. Infragistics already has a prototype. Microsoft showed it on stage today. And it did look really nice.
Data validations are built in. Search is built in. Business data types (rather than simple database or .NET data types) are built in. LightSwitch takes away the burden of creating a bunch of plumbing for corporate apps. Plumbing that you either have to write every time, or else use some framework that, by definition, won’t be very standard.
Tools in the 1990s did this too. Then the 2000s came and many of those tools largely went away. Now one has come back, and it targets the modern Microsoft stack, including Silverlight and Azure and the Entity Framework and WCF RIA Services. With considerably less working in the weeds to use these technologies than has been required until now. And, yes, LightSwitch lets write .NET code when you need to.
I watched the tweets fly by during the keynote. Many expressed curiosity and excitement. Others expressed dismay. Dismay that “lesser” developers will have access to the modern stack. Dismay that they’ll build the apps quickly. And dismay that Microsoft wants to enable them. The dismay was often uttered under the cover of concern for stability, scalability and maintainability.
To the dismayed, I must say: get over it, and stop worrying. There’s room for productivity developers. There’s room for enterprise developers. They don’t have to be at odds. This is not a zero sum game.
We need productivity programmers to be accommodated on the Microsoft stack. if they are not, they will go to other stacks. In fact, they already have. We have to try and get them back. They create opportunities for enterprise devs, and they create opportunities for their customers. I hope LightSwitch appeals to them. I hope it brings them back to the Microsoft ecosystem. I don’t know if it will. But even if it doesn’t, that doesn’t make it a bad idea. Celebrating difficulty and demonizing productive ease? To me, that’s the bad idea.
On Thursday, a scathingly bad review of Windows Phone 7 (WP7) was published by InfoWorld. I had considered writing a post to refute some of its points, but Paul Thurrott did just that, and did it masterfully. There's little value that I can add to his post, other than to link it and suggest that you read it.
Meanwhile, Sunday and Monday, much more fair reviews were posted at Cnet, ZDNet, Gizmodo, Engadget and MobileCrunch. All of these reviews were based on actual hands-on experience with a prototype Samsung device called "Taylor;" the InfoWorld post was based on the author's apparently unenjoyable experience at a product demo.
I'll let you read the reviews on your own and won't provide a CliffsNotes style redux of them here. What I will do though, is try and present some of the consensus findings, and how I think those findings bode for the success of the WP7 platform. Here goes:
1. The touch screen is accurate and fast. This is huge...my biggest concern about WP7 was that in the early demos, the combination of the hardware and software seemingly produced a substandard touch experience. If you look carefully at those early demos, you will see flicks and swipes that are either ignored, or which produce responses on an unacceptably delayed basis. What I said then is that Microsoft and its OEMs needed to fix this and make it flawless, otherwise it would be a deal-breaker. Seems like this gap has been closed, at least on the Samsung hardware that the reviewers used in their evaluations.
2. The keyboard is accurate and fast too. A couple of the reviewers were emphatic in their enthusiasm over the keyboard. This is a big deal too, especially as a high-value candidate WP7 customer group is current BlackBerry customers, and they are used to physical keyboards. This really looks like an area where Microsoft can tie with Apple and win against Android.
3. The highly text-oriented Metro interface is very appealing to certain users, and others find it disorienting. This is about what I expected, and even a bit better for Microsoft than I might have predicted. Microsoft decided -- wisely, in my opinion -- to craft a smartphone user interface that was not derivative of the iPhone's or Android's. I applaud this, but the danger in that is that Microsoft is breaking with a standard, and many people will see that effort as folly, and its work product as unusable. The outcome seems to be that InfoWorld hates it, a couple of the other reviewers were uncomfortable with it, and the remainder were pretty positive. Even Cnet (one of the doubters) sees the validity in doing something different. Together, these reviews provide a genuine endorsement of Microsoft's UI strategy gamble, even if not a vote specifically for Metro, in all cases.
4. Exchange integration and email in general seem very well implemented. Once again, this will appeal to the Blackberry crowd. Office integration seems more optimized for viewing documents than for editing them. That’s a disappointment, to be sure. But it’s no worse than the other platforms.
5. The camera is really good, highly accessible, and fast. This could be an unexpectedly important advantage for WP7. Megapixels aside, the state of the art in mobile phone cameras still sucks wind. If Microsoft breaks this precedent and people hear about it, then it could be a nice driver of new handset sales for the platform.
6. The Web browser, though not best in class, seems very good. This will surprise people who assume that Microsoft's lack of a WebKit-based browser means WP7 can't be functional for Web browsing. Opinions seem mixed regarding lack of HTML 5 support. My take: this will need to come fairly quickly, but is likely not to be crucial at launch. My Motorola Droid has a WebKit browser with decent HTML 5 support. But I think the only place I've put it to work was on the HTML 5 test and demo sites I hit with it, out of curiosity.
7. Everyone thinks the lack of cut and paste is unfathomably sucky. And they're right; it is. I think there's a very high probability that this capability will come in an over-the-air OS update within months of launch, and maybe sooner. In fact, I think there's a 30% chance that Microsoft will surprise us and have cut and paste ready for launch itself. Most reviewers bemoan the lack of multitasking too. I think this is less important – I think most iPad owners would agree, or at least they will up until the iOS4 release for their devices. That’s sort of my point: you can live without multi-tasking, until you have it, and then it’s a non-issue.
8. Facebook integration is elegant and simple. It "lights up" exciting and impressive functionality on the phone. But it's not configurable enough and is unwieldy for people with a large number of Facebook friends. Good enough for v1.0, but probably not for v1.1, let alone v2.0.
9. Twitter integration, other than through Windows Live, is conspicuously absent. Either Microsoft needs to add this, or a third party Twitter app, hopefully from Seesmic, needs to be be available immediately and its integration with WP7's hubs and other features must be exemplary. If neither a native nor good 3rd-party app is available at launch or very soon thereafter, it could make WP7 a laughing stock. That could happen anyway, of course, but the lack of Twitter integration could be a laughter accelerant.
10. UI inconsistencies in WP7 exist, especially around search and hidden “long taps,” and could prove fatal. Or not. On the one hand, WP7 needs to be perfect, and these apparent issues make it fail the perfection test. That, in turn, could prevent WP7 from getting over the incumbency lock that Apple and Android have on the market. On the other hand, neither of those platforms is perfect either, and they certainly were not perfect at launch. So maybe people will cut WP7 some slack, given the high points already discussed here.
11. Overall, WP7 will make Microsoft a contender in the mobile arena again. How long it can maintain that contention, and whether it can convert it to a leadership position is anyone's guess. But it is trying, it is getting traction, and it has the will to fight. Given the lowered expectations just about everyone has of Microsoft in this market, the mere fighting spirit and encouraging interim achievements it has delivered may catch people's attention. Heck, maybe that's why the crash and burn of Kin was so public and extreme.
WP7's introduction and market positioning will be seminal for Microsoft, to the upside, or to the downside. A significant success could restore morale amongst MS employees, partners and customers. If it merely establishes a toehold, that could be very positive too -- just look at Bing for evidence of this. But if WP7 flops, it could cause irreparable damage to a company that is already diminished in the mobile and consumer space, a space which is becoming ever more influential on the enterprise arena that is Microsoft’s bread and butter.
A WP7 flop could come even if Microsoft does everything right with the product. Many people have true disdain for Microsoft, and at least some of these people need to be won over. That's hard when the hatred runs so deep and the loyalty to other players seems to impenetrable.
To win this one, Microsoft needs to needs to do what it did to make Word overcome WordPerfect, Excel beat Lotus 1-2-3, Exchange overcome Notes, and Live Messenger overcome AIM, all combined with the chutzpah, naïveté and finesse used to launch Bing and make everyone forget about Live Search. Given all but the Bing victory occurred long ago, when Microsoft was much more on its game, this victory is nearly impossible. But if you bet on Microsoft, you'll certainly get good odds.
You might get a really good phone too. And isn’t that the authentic goal?
This week, Scott Guthrie, Corporate Vice President at Microsoft’s Developer Division, announced, via blog post, the early Beta release of a new tool called WebMatrix. WebMatrix is a free developer tool that enables Web development geared toward what might I might call Markup-and-Script developers (more on that in a minute). And although WebMatrix draws upon technologies already, or soon to be, present in the fuller ASP.NET Web development platform and the Visual Studio integrated development environment (IDE), it is a radical departure from what those technologies have evolved into. Some review of Microsoft developer tool history might bring this into perspective.
Simple Beginnings
In the early and mid 90’s, Microsoft’s developer tools were pretty simple and straightforward. For Windows development, Microsoft had its Visual Basic (VB) product, and for Web development, it had something called Visual InterDev. For hardcore developers there was Visual C++, and for adherents to the acquired FoxPro product (now called Visual FoxPro, of course) there was that too. The four products were sold together as a single entity called Visual Studio, but that name was really a bundle and umbrella brand for the four constituent products. Most Visual Studio customers used VB and InterDev for their work. VB featured an easy drag-and-drop design environment for building Windows desktop applications: drop controls on the form, set some properties, add a little code, and you could have a functional application. Visual InterDev provided an IDE for developing Active Server Pages (ASP) applications, which were simple text files consisting of HTML and Visual Basic code (actually a scripting version of VB, called VBScript). The VBScript was embedded within the HTML markup within <% and %> tokens so that the ASP engine on the Web server would know to parse it and send it to the Active Scripting engine. The files ended in an .asp extension so that the ASP engine would be invoked in the first place.
None of this was especially difficult, and yet it was impressively powerful. With VB, and ASP/Visual InterDev, Microsoft provided a way for clever, logical thinkers to be productive programmers in a short amount of time, and to use the same programming langauge expertise for both desktop and Web applications. It was the best of times; it was the worst of times. Microsoft made programmers productive, but the low barrier to entry meant that lots of VB and ASP applications were written by bad programmers, and it gave the platform a bad name. Meanwhile, Java and its Java 2 Enterprise Edition (J2EE) flavor were eating VB and ASP for breakfast. J2EE was more complex and fragmented, but also more robust, scalable and, to be honest, it attracted a higher caliber of developer.
Redmond’s Revenge
Microsoft’s response was to create .NET. Version 7 of Visual Studio was the first version of Visual Studio .NET. It provided a single IDE for desktop development and Web development, which could be done in a new version of VB (called VB .NET), or in a new langauge called C#, which bore an uncanny resemblance to Java. C++ could be used inside this IDE as well, and so could Microsoft’s own licensed version of Java, called J#.
This version of Visual Studio and its Web technology, now called ASP.NET, extended the forms metaphor to Web development, such that the old “VB” and “ASP” were now called WinForms and WebForms, and they worked in a very similar manner. A (surprisingly) little known fact is that ASP.NET applications could still be developed using the old <%…%> syntax in the markup, without the need for forms and controls, but there was no encouragement from anyone to write ASP.NET code as if it were ASP.
The new IDE was more complex than any of the old ones, but in unifying them, it added simplicity too. A universal forms metaphor and a unified IDE, with the added rigor of the .NET Framework, and fully object-oriented programming made .NET very competitive with J2EE. Also, the programming was just enough harder to filter out many of the less capable developers who were on the Microsoft platform before. Microsoft made a big bet, and it won.
The Plot Thickens…And So Does the Platform
But Microsoft lost too. In political terms, it abandoned its base. And I think it did so based on a notion of false choice: it thought it had to cater to enterprise developers or productivity programmers, but that it couldn’t do both. And then it got worse: after the 2005 edition of Visual Studio and version 2.0 of the .NET Framework came out, Microsoft added a trio of technologies: the Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF). Originally these three technologies were planned to be part of what became Windows Vista, and were to be known collectively as WinFX. When they shipped, however, Microsoft decided to dissociate them from Vista and allow them to run on XP as well. Since they were really extensions to .NET, Microsoft rebranded the collection as .NET 3.0.
And this is where things started to get really complex. WCF and WF were not, and are not, for the fain of heart. WPF introduced a completely new way to create desktop applications. And while it added a slew of new capabilities, its designer for Visual Studio removed most of the productivity from its WinForms counterpart. These technologies have since been updated and have been joined by Silverlight (a relative of WPF, remade for Rich Internet Application use), ASP.NET MVC (which does away with the WebForms metaphor, but does not return us to the single-file comingled code + markup model), Langage INtegrated Query (LINQ), the Entity Framework (a data access model which sits atop, but effectively replaces, the native data access core, known as ADO.NET) and an array of application lifecycle management features within the Visual Studio IDE itself.
This is neat stuff. This ups the challenge to Java. It accommodates development of very large applications, built by big teams, distributed across the world. All of that is good. Much of it is crucial and necessary. But none of it helps that original constituency of developers who want a highly productive environment in which they can build entire applications (albeit smaller ones), quickly, easily, and largely by themselves. And those folks have been willing to be neglected for only so long.
Voting with Feet
Many of those productivity programmers have left the Microsoft platform, and many newer, younger programmers who also fit that profile, have steered clear of .NET and Microsoft completely, for this and a variety of other reasons. A lot of them have moved to languages like PHP. If you look at PHP, you’ll see it bears a strong resemblance to the old ASP: code comingled with markup, contained in blocks offset with <?php and ?>, inside files with a .php extension. There’s no huge framework, nothing really like WCF and WF, and most PHP developers use very light tools for editing their code…thick IDEs exist, but aren’t so much the norm. PHP has a huge and enthusiastic community around it too. And while it may not be the right environment for those huge enterprise apps, it’s good enough: Yahoo and Facebook run it, in fact.
So we’re left with a situation where Microsoft is losing in market share, passion and enthusiasm to a development environment that works quite similarly to something Microsoft had 15 years ago. Yes, there are important differences: PHP runs on Linux as well as Windows. PHP is open source. Its syntax looks much more like C or JavaScript than it does Visual Basic. But the fact remains it has a simplicity and short path to productivity that intrigues developers and empowers them, and that’s exactly what Microsoft knowingly and willfully jettisoned
Microsoft could always promote the fact that code + markup still works with ASP.NET. You can still use <%…%> syntax…and store everything in single files with an .aspx extension that you can then just push up to a Web server. You can edit these files pretty easily in Visual Studio. If you have the discipline to ignore all the other stuff in ASP.NET and the .NET Framework and all those menu options and toolbars and dockable windows in Visual Studio, you’ll be fine. But advising abstinence and calm is no way to win over an entire population of developers that wants to spread out in territory that is friendly and navigable to them
Back to Basics
So instead of providing guidance around using a subset of ASP.NET Web Forms and a subset of Visual Studio, or just bringing back the old tools, Microsoft has done something far better. Through the introduction of a technology code-named Razor and its use in a new code + markup environment called ASP.NET Web Pages (not Forms) and provision of the new, highly streamlined WebMatrix IDE, Microsoft is beckoning the productivity programmers back, in a credible way, without , condescension. Now instead of starting your code with <%, you can use a simple @ sign for embedded expressions (and you don’t need to end the expression with anything!) or use @{ and } for full-on code blocks. You put everything into files with a .cshtml extension (you can use .vbhtml too, with the inline code in VB.NET but the Razor code block syntax differs slightly). Razor also provides so-called HTML Helpers that make short work out of complex tasks. Want a scrolling window with tweets from me? Just embed this code in a page:
@Twitter.Profile("andrewbrust")
There’s another helper just like that for Facebook, and a collection of others for creating data-driven user interfaces, sharing links on social networking sites and performing Web Analytics tasks.
WebMatrix also comes with a workstation-hostable version of Microsoft’s Web server (Internet Information Server, or IIS) called IIS Developer Express. And it comes with a small, file-based database engine called SQL Server Compact which is entering its 4th version, but only its first version optimized for ASP.NET. SQL Server Compact databases, and SQL Server Compact itself, can be easily deployed to any Windows Web server over any file copying protocol, including FTP. And WebMatrix can do that for you, with just a couple of clicks. It can even help you find a hoster and provision an account. There’s also built-in starter features for creating and editing data, and for performing SEO analysis on your pages.
Web Matrix isn’t exclusive to ASP.NET and SQL Server by the way…it also lets you edit and create applications using PHP and MySQL! That’s a HUGE step for Microsoft, especially with regard to the database.
Gimmick, Experiment or New Leaf?
WebMatrix isn’t perfect, certainly. And it’s streamlining sometimes borders on plain old bare-bones. There’s no IntelliSense (pop-up syntax completion), no rendered view of your Web Pages (you have to run the pages in a browser for that) and not much documentation that I can find, either on the tool itself or on Razor and the HTML helpers it includes. Also, this is not the first product Microsoft has had called WebMatrix…an earlier product with the same name, back in the early days of .NET, which provided a simplified IDE for creating ASP.NET WebForms, was put on offer, also for free. That product gave rise to the Visual Studio “Express” Editions…but the original Web Matrix project died.
Will its successor suffer a similar fate? Is this just a freebie tool that Microsoft will obsess on for a while and then let languish? Is it just a cynical attempt at converting PHP developers over to the full-blown ASP.NET stack? It’s hard to say…and Microsoft needs to make a real commitment to this WebMatrix if it wants developers to invest in it.
But it’s a great start, and it’s the first thing I have seen in a while from Microsoft that makes programming powerful and fun at the same time. I hope it’s a precedent, and not mere anomaly.
On Wednesday, Microsoft announced that their short-lived social networking-oriented phone, Kin, was being discontinued. I’m glad. In a post I wrote over a month ago, I implored Steve Ballmer to kill the product. I didn’t just do that because Kin 1 and 2 received terrible reviews; I had other reasons to distrust this product’s efficacy.
The Kin team has been led by Roz Ho, whose title has been Corporate Vice President, Premium Mobile Experiences. During the development cycle for Kin, a.k.a. Project “Pink,” there was some reporting that Ms. Ho led the team badly. The team was the successor to the crew at Danger, the company that built the T-Mobile Sidekick, and which Microsoft acquired in 2008. The negative reporting on Ho included the suggestion that her leadership made for morale so low that most of the original Danger team quit their jobs.
Cnet’s Ina Fried broke the Kin Killed story Wednesday. In her piece we learned that the Kin team would be merged into the Windows Phone 7 group and that:
“Roz Ho, the Microsoft executive who lead the unit that developed the Kin will oversee the transition of the team and then move to an as-yet-determined role at the company, according to a source.”
None of this is surprising. Given the product’s history, It was clear to me that Microsoft would have to kill their Kin. But Windows Phone 7, which still looks promising, got under development quite a while back. When that team was organized, the legacy Windows Mobile team was disbanded. Why didn’t Roz Ho get the heave ho, too? (Ahem!) With WP7 on track and looking good, why on earth did Microsoft bring Kin to market? Here are my top 10 reasons, some more serious than others (drum roll, please, Paul):
10. Taking down a Corporate VP wasn’t politically feasible. Kin had to be brought to market, and had to fail, in order to topple Ho from her position and consolidate power in the WP7 team.
9. The investment in Kin, both in terms of the Danger acquisition and subsequent development was really big. Ballmer figured he had to give it the old college try…and then bail quickly if indeed the phones were duds.
8. Verizon wanted their own Sidekick-like device (not wanting to cede that part of the market to T-Mobile) and implored Microsoft to persevere with Kin’s development.
7. Microsoft knew the Kin would fail, but they wanted to use it as a trial balloon for Kin Studio, the companion cloud service that replicates most data and content stored on the phone. This would help Microsoft determine if the Studio concept should be used with Windows Phone 7 when it launches later this year.
6. When the Kin team finished its work, it was nearing the end of Microsoft’s July 1 fiscal year. They had leftover TV ad budget and they had to spend it on something.
5. Microsoft got the kin.com three-letter domain name and they couldn’t let it go to waste.
4. Microsoft really didn’t want Sharp to be a Windows Phone OEM. They didn’t have the heart to tell them though. This was their passive-aggressive way of getting Sharp to back off.
3. Microsoft was pissed at Engadget for their negative review of Kin. So they killed it and gave Gizmodo the scoop.
2. The announcement yesterday was an elaborate April Fool’s joke. But its ship date was delayed until the end of the quarter.
and…
1. The whole thing was a dare to Verizon from Apple. Jobs said if they carried the Kin in earnest for 2 months, he’d give them the iPhone in January. And Verizon really wanted the iPhone.
I once worked for a guy who told me sarcasm was the lowest form of wit. So be it. I’m done now.
This past Monday, June 21st, The New York City Council Committee on Technology in Government held a hearing on its proposed legislation, known as Introduction 029-2010, that would require all City agencies to publish their data online, in “raw” form. The data would be available to private citizens who wished to analyze it, hobbyist developers who wished to work with it, and commercial entities looking to utilize it internally or create products that use and add value to it.
Such initiatives have already taken root in other jurisdictions, including the U.S. Federal Government. Its open data portal, at www.data.gov, serves as a very good example to state and local governments who wish to implement the same sort of good government transparency through technology.
At first blush, the legislation would appear difficult for anyone to oppose. Donn Morrill, Chairman of the New York Technology Council (NYTECH), eloquently expressed this point of view in his testimony at the hearing: “This should not be a contentious bill. None of you will lose a vote. None of you will lose an endorsement. None of you will lose a dollar in financing by supporting this bill. What you will gain is recognition from the community that your affirmative vote will open doors for enterprising companies to develop new and exciting ways to experience New York City.”
In my opinion, Morrill’s quite right; enactment of the legislation should be a “no brainer.” The fact remains, however, that there has been resistance to it. A year ago I was present, and testified, at another City Council hearing on last year’s version of the same legislation. At that meeting representatives from the Mayor’s Office, in their own testimony, discussed the then recently-announced NYC Big Apps competition and the data feeds that were published to facilitate it. They proclaimed the Mayor’s “customer”-centric position that only select data should be published, because only select data would be of interest to City residents.
The Mayor’s thinking, at the time, was that investment of City resources in producing feeds of all non-privacy-protected City data would be impractical, given that only a relatively small subset of it would be used. Committee Chairperson Gale Brewer disagreed, explaining that determining which data was valuable prior to its publication was virtually impossible. Andrew Hoppin, the New York State Senate’s CIO (follow him on Twitter at @ahoppin), made a similar point in his testimony this week, appealing to the City to “Resist the temptation to adjudicate what [data] is of value and what is not of value".
I agree, and said so in my own testimony at this week’s hearing. I think the whole point of publishing government data is that seemingly mundane data can form the raw material of extremely useful information, be it related to health, economics, commerce or even potholes.
The good news is that at this year’s hearing, the Administration’s attitude seems to have changed. The recently appointed Commissioner of the City’s Department of Information Technology and Telecommunications (DoITT), Carole Post, essentially the City’s CIO, expressed her agreement in principle with the legislation’s aim of making all agency data available. Where Post took exception to the legislation is in the cost and effort feasibility of making such a wide ranging set of data available in a relatively short timeframe. This is a tough call. As I said in one of my live tweets during the hearing, the "ask" of DoITT is big and scary. But if they express that, it looks like they're stonewalling. For what it’s worth, I think Commissioner Post is not stonewalling. I think she’s dedicated to this effort, and wants to avoid overpromising and under-delivering.
Getting the data out can be difficult, both for reasons of bureaucracy, and technology. If the data to be published is managed by a legacy mainframe application, getting it out there in digestible XML or CSV form may not be so easy. And even if it is, publishing static data is only the first step. Eventually the data should have an API (application programming interface) around it so that developers can query it interactively and, in some cases, create/submit data as well. Think about it: we don’t just want to get a list crimes that took place. We want to be able to query that list by neighborhood or police precinct, median income level of the area, severity of the crime, and determine also if the rate of crime in that narrowed category is increasing or decreasing. Insurance companies, real estate agents, and makers of security products may like to know likewise. And the City itself should want to know too, so resources in the next fiscal year can be allocated appropriately.
Beyond such analytical inquiries, there should also be an API for reporting crimes (which would require creation of data, not consumption of it) too. This could allow citizens to report crime, in real time, from their mobile phones, with the tap of a button in an app. The GPS in the phone could alert authorities to the precise location of the incident, and the phone’s camera could even submit a photo. Maybe such technology could address the “bystander effect” allegedly exhibited in the infamous Kitty Genovese stabbing case of the 1960s. Imagine if New York City government used technology to obsolesce a phenomenon made prominent in its own jurisdiction. Removing that blemish would be a proud moment.
I mentioned in my testimony that Microsoft’s Open Government Data Initiative (OGDI), should be considered by the City as one platform for serving the City’s Open Data. OGDI is based on the Open Data Protocol (OData - itself based on numerous open Web standards) and Microsoft’s Cloud platform, Windows Azure. OGDI is itself an Open Source starter kit that provides not just for the publication of data, but of a programming API and the ability both to read and write data.
Regardless of the protocol used, Open Data for this nation’s largest city is immensely important and it’s very heartening to see the Council and the Administration in relative agreement on this point. Should the legislation be enacted, and implemented, the opportunities for entrepreneurs and the potential benefit to the public, to business and to the City itself will likely be big, exciting, and inspiration for municipalities across the world.
June 21st, 2010
The Importance of Open Government Data
To all those present, good afternoon. My name is Andrew Brust. I help run a consulting firm, twentysix New York, here in Manhattan. I am also a technology columnist and blogger, and serve on the New York Technology Council’s Advisory Board. As I have explained in previous testimony, I am a lifelong New Yorker, and began my IT career in the employ of the government of the City of New York.
I’ve testified to this Committee before, voicing my support for Open Government Data. I’ll reiterate today that I feel the benefits of publishing data from all City agencies are huge. In the City of New York we have a large government consisting of many departments, authorities and commissions. Given the pervasiveness, especially recently, of technology in ordinary peoples’ lives, it only makes sense to publish this data online. Data published in raw form allows citizens to query that data from computers, smart phones, tablets and other devices. It also allows software developers, be they hobbyists or entrepreneurs, to create applications that analyze the data, mash it up with private data, or visualize it geographically, or through charts, gauges, and diagrams.
Just as the Federal government has created data.gov as a portal for data from Federal agencies, so too should the City of New York, perhaps through DoITT, create a portal for City data. This would provide a platform for an aftermarket in City data-based products and services. It could stimulate greater public participation in government. In the same spirit as the Green Book directory and the various NYC TV cable channels, a City data portal that were both human- and machine-readable could enable self-service acquisition of government information and make City services more effective in the process.
The prospect of opening up each data stream in each agency might seem daunting to City IT professionals. I would encourage DoITT and the individual agencies to conceive of the requirement with the right mindset. Data feeds are just software services, and good software is built on the premise of designing a service layer at the foundation. So rather than taking the approach of building closed systems and then opening them up, agencies should premise the architecture of their systems on building the services/feeds first, then layering application logic and functionality on top of them. With this approach, Open Government Data would become a byproduct of normal software development, rather than a burdensome, discrete step.
This would still leave the “back catalog” of applications and databases, of course, but that can be processed in a phased, scheduled way. Each pre-existing data source exposed would facilitate not just public consumption of the data but re-use of that same data by the agency in new software applications.
Mashup Examples Redux
In my previous testimony, I suggested some examples of how government data could be utilized and commercialized. Allow me to present these ideas, briefly, once more.
Google Maps should be able to show where the big potholes are; Zagat should be able to indicate which restaurants have a sterling Health Department inspection record; WebMD should be able to create heatmaps showing which neighborhoods are hardest hit by an epidemic, and the New York Times ought to be able to indicate which boroughs and neighborhoods are getting the most, or least, arts funding.
Retail consultancies should be able to show which precincts are best and least served by certain types of shops. Tourists should be able to see where the highest concentrations of hotel rooms are, and thus where the most availability and best prices may exist. Members of this Committee should be able to see how well Verizon is living up to its commitment to deploy FiOS service to all areas of all five boroughs.
Children’s Aid Society should be able to illustrate where concentrations of child homelessness and abuse exist. Food for Survival should be able to show which ethnic, geographic, economic and age groups are most susceptible to hunger.
Ultimately, the thing to remember is that data is a raw material, which the City government can refine only to a certain extent. Making the raw material available to the public allows a far greater amount of refinement and value to be added to that data, than can be had by keeping it sequestered within the agency that has collected it.
The City as Data Consumer
Even City government can directly benefit from such Open Government Data. That’s because integration of systems between agencies will be much better facilitated through a normal data sharing regime than through customized, point-to-point data interchange. This will enable streamlined construction of numerous systems. For example, a comprehensive city-wide enterprise data warehouse will be much easier to build in a data sharing environment, making the Mayor’s Management Report much easier to produce. The notion of a general inquiry system, across all agencies, for 311, becomes compellingly feasible. Key Performance Indicators, and hierarchical balanced scorecards for the entire City government become approachable, as does an automated alerting system that would cover the situation where any of those KPIs fell below or exceeded acceptable values.
The exciting internal applications for Open Government data should eliminate any fear that the external applications would be limited or underwhelming. They should also eliminate doubt as to the importance of sharing virtually all data (within important privacy and security limits), no matter how mundane some of the data, in raw form, may seem.
A Possible Technology
The technology platform with which agencies publish and even host their data most likely should be determined at the discretion of the individual agency itself. Making all agencies adhere to a single technology, hosting or cloud platform would likely be cumbersome to the point of being counterproductive to the goal of publishing the data in the first place.
That said, I would like to alert the Committee to an important technology and platform, from a perhaps unlikely source: Microsoft. Microsoft has created a framework called the Open Government Data Initiative, or OGDI. The software developer’s kit for OGDI is, believe it or not, published under an open source license. It was developed not by a product team on the corporate campus in Redmond, WA, but by the field organization that works with developers in the U.S. public sector (including federal, state and local government). OGDI is already being used to publish data from the US Bureau of Labor Statistics, General Services Agency and Geological Survey, as well as from the city government in the District of Columbia, and the City of Edmonton in Canada. Rather than just a static feed, OGDI provides a fully queryable Web service as well as built-in capabilities for mapping and charting the data. Data can also be downloaded in CSV, Excel, or KML formats, the last of these being compatible with Google Earth.
You may know I work closely with Microsoft and have done so now for the better part of two decades. As I have done so, I have often been critical of the proprietary approach the company takes to certain technologies, including data access. But recently things here have changed.
First Microsoft developed a data Web Services technology for its .NET software platform; the technology is called WCF Data Services, but its original code name, which many people still use, was “Astoria.” From the beginning I thought any technology that shared a name with a neighborhood in Queens had to be good. And it was: Astoria is based on open standards including HTTP, REST, ATOM, XML and JSON. These are common Web programming technologies that are in no way unique to Microsoft; that, in and of itself, was noteworthy. But then Microsoft took this approach a step further, doing something quite uncharacteristic: it took Astoria’s format and wire protocol and published it as an open protocol, which could be implemented on any platform. Microsoft christened the platform-neutral assets from Astoria the Open Data Protocol, or OData.
OData is compatible, in a raw way, with any programming environment which has the capability of interfacing with the Web. But what about a full library that consumes OData feeds and makes their data items appear as rich objects that developers can program against, without having to write the code to procure the feeds and parse each record and field within them? Of course such a facility exists for Microsoft’s .NET platform. But it extends well beyond that: OData native client libraries also exist for JavaScript, Java, PHP, Ruby, and Objective C (used by the iPhone/iPad platform). Microsoft has actually published the source code from the .NET client implementation (available under the Apache Open Source license) so that everyone has access to a sturdy reference implementation. On the server side, in addition to Microsoft’s Astoria implementation, IBM has implemented OData for its WebSphere eXtreme Scale REST data service (for its grid database service).
The Open Government Data Initiative is built upon OData, and I hope City agencies will consider using it. To me, this isn’t about supporting Microsoft. It’s about getting Open Government Data up quickly and easily, in machine-readable form and with a basic user interface that is Section 508-compliant for accessibility. It’s also about encouraging Microsoft to continue this open approach to technology, so that it becomes more the rule than the occasion.
Data for the People
Regardless of which technology or collection of technologies the City Of New York uses to open its data, my hope is that it will indeed do so, somehow, and quickly. The data shouldn’t be proprietary to City agencies, because the data isn’t the City government’s property. The data belongs to the public, to use for public benefit and innovative results. I applaud the Council and this Committee for being such strong advocates of such an outcome, and I fervently support passage of Int. 029-2010. Thank you for your time and attention today.
Three days ago I participated in a special outreach campaign. Specifically, I was part of an effort to mentor various members of the U.S, Congress (in both the House and Senate) in issues concerning technology companies. I took part in a full day of meetings on Capitol Hill, organized by the Association for Competitive Technology (ACT), an organization with which I have been associated for more than 10 years and on whose board I now sit.
I met with many elected officials' staff, but also had certain meetings with members of Congress themselves. I have participated in an ACT "fly-in" before but, even so, I was once again exhilarated with the experience of engaging members of Congress so directly,
The participating ACT membership split up into five groups, roughly defined along geographic lines, such that each group was matched with its own members' elected officials. All in all, the ACT membership met with the offices of more than 30 Representatives and Senators, from both major parties. We carried forth important messages about Cloud computing, net neutrality, intellectual property, taxation of carried interest and its impact on funding of tech startups, and more.
The good news? The ACT delegation was respectfully received, and members of both parties seem very cognizant of the importance of small technology companies to the economy. Everyone listened to us attentively, many took careful notes, and several seemed interested in working with ACT in the future, in order to understand tech issues better.
The bad news? Many, though not all, members of the Congress, including those who have significant influence over legislation affecting the industry, remain ignorant of many aspects of technology. It's a bit frightening, to be honest, and as good as the fly-in was, it certainly didn't resolve the problem.
That problem will only be solved if and when our participatory democracy enjoys, well, greater participation from the tech industry. That's a tough order because, in my experience at least, most technology entrepreneurs tend to be cynical about government, and politics too. In fact, there seems to be an intractable paradox: those who need to educate elected officials most are those least likely to believe that they can. Given how busy techies are, and their corresponding need to triage their time, political activism often gets ruled out.
Where does this leave us? I am not sure. But I would encourage people to get involved, on a trial basis, and here's why: everyone who I have seen try, including those most skeptical, become excited, engaged and much more optimistic once they've been through the process. And the next such convert could be you.
ACT maintains an office in Brussels and lobbies the European Parliament, as well as the U.S. Congress. If you're a tech entrepreneur or executive in the US or the EU, consider joining ACT and getting involved. Participate in one fly-in. If it doesn't change your outlook, so be it. But I bet it will, and I bet you can make a concrete difference in laws that affect your business, and you.