It is the last of these which interests me most. Becker’s statements come soon after the preview of Visual Studio LightSwitch, which is solely designed for data-driven business applications. Taking the two together, and bearing in mind that apps may run on the desktop as well as in browser, Silverlight is now encroaching on the territory which used to belong to Windows applications. With LightSwitch in particular, Microsoft is encouraging developers who might previously have built an app in Access or Visual Basic to consider Silverlight instead.

Why? Isn’t Microsoft better off if developers stick to Windows-only applications?

In one sense it is, as it gets the Windows lock-in – and yes, this is effective. I’m aware of businesses who are tied to Windows because of apps that they use, who might otherwise consider Macs for all or some of their business desktops. On the other hand, even Microsoft can see the direction in which we are travelling – cloud, mobile, diverse clients – and that Silverlight fits better with this model than Windows-only desktop clients.

Another consideration is that setup and deployment issues remain a pain-point for Windows apps. One issue is when it goes wrong, and Windows requires skilled surgery to get some app installed and working. Another issue is the constant energy drain of getting new computers and having to provision them with the apps you need. Microsoft has improved this no end for larger organisations, with standard system images and centralised application deployment, but Silverlight is still a welcome simplification; provided that the runtime is installed, it is pretty much the web model – just navigate to the URL and the app is there, right-click if you want to run on the desktop.

If Microsoft can also establish Windows Phone 7, which uses Silverlight as the runtime for custom apps, the platform then extends to mobile as well as desktop and browser.

The downside is that Silverlight apps have fewer capabilities than native Windows apps. Printing is tricky, for example, though Becker refers to “Virtualized printing” and I am not sure what exactly he means. He also highlights COM automation and group policy management, features that only work on Windows and which undermine Silverlight’s cross-platform promise. That said, via COM automation Silverlight has full access to the local machine giving developers a way of overcoming any limitations if they are willing to abandon cross-platform and browser-hosted deployment.

A winning strategy? Well, at least it is one that makes sense in the cloud era. On the other hand, Microsoft faces substantial difficulties in establishing Silverlight as a mainstream development platform. One is that Adobe was there first with Flash, which has a more widely deployed runtime, works on Android and soon other mobile devices, and is supported by the advanced design tools in Creative Suite. Another is the Apple factor, the popular iPhone and iPad devices which are a spear through the heart of cross-platform runtimes like Silverlight and Flash.

Finally, even within the Microsoft development community Silverlight is a hard sell for many developers. Some us recall how hard the company had to work to persuade Visual Basic 6 developers to move to .NET. The reason was not just stubborn individuals who dislike change – though there was certainly some of that – but also existing investment in code that could not easily be migrated. Both factors also apply to Silverlight. Further, it is a constrained platform, which means developers have to live with certain limitations. It is also managed code only, whereas some of the best developers for both desktop and mobile apps work in C/C++.

I suspect there is division even within Microsoft with regard to Silverlight. Clearly it has wide support and is considered a strategic area of development. At the same time, it is not helpful to the Windows team who will want to see apps that take advantage of new features in Windows 7 and beyond.

Yesterday Windows Phone 7 was released to manufacturing, which means the software is done. Another piece of the Silverlight platform is in place; and I guess over the next year or two we will see the extent to which Microsoft can make it a success.

Related posts:

1. Microsoft playing HTML 5 standards game alongside Silverlight game
2. Silverlight 4.0 released to the web; tools still not final
3. Microsoft Silverlight: 10 reasons to love it, 10 reasons to hate it

Fortunately I know exactly what this means. Read here for my earlier explanation. And if I go to the registry editor I can see these entries:

I also still get the error:

Error executing ‘C:\ProgramData\{7DE921C9-42C8-4DA3-8A44-043C3349FD1D}\Setup.exe’: The requested operation requires elevation

In one sense the error is not important, and the dialog does not reappear. It is still an ugly dialog, and as you can see from my Registry Editor, not a new one. Maybe next time?

Related posts:

1. Delphi and C++ Builder 2010 are out
2. Delphi and Windows Installer: small problem, fiddly solution
3. Installing Delphi 2006 on Vista

