Category Archives: web authoring

Apple, Google: risks of third–party platforms for developers

This week there are a couple of stories about companies whose business was affected by the third-party platform on which they deploy.

The first is from a post from Beamitdown Software’s Dennis Morin whose iFlowReader app for iOS is no longer viable following changes Apple has made to its developer agreement, insisting that add-on content for apps must be sold through Apple’s purchase system, where it is subject to a 30% fee. Beamitdown’s product is an eBook reader, and the content is eBooks, on which the company gets a 30% commission from the publisher. No profit.

It is also worth reading Morin’s interview with CNET in which he adds some detail.

Morin’s complaint is that Apple changed the rules; and reading his account of how difficult it was to communicate with Apple and how unsatisfactory and unreasonable the outcome is, it is hard not to be sympathetic.

On the  other hand, was it sensible to build a business on a platform that you do not control, and with a product that competes, and was always likely to compete, with a similar service from the owner of that platform?

Ask Skyhook, which is trying to offer location services on Android devices, and is suing Google for allegedly blocking Skyhook’s deal with Motorola to favour of its own services. The action has unearthed  correspondence between Google and Motorola that shows the limits of Android’s openness, though I have no idea about the merits of the legal action. Note that a key point here is not the Android OS itself, but Google’s applications which include Android Market. You will notice that the cheapest Android devices, like the famously poor Next Tablet, do not include the Android Market or other Google applications; they use Android source code but are not fully part of the ecosystem:

Is compatibility mandatory?

No. The Android Compatibility Program is optional. Since the Android source code is open, anyone can use it to build any kind of device. However, if a manufacturer wishes to use the Android name with their product, or wants access to Android Market, they must first demonstrate that the device is compatible.

How can I get access to the Google apps for Android, such as Maps?

The Google apps for Android, such as YouTube, Google Maps and Navigation, Gmail, and so on are Google properties that are not part of Android, and are licensed separately. Contact android-partnerships@google.com for inquiries related to those apps.

Who determines what will be part of the compatibility definition?

Since Google is responsible for the overall direction of Android as a platform and product, Google maintains the Compatibility Definition Document for each release. We draft the CDD for a new Android version in consultation with a number of OEMs, who provide input on its contents.

The Next tablet and devices like demonstrate why Google having a measure of control over Android is not a bad thing. However it gets uncomfortable if you want to put out a device that uses Android in ways that conflict with Google’s goals.

What are Google’s goals? It is a good question; but my assumption is that Android is intended to promote Google’s services such as search, and to make your Google identity central to your digital life so that you use Google mail, payments, Google Apps and so on. Further, Android is a strategic play to prevent Apple from owning mobile outright, at least at the high end, and in that respect it is proving successful.

The newly announced Chromebook is more closely tied to Google and delivers more obvious benefit to the company, but whether it will be as successful as Android is doubtful.

The bottom line is that if you choose to deploy on someone else’s platform, you have to take account of the risk that entails. This is nothing new – try marketing an office suite for Windows – but the extent to which the platform is controlled has been taken to a new level by Apple, and even Android has its risks. The nearest thing to an open platform that has broad reach is the Web and web technologies.

Mobile developers follow the users; PhoneGap most popular cross-platform toolkit says survey

Web Directions has published a State of Mobile Web Development based on input from around 1300 professional web developers. Note that this is a survey of web developers not app developers, which must skew the results if you are interested in the overall app picture, but it is still interesting.

One result deals with developer platform decisions. What are the factors that count when choosing a platform to develop for? New and minority mobile platform players will study this with interest, since getting a large number of developers on board is a high priority.

Here is the ranking of factors based on how many developers consider each one “Very important”:

  1. Number of potential users of your app: 68.55%
  2. Platform capabilities: 60.36%
  3. Ease of development: 58.55%
  4. Worldwide reach of marketplace: 40.02%
  5. Assistance in marketing your app: 23.40%

The message for the likes of Microsoft, HP and RIM is that the best way to attract developers is to sell lots of cool devices. Ease of development matters, but not as much as a large market.

Another section asks which toolkits are preferred if you are developing native apps with web technologies (note the exact question):

  1. PhoneGap 47.6%
  2. Appcelerator 26.5%
  3. Other 15.6%
  4. Adobe AIR 7.8%
  5. Apparatio 1.2%
  6. Rhomobile 1.2%

