When a user is outside the Mall boundry, a message indicating this should appear. Possibly a jQuery UI dialog.

After a successful geolocation, a marker appears at the location, indication the coordinates of the device. This marker should distinguish itself from the item markers.

http://leafletjs.com/reference.html#icon

When clicking on View More Info, bubble adjusts, but does not take user to the item/show page.
@kimisgold @jimsafley

This is a weird one. The "out of bounds" dialog modal is invisible on Safari and Chrome for the iPad—it renders perfectly on the same browsers for the iPhone, as well as Firefox and Chrome for my Nexus 7.

When remote debugging, the browser seems to recognize that something's supposed to be there with the correct dimensions, but it just doesn't show for some reason. I've tested other websites that use jQuery UI dialogs, including the Omeka admin, and the iPad can render them fine.

Here's a screenshot of the remote inspector looking for the dialog on the iPad.

The app currently retains marker state when navigating back from an item show page. (This is possible because browsers automatically save the state of the form.) Unfortunately the browser is unaware of the state of the map, i.e. the base layer's latitude/longitude and zoom level.

This can be done using some kind of persistent data storage, such as cookies or web storage, unless there's an easier way that eludes me.

This may be able to be done by manipulating the browser history, using history.pushState(). I'm not sure if this is compatible with mobile browsers.

What item metadata should be on each marker's popup? How should it be styled?

There are two historic maps in chnm.gmu.edu:/storage/mall-files that should replace current maps:

• 1862topo.tif replaces 1860-1889
• L'Enfant_Thackeray.tif replaces pre-1800s

Steps to process maps:

1. Copy map from chnm.gmu.edu:/storage/mall-files/ to original/
2. Convert TIFF to JPEG (for smaller, compatible file): $ convert x.tif x.jpg
3. Upload map to Map Warper: http://mapwarper.net/
4. Rectify map to OSM using control points common to both, such as White House, US Capitol, Washington Monument, Smithsonian Institution, Union Station
5. Download georectified map PNG and KML file into georectified/ (rename files to their original name)
6. Convert PNG to JPEG (for smaller file): $ convert x.png x.jpg
7. Tile georectified map in MapTiler: $ maptiler
   • Add PNG and georeference against the in the related KML file: "north south east west"
   • Set the "WGS84 - Latitude and longitude (geodetic)" spacial reference system
   • Set zoom levels: minimum zoom=11, maximum zoom=18; set JPEG file format
   • Set the download directory to tiled/[mapnumber]/; do not set a destination URL
   • Don't set any viewers to generate
   • Render

• The map tiles are slow to load, especially when zooming/panning.
• Geolocation is slow

I suspect the map gets slower the more markers are loaded onto it. According to alpha testers, the map runs very slow on the Mall wi-fi hotspots, but 4G works well (at least on iPhone).

We'll need to benchmark to see which components are slowing down the application. Use start() and stop() to benchmark.

Potential solutions:

• Use Leaflet.markercluster to minimize the amount of markers on the screen
• Use an item info panel instead of popups (#22), which will load item metadata on-demand instead of all at once.
• Compile the JavaScript using Closure Compiler
• Download OpenStreetMap tiles and serve locally (this is strongly discouraged)

After clicking on a marker, the top of the popup may be outside the viewport. One solution is to pan to just north of the marker coordinates, allowing more room for the popup.

Upon entering the page, users should be able to see all markers if they so desire. This button probably should take visual precedence over the filter button since it's geared toward new users.

We could have a button on the map that, once pressed, pans/zooms to the user's location. (The user will have to agree to share the device's location first.)

Compile views/public/javascripts/mall-map.js using Closure Compiler. This should marginally increase download and run time. Make sure to save the original source as views/public/javascripts/mall-map-src.js.

See #5 for previous discussion about this.

Currently this is the way we handle geolocating the user:

• Upon first map load, we ask the user to share her location (this does not apply on subsequent loads);
• If the user agrees, we determine whether the coordinates fall within the Mall or surrounding area;
  • If so, the map pans and zooms to the detected location and places a user location marker on the map;
  • If not, the map centers on the Mall.
• The map continuously watches for location changes and updates the location marker accordingly.

One question I have is what behavior the user will expect once the map determines that her coordinates lie outside the Mall and surrounding area. Should we alert her that she's out of bounds and that we're centering the map on the Mall? Or should we just fail silently? My concern is that when we ask permission to locate a user, many would expect to be located explicitly on the map.

This isn't the easiest behavior to test unless you're on the Mall, so I hope to get some on-location testing done soon.

Icons take up less space than text, which is important on small devices. Finding icons that carry the same semantic weight as their text equivalents will be tricky.

@sheilabrennan

Currently, when a user is out of bounds a dialog modal appears:

Title: Out of Bounds
Text: Location out of bounds. You are x miles away.

Currently, when a user cannot be located a dialog modal appears:

Title: Location Not Found
Text: Could not find your location.

We need to determine the optimal user experience for the two contingencies:

• What the user expects
• What we need to tell the user, if anything

@sheilabrennan @leeannghajar

When a user clicks on a marker, a popup appears that should contain the absolute minimum of item metadata (currently it contains title and thumbnail image). In the popup, when a user clicks on "view more info," an info panel appears on top of the map that should contain as much item metadata that an average user should ever need to see (currently it contains title, description, and fullsize image).

• What content should the popup contain?
• What content should the info panel contain? This includes item type metadata.

Great suggestion from the fellows. Making the info panel a sliding panel would be helpful for two reasons:

• provide a consistent interface, similar to filter panel
• give a better indication on how to close the panel (otherwise, more users will use the device's back button, which we have no control over)

After navigating to an item show page from the map, the map should retain its previous state when returning to it. A doFilters() and some checks on form state on the global scope should do the trick.

The opacity slider uses jQuery UI slider, augmented for mobile with Touch Punch. It does not work as expected in some OS/browser combinations:

Unresponsive

• Samsung Galaxy
• HTC Incredible 2
• Droid 4

Sluggish

• LG Optimus L9, Chrome
• Droid 4, Chrome
• Nexus 4, Chrome

Works

• Nexus 7, Firefox/Chrome
• IPhone 4, Firefox/Chrome
• Nexus 4, Firefox
• Droid 4, Firefox

Unfortunately there may not be an easy way to fix this using our current technologies. While it works most of the time, jQuery UI is not optimized for mobile devices. (Touch Punch may be the only reason it works in the first place.)

jQuery Mobile has a slider that would work, but it's a web framework that would require a rewrite of the map application. I can find no other alternative that is sure to work. I recommend that we move back to the toggle visibility button.

Currently when the user chooses not to answer the location question, the locate button remains active nonetheless. Instead, the locate button should be disabled by default and enabled only after a successful and in-bounds locate.

@sheilabrennan @leeannghajar

To fix #17 and create a better user experience, I added marker clusters to the map. Instead of rendering 190+ markers at a time, which slows down panning and zooming, markers are clustered into groups according to location.

Tapping the cluster will zoom in and render smaller clusters and/or individual markers. Tapping a cluster at the highest zoom level will "spiderfy" the markers, meaning it will expand the markers sharing approximate locations so they can be selected.

Clustering is is being used by an increasing number of mapping applications to manage many markers in a small geographical area, so I think our users will find it an acceptable experience.

The number of markers for any query should be visible somewhere on the map or filter form.

Currently, the "Map Era" select menu is responsible for two things: 1) display items tagged to that era, and 2) add the associated historical map layer. I question whether this conflation results in an optimal user experience. Instead, we could have a "Era" select menu for filtering items and a "Show Era Map" checkbox for adding the historical map layer.

In MallMap_IndexController item type IDs and element IDs are hard coded in $_formData property. Since IDs may change in the future, it may be best to move them to class constants. This way ID variables in filterAction() can be changed to constants. Unfortunately it's not practical to move item type names and element texts to constants.

After selecting a top-level item type in the filters menu, markers for every second level item type appear on the map by default. The user can then filter further by checking off second level item types, but there should be an indicator that 'all' are included first.

For example:

Item Type:
Event

Event Types

• All Event Types
• D.C. History
• Marches and Rallies
• Openings and Dedications
• Encampment
• Environmental Disaster
• Concerts
• Concert
• Cultural Gathering
• Inaugurations
• Remembrances
• Planning and Design

Here, "All Event Types" would be checked by default. If the user selected any of the other Event Types, "All Event Types" would lose its checked state.

After clicking on a pin, the item pop-ups appear under the map-nav bar (with number of items, Show All, Tools), on Safari and Chrome for iPhone.

Is there a reason why we shouldn't restrict the map to the National Mall and surrounding area? Doing so would prevent users from zooming beyond the historical map boundaries, where there's an unsightly white frame.

From the Leflet documentation:

When this option is set, the map restricts the view to the given geographical bounds, bouncing the user back when he tries to pan outside the view, and also not allowing to zoom out to a view that's larger than the given bounds (depending on the map size). To set the restriction dynamically, use setMaxBounds method

The map should provide optimal interactive and viewing experience across a wide range of devices. Since this map is "mobile first," we should pay closest attention to mobile devices, but we should not ignore the desktop experience. Crafty use of media queries will help us through the process.

As discussed in #7, instead of a marker popup containing only title and thumbnail, we should display a scrollable info panel on top of the map that contains more information about the item. This way the user won't have to navigate away from the map to get detailed information about the item. Of course we'd also provide a link to the item show page.

Info panel contents:

• Title
• Description
• Date
• Source
• Thumbnail
• Link to item show page
• [anything else?]

After opening a marker popup, the popup disappears when some portion of it is off the viewport. Happens in @patrickmj's Droid X, Dolphin browser.