His book illustrates the power shift that has taken place in computing. In the early days, it was the developer’s task to make an application that worked, and the user’s task to understand how to use it, through manuals, training courses, or whatever it took.

There are still traces of this approach in the software industry, but when it comes to iPhone apps it has reversed completely. The app creator has to build an app that the user will find intuitive, useful and fun; otherwise – no sale.

An early heading reads “Bored, Fickle and Disloyal”. That’s the target user for your app.

Clark’s point is valid, and he does hammer it home page after page. You will get the message; but it can get tiresome. His style is frank and conversational: some readers will love it, others will find it grating after a chapter or two.

Even if you are one of the latter group, it is worth persevering, because there is a ton of good content here. There are also numerous short interviews with developers of actual apps, many of them well-known, discussing the issues they faced. The persistent issue: we’ve got a complex app, a small screen, and intolerant users, how on earth do we make this seem simple and intuitive?

Constraints like these can actually improve applications. We saw this on the web, as the enforced statelessness and page model of web applications forced developers to simplify the user interface. It is the same with mobile. Joe Hewitt, author of the first generations of Facebook for iPhone:

There is so much stuff that is actually better on the small screen because it requires designers to focus on what’s really important.

So what’s in the book? After a couple of scene-setting chapters, Clark drills down into how to design for a tiny touchscreen. Be a scroll sceptic, he says. Chapter 4 then looks at app structure and navigation. Chapter 5 takes you blow by blow through the iPhone controls and visual elements. Then we get a chapter on making your app distinctive, a chapter on the all-important start-up sequence and how to make seem instantaneous, and a chapter on touch gestures.

The last three chapters cover portrait to landscape flipping, alerts, and finally inter-app communication and integration.

Throughout the book is illustrated in full colour, and the book itself is a pleasure to read with high quality paper and typography. 300 pages that will probably improve your app design and increase its sales; a bargain.

Related posts:

1. Review: Web Design for Developers by Brian Hogan
2. Spotify for iPhone looks great – if Apple allows it
3. Enterprise app development on Apple iPhone and iPad

Why bother? There’s two aspects to this. One is simply the comfort factor: if you are a .NET developer used to Visual Studio, but now working on Flash or Flex, this could be an easier way in than the Eclipse-based Flash Builder. There is a visual designer, a full-featured debugger, a property inspector with sections for properties, events, effects and styles, for example, and double-clicking an event generates an event handler as you would expect.

The other factor is areas where Amethyst can improve on what Flash Builder offers. One example is ActionScript refactoring, disappointing in Adobe’s product. Amethyst is not brilliant, but does have a few extras including Extract Method, Encapsulate Field and Extract Interface.

Another useful feature is that Amethyst can share projects with Flash or Flash Builder. Before you get excited, it does not do the magic you might want, Visual Studio editing of .fla files with embedded ActionScript. It does work reasonably seamlessly though: you can open .fla file in the Flash IDE by clicking within Amethyst.

This would have been even more interesting if Adobe had not added a measure of Flash Builder integration in Flash Professional CS5; and that is the challenge facing SapphireSteel – how to keep up with Adobe’s official development tools.

I’ve only played briefly with Amethyst but although I’ve been impressed with it in some ways, I also found myself missing features in Flash Builder, such as the Connect to Data wizards, and the view state management.

It is early days though; and I would be interested to hear from others who have tried Amethyst on what they do or do not like about it.

Price is not yet stated, but SapphireSteel also offer a Ruby product which is priced at $49 for a basic edition, or $199 for a professional version. Amethyst also comes in two editions so perhaps we will see something similar.

Related posts:

1. Amethyst from SapphireSteel: Develop Flex in Visual Studio, an alternative to Tofino
2. Develop for Adobe Flex in Microsoft Visual Studio – or maybe not
3. Adobe’s Flex Builder to Flash Builder name change does not go far enough

What else? Well, Schmelzer and Seven had read my earlier blog post so we discussed some of the things I speculated about. Windows Phone 7? Won’t be in the first release, they said, but maybe later.

What about generating other application types from the same model? Doug Seven comments:

