Moving on up…

It’s been a good run over here, but I’ve recently migrated this blog over to posterous.  Henceforth you can find me over here.  Please update your bookmarks, links, subscriptions, etc.  I’ll keep this blog in place for awhile but it will eventually be taken down. Be sure to check out http://blog.briannoyle.com

Migrating Your Apps to the Cloud at ArcGIS 10

Just in time for the 2010 ESRI User Conference, our team has been doing some investigation and testing of several apps running against ArcGIS Server 10 in the Amazon cloud.  What follows is a summary of our experience building and deploying a couple of apps against ESRI’s cloud-based solution.

Background and Business Case

In several presentations, blog posts, and articles of the recent past, Dave and I have detailed some of the Flex API work we have been doing for the USDA Forest Service Forest Health Technology Enterprise Team (FHTET). Historically, the FHTET team has collected and analyzed data describing the effects of major forest pests on the landscape. To this point in time, information has been disseminated by means of an annual pest report in hard copy format. While GIS and hard copy maps play a role in the preparation of this report, as a static report it does not fully leverage the data exploration and analysis tools available within today’s geoweb applications.

Calling all GeoGeeks: ESRI 2010 Dev Summit Party

Since we managed to stay out of trouble last year, and since two years in a row starts to make things look like a tradition, we’re throwing another “swa-ray” at our rental in Palm Springs to get the 2010 ESRI Developer Summit off on the right foot.  We’ll combine ESRI staff, developers, and miscellaneous members of the GeoGeek community with food and Fat Tire from New Belgium Brewing.  The result last year was a resounding success and we’re looking forward to seeing our old friends, making new ones, and enjoying an evening bbq around the pool.

If you stumbled across this post and are planning on attending the 2010 Developer Summit in Palm Springs, please consider joining us for an evening of socializing, networking, and good company. You can view the details and RSVP here.  Be sure to provide us a valid email address so we can send you directions as the date approaches.

A Show of Hands Please! Vote Now for 2010 ESRI Dev Summit Talks

Well abstract submissions for the ESRI 2010 Developer Summit in Palm Springs, CA are now closed and community voting for what user presentations will appear on the program has begun.  Dave has already thrown up a blog post here, discussing what we’re all planning on chatting about but I thought I’d reinforce that information with a quick note here.

Usability and the GeoWeb Part 4: Make it Fast

It’s taken me awhile to get to it due to a variety of work and family obligations but we’ve finally reached what will be my final post on usability and the geoweb…for now at least.  I haven’t covered all possible usability issues and scenarios, but have hit the high points and “big win” factors over the course of this series of posts.  To this point we’ve dealt with hiding complexity from our users, providing users with consistent, meaningful feedback within an application, and protecting users from themselves.  The lesson plan for this last installment will focus on application performance and its criticality in the overall user experience.

Fact: One of the most critical components of a highly usable software system is that it be highly performant…in other words, fast.  In the realm of the GeoWeb, this means that applications should load fast initially, and that responses to user activity within the application should be as quick as possible.  We now live in a world of instant gratification when it comes to our news, our hobbies, our finances, and above all our interactions with computers. Users don’t like to be kept waiting for 5 seconds every time they use your app to request information, input data, or perform other common processing tasks.  Gone are the days when watching the blue bar move in a web app, or watching the cursor spin on a wireless app were the status quo.  And frankly with the amount that we, as consultants, get paid to build custom software, the user shouldn’t have to wait.

Headlong into the breach then for our fourth and final lesson…

Usability and the GeoWeb Part 3: Protect Your Users From Themselves

As I write this post, I’m attending the GeoWeb 2009 Conference in Vancouver, BC.  This is then a pretty appropriate time to drop part 3 in the Usability and the GeoWeb series.  Part 1 in the series discussed the importance of hiding unnecessary complexity from the user, while Part 2 focused on the importance of never leaving your users guessing and providing them with consistent, meaningful feedback.  In an effort to encourage the incorporation of key usability features into emerging web mapping applications, the lesson plan this time focuses on key application elements designed to protect the users from themselves.

While that statement may sound a little rough (nobody should be out insulting their customers and clients after all) it is not meant as such.  I most certainly am not saying your users are foolish, stupid, or otherwise deficient in any way.  Recall Scott Karp’s assertion that in the age of Google,

“…there are no stupid users, only inadequate designs”

On the contrary, I simply mean that otherwise well-meaning users frequently do things within an application that the application does not expect or that create coding/logic challenges for the developer.  Our task then in building next generation systems to support/integrate with the GeoWeb requires that we anticipate as many corner cases or unexpected results as possible, and architect and code solutions to prevent the user from becoming frustrated at best, and destroying critical information at worst.  Keep the user focused on the application, and put out fires before they arise