The sample here is rather small, with only 79 of the 1300 using PhoneGap, for example. I also quibble with the definitions here. Rhomobile’s Rhodes framework compiles Ruby to native code and I doubt it counts in the category “developing native apps with web technologies”. I am even sure whether AIR belongs alongside PhoneGap and Appcelerator, since AIR is Flash whereas the other two are HTML 5. Incidentally, Appcelerator is the company name and what should appear here is Titanium, which is the name of the cross-platform toolkit. Apparat.io is in private beta so its low take-up is not surprising.

Still, it is a good result for the top two. If you are interested in these toolkits don’t miss my recent interviews with André Charland at Nitobi (PhoneGap) and Jeff Haynie at Appcelerator.

Dreamweaver CS5.5 PhoneGap apps: performance issues on Android

This is a follow-on from my earlier post about building a simple PhoneGap app using Adobe Dreamweaver CS5.5. I built it on Windows targeting Android. I liked the development experience up to the point of trying the app: it looks great, but performance is terrible. That is, you tap a button and there is a perceptible pause before the app responds. It is worse in the emulator than on my HTC Desire, but still poor.

I had thought it was a configuration setting – though Dreamweaver makes it rather hard to access the build settings – but I am now wondering if jQuery mobile plus PhoneGap is just too demanding for most Android devices out there right now. Admittedly my Desire is a year or so old now. See this thread for example:

JQuery Mobile on Android is definitely slow. (Tested A2 and A3Pre on Samsung Galaxy S, HTC Desire, ZTE Blade (edit: 2.2 Froyo) – with PhoneGap, stock browser, Opera Mobile)

Something has to be done. The experience is low quality.

It is worth noting that PhoneGap is not yet a version 1.0 release – I was told it may be done by July. Further, you do not have to use jQuery Mobile with it in Dreamweaver; it just happens to provide a great set of user interface widgets. It may be better on Apple iOS; I have not tried that yet.

Nevertheless, this looks like a significant issue if you planning to dive in and deliver Android apps using the tools in the new Dreamweaver.

Getting started with VMWare Cloud Foundry

I have been meaning to post about VMWare’s Cloud Foundry, a new cloud platform for Spring Java, Ruby on Rails and Node.js applications. Good, incidentally, to see Node.js getting increasing attention – see my post from December when I heard Ryan Dahl present on the subject. I signed up for Cloud Foundry when it was announced, since it has free participation in the current beta.

Today my account went live and I spent just a few minutes creating a first application using the steps here. Well, my first app is indistinguishable from a static web page; but having been immersed in Windows Azure for the last few days, with its accounts and subscriptions and certificates and the portal and the ServiceConfiguration.cscfg and the ServiceDefinition.csdef and all the rest of it, I admit to having a pleasant sense of “is that it?” when deploying the Cloud Foundry app.

I typed a few lines of Ruby code, saved the file to a directory, and then typed vmc push.

image

image

Let me add that I like what Microsoft is doing with Azure, and that in combination with Visual Studio it makes an impressive cloud development platform that, from what I have seen, works very well; I think it is of major importance. I also like the fact that Microsoft has pushed down the cost of entry, with its Extra Small instances and more generous offers to MSDN subscribers, partners and others. It easier to experiment a bit with Azure than it used to be.

Nevertheless, Azure lacks the delightful simplicity of getting started that you can see in Cloud Foundry. After doing my Hello World app I look forward to trying something more advanced; and while I am sure that the delightful simplicity soon disappears as the lines of Ruby code increase, and as you try to make your application scalable and transactional and secure and all those good things, the fact that it draws you in is an advantage.

Native apps better than web apps? That’s silly talk says PhoneGap president

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

Is Appcelerator Titanium native? And what does native mean anyway?

Of course we all know that Microsoft’s IE9 and the forthcoming IE10 are native – VP Dean Hachamovitch said so many times during his keynote at the Mix 2011 conference earlier this week. That has sparked a debate about what native means – so here is another interesting case.

Appcelerator’s Titanium cross-platform tool for mobile development is native, or at least that is what it claims:

image

Now, I am not sure that native has a precise definition, but to me it suggests a compiled application, rather than one interpreted at runtime. So this description of how Titanium executes JavaScript – its main language – is surprising:

In a Titanium Mobile application, your source code is packaged into a binary file and then interpreted at runtime by a JavaScript engine bundled in by the Titanium build process. In this guide, you will learn more about the JavaScript runtime environment that your code runs in. Titanium runs your application’s JavaScript using one of two JavaScript interpreters – JavaScriptCore on iOS (the interpreter used by Webkit) and Mozilla Rhino on Android and BlackBerry.