The way we’ve architected LightSwitch does not preclude us from making changes .. it’s not currently on the plan to have different output formats, but if demand were high it’s feasible in the future.

I find this interesting, particularly given that the future of the business client is not clear right now. The popularity of Apple’s iPad and iPhone is a real and increasing deployment problem, for example. No Flash, no Silverlight, no Java, only HTML or native apps. The idea of simply selecting a different output format is compelling, especially when you put it together with the fast JIT-compiled JavaScript in modern web browsers. Of course support for multiple targets has long been the goal of model-driven architecture (remember PIM,PSM and PDM?) ; but in practice the concept of a cross-platform runtime has proved more workable.

There’s no sign of this in the product yet though, so it is idle speculation. There is another possible approach though, which is to build a LightSwitch application, and then build an alternative client, say in ASP.NET, that uses the same WCF RIA Services. Since Visual Studio is extensible, it will be fun to see if add-ins appear that exploit these possibilities.

I also asked about Mac support. It was as I expected – the team is firmly Windows-centric, despite Silverlight’s cross-platform capability. Schmelzer was under the impression that Silverlight on a Mac only works within the browser, though he added “I could be wrong”.

In fact, Silverlight out of browser already works on a Mac; the piece that doesn’t work is COM interop, which is not essential to LightSwitch other than for export to Excel. It should not be difficult to run a LightSwitch app out-of-browser on a Mac, just right-click a browser-hosted app and choose Install onto this computer, but Microsoft is marketing it as a tool for Windows desktop apps, or Web apps for any other client where Silverlight runs.

Finally I asked whether the making of LightSwitch had influenced the features of Silverlight or WCF RIA Services themselves. Apparently it did:

There are quite a few aspects of both Silveright 4 and RIA services that are in those products because we were building on them. We uncovered things that we needed to make it easier to build a business application with those technologies. We put quite a few changes into the Silverlight data grid.

said Schmelzer, who also mentioned performance optimizations for WCF RIA Services, especially with larger data sets, some of which will come in a future service pack. I think this is encouraging for those intending to use Silverlight for business applications.

There are many facets to LightSwitch. As a new low-end edition of Visual Studio it is not that interesting. As an effort to establish Silverlight as a business application platform, it may be significant. As an attempt to bring model-driven architecture to the mainstream, it is fascinating.

The caveat (and it is a big one) is that Microsoft’s track-record on modelling in Visual Studio is to embrace in one release and extinguish in the next. The company’s track-record on cross-platform is even worse. On balance it is unlikely that LightSwitch will fulfil its potential; but you never know.

Related posts:

1. Ten things you need to know about Microsoft’s Visual Studio LightSwitch
2. Silverlight versus HTML, Flash – Microsoft defends its role
3. New Visual Studio 2010 beta has WPF editor, Silverlight designer

1. LightSwitch builds Silverlight apps. In typical Microsoft style, it does not make the best of Silverlight’s cross-platform potential, at least in the beta. Publish a LightSwitch app, and by default you get a Windows click-once installation file for an out-of-browser Silverlight app. Still, there is also an option for a browser-hosted deployment, and in principle I should think the apps will run on the Mac (this is stated in one of the introductory videos) and maybe on Linux via Moonlight. Microsoft does include an “Export to Excel” button on out-of-browser deployments that only appears on Windows, thanks to the lack of COM support on other platforms.

I still find this interesting, particularly since LightSwitch is presented as a tool for business applications without a hint of bling – in fact, adding bling is challenging. You have to create a custom control in Silverlight and add it to a screen.

Microsoft should highlight the cross-platform capability of LightSwitch and make sure that Mac deployment is easy. What’s the betting it hardly gets a mention? Of course, there is also the iPhone/iPad problem to think about. Maybe ASP.NET and clever JavaScript would have been a better idea after all.

2. There is no visual form designer – at least, not in the traditional Microsoft style we have become used to. Here’s a screen in the designer:

Now, on one level this is ugly compared to a nice visual designer that looks roughly like what you will get at runtime. I can imagine some VB or Access developers will find this a difficult adjustment.

