It’s ESRI’s free Web platform for creating annotated maps for any application or purpose. explorer.arcgis.com has a simple, intuitive interface for adding text, place notes, lines, areas, measurements and more. I used it for operational planning and as a geospatial wiki for organizing and archiving Clean the Bay Day activities in my neighborhood. But that’s all just by way of introduction.

There is one feature in ArcGIS Explorer that is so elegant it is sublime in almost every sense of the word:  Presentation mode.

These two little buttons enable you to create slides from any views of your map and step through them just like a presentation.

What’s elegant is that the presentation is really just a series of view points of the map.  That means the transition between presentation and the full compliment of data and features of the map is seamless.  When I say “seamless” I mean entirely indistinguishable from one mode to the other.  The presentation tool and the map are one and the same.

This capability is useful because it affords presenters and audiences the ability to drill down into details on demand. It provides the ability to change course in response to discussion or questions & answers about something that exists in underlying analysis but isn’t included in the presentation (which happens all the time). Try that with any other presentation tool.

Let’s take it a step further. For military, government, and business enterprises that seem to make every decision from a slide deck this is a profound evolution, perhaps The killer feature. Our over-reliance on slide presentations and our low standards for elements of style have caused us to accept a negative, even mocking conclusion that slides are inherently bad. Yet slide decks are so pervasive they are viral. It seems there is no stopping them. At Bridgeborn we used to joke that it was our job to rid the world from the tyranny of PowerPoint. That was neither fair to Microsoft or slide presentation as a medium. Slides have their purpose. In the right hands “slides” are a powerful medium. It seems there are even more choices for creating and publishing presentations than ever, too.  These tools will always require skilled operators and never are connected to data, however.  The Presentation mode of ArcGis.com, by contrast, does link presentations to underlying details. Widgets for creating layers of text, place notes, lines, areas, measurements and the like can be effectively wielded with no training.

The fact that this feature was implemented on a map is important.  The trend toward more location based data is undeniable. Coupled with straightforward tools for creating layers, ArcGis.com’s presentation mode supports both top level stories and details with the same ease.  But one could easily imagine how this feature could be applied to any content.  What if every Web dashboard could be put into presentation mode?

Sometimes it feels like acronyms are the only words we use.

The government is awash with acronyms. New acronyms are created daily. Acronyms create a barrier to understanding if they cannot be easily resolved, where easy = universal and universal = URLs. There are many online dictionaries with entries that are found in Web searches. However, most of these return results only in highly formatted, not-well-formed HTML that is not always accessible through simple URLs. Furthermore, these dictionaries provide no way for the community to create and share new entries as they are needed. A simple solution to this is:

• Use the cloud to store terms and definitions
• Use Web services to return definitions through URLs as XML, JSON, and XHTML
• Provide a simple form that lets users add and edit terms

We have created a proof of concept here using XAMPP and Amazon’s S3 Web service:

http://dev.os.bridgeborn.com/wiktionary/

It’s not perfect or even complete. For example, the XHTML returns 37 errors and 19 warnings from the W3C validator so it’s really not even XHTML. But I think this is a solid start and I think it can easily get to where we want without too much more effort and resources. Searching/sorting by domain is a must-have feature that I’m chomping at the bit to have implemented!

Creating new opportunities, not re-inventing wheels

There are a couple of services out there already that support some of the functionality we seek. acronyms.thefreedictionary.com provides some of the things we like to see from a service: references/citations, categories, direct URL to entry, notes, and anyone can update (don’t even have to auth).  Wikitionary.org is another useful service that supports citations, direct URLs, discussion, and collaborative updates.  Wiktionary also offers an API, which a good practice when rightly done.

These services fall short of our expectations, however.  freedictionary.com provides no API and the direct links to definition pages are full of ads, forms, and a myriad other distractions.  Wiktionary uses Wikimedia’s typical format for entries, which cuts out the distractions and focuses on the unit of knowledge.  But direct links to terms through the API are muddled with parameters and point to documents written mostly in wiki’s specialized format, not XML, XHTML, or JSON.

Contrast this with our wiktionary implementation, where pointing to XHTML, XML, and JSON is mostly a matter of changing the file extension of the result:

http://dev.os.bridgeborn.com/wiktionary/viewentry.php?term=XML
http://dev.os.bridgeborn.com/wiktionary/terms/XML.xml
http://dev.os.bridgeborn.com/wiktionary/terms/XML.json

(That first one needs to be: http://dev.os.bridgeborn.com/wiktionary/terms/XML.xhtml and it will be nice if we can simplify the path by removing “terms” from it.)

So, each of these services still leaves something to be desired.  To be clear, we are not claiming that our service is better than “theirs.”  But, bias not withstanding, if I were to choose a starting point I would definitely choose our service over the others.

Feel free to use our wiktionary (no warranty!).  It uses OpenID for login, so if you have accounts with any of these providers you’re good to go:

Eventually we’ll make it possible for you to create your own instance and/or get the source code, but we have some other priorities right now and just wanted to share what we have.

Credits: I created the wireframes and drove the requirements.  Our 2009 RIT Co-op student, Ian Wittenberg wrote the code

This standard is approved for use by all departments and agencies of the Department of Defense (DOD). Using human factors engineering research, the standard is designed to eliminate conflicts within various symbol sets and to bring a core set of common warfighting symbology under one DOD standard. MIL-STD-2525 is designed to equip the DOD with a standard solution that provides sets of command and control (C2) symbols, a coding scheme for symbol automation and information transfer, and technical details to support systems. The standard provides support through interoperability and users’ input, which are essential to ensure that the standard continues to meet the warfighter’s requirements. MIL-STD-2525 is the primary directive that DOD uses to standardize warfighting symbology.

Here at Bridgeborn all about liberating valuable data locked up in (proprietary) document formats. We’re not the only ones with a desire to break this highly structured symbol set out of its published container, either. In fact, if True Type Fonts are what you seek then you may be in luck.

What we’re after, however, is interoperability among the many, many applications that depend on MILSTD 2525. To achieve that we need much greater accessibility to and portability of the symbols. That’s why we created a Web service that publishes the symbols through URLs via a simple API.

You can browse the symbols by Force Type and Track:
http://dev.bridgeborn.com/symbology/

Point to a specific symbol using the MILSTD’s dot notation:
http://dev.bridgeborn.com/symbology/WarfightingSymbologyHandler.ashx?hierarchy=WAR.GRDTRK.UNT.CBT.ARM.WHD.MDM

Point to a specific symbol by Table of Organization and Equipment (TOE) series (Army-centric):
http://dev.bridgeborn.com/symbology/WarfightingSymbologyHandler.ashx?toeseries=17&modifiers=WHD,AMP

Add modifiers:
http://dev.bridgeborn.com/symbology/WarfightingSymbologyHandler.ashx?forcetype=hostile&echelon=brigade&hierarchy=WAR.GRDTRK.UNT.CBT.ARM.WHD.MDM

Here’s the documentation:
http://dev.bridgeborn.com/symbology/WarfightingSymbologyHandler.ashx

The service returns PNG files, which are common and easy to use.  The service isn’t completely populated yet, but it’s coming along fast and ready to use now.  In fact, the image at the top of this blog post is just a pointer to:
http://dev.bridgeborn.com/Symbology/WarfightingSymbologyHandler.ashx?forcetype=friend&toeseries=17&modifiers=WHD,AMP

Credits:  I created the requirements & use cases.  Chris Martin and John Hadzima wrote the code.  (The browser was John’s idea, too.)  Liz Fredericks created the base icons.