So a Titanium application is actually interpreted.

Native is a vague enough term that Appcelerator can no doubt justify its use here. “Native UI” is fair enough, so is “Native capabilities.” Native performance? That seems to me a stretch, though JavaScript performance is good and constantly improving. Appcelerator even has a web page devoted to what it means by native.

Titanium is also open source. Anyone doubtful about how it works need only consult the code.

In the light of Microsoft’s statements, it is interesting that what Appcelerator really means by native is “not a web page”:

Build Native Apps … Everything else is basically a web page.

So can an application be both native and interpreted? What about Silverlight apps on Windows Phone 7, are they native? Adobe AIR apps, surely they are not native? Google Android has a Native Development Kit which is introduced thus:

The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code.

The implication is that byte code executed by the Dalvik virtual machine, which is the normal route for an Android app, is in some sense not native code. Which also implies that Appcelerator’s claims for Titanium are at least open to misunderstanding.

Microsoft releases IE10 preview, talks up native HTML5

Microsoft has released an early preview of Internet Explorer 10, which you can download now. It shows the company’s commitment – for the moment – to an energetic release cycle for its web browser.

image

Why use IE? Microsoft is pushing the notion that only IE is truly native on Windows:

IE10 continues on IE9’s path, directly using what Windows provides and avoiding abstractions, layers, and libraries that slow down your site and your experience.

In practice, this means using the Windows graphic stack directly and integrating with the Windows shell through features like jump list support on Windows 7.

IE10 supports more CSS3 standards including multi-column layout, Grid layout and Flexible Box Layout,  and Gradients. There is also support for EcmaScript 5 Strict Mode, which enforces tighter standards so reducing the likelihood of errors. Strict Mode is optional; if a web browser tried to apply it to the entire web lots of pages would break.

Microsoft is promising to support additional CSS3 standards including transitions and 3D transforms, though these are not in the preview. New preview releases will appear every 8-12 weeks.

According to Corporate VP Dean Hachamovitch, the company is steering a tight path between falling behind, and implementing immature standards:

When browsers prematurely implement technology, the result is activity more than progress. Unstable technology results in developers wasting their time rewriting the same site.

he writes in a blog post.

IE10 was announced today at the Mix conference in Las Vegas. Mix seems to be featuring equal measures of HTML5 and Silverlight, which makes for an interesting tension. News on Windows Phone is also promised, though I am not sure whether this is the moment when Microsoft will tell us about the next generation of Windows Phone and how it ties in with Windows 8 and with tablet devices. All will be revealed (or not) tomorrow.

Adobe announces Flash Builder for PHP, PhoneGap integration in Dreamweaver

Adobe has stepped up its support for mobile and Flash development with a couple of announcements today.

The first is that Dreamweaver 5.5, part of the new Creative Suite 5.5, has integrated support for PhoneGap.

image

PhoneGap lets you build apps for Apple iOS and Google Android using HTML and JavaScript, taking advantage of the WebKit runtime that is present in these devices. The apps are packaged as native apps and also have access to some device-specific features. This does not mean Adobe is abandoning Flash, but is part of a both/and strategy, which makes sense to me.

There is also a new 4.5 version of Flash Builder which has greatly improved mobile support.

image

 

Flex 4.5 compiles to AIR apps on Android, Blackberry and iOS, as well as desktop Mac, Windows and Linux.

You can debug directly on an Android device connected via USB, or using a new emulator built into Flash Builder:

image

Adobe has also announced Flash Builder 4.5 for PHP, in partnership with Zend. A great feature is that you can debug seamlessly from PHP code on the server to Flex code running in a Flash client, provided you are using Zend server.

The new Flash Builder products will ship within 30 days. The premium edition is part of the Creative Suite 5.5 bundle – an improvement over Creative Suite 5.0 which only bundled the Standard edition – or available separately, while Flash Builder for PHP is a separate purchase at $399 or €319 for Standard, and $799 or €629 for Premium.

I asked Adobe’s Adam Lehman, Flash Builder produce manager, how developers should decide between PhoneGap and AIR for Mobile, given that both are now in Creative Suite.

They’re coming from two different technical perspectives. If you’re going to come in with your HTML skills and try to build an application that way, PhoneGap is better than trying to go and learn ActionScript and Flex from scratch. But from a performance and functionality perspective we believe we’re offering a lot better solution with Flash Builder and Flex.