On the positive side though, it does relieve the developer of the most tedious part of building this type of forms application – designing the form. LightSwitch does it all for you, including validation, and you can write little snippets of code on top as needed.

I think this is a bold decision – it may harm LightSwitch adoption but it does make sense.

3. LightSwitch has runtime form customization. Actually it is not quite “runtime”, but only works when running in the debugger. When you run a screen, you get a “Customize Screen” button at top right:

which opens the current screen in Customization Mode, with the field list, property editor, and a preview of the screen.

It is still not a visual form designer, but mitigates its absence a little.

4. LightSwitch is model driven. When you create a LightSwitch application you are writing out XAML, not the XAML you know that defines a WPF layout, but XAML to define an application. The key file seems to be ApplicationDefinition.lsml, which starts like this:

Microsoft has invested hugely in modelling over the years with not that much to show for it. The great thing about modelling in LightSwitch is that you do not know you are doing it. It might just catch on.

Let’s say everyone loves LightSwitch, but nobody wants Silverlight apps. Could you add an option to generate HTML and JavaScript instead? I don’t see why not.

5. LightSwitch uses business data types, not just programmer data types. I mean types like EmailAddress, Image, Money and PhoneNumber:

I like this. Arguably Microsoft should have gone further. Do we really need Int16, Int32 and Int64? Why not “Whole number” and “Floating point number”? Or hide the techie choices in an “Advanced” list?

6. LightSwitch is another go at an intractable problem: how to get non-professional developers to write properly designed relational database applications. I think Microsoft has done a great job here. Partly there are the data types as mentioned above. Beyond that though, there is a relationship builder that is genuinely easy to use, but which still handles tricky things like many-to-many relationships and cascading deletes. I like the plain English explanations in the too, like “When a Patient is deleted, remove all related Appointment instances” when you select Cascade delete.

Now, does this mean that a capable professional in a non-IT field – such as a dentist, shopkeeper, small business owner, departmental worker – can now pick up LightSwitch and and write a well-designed application to handle their customers, or inventory, or appointments? That is an open question. Real-world databases soon get complex and it is easy to mess up. Still, I reckon LightSwitch is the best effort I’ve seen – more disciplined than FileMaker, for example, (though I admit I’ve not looked at FileMaker for a while), and well ahead of Access.

This does raise the question of who is really the target developer for LightSwitch? It is being presented as a low-end tool, but in reality it is a different approach to application building that could be used at almost any level. Some features of LightSwitch will only make sense to IT specialists – in fact, as soon as you step into the code editor, it is a daunting tool.

7. LightSwitch is a database application builder that does not use SQL. The query designer is entirely visual, and behind the scenes Linq (Language Intergrated Query) is everywhere. Like the absence of a visual designer, this is a somewhat risky move; SQL is familiar to everyone. Linq has advantages, but it is not so easy to use that a beginner can express a complex query in moments. When using the Query designer I would personally like a “View and edit SQL” or even a “View and edit Linq” option.

8. LightSwitch will be released as the cheapest member of the paid-for Visual Studio range. In other words, it will not be free (like Express), but will be cheaper than Visual Studio Professional.

9. LightSwitch applications are cloud-ready. In the final release (but not the beta) you will be able to publish to Windows Azure. Even in the beta, LightSwitch apps always use WCF RIA Services, which means they are web-oriented applications. Data sources supported in the beta are SQL Server, SharePoint and generic WCF RIA Services. Apparently in the final release Access will be added.

10. Speculation – LightSwitch will one day target Windows Phone 7. I don’t know this for sure yet. But why else would Microsoft make this a Silverlight tool? This makes so much sense: an application builder using the web services model for authentication and data access, firmly aimed at business users. The first release of Windows Phone 7 targets consumers, but if Microsoft has any sense, it will have LightSwitch for Windows Phone Professional (or whatever) lined up for the release of the business-oriented Windows Phone.

Related posts:

1. Visual Studio LightSwitch – model-driven architecture for the mainstream?
2. Silverlight versus HTML, Flash – Microsoft defends its role
3. New Visual Studio 2010 beta has WPF editor, Silverlight designer

