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.

Getting yer’ Agile on at a discount: Upcoming course

Come on out and join us to drink the agile kool-aid, take your agile medicine, learn what agile can do for your team or organization, or have a skills refresher for experienced agile practitioners.

Dave Bouwman and myself will be collaborating to give a one day Agile Project Management training seminar on Friday, June 26, 2009 near Denver, CO.  This course will cover both project management practices and development/engineering practices.  We’ll begin with an introduction to agile practices and rapidly progress to specific methodology examples (Scrum), cover roles and responsibilities, project controls, and how to scale the agile process in your organization.  In addition, we’ll introduce specific software development processes that mesh well with the agile process including automation for code documentation and unit testing, design patterns, refactoring tools, and automated builds and continuous integration.  Throughout the course we’ll give you specific examples, the good, the bad, and the ugly, from our own experiences using the methodology in our shop.

Fun with Dojo filtering selects

While the Dojo JavaScript libraries are really an excellent resource for building rich internet applications (RIAs), sometimes Dojo just makes things harder than they have to be.  Last week I was working on public map viewer, based on our custom implementation of ESRI’s JavaScript API starter kit,  for one of our clients.  The site is really pretty basic in terms of functionality with one of the tools allowing the user to configure and execute a multi-criteria search for information and have that information displayed on a map.  The user interface looks something like the following screen cap:

In this user interface example, the combo boxes for counties and cities are Dojo FilteringSelect controls.  The FilteringSelect extends the typical html drop down so that you get an intellisense/autocomplete of sorts when the user starts typing in the combo box.  In addition, in the event that the user types a value rather than using the drop down list, the FilteringSelect will validate manual text entries to ensure they are in the select list.  All of this prevalidation is important because it allows us to reduce the potential for errors in searches by constraining the user’s input to a list of valid values pulled from database lookup tables.  It’s a pretty neat little control…until you have to clear it.