Category Archives: web authoring

The Windows 10 web browser story: it’s complex

Microsoft’s Jason Weber has posted details of the web browser story in Windows 10.

There will be two browsers and two rendering engines in Windows 10:

  • Project Spartan is the “universal app” version of the browser, the successor to Metro IE.
  • Internet Explorer will remain.

The two rendering engines are EdgeHTML (new) and MSHTML (old). Both engines can be used in either browser, so even the “Project Spartan” browser has a compatibility mode. Both browsers default to the new rendering engine.

image

However, only Internet Explorer supports features such as ActiveX controls and Browser Helper Objects, so some legacy web sites and applications will only work properly in IE.

For details of what EdgeHTML supports, see the status page.

Microsoft has been plagued by the “coded for IE” problem, where sites deliver inferior content if IE is detected – even where IE is fully capable of rendering the up-to-date content. Hence this comment:

Edge mode introduces an interoperable UA string designed to get today’s modern Web content, and to avoid old IE-only content. We’ve also spent a lot of time ensuring that the IE platform behaves like modern Web content expects.

It is unfortunate that Windows 10 will still have two web browsers, since this is a point of confusion for users. A lot will depend on presentation and defaults; if Microsoft can hide desktop IE so it is only used by those organisations that know they need it, that would be a good thing – presuming that Project Spartan offers a decent experience when used on the desktop.

There is a debate in the comments to Weber’s post about whether Microsoft should cease developing its own browser:

This looks like chrome. Please contribute to chrome if you want to make the web browser better. All this does is increase development costs by having to support another browser. Enough damage has been done by IE. Please stop development.

and the counter:

No, sane developers don’t want a single engine.

People want different engines that pushes each other forward, make things in a standard way (not like Chrome) and allows to check if the problem is their code or a bug in the browser.

My perspective on this is that Google already dominates web search and if Microsoft were to adopt its browser engine, there would be increased risk of Google dictating whatever standards suit its own purpose – just as Microsoft did in the dark days of stagnant IE development. Microsoft’s energetic development of IE is actually good for Google and for the rest of us.

Microsoft takes its .NET runtime open source and cross-platform, announces new C++ compilers for iOS and Android: unpacking today’s news

Microsoft announced today that the .NET runtime will be open source and cross-platform for Linux and Mac. There are a several announcements and it is potentially confusing, so here is a quick summary.

The .NET runtime, also known as the CLR (Common Language Runtime) is the virtual machine that runs Microsoft’s C#, F# and Visual Basic .NET languages, performing just –in-time compilation to native code and providing interop between the application code and the operating system APIs. It is distinct from the .NET Framework, which is the library of mostly C# code that underlies application platforms like ASP.NET, Windows Presentation Foundation (WPF), Windows Forms, Windows Communication Foundation and more.

There is is already a cross-platform version of .NET, an open source project called Mono founded by Miguel de Icaza in 2001, not long after the first preview release of C# in 2000. Mono runs on Linux, Mac and Windows. In addition, de Icaza is co-founder of Xamarin, which uses Mono together with its own technology to compile C# for iOS, Android and Mac OS X.

Further, some of .NET is already open source. At Microsoft’s Build conference earlier this year, Anders Hejlsberg made the Roslyn project, the compiler for the next generation of the .NET Runtime, open source under the Apache 2.0 license. I spoke to Hejlsberg about the announcement and wrote it up on the Register here. Note the key point:

Since Roslyn is the compiler for the forthcoming C# 6.0, does that mean C# itself is now an open source language? “Yes, absolutely,” says Hejlsberg.

What then is today’s news? Blow by blow, here are what seems to me the main pieces:

  • The CLR itself will be open source. This is the C++ code from which the CLR is compiled.
  • Microsoft will provide a full open source server stack for Mac and Linux including the CLR. This will not include the frameworks for client applications; no Windows Forms or WPF. Rather, it is the “.NET Core Runtime” and “.NET Core Framework”. However Microsoft is working with the Mono team which does support client applications so there could be some interesting permutations (bear in mind that Mono also has its own runtime). However Microsoft is focused on the server stack.
  • Microsoft will release C++ frameworks and compilers for iOS and Android, using the open source Clang (C and C++ compiler front-end) and LVVM (code generation back end), but with Visual Studio as the IDE. If you are targeting iOS you will need a Mac with a build agent, or you can use a cloud build service (see below). The Android compiler is available now in preview, the iOS compiler is coming soon. “You can edit and debug a single set of C++ source code, and build it for iOS, Android and Windows,” says Microsoft’s Soma Somasegar, corporate VP of the developer division.
  • Microsoft has a new Android emulator for Windows based on Hyper-V. This will assist with Android development using Cordova (the HTML and JavaScript approach also used by PhoneGap) as well as the new C++ option.

    image

  • The next Visual Studio will be called Visual Studio 2015 and is now available in preview; download it here.
  • There will be a thing called Connected Services to make it easier to code against Office 365, Salesforce and Azure
  • A new edition of Visual Studio 2013, called the Community Edition, is now available for free, download it here. The big difference between this and the current Express editions is first that the Community Edition supports multiple target types, whereas you needed a different Express edition for Web applications, Windows Store and Phone apps, and Windows desktop apps.  Second, the Community Edition is extensible so that third parties can create plug-ins; today Xamarin was among the first to announce support. There may be some license restrictions; I am clarifying and will update later.
  • New Cloud Deployment Projects for Azure enable the cloud infrastructure associated with a project to be captured as code.
  • Release Management is being added to Visual Studio Online, Microsoft’s cloud-hosted Team Foundation Server.
  • Enhancements to the Visual Studio Online build service will support builds for iOS and OS X
  • Visual Studio 2013 Update 4 is complete. This is not a big update but adds fixes for TFS and Visual C++ as well as some new features in TFS and in GPU performance diagnostics.

The process by which these new .NET projects will interact with the open source community will be handled by the .NET Foundation.

What is Microsoft up to?

Today’s announcements are extensive, but with two overall themes.

The first is about open sourcing .NET,  a process that was already under way, and the second is about cross-platform.

It is the cross-platform announcements that are more notable, though they go hand in hand with the open source process, partly because of Microsoft’s increasingly close relationship with Mono and Xamarin. Note that Microsoft is doing its own C++ compilers for iOS and Android, but leaving the mobile C# and .NET space open for Xamarin.

By adding native code iOS and Android mobile into Visual Studio, Microsoft is signalling real commitment to these platforms. You could interpret this as an admission that Windows Phone and Windows tablets will never reach parity with their rivals, but it is more a consequence of the company’s focus on cloud, and in particular Office 365 and Azure. The company is prioritising the promotion of its cloud services by providing strong tooling for all major client platforms.

The provision of new Microsoft server-side .NET runtimes for Mac and Linux is a surprise to me. The Mac is not much used as a server but very widely used for development. Linux is an increasingly important operating system within the Azure cloud platform.

A side effect of all this is that the .NET Framework may finally fulfil its cross-platform promise, something Microsoft suppressed for years by only supporting it on Windows. That is good news for those who like programming in C#.

The .NET Framework is changing substantially in its next version. This is partly because of the Roslyn compiler, which is itself written in C# and opens up new possibilities for rich refactoring and code transformation; and partly because of .NET Core and major changes in the forthcoming version of ASP.NET.

Is Microsoft concerned that by supporting Linux it might reduce the usage of Windows Server? “In Azure, Windows and Linux are a core part of our platform,” Somesegar told me. “Helping developers by providing a good set of tools and letting them decide what server they run on, we feel is all goodness. If you want a complete open source platform, we have the tools for them.”

How big are these announcements? “I would say huge,”  Somasegar told me, “What is shows is that we are not being constrained by any one platform. We are doing more open source, more cross-platform, delivering Visual Studio free to a broader set of people. It’s all about having a great developer offering irrespective of what platform they are targeting or what kind of app they are building.”

That’s Microsoft’s perspective then. In the end, whether you interpret these moves as a sign of strength or weakness for Microsoft, developers will gain from these enhancements to Visual Studio and the .NET platform.

Microsoft releases WinJS cross-browser JavaScript library but why?

Microsoft has announced WinJS 3.0:

The Windows Library for JavaScript (WinJS) project is pleased to announce the general availability of its first release – WinJS 3.0 – since the open source project began at //BUILD 2014.

Much of WinJS will run on any modern browser but the browser support matrix has a number of gaps:

image

You can also see what runs where from this status table.

But what is WinJS? Note that it comes from the Windows apps team, not the web development team at Microsoft. WinJS was designed to enable app development for Windows 8 “Metro” (also known as the Windows Runtime) using JavaScript, CSS and HTML. Back in 2010, when Microsoft signalled the end of Silverlight and the rise of HTML 5 for browser-based applications, early versions of WinJS would already have been in preparation. Using WinJS you can share code across a Windows 8 app, web apps, and via an app packager like Apache Cordova, in apps for Android and iOS as well.

Note that Cordova is now integrated into Visual Studio, using the catchy name Multi-Device Hybrid App:

image

If you want to know what kind of controls and components are on offer in WinJS, you can find out using the excellent demo site here. This is Firefox:

image

Quick summary then: WinJS lets you build apps that look like Windows 8 Store apps, but which run cross-browser and cross-platform. But who wants to do that?

Maybe Microsoft does. The messaging from the company, especially since CEO Satya Nadella took over from Windows guy Steve Ballmer, is “any device”, provided of course that they hook up to Microsoft’s services. That messaging is intended for developers outside the company too. Check out the current campaign for Microsoft Azure, which says “consume on any device”.

image

This could be a web application, or it could be a client app using Azure Mobile Services or an ASP.NET Web API application to connect to cloud data.

You do not have to use WinJS to consume Microsoft’s services of course. Why would developers want to use the look and feel of a rather unloved app platform, rather than the native look and feel of Android or iOS? That is an excellent question, and in most cases they will not. There could be cases though, for example for internal business apps where users care most about functionality. What is the current stock? What is the lead time? Show me this customer’s order history. A WinJS app might not look right for the platform, but the UI will be touch-friendly, and ease of rollout across the major mobile platforms could trump Apple’s design guidelines.

If you are writing a pure web application, users expectations concerning native look and feel are not so high. The touch-oriented design of WinJS is its main appeal, though other web frameworks like JQuery Mobile also offer this. The “Metro” design language is distinctive, and Microsoft will be making a renewed push for Windows Store apps, or Universal Apps, as part of the new wave of Windows called Windows 9 or “Threshold”. WinJS is the way to build apps for that platform using JavaScript and HTML, with the added bonus of easy porting to a broad range of devices.

This is a hard sell though. I am impressed by the effort Microsoft has put into making WinJS work cross-platform, but will be surprised to see much usage outside Windows Store apps (including Windows Phone). On the other hand, it does help to keep the code honest: this really is HTML and JavaScript, not just a wrapper for Windows Runtime APIs.

Book review: Professional ASP.NET MVC 5. Is this the way to learn ASP.NET MVC?

This book caught my eye because while I like ASP.NET MVC, Microsoft’s modern web application framework, it seems to be badly documented. Even the word “badly” is not quite right; there is lots of documentation, some of high quality, but finding your way around it is challenging, thanks to the many different pieces involved. When I completed an ASP.NET MVC project recently, I found it frustrating thanks to over-reliance on sample projects (hey, here is a an application we did that works, see if you can figure out how we did it), many out of date articles relating to old versions; and the opposite, posts and samples which include preview software that does not seem wise to use in production.

image

In my experience ASP.NET MVC is both cleaner and faster than ASP.NET Web Forms, the older .NET web framework, but there is more to learn before you can go ahead and write an application.

Professional ASP.NET MVC 5 gives you nearly 600 pages on the subject. It is aimed at a broad readership: the introduction states:

Professional ASP.NET MVC 5 is designed to teach ASP.NET MVC, from a beginner level through advanced topics.

Perhaps that is too broad, though the idea is that the first six chapters (about 150 pages) cover the basics, and that the later chapters are more advanced, so if you are not a beginner you can start at chapter 7.

The main author is Jon Galloway who is a Technical Evangelist at Microsoft. The other authors are Brad Wilson, formerly at Microsoft and now at CenturyLink Cloud; K Scott Allen at OdeToCode, David Matson who is on the ASP.NET MVC team at Microsoft, and Phil Haack formerly at Microsoft and now at GitHub. I get the impression that Haack wrote several chapters in an earlier edition of the book, but did not work directly on this one; Galloway brought his chapters up to date.

Be in no doubt: there are plenty of well-informed ASP.NET MVC people on this team.

The earlier part of the book uses a sample Music Store application, a version of which is publicly available here. You can also download a tutorial, based on the sample, written by Galloway. The public tutorial however dates from 2011 and is based on ASP.NET MVC 3 and Visual Studio 2010. The book uses Visual Studio 2013.

Chapters 1 to 6, the beginner section, do a decent job of talking you through how to build a first application. There are chapters on Controllers, Views, Models, Forms and HTML Helpers, and finally Data Annotations and Validation. It’s a good basic introduction but if you are like me you will come out with many questions, like what is an ActionResult (the type of most Controller methods)? You have to wait until chapter 16 for a full description.

Chapter 7 is on Membership, Authorization and Security. That is too much for one chapter. It is mostly on security, and inadequate on membership. One of my disappointments with this book is that Azure Active Directory hardly gets a mention; yet to my mind integration of web applications with Office 365 (which uses Azure AD) is a huge feature for Microsoft.

On security though, this is a useful chapter, with handy coverage of Cross-Site Request Forgery and other common vulnerabilities.

Next comes a chapter on AJAX with a little bit on JQuery, client-side validation, and Ajax ActionLinks. Here is the dilemma though. Does it make sense to cover JQuery in detail, when this very popular open source library is widely documented elsewhere? On the other hand, does it make sense not to cover JQuery in detail, when it is usually a vital part of your ASP.NET MVC application?

I would add that this title is poor on design aspects of a web application. That said, I was not expecting much on the design side; but what would help would be coverage of how to work with designers: what is safe to hand over to designers, and how does a typical designer/developer workflow play out with ASP.NET MVC?

I would also like to see more coverage of how to work with Bootstrap, the CSS framework which is integrated with ASP.NET MVC 5 in Visual Studio. I found it a challenge, for example, to discover the best way to change the default fonts and colours used, which is rather basic.

Chapter 9 is on routing, dry but essential background. Chapter 10 on NuGet, the Visual Studio package manager, and a good chapter given how important NuGet now is for most Visual Studio work.

Incidentally, many of the samples for the book can be installed via NuGet. It’s not completely obvious how to do this. I found the best way is to go to http://www.nuget.org and search for Wrox.ProMvc5 – here is the link to the search results. This lists all the packages available; note the package names. Then open the Nuget package manager console and type:

install-package [packagename]

to get the sample.

Chapter 11 is a too-brief chapter on the Web API. I would like to see more on this, maybe even walking through a complete application with clients for say, Windows Phone and a web application – though the following chapter does present a client example using AngularJS.

Chapter 13 is a somewhat theoretical look at dependency injection and inversion of control; handy as Microsoft developers talk a lot about this.

Next comes a very brief introduction to unit testing, intended I think only as a starting point.

For me, the the next two chapters are the most valuable. Chapter 15 concerns extending MVC: you learn about extending models with value providers and model binders; validating models; writing HTML helpers and Razor (the view engine in ASP.NET MVC) helpers; authentication filters and authorization filters. Chapter 16 on advanced topics looks in more detail at Razor, routing, templates, ActionResult and a few other things.

Finally, we get a look at how the Nuget.org application was put together, and an appendix covering some miscellaneous details like what is new in ASP.NET MVC 5.1.

Conclusions

I find this one hard to summarise. There is too much missing to give this an unreserved recommendation. I would like more on topics including ASP.NET Identity, Azure AD integration, Entity Framework, Bootstrap, and more. Trying to cover every developer from beginner to advanced is too much; removing some of the introductory material would have left more room for the more interesting sections. The book is also rather weighted towards theory rather than hands-on coding. At some points it felt more like an explanation from the ASP.NET MVC team on “why we did it this way”, than a developer tutorial.

That said, having those insights from the team is valuable in itself. As someone who has only recently engaged with ASP.NET MVC in a real application, I did find the book useful and will come back to some of those explanations in future.

Looking at what else is available, it seems to me that there is a shortage of books on this subject and that a “what you need to know” title aimed at professional developers would be widely welcomed. It would pay Microsoft to sponsor it, since my sense is that some developers stick with ASP.NET Web Forms not because it is better, but because it is more approachable.

 

A note on Azure storage and downloading large files

I have written a simple ASP.NET MVC application for upload and download of files to/from Azure storage.

Getting large file upload to work was the first exercise, described here. That is working well; but what about download?

If your files in Azure storage are public, you can simply serve an URL to the file. If it is not public though, you have a couple of choices:

1. Download the file under application control, by writing to Response.OutputStream or using a FileResult action.

2. Issue a Shared Access Signature (SAS) to the client which enables it to retrieve the file directly from Azure storage. The SAS is sent as an URL argument which tells Azure storage that the request is authorised. The browser downloads the file directly, so it makes no difference to your web application if the file is large.

Note that if you use the first option, it will not work with large files if you simply call DownloadToStream or similar:

container.GetBlockBlobReference(FileName).DownloadToStream(Response.OutputStream);

Why not? Well, the way this code works is that it downloads the large file to the web server, then sends it to the browser. What if your large file is 5GB? The browser will wait a long time for the first byte to be served (giving the user an unresponsive page); but before that happens, the web application will probably throw an exception because it does not like downloading such a large file.

This means the SAS option is a good one, though note that you have to specify an expiry time which could cause problems for users on a slow connection.

Another option is to serve the file in chunks. Use CloudBlockBlob.DownloadRangeToStream to write to Response.OutputStream in a loop until the download is complete. Call Response.Flush() after each chunk to send the chunk to the browser immediately.

This gives the user a nice responsive download experience complete with a cancel option as provided by the browser, and does not crash the application on the server. It seems to me a reasonable approach if the web application is also hosted on Azure and therefore has a fast connection to Azure storage.

What about resuming a failed download? The SAS approach should work as Azure supports it. You could also support this in your app with some additional work since Resume means reading the Range header in a GET request. I have not tried doing this but you might find some clues here.

Google forks WebKit into Blink: what are the implications?

Yesterday Google announced that it is forking WebKit to create Blink, a new rendering engine to be used in its Chrome browser:

Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation – so today, we are introducing Blink, a new open source rendering engine based on WebKit.

Odd that not long ago we were debating the likelihood and merits of WebKit becoming the de facto standard for HTML. Now Google itself is arguing against such a thing:

… we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.

Together with the announcement from Mozilla and Samsung of a new Android browser which, one assumes, may become the default browser on Samsung Android phones, there is now significant diversity/competition/fragmentation in the browser market (if you can call it a market when everything is free).

The stated reason for the split concerns multi-process architecture, with claims that Google was unwilling to assist with integrating Chromium’s multi-process code into WebKit:

Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn’t really an API-stable layer of the Chromium stack that packaged the process support.)

Writing our own seemed like the least bad approach.

Or maybe it was the other way around and Apple wanted to increase its control over WebKit and optimize it for the OSX and iOS rather than for multiple platforms (which would be the Apple way).

It matters little. Either way, it is unsurprising that Apple and Google find it difficult to cooperate when Android is the biggest threat to the iPhone and iPad.

The new reality is that WebKit, instead of being a de facto standard for the Web, will now be primarily an Apple rendering engine. Chrome/Chromium will be all Google, making it less attractive for others to adopt.

That said, several third parties have already adopted Chromium, thanks to the attractions of the Chromium Embedded Framework which makes it easy to use the engine in other projects. This includes Opera, which is now a Blink partner, and Adobe, which uses Chromium for its Brackets code editor and associated products in the Adobe Edge family.

The benefit of Blink is that diverse implementations promote the importance of standards. The risk of Blink is that if Google further increases the market share of Chrome, on desktop and mobile, to the point where it dominates, then it is in a strong position to dictate de-facto standards according to its own preferences, as suggested by this cynical take on the news.

The browser wars are back.

Native apps vs HTML 5: no consensus over how to choose

Wondering whether to invest in native apps or HTML5 web apps (maybe wrapped as native) for your next mobile development project? Welcome to plenty of confusion about which is the best path to take. Here are a few pieces of evidence from this month:

A Compuware survey of 3,500 consumers showed a preference for mobile apps over mobile websites:

When consumers were asked about the benefits of using a mobile app versus a mobile website (a website that is specifically designed to be viewed on a mobile device), the majority (85 percent) said they preferred mobile apps primarily because apps are more convenient, faster and easier to browse.

Just 1% expressed a preference for mobile websites over apps. Note that consumers cannot be expected to know whether or not a native app is actually written in HTML5 or not; but here is an intriguing report from Xero, which makes accounting software:

Very early on we chose to build Xero Touch using HTML5 technologies. That choice showed that we care about the future of the open web and its continued success as an application delivery platform and we firmly believe that HTML5 is the future of development across any and all platforms. We do not regret this choice – but we’ve found that building a complicated mobile application in HTML5 has been hard. Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex.

… the lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go … Maintaining and iterating a web app was becoming a big impediment – so the next release of Xero Touch will be built with native technologies and we’ve already made a lot of progress. It does feel better.

If a company is so unhappy with its development platform that it is willing to endure the pain and expense of switching, that is evidence of deep dissatisfaction.

On the other hand, here is the UK’s Government Digital Service:

Our position is that native apps are rarely justified. Since November 2012, central government departments and agencies have to get approval from Cabinet Office before starting work on apps. For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs, especially if the underlying service design is sub-optimal. Departments should focus on improving the quality of the core web service.

Is this because the Government Digital Service is spending public money and therefore apps are an unnecessary luxury? That is arguable, though it has not stopped the BBC (also publicly funded) from delivering a ton of apps, to predictable complaints from owners of less favoured platforms like Windows Phone.

This one will run and run. HTML5 will get better, but so also will native platforms, so I doubt this difficult choice will get easier any time soon.

It may be a matter of whether your particular app is a good fit for HTML5 or not. However, I am not aware of any consensus over what characteristics make an app a good or bad fit for an HTML5 solution, except that for broad reach HTML5 cannot be beaten, and for full access to device and OS features there is no substitute for native.

Google the new Microsoft, goes to war on Windows Phone users (updated)

Google has fired a one – two – three salvo at Microsoft and Windows Phone users. Consider the following.

First, we learn that Google, under the guise of Winter cleaning, is removing Google Sync from its Mail, Calendar and Contacts online products, for consumers only. This is the Exchange ActiveSync protocol used by Windows Phone and other mobile devices:

Starting January 30, 2013, consumers won’t be able to set up new devices using Google Sync; however, existing Google Sync connections will continue to function

Next, Microsoft reveals that Google is blocking the creation of a YouTube app for Windows Phone:

Microsoft is ready to release a high quality YouTube app for Windows Phone. We just need permission to access YouTube in the way that other phones already do, permission Google has refused to provide.

Now Google is blocking Windows Phone users from accessing Google Maps in the mobile browser. Google says:

The mobile web version of Google Maps is optimized for WebKit browsers such as Chrome and Safari. However, since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile web.

but Microsoft observes that Google Maps works fine in IE on Windows and:

Internet Explorer in Windows Phone 8 and Windows 8 use the same rendering engine.

This last is of most concern. It is one thing to “optimize” for WebKit, another specifically to block non-WebKit browsers. If WebKit is in Google’s eyes the de facto standard for mobile devices – which are more significant than desktop browsers – then what is the function of the W3C, and what is to prevent a repetition of the IE6 effect where one company (Microsoft) in controlled what was implemented for most users?

We can conclude that Google has decided its interests are better served by inconveniencing Windows Phone users in the hope of stifling the platform, rather than trying to persuade Windows Phone users to use its services as it does on Apple’s iOS platform (with considerable success).

Sympathy for Microsoft will be limited because of its history. The company has never been a friend of cross-platform support, preferring to keep its customers on Windows. That said, it is difficult to find exact analogies for what is happening now. Nor is it clear what is and is not reasonable. Google Mail, YouTube and Maps are all Google properties. Is it reasonable to expect Google to make the extra effort required to support additional platforms? It is a matter for debate with no easy and clear cut answer.

This does not mean you have to like it. If it is Windows Phone today, what platform might it be tomorrow? Google’s willingness to lock out users of other platforms is a warning, and one that should give pause for thought to any individual, business or government entity who depends or is considering depending on the Google platform. If history tells us anything, it is that monopoly and lock-in always works out badly for users. Check the price of inkjet cartridges for a simple example, or the price of Microsoft Office for business users for another.

What will be the effect on Windows Phone of Google’s campaign? That again is hard to judge. Microsoft is better off than RIM, for example, because it does have something like a complete stack of what it takes to be a mobile platform, especially in conjunction with Nokia: search, maps, email, web-based documents, cloud storage, music streaming and so on. That said, “doesn’t work properly with YouTube, Gmail, Google Maps” is hardly a selling point.

Update: Google now says:

We periodically test Google Maps compatibility with mobile browsers to make sure we deliver the best experience for those users.

In our last test, IE mobile still did not offer a good maps experience with no ability to pan or zoom and perform basic map functionality. As a result, we chose to continue to redirect IE mobile users to Google.com where they could at least make local searches. The Firefox mobile browser did offer a somewhat better user experience and that’s why there is no redirect for those users.

Recent improvements to IE mobile and Google Maps now deliver a better experience and we are currently working to remove the redirect. We will continue to test Google Maps compatibility with other mobile browsers to ensure the best possible experience for users.

Is Google being straight with us? Why has the statement changed overnight?

One user discovered that certain URLs work for Google maps on Windows Phone and posted a video to prove it.

The video shows Google Maps working on a Lumia 800 (not the latest version of Windows Phone). I tried this URL:

ms-gl=au&ie=UTF8&t=m&source=embed&oe=UTF8&msa=0&msid=202255975001106586432.0004bb17c01b36a71a644

on my own Lumia 800 and it does indeed work. You can search for places, they show up on the map, and you can zoom with the + and – controls. However, it is not perfect. The search box is slightly corrupted and I am unable to pinch to zoom or swipe to pan. Better than nothing? Certainly.

Still, the experience is sufficiently degraded to lend some credence to Google’s statements; and there is undoubtedly extra work in supporting additional browsers as any web developer will confirm. 

Is Google at war with Windows Phone, or just not going out of its way to support a rival platform? Watch this space.

Microsoft scraps Expression Web and Design, blends Blend with Visual Studio

Microsoft is giving up its long effort to compete with Adobe in the design tools space. The Expression range of products is being discontinued, in favour of enhanced design capabilities in its developer-focused Visual Studio. Blend for Visual Studio continues, as a design tool for Windows Store apps and Windows Phone apps. A future edition of Blend for Visual Studio, currently in preview, will add WPF (Windows Presentation Foundation), Silverlight, and SketchFlow support. The release version of this upgraded edition is promised for Visual Studio 2012 Update 2.

The new product plans are announced here:

Microsoft is consolidating our lead design and development offerings — Expression and Visual Studio — to offer all of our customers a unified solution that brings together the best of Web and modern development patterns.

Expression Web, the web design tool which evolved out of FrontPage, and Expression Design, a vector drawing tool, will be discontinued completely. Microsoft’s web design tool will now be Visual Studio.

One consequence of this decision is that Expression Web 4 and Expression Design 4 are now free downloads, though unsupported.

Expression Encoder, for converting media for streaming, is also being discontinued, though Expression Encoder Pro will remain on sale throughout 2013. Microsoft says it is still investing in format conversion as part of Windows Azure Media Services.

Is this a good decision? In one sense it is a shame, since Expression Web is a decent product. At least one longstanding user of the product is disappointed:

For Microsoft, the web is dying and the future lies in Windows 8 apps. When asked what we web developers should be doing the answer was the same: Make Windows 8 apps. Which is about as useful as telling a contractor to start erecting tents instead of houses because houses are no longer relevant. Anyone outside the reach of whatever reality distorting force field they have running at the Redmond campus can see how idiotic this is, but that hasn’t stopped the people in charge for pulling the plug on one of the few applications from the company that had something new to offer.

That said, Expression Web has been available for a number of years and made little impression on the market, so how much value is there in continuing with a tool that few use, irrespective of its merits?

The decision makes sense in that Microsoft is shutting down an unsuccessful product line in order to focus on a successful one, Visual Studio.

Further, the end of Expression illustrates the difficulty Microsoft has had in attracting designers to its platform, despite high hopes in the early days of WPF and Mix conferences in Las Vegas.

Microsoft Silverlight: shattered into a million broken urls

There has been some Twitter chatter about the closure of silverlight.net, Microsoft’s official site for its lightweight .NET client platform. multimedia player and browser plug-in.

image

I am not sure when it happened, but it is true. Silverlight.net now redirects to a page on MSDN. Some but not all of the content has been migrated to MSDN, but Microsoft has not bothered to redirect the URLs, so most of the links out there to resources and discussions on Silverlight will dump you to the aforementioned generic page.

One of the things this demonstrates is how short-sighted it is to create these mini-sites with their own top-level domain. It illustrates how fractured Microsoft is, with individual teams doing their own thing regardless. Microsoft has dozens of these sites, such as windowsazure.com, windowsphone.com, asp.net, and so on; there is little consistency of style, and when someone decides to fold one of these back to the main site, all the links die.

What about Silverlight though? It was always going to be a struggle against Flash, but Silverlight was a great technical achievement and I see it as client-side .NET done right, lightweight, secure, and powerful. It is easy to find flaws. Microsoft should have retained the cross-platform vision it started with; it should have worked wholeheartedly with the Mono team for Linux-based platforms; it should have retained parity between Windows and Mac; it should never have compromised Silverlight with the COM support that arrived in Silverlight 4.

The reasons for the absence of Silverlight in the Windows Runtime on Windows 8, and in both Metro and desktop environments in Windows RT, are likely political. The ability to run Silverlight apps on Surface RT would enhance the platform, and if COM support were removed, without compromising security.

XAML and .NET in the Windows Runtime is akin to Silverlight, but with enough differences to make porting difficult. There is an argument that supporting Silverlight there would confuse matters, though since Silverlight is still the development platform for Windows Phone 8 it is already confusing. Silverlight is a mature platform and if Microsoft had supported it in the Windows Runtime, we would have had a better set of apps at launch as well as more developer engagement.

I posted that Microsoft’s Silverlight dream is over in October 2010, during Microsoft’s final Professional Developers Conference, which is when the end of Silverlight became obvious. It lives on in Windows Phone, but I would guess that Windows Phone 8.5 or 9.0 will deprecate Silverlight in favour of the Windows Runtime. A shame, though of course it will be supported on the x86 Windows desktop and in x86 Internet Explorer for years to come.