It is notable that native code is much faster than the runtimes, and that .NET is ahead of Java – to be expected, perhaps, since Windows is its native environment.

The test application is tiny and when we are talking about a time of less than a tenth of a second, users are unlikely to care much. I would like to see tests based on a larger application; on the other hand it becomes increasingly difficult to make a fair comparison.

It’s a shame Embarcadero Delphi was not included, though I’d expect similar figures to those for Visual C++.

Start-up time is critical to perceived performance. One reason I use an ancient version of Paint Shop Pro for simple image manipulation is that I can double-click an image and be editing it instantly, whereas alternatives like Adobe PhotoShop or the free paint.net make me wait. Unless I need the extra features these provide, I stick with fast and simple.

Related posts:

1. Java versus C/C++ performance – which is really faster?
2. Oracle still foisting Google Toolbar on Java users
3. JavaFX – just for Java guys?

When IE9 was first previewed, back in March, it scored only 55% on the Acid3 standards test – well ahead of IE8 which scores around 20%, but far short of rivals like Google Chrome and Apple Safari which achieve full marks. Mozilla Firefox is at 94%.

The new preview is at 95%. IE9 is now up there with them – but why not 100%?

According to UK Web Product Manager Mark Quirk, it is down to three features, two of which are related to SVG (Scalable Vector Graphics). Two points are lost because of SMIL (Synchronized Multimedia Integration Language) presentations, which Microsoft does not intend to support because a similar feature will be part of CSS in future. Two points are lost because of SVG fonts, which again Microsoft does not intend to support because it sees WOFF (Web Open Font Format) as the future standard here. One point is lost because of the inability to draw SVG fonts on a path, though there are other ways to draw fonts on a path.

The bottom line: IE9 will most likely stay at 95% right through to its final release.

Incidentally, IE9 JavaScript performance is wildly faster than IE8, thanks to the new “Chakra” engine. IE9 is on the left, Firefox 4 on the right :

So when will we get IE9? Although it is not long to September, there is a major difference between the preview and the coming beta, which is that the preview does not have a full user interface. It is mainly to show off the rendering and JavaScript engine. Therefore we can expect new features in the beta versus the preview. Despite that, Quirk says that Microsoft intends the beta to be “good quality for any user”, not just for brave developers and testers.

But how long before the final release? Microsoft is not saying, though when I suggested the first half of 2011 as a reasonable guess, Quirk reminded me that the beta will be high quality and that the release should therefore follow “not too long” after.

Since we will get much of HTML 5 in IE alongside the other popular browsers, do we still need Silverlight?

“As the number of the things you can implement with HTML clearly goes up, the need for Silverlight and Flash goes down,” said Quirk, though he added hastily, “The value that those players add needs to go higher.”

I’d add that even if IE9 is all that we hope, it will take years before older versions fall out of use. Recently the UK government said it will stick with IE6, and whatever you think of that decision, it shows how hard it is to get browsers upgraded everywhere. By contrast, plug-ins like Flash and Silverlight get updated rather fast. I noticed on Riastats today that over 50% of browsers now have the latest Silverlight, and 39% already have Flash 10.1 – over 90% have Flash 10 or higher.

If you combine that issue with things like video playback that are problematic even in HTML 5, it suggests that plug-ins will be with us for the foreseeable future, though it is quite possible that their use may decline.

Another factor is tool support, mature for Flash and Silverlight, but not for the newest features of HTML. After IE9 appears, will Microsoft come up with tools that properly support it, in Expression Web and Visual Studio? “We have to, it’s as simple as that,” says Quirk, though he adds, “we haven’t said when.”

Related posts:

1. Big browser and RIA news: Canvas comes to Internet Explorer 9
2. Microsoft unbundles Internet Explorer from Windows 7 – in Europe, that is
3. Why Internet Explorer users get the worst of the Web

Browsers

The first is that usage of Microsoft’s Internet Explorer has levelled off after a long period of decline. Microsoft says it is increasing but the numbers are too small to say that with confidence. StatCounter global stats for May to July show slight decline for IE (52.83% –> 52.37%) and FireFox (31.54%->30.88%), with Google Chrome the main beneficiary (8.81%->10.32%).