With that intro, here’s lesson 3…

Usability and the GeoWeb Part 2: Provide Feedback

This post is the second in a multi-part series on usability in web-mapping applications.  Dave has spoken extensively on this topic of late…and much of this is just putting fingers to keyboard on the issues we’ve been harping on for some months now.  The first post in the series asserted that we, as developers and architects of these systems have a tendency to make things too complex and flood the user with all manner of features, functions, and data layers they don’t need.  In essence, the age of GIS in a browser is ending (I sincerely hope) and we’re moving toward highly performant, intuitive, and focused applications in a browser that serve a particular purpose, and do it very well.  Why? Because someone else is bound to be offering the same stuff you are, and if they can provide the information faster, they win…bye, bye users and bye, bye clients.

Part 1 discussed hiding unnecessary complexity from the user, while our lesson plan this time around uses extensive feedback mechanisms within a site to keep the user on our side and make them feel comfortable when visiting our site.  A confident user is a comfortable user. A comfortable user gets what they need and gets back out fishing, golfing, spending time with their kids, or otherwise doing something else besides staring blankly at your interface.

Usability and the GeoWeb: Part 1 of ?

Myself and my partner in crime, Dave Bouwman, have talked incessantly in trade publications and at conferences of late about the Geospatial Web or “GeoWeb” and what it means to GIS professionals and software developers.  This post is the first in a several part series on usability issues and concerns when designing and building applications for the GeoWeb.  How many parts will the series have?  Well that all depends upon how worked up I get and how often and long I want to rant.

It is my sincere hope that we, as a community, are finally moving on from the era of exposing buckets of complex GIS functionalities in the browser.  As noted in a previous post, the GeoWeb is, in essence, all things Web 2.0 writ large on a map. For ESRI customers it is REST, JavaScript, Flex, and Silverlight APIs for ArcGIS Server.  Beyond the ESRI realm it is Microsoft Bing Maps, Google Maps, Google Earth, or myriad FOSS offerings.

Standard Architecture for the GeoWeb: Give it a REST

Author’s note: This post was prepared in advance of an architecture panel I will be participating in at the GeoWeb conference July 27-31, 2009 in Vancouver.  At the request of conference organizers, myself and the other panel participants have all prepared posts on our “pet” architectural style.  This year I drew the REST straw while Ian Painter of Snowflake Software will vigorously defend SOAP/RPC and Hans Shoebach of Galdos Systems will do battle for P2P/Event Driven architecture.  This post will be cross posted over on the GeoWeb 2009 blog as well. 

The Geospatial Web, the current darling of location based technologies and neogeography, has been variously described as:

• web mapping – the generation and publication of highly performant web applications that include a map
• mashups – combining spatial data with abstract information to produce novel representations
• a distributed GIS for the web – essentially the combination of elements of traditional GIS technologies with advanced web development tools
• equivalent or synonymous with relatively new technologies such as Google Earth, Microsoft Bing Maps, Yahoo Maps, etc.
• communal or user-generated geospatial content

While each of these descriptions is both incomplete and an oversimplification, I assert that at its core the GeoWeb is a technical foundation of information services and collaborative tools built upon or merged with data that provide a spatial context…a location.  It is indeed shiny “slippy” maps, Web 2.0 application layouts, nano-formats, mashups, LBS, service-based spatial information sharing, but it is also the hardware, software, information architecture, advanced web application techniques, and people who come together to make such an organic endeavor possible.

The number of organizations working with GeoWeb technologies is already large and growing daily.  It seems only logical then, that as a community we engage in an open debate about how exactly all of these databases, services, clients, and functionalities are ultimately going to communicate, integrate, and grow. My endeavor, in the context of this post and in preparation for an architecture panel at the GeoWeb 2009 conference, is to espouse Representational State Transfer (REST) as a standard architectural pattern for the GeoWeb. I’ll try to keep my points brief here with hope of stimulating discussion that will continue at the GeoWeb conference in Vancouver at the end of July.

Teaching an old dog new tricks: Dojo

Over the last two weeks, I’ve been waist deep in what has been, for me, a completely new client side development platform.  We have several projects underway at present that leverage Dojo as the framework for rich client GeoWeb applications and, simply put, we’ve got more Dojo work than our two resident experts can handle at present.  Time to roll up my sleeves and learn something new!

Since I’m a botanist by training, and not a classically trained programmer by any stretch, I don’t typically look at a new technology and say “Gee Whiz, this looks an awful lot like <pick your poison> that I learned back in University”.  I’ve got sort of a free form learning process that works for me, and usually get’s me up and running and useful in a relatively short period of time…a matter of days if I have examples and a pattern rather than weeks.  And after doing this for 10 years or so, it seems that you still can teach an old dog new tricks.