The other part of it is that our tooling is superior. The sort of workflow that we showed [Design and develop with round-tripping between Flash Catalyst and Flash Builder] isn’t going to be available on the PhoneGap side with our tooling. Dreamweaver might be able to support different layouts and things like that, but it is not going to be a full-fledged IDE. What you’re getting with the AIR runtime and the full tooling stack is far superior that if you were building the HTML-based PhoneGap app. You can always tell a PhoneGap app, you can tell that it is running in an embedded browser. There’s tons of inconsistencies between the devices because the browsers are very different. There’s a lot of advantages to going AIR where you know that the design is going to look exactly the same. But while we love Flash we’re not zealous about it to ignore the fact that you can build with these other technologies as well.

More information on Flash Builder 4.5 here.

Adobe announces Flash Builder for PHP, PhoneGap integration in Dreamweaver

Adobe has stepped up its support for mobile and Flash development with a couple of announcements today.
The first is that Dreamweaver 5.5, part of the new Creative Suite 5.5, has integrated support for PhoneGap. PhoneGap lets you build apps for Apple iOS and Google Android using HTML and JavaScript, taking advantage of the WebKit runtime that is present in these devices. The apps are packaged as native apps and also have access to some device-specific features. This does not mean Adobe is abandoning Flash, but is part of a both/and strategy, which makes sense to me.
Adobe has also announced Flash Builder 4.5 for PHP, in partnership with Zend. A great feature is that you can debug seamlessly from PHP code on the server to Flex code running in a Flash client, provided you are using Zend server.
Flex 4.5 compiles to AIR apps on Android, Blackberry and iOS, as well as desktop Mac, Windows and Linux.
The new Flash Builder products will ship within 30 days. The premium edition is part of the Creative Suite bundle or available separately, while Flash Builder for PHP is a separate purchase at $399 or €319 for Standard, and $799 or €629 for Premium.
More news on this and screenshots soon.

Hands On with Visual Studio LightSwitch – but what is it for?

Visual Studio LightSwitch, currently in public beta, is Microsoft’s most intriguing development tool for years. It is, I think, widely misunderstood, or not understood; but there is some brilliant work lurking underneath it. That does not mean it will succeed. The difficulty Microsoft is having in positioning it, together with inevitable version one limitations, may mean that it never receives the attention it deserves.

Let’s start with what Microsoft says LightSwitch is all about. Here is a slide from its Beta 2 presentation to the press:

image

Get the idea? This is development for the rest of us, "a simple tool to solve their problems” as another slide puts it.

OK, so it is an application builder, where the focus is on forms over data. That makes me think of Access and Excel, or going beyond Microsoft, FileMaker. This being 2011 though, the emphasis is not so much on single user or even networked Windows apps, but rather on rich internet clients backed by internet-hosted services. With this in mind, LightSwitch builds three-tier applications with database and server tiers hosted on Windows server and IIS, or optionally on Windows Azure, and a client built in Silverlight that runs either out of browser on Windows – in which case it gets features like export to Excel – or in-browser as a web application.

There is a significant issue with this approach. There is no mobile client. Although Windows Phone runs Silverlight, LightSwitch does not create Windows Phone applications; and the only mobile that runs Silverlight is Windows Phone.

LightSwitch apps should run on a Mac with Silverlight installed, though Microsoft never seems to mention this. It is presented as a tool for Windows. On the Mac, desktop applications will not be able to export to Excel since this is a Windows-only capability in Silverlight.

Silverlight MVP Michael Washington has figured out how to make a standard ASP.NET web application that accesses a LightSwitch back end. I think this should have been an option from the beginning.

I digress though. I decided to have a go with LightSwitch to see if I can work out how the supposed target market is likely to get on with it. The project I set myself was a an index of magazine articles; you may recognize some of the names. With LightSwitch you are insulated from the complexities of data connections and can just get on with defining data. Behind the scenes it is SQL Server. I created tables for Articles, Authors and Magazines, where magazines are composed of articles, and each article has an author.

The LightSwitch data designer is brilliant. It has common-sense data types and an easy relationship builder. I created my three tables and set the relationships.

image

Then I created a screen for entering articles. When you add a screen you have to say what kind of screen you want:

image

I chose an Editable Grid Screen for my three tables. LightSwitch is smart about including fields from related tables. So my Articles grid automatically included columns for Author and for Magazine. I did notice that the the author column only showed the firstname of the author – not good. I discovered how to fix it. Go into the Authors table definition, create a new calculated field called FullName, click Edit Method, and write some code:

partial void FullName_Compute(ref string result)
{
    // Set result to the desired field value
   result = this.Firstname + " " + this.Lastname;

}

Then you set FullName as the “Summary” field for the table.

Have we lost our non-developer developer? I don’t think so, this is easier than a formula in Excel once you work out the steps. I was interested to see the result variable in the generated code; echoes of Delphi and Object Pascal.

I did discover though that my app has a usability problem. In LightSwitch, the user interface is generated for you. Each screen becomes a Task in a menu on the left, and double-clicking opens it. The screen layout is also generated for you. My problem: when I tried entering a new article, I had to specify the Author from a drop-down list. If the author did not yet exist, I had to open an Authors editable grid, enter the new author, save it, then go back to the Articles grid to select the new author.

I set myself the task of creating a more user-friendly screen for new articles. It took me a while to figure out how, because the documentation does not seen to cover my requirement, but after some help from LightSwitch experts I arrived at a solution.

First, I created a New Data Screen based on the Article table. Then I clicked Add Data Item and selected a local property of type Author, which I called propAuthor.

image

Next, I added two groups to the screen designer. Screen designs in LightSwitch are not like any screen designs you have seen before. They are a hierarchical list of elements, with properties that affect their appearance. I added two new groups, Group Button and GroupAuthor, and set GroupAuthor to be invisible. Then I dragged fields from propAuthor into the Author group. Then I added two buttons, one called NewAuthor and one called SaveAuthor. Here is the dialog for adding a button:

image

and here is my screen design:

image

So the idea is that when I enter a new article, I can select the author from a drop down list; but if the author does not exist, I click New Author, enter the author details, and click Save. Nicer than having to navigate to a new screen.

In order to complete this I have to write some more code. Here is the code for NewAuthor:

partial void NewAuthor_Execute()
{
     // Write your code here.
     this.propAuthor = new Author();
     this.FindControl("GroupAuthor").IsVisible = true;
}

Note the use of FindControl. I am not sure if there is an easier way, but for some reason the group control does not show up as a property of the screen.

Here is the code for SaveAuthor:

partial void SaveAuthor_Execute()
{
    // Write your code here.
    this.ArticleProperty.Author = propAuthor;
    this.Save();
}

image

This works perfectly. When I click Save Author, the new author is added to the article, and both are saved. Admittedly the screen layout leaves something to be desired; when I have worked out what Weighted Row Height is all about I will try and improve it.

image

Before I finish, I must mention the LightSwitch Publish Wizard, which is clearly the result of a lot of work on Microsoft’s part. First, you choose between a desktop or web application. Next you choose an option for where the services are hosted, which can be local, or on an IIS server, or on Windows Azure.

image

Something I like very much: when you deploy, there is an option to create a new database, but to export the data you have already entered while creating the app. Thoughtful.

image

As you can see from the screens, LightSwitch handles security and access control as well as data management.

What do I think of LightSwitch after this brief exercise? Well, I am impressed by the way it abstracts difficult things. Considered as an easy to use tool for model-driven development, it is excellent.

At the same time, I found it frustrating and sometimes obscure. The local property concept is a critical one if you want to build an application that goes beyond what is generated automatically, but the documentation does not make this clear. I also have not yet found a guide or reference to writing code, which would tell me whether my use of FindControl was sensible or not.

The generated applications are functional rather than beautiful, and the screen layout designer is far from intuitive.

How is the target non-developer developer going to get on with this? I think they will retreat back to the safety of Access or FileMaker in no time. The product this reminds me of more is FoxPro, which was mainly used by professionals.

Making sense of LightSwitch

So what is LightSwitch all about? I think this is a bold effort to create a Visual Basic for Azure, an easy to use tool that would bring multi-tier, cloud-hosted development to a wide group of developers. It could even fit in with the yet-to-be-unveiled app store and Appx application model for Windows 8. But it is the Visual Basic or FoxPro type of developer which Microsoft should be targeting, not professionals in other domains who need to knock together a database app in their spare time.

There are lots of good things here, such as the visual database designer, the Publish Application wizard, and the whole model-driven approach. I suspect though that confused marketing, the Silverlight dependency, and the initial strangeness of the whole package, will combine to make it a hard sell for Microsoft. I would like to be wrong though, as a LightSwitch version 2 which generates HTML 5 instead of Silverlight could be really interesting.