On this blog Chrome has grown from 4.2% to 12.4% in the last year. IE is still declining: 44.9% in July 09, 39.6% in June 10, and 38.2% in July 10.

My guess is that the success of Windows 7 might have brought back a few FireFox users. The interesting story though is where Chrome will be when it stops growing its share. My second guess is that it will be ahead of FireFox, though that is speculative. It is WebKit though, and I think that will be bigger than Mozilla’s Gecko thanks to adoption by Google, Apple, Adobe and others.

Mobile

Next, Google Android. Nielsen reports that it has pulled ahead of Apple iPhone in the US SmartPhone market; both are behind RIM’s Blackberry though that is in steady decline. RIM is announcing Blackberry 9800, the first on OS 6, later today; but I doubt it will disrupt Android’s growth. The developer angle is that Android is now equal to Apple’s iPad/iPhone in strategic importance, which will be a relief to Adobe – Flash runs on Android but not iPhone.

Android owners lack the satisfaction of Apple iPhone owners. 21% of them are eyeing the iPhone for their next upgrade, whereas only 6% of iPhone owners want Android next. Only 42% of Blackberry owners intend to remain loyal. It is all tending to confirm my speculation back in April that Android is the new Windows.

So in two years time, what will be the market share for RIM, Nokia Symbian/MeeGo, Windows Phone, HP Palm WebOS? It will not be easy for any of them.

eBooks

Finally, eBooks. The Kindle vs iPad vs Nook vs Sony is one story; but the bigger one is that the eBook is happening at last. David Carnoy’s recent articles on Amazon give the background. One is an interview with Amazon’s Ian Freed in which the retailer says eBook sales have tripled in the first quarter of 2010 vs that in 2009, and claims 70-80% of the market. Another looks at what Amazon didn’t say. However the market shares work out though, what matters is that screen, battery and wireless technology are now good enough, and publishers and authors willing enough, for eBooks to become mainstream, with huge implications for the media industry.

Related posts:

1. Building for multiple mobile platforms with one codebase
2. Android the new Windows?
3. Google Chrome Mac and Linux arrives – may hurt Firefox more than Safari

Nickull defends the Flash behaviour:

Flash’s HTTP libraries currently support GET and POST. My architectural view of this is that the HTTP libraries only should really support these and not worry about the others.

He also notes that cookies are a poor way to manage state:

Cookies are for the browser and belong in the browser. Having Flash Player able to access cookies would be a mistake in my own opinion. Any logic that is facilitated by a browser should probably be dealt with at the browser layer before Flash Player is used.

Now, I think the comments on REST are important to read if you are engaged in designing a web service, as many of us in these days of cloud+device. There is a kind-of “word on the street” approach to web services which says that REST is good, SOA/SOAP is bad; but in reality it is not so simple, and these distinctions are muddled. REST is arguably a form of SOA, you can do SOAP with REST, and so on.

One factor is that reading data in a web client is far more common than writing data. It is easy to be an advocate of the simplicity of REST if all you are doing is GET.

The question Nickull asks is whether the transport protocol has any business dictating how the data it transports should be processed, for example whether it is an operation to retrieve or to write data:

In an SOA world, the transport functionality (usually implemented using SOAP) should focus on just delivering the message and it’s associated payload(s) to the destination(s), optionally enforcing rules of reliability and security rather than declaring to the application layer processing instructions to the service endpoint.

Read the post for more of the rationale behind this. Maybe, even if you are doing REST, restricting your web service to GET and POST is not such a bad idea after all.

That said, whatever you think about the architectural principles, you may find yourself having to write a browser-hosted Flash client for a service that requires an HTTP verb other than GET or POST. There are ways round it: see this discussion of Amazon S3 (which uses PUT) and Flash for an example.

Related posts:

1. Develop for Adobe Flash/Flex in Amethyst for Visual Studio
2. Adobe’s Acrobat.com REST API
3. Flash and AIR for Windows Phone 7 by mid 2011?