Location based services are increasingly important, especially when it comes to accessing health information and services. Over the past year and a half, AIDS.gov, a program of the U.S. Department of Health and Human Services, Office of HIV/AIDS Policy, has been collaborating with other Federal agencies (CDC, HUD, SAMHSA, among others) to develop an HIV/AIDS prevention and service locator. This new tool combines key Federal HIV/AIDS programs such as HIV testing, mental health services, health centers, substance abuse clinics, and housing services. Each of these programs is run by a separate agency and pulls information from a wide range of sources. Beyond addressing what it took to get each agency to collaborate and push their data in a consumable format, this presentation will focus on the steps AIDS.gov took to create this locator service. We take a technical approach to discuss the GeoRSS standard, how we built the service using mostly JavaScript, and how we pushed this service to mobile, standard web, and native application platforms. We will also talk about the iterative design and development process, and we tie it all together with the big ticket: the sweet spot of location, mobile, and health. We cover it all, location, Health IT, and Gov 2.0.
IntroConfessions (SXSW, no mobile, didn’t follow any advice from SpeakerUp)
So, a wee bit about me. I used to live here,
And work over here.
Now I live here,
And still work over there. Well, virtually, anyway.
One of the projects I work on is the AIDS.gov web site
As part of that project, we created a location based search tool to help people living with HIV/AIDS or their caretakers to find service providers near them.Been a tripMight have something useful to share
Whether you’re pulling data from many different sources, or…
Building widgets people can use on any website.Specific anecdotes throughoutLet’s get started
So, first, let’s look at the problem we wanted to solve.
Gov agencies offer tools to find service providers
These are extremely useful
but are difficult to find (the Goog is not with them)
Some are many layers deep in the agency’s hierarchy
-all only one type of service provider-wanted to help people find all different types of service providers using one search.-wanted to leave the data where it was-people who were already collecting and maintaining it could continue taking care of that, and we wouldn’t have to.
Instead of bringing all the data together into one central database, we wanted to aggregate it dynamically.asked each agency to provide a REST APIreturn a GeoRSS feedAccept two parameters, ZIP Code and distance. We settled on those after looking at the existing search engines, but In hindsight, latitude and longitude would be nice, and we’ve started working with some of the data providers to accomplish that as well.
Here is an example URL for the CDC HIV Testing data feed API. It takes a ZIP Code and a distance in miles, and returns…
An RSS (Atom, actually) feed with all of the locations within that distance of that ZIP Code.
The crucial bit that makes this GeoRSS is each <entry> element brings along a latitude and longitude with it.
So they can be plopped on the map like so. The Google Maps API actually offers a GeoRSS parser, but I found it rather finicky so ended up rolling my own.[anecdote]-issues while implementing-wrote our initial how-to on GeoRSS-made point data, the latitude and longitude, optional. -Bad idea.We were afraid making it mandatory would be a barrier to entry for some agenciesWe thought it would be simple enough to geocode the addresses on our end.Most of agencies already had geocoded data, or were pretty quick to do so, even though we’d made it optional.one data provider called our bluffDelays between us trying to dynamically geocode and giving up and them adding lat and long on their end.
Not only did we want to give people one place to search, we wanted to make that tool available anywhere.
This is a pure JavaScript widget, which can be placed in a page with a single line of HTML.
There’s the one liner, we include a <noscript> tag for times when JavaScript might be turned off for some reason. It makes for more for people to copy and paste, but I think it’s the right thing to do in the long run.
This widget is styleable and somewhat modular. We’ve created a few different versions, one for the CDC,
A vertical version,
We’re also working on a version that can be attached to an already existing form field.
search without leaving the page their on. This overlay is actually an iframe, which is loading http://locator.aids.gov/. Amazingly, we were able to get it to look decent in most browsers. In IE6, it simply opens a new window.[anecdote]After implementing the overlay, we realized that if any Flash elements were on the page, they appeared above the overlay. After some serious debugging, we came up with a way to keep this from happening.
-Flash toobey z-index rules-‘wmode’ param set to ‘transparent’.-attribute must be present before the <object> element is loaded in the DOM.-So… what we’re doing here is manually removing every <object> element, setting it’s wmode parameter, and then sticking it back where it was-not the cleanest code, and I’m sure there are probably a lot of edge cases where this would blow up.-I’ve run across at least one, where if a movie is set to autoplay (please never do that), it will restart when this code runs.
One of the fun things about the widget is that you can grab the embed snippet directly from it to place on your own site.
Analytics are a great way to make sure what you’re working on is actually reaching the people it should. Analytics are a bit more complicated with a widget, since you’re tracking loads of something on someone else’s page.
We tried using Clearspring for awhile until they canned the bit of their API we were using earlier this year. You might be able to find another use for them, though.
We now are using Omniture through an arrangement with CDC in order to get metrics on the widget. This is more or less out of convenience, it wouldn’t be my preference, also it takes major bank. Also, we’re using Google Analytics on locator.aids.gov itself.
National HIV Testing Daywe created a special look for the locator widgetsAsked partners to place the widget on their web sites.loaded ~1.6 million timesMeaninglessDoesn’t even mean eyeballs (below the fold)
of those 1.6 million loads2000 real searches.Measured by interactions on the widget and GA on locator.aids.gov
Embedded on 70 different websitesmany of those including the widget on several, or all, pages.
General case
Unique name, and a local alias
Replace the <script> element which loaded this script with new DOM elements
Add the init function to the window.onload event
This is a technique we hope to implement in the future, pioneered by the guys who work on the Meebo Bar. Check the video of their Velocity conf presentation.
The Meebo guys do a much better job of explaining this, but effectively they’ve come up with a way to achieve truly non-blocking JavaScript by tacking their code onto an iframe.
Some of the issues we’ve had with the widget: it does block, CSS isn’t totally sandboxed, and it’s not able to be inserted on a MySpace or Facebook page because JS isn’t allowed there.
Currently, if our servers are unavailable for whatever reason, a page will stop rendering at the point the widget is loaded. Fortunately, this hasn’t been a big issue yet because our servers have been doing fine, but obviously that’s not something we should bank on. We need to protect any site which lets our widget loose on their pages.deferasync
Kent Brewster actually provides a technique that we use to add style to our widget. However, it’s problematic to ensure that any given styles from the parent page aren’t overriding our CSS. So, it’d be nice if our widget’s DOM was totally sandboxed from the parent page’s CSS. Cleanslate is part of Sqwidget, a JS widget toolkit that I’m hoping to use in future versions of the locator widget.
Many social networking sites and free blog sites disallow pasting JavaScript onto your pages, as a preventative measure against misbehaving scripts. We need to come up with a way to allow people using those services to use our widget.
-page load time contributes to Google algorithm-better user experience-some tools to help you on your way
LABjs, a JavaScript library by Kyle SimpsonHelps pages load more quickly by loading the scripts in parallel, but still giving you control over execution order
Yahoo! has an excellent resource on how to speed up page load time.far-future expires on static contentDownside: changes don’t get loaded if url doesn’t change
Auto version static files based on modification dateApache directivesPHP – read this article to get the full story