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.

Calling all Silverlight and dojo gurus: Hiring again

That’s right, DTSAgile is again looking to expand our team building next generation RIAs and GeoWeb applications in our Fort Collins, CO office.

As we have a backlog of projects that use diverse technologies, we’re looking for an excellent developer with one of the following skill sets.

SL, EF, ADO.NET Data Services

If you have bona fide project level experience with Silverlight 2, Entity Framework, and ADO.NET Data Services or NHibernate, DTSAgile wants to talk to you.  We are not looking for an entry level developer or someone who can learn on the job, we are seeking developers who have real world experience implementing this technology stack.  We’re looking for someone who can make an immediate impact, show us how this stack should be implemented, and tell us how to avoid the pitfalls.

JavaScript, Dojo, CSS, etc.

Alternatively, if you have mastered the zen of dojo, JavaScript, CSS and all things client-side we’d also like to receive your resume and review your credentials.  Actual project experience implementing mapping technologies using ESRI’s JavaScript API including the starter kit will be reviewed favorably. Again, we’re not looking for entry level folks here…you’ll be asked to come in and put fingers to the keyboard relatively quickly out of the gate and show us what you’ve got.

Other fun stuff you should grok

• Agility. No, you don’t have to do backflips or crazy stretches in an interview setting. As our name implies, we’re a group of consultants pretty committed to Agile processes on our projects.  At minimum you should have some background knowledge regarding Agile and an interest in working on an Agile team
• Favorite patterns. ASP.NET MVC is high on our list of happy shiny things that we like to work with.  Many of our projects are and will continue to be architected with ASP.NET MVC in the mix.  Real world project experience with it will be be reviewed favorably.
• Unit testing.  We’re big on tests…lot’s of ‘em.  Some of our projects are run in TDD fashion while others have a test-late lifecycle.  Regardless, we unit test everything that goes out the door thoroughly.  NUnit, MBUnit, TestDriven.net, mocking frameworks such as Rhino mocks, and IoC/DI principles should all be on your resume.
• The Geo.  We primarily target mapping related projects so exposure to GIS, the GeoWeb, etc. in the form of the ESRI product stack, VE, Google Maps, Open Layers, Geoserver, Mapserver, PostGIS, etc. will be viewed favorably but is not required.
• Information exchange and social networking.  We’re software architects and developers, and we’re also bloggers, presenters, and participants in growing social networks.  Run a blog? Participate in Twitter? Grasp the finer points of presentation zen and really good Powerpoint? Great, you’ll fit in just fine.

Still interested?  Drop a line to myself or Dave and we’ll have a gander at your qualifications and see if you might be a fit for our current needs.

The Agile Process: What my 3 year old taught me

I love spending time with my son.  He frequently reminds me that sometimes, life perceived through the eyes of a child is a pretty acceptable way to go.  I was a bit naive going into father hood and thought that I’d be the one doing all of the teaching. Yet every day I spend with my son teaches me something new about how to look at work or personal life in a different way.

Dave and I are in the process of collaborating to produce a new version of our Agile Training Course and I’ve had the chance to sit and reflect a bit on the Agile Process.  When you’re deep into project execution, it’s easy to loose site of the forest for the trees and it’s good to take a step back now again (distinct and separate from your post-mortems) and look at the big picture.  Of late, I’ve been mentally musing about how to look at the process through the eyes of a child, and what that view can teach us as Agile practitioners and trainers.