Archive for November, 2010

…Long live HTML5

November 16th, 2010 by Steven Myhill-Jones

I trust most readers recognized immediately that my HTML5 is dead post last week was laden with irony. This week, I want to take a step back and put this important standard in proper context (which is ultimately more helpful for decision makers). And since this blog is geared towards organizations deploying Esri web mapping technology like ArcGIS Server, I’ll get a bit more specific to our domain.

I’ll first acknowledge a personal bias; I’m biased against plugins and always have been because they can act as barriers to use (I still have nightmares about trying to deploy the Java client for ArcIMS in 2001). This is a reason why I’m excited about HTML5.

While I’ve been vocal about my general disdain for plugins over the years, I recognize that not all plugins are created equal and the benefits can outweigh the costs sufficiently to warrant their use for certain types of applications (read, in lots of situations that hundreds of our clients have requirements for).

Especially when used for internal apps and/or more feature-rich apps, I think that Flash/Flex and Silverlight remain highly relevant and appropriate for several reasons:

  • As far as plug-ins go, Flash is ubiquitous (98%) and Silverlight (presently ~65%) will likely be there soon.
  • They’re from major vendors that people know and trust.
  • Esri is placing considerable focus on their Flex and Silverlight APIs.
  • They are well-suited to web GIS. As unfashionable as feature rich ArcView 3.x surrogate apps are these days, orgs quickly discover you can’t take functionality away that users have become accustomed to as part of their ArcIMS-generation apps. Users can get pissed when you take stuff away that they’re used to having.
  • They deliver a consistent user experience assuming your device supports that plugin (the latter is important, which I’ll discuss later). There are foibles with JavaScript across different browsers (for our product/project development, vastly more testing has been required), which slows development.
  • You can accomplish things (non-trivial things) that you likely won’t be able to with HTML5 any time soon, which is pertinent to certain types of apps.
  • They’re really starting to hit their stride productivity-wise for Esri technology, whereas HTML5 is probably a couple years off before we can start to get going in earnest for many common use cases. Note: We’re releasing Silverlight and Flex technology that allows people to start migrating/replacing their ArcIMS apps and Web ADF apps in earnest in 2011. While we think we’ve got a smart, realistic HTML5 strategy rolling, it’d be way premature to be attempting any of our product development using HTML5.
  • It’s possible to leverage these platforms now, and tie in HTML5 naturally over time, reusing much of the same architecture.

Here’s why I particularly like Silverlight:

  • The Silverlight development experience is integrated with excellent Microsoft development technology which allows orgs to get more done, faster. Our development pace with Silverlight far outstrips our output with Esri’s JavaScript API and Flex API. We’ve done lots of product development with all three, and our team prefers Silverlight by a significant margin (followed by Flex).
  • Silverlight seems to be gaining lots of traction, and there’s a huge talent pool of Microsoft developers. I have a hunch Esri is going to continue getting behind Silverlight in a significant way.

Here’s why I’m excited about HTML5:

  • It requires no plug-in, which removes a potential hurdle in front of the map counter for end-users. I consider this significant.
  • Not proprietary; this is usually key for any true web standard.
  • Ideal for apps that receive massive traffic (e.g. hurricane evacuation apps).
  • One app that serves multiple platforms is preferable to developing different apps for different platforms, provided interactions aren’t substantially different between your small touch screen vs. desktop screen/mouse which they often are.
  • All the big vendors are getting behind HTML5, and I have minimal concerns it’ll suffer from a failure to launch. There will be tremendous competition to implement it well.
  • Every time I hear the word “Flash” I think of splash pages, and every time I hear “Silverlight” I picture a silverfish zipping across my old kitchen floor.

People should default to the simplest solution that meets their requirements. I doubt anyone would argue that, all things being equal, not requiring a plug-in is superior to requiring a plug-in. If you’re in a situation now where you think a plug-in jeopardizes your maximum user base and you can deliver an app that doesn’t require a plug-in and it delivers the goods without increasing your work significantly, definitely do it. A common candidate for this is a simple, targeted app intended to answer one or two questions for lots of people. Esri’s JavaScript API will be your go-to technology right now (which is what we use) but cool stuff with HTML5 isn’t that far off (which is what we will be using, and are doing early-stage R&D with now).

Technologies like Flex and Silverlight have an essential role to play for quite a while; especially over the next few years and likely much longer for heavier/richer applications. HTML5 will provide tremendous value as it matures in the years ahead, and will inevitably replace many types of apps for which it is fundamentally better suited.

HTML5 is dead

November 9th, 2010 by Steven Myhill-Jones

That’s right, you heard it here first. HTML5 is dead. Here’s why: HTML6 is going to be way better. It’ll overcome the things that the HTML5 standard is missing and better integrate with the technology of tomorrow. It’ll provide the kind of development tools and rich user experience that we all wish HTML5 included.

Sound ridiculous?  It is, except that it’s ridiculous because we’ve simply added an extra 5-10 years or so onto the correct but unhelpful declarations opinionati make all the time in the tech sector. If we all listened to these folks, nothing would get done. By the time a technology reaches the plateau of productivity, they consider it irrelevant.

What’s my point? Build for the era you’re in. Choose the development technology of today that you envision best fitting your needs now and for the next while (whether that be Silverlight, Flex, or JavaScript). The evolution of technology is inexorable, so make your plans assuming and embracing change over time. Educate yourself about what’s coming, and then make decisions that keep you as aligned with the future as possible. Fight against the paralysis of inaction caused by future technologies that are still too far off to wait for.

Picking a technology that’s out of favor in five years isn’t a screw-up if you made the best decision from among available alternatives to actually get stuff done. That such a choice will eventually be obsolete (and sometimes sooner than you really have the stomach for) doesn’t represent failure on your part. On the contrary, it shows that you understand the importance of delivering value to end users in the present.

Silverlight, Microsoft and HTML5

November 5th, 2010 by David Stevenson

Microsoft recently held their annual PDC (Professional Developer’s Conference) during which Steve Ballmer and Bob Muglia (President, Server and Tools business) made comments regarding a shift in Microsoft’s strategy on Silverlight as well as a concerted focus on HTML5.  A subsequent article surprised the tech community around the future of Silverlight.  There was a lot of speculation and confusion last Friday; some people were suggesting that Microsoft was winding down Silverlight and others suggested that Microsoft simply screwed their messaging up.  On Monday arrived a clarifying blog post from Bob Muglia explaining that Microsoft is in no way backing away from Silverlight, and that it will remain a core technology well into the future.  Similar messages from Microsoft followed.  Another one worth reading came from Scott Guthrie a few days later.

Here’s my take on the situation.  First, it’s unfortunate that Mr. Muglia’s message was delivered and quoted the way it was.  Microsoft is now taking steps to try to undo the understandable surprise Mr. Muglia caused in the developer community. For some, regardless of all subsequent clarifying communication from Microsoft, they’ll still perceive it as simply kicking sand over Mr. Muglia’s unwanted and premature reveal of the truth. Some people have a thing against Microsoft, and they’ll pick the reality that conforms to their desires.

Silverlight is valuable, fills many of the gaps that HTML currently has and might always have, and continues to be a core Microsoft web development technology. The community uproar from the events of last Friday support this.  While there were PDC sessions on Silverlight and other established technologies, Microsoft focused their marketing machine on new technologies; Windows Phone 7, Azure, IE9 (with a lot of HTML5 focus), and other offerings for which they want to increase their exposure and market share. Remember that the PDC is as much about marketing Microsoft’s new and emerging technologies as it is about educating developers on the existing, successful ones!

The reality is that HTML5 is important and it’s still really early in its evolution. Microsoft, along with the rest of the world, realizes that the standard for the open web is moving toward HTML5.  HTML5 clearly strives to do what technologies like Silverlight and Flash already can, and for true standardization to occur it is essential outside any proprietary plug-in. The race between the giants like Microsoft, Apple, and Google is only just beginning, and a lot of the recent messaging from Microsoft around HTML5 can simply be seen as declaring their intent to be at the forefront of that race.  However, HTML5 has a long way to go before it meets the functional and development productivity levels of Silverlight, not to mention overcoming the browser compatibility issues that we still face with HTML4.  I, like anyone else, can only speculate, but it appears to me that truly pervasive use of HTML5 is still years away. In fact, the W3C is going so far as to suggest to the tech community to hold off on HTML5 deployments until the spec settles more.  Until that time, technologies like Silverlight will remain the go-to technologies for efficiently building rich, interactive applications that run across multiple browsers on multiple platforms.

For our customers that are building or are considering building Esri ArcGIS Server applications using Silverlight, my recommendation is to not let the recent articles and discussions cause undue concern.  Of course assimilating new information in order to make sensible, informed decisions remains paramount and I’m not suggesting simply disregarding recent news.  Rather, don’t be paralyzed by HTML5’s future potential and realize that Silverlight continues to remain a great option for efficiently building and delivering value to your customers today and for years to come.

Scalable, Distributed Architecture for REST-based Applications

November 3rd, 2010 by Drew Millen

We recently announced the release of Geocortex Essentials 3.1.  One of the big changes in this release is the introduction of an architecture which will support distributed deployments of the Geocortex Essentials REST API.

To understand this, let’s take a look at the architecture before 3.1:

image

NOTE: For simplicity, the relationship with ArcGIS Server is not described in this diagram.

Notice how multiple client applications (such as the Geocortex Viewer for Flex and the Geocortex Viewer for Silverlight) connect to the Geocortex Essentials REST API.  From the REST API they learn about the configuration of the site structure that should be used, and they can access server side functionality such as hi-resolution, large-format printing and reporting.  The Geocortex Essentials REST API is responsible for managing the content in the Sites Directory.

Now let’s take a look at how things have changed with the introduction of the distributed architecture in Geocortex Essentials 3.1:

image

Geocortex Essentials now has a new component called Geocortex Application Services.  The application services live within Geocortex Agent, which is windows service (the same Geocortex Agent that gets installed with Geocortex Optimizer).  Application Services introduces a centralized mechanism to deal with authentication and user management, security tokens, and access to storage (for example, reading/writing site configuration files or print templates).

By creating Application Services and externalizing these functions from the Geocortex Essentials REST API, we can improve the performance of systems under heavy load by distributing the REST APIs across multiple servers.  Think cloud deployment: when your application is under heavy load you can respond by standing up more instances of the REST API behind a load balancer.

Having the Application Services centralized means that you only have to configure your sites and security in one single location.