Skip to content

2017 MapStory RoadMap Archive

Jump to bottom
lhcramer edited this page Feb 1, 2018 · 3 revisions

2017 MapStory.org Roadmap

Interested in what the team will be up to in the future? Check out our MapStory.org Road Map for details. The the list starts with items we hope to tackle in the near-term, and is roughly in order of priority with farther-future pursuits we are still working to define near the bottom. Note that priorities (especially those closer to the bottom) may naturally shift and change order as the team completes work.

This road map presents the full scope of work for releases after the 0.1.0 release that occured in April 2017. Once this roadmap is approved by key stakeholders, highest priority items from this roadmap will be pulled and placed into Milestones by the development team, with story point estimates, so that length of work can be predicted. Note that priorities may naturally shift and change order as the team completes work, or as new resources and team members become available. MapStory is an agile open-source project that relies on constant communication and collaboration across the designers, developers, users and key stakeholders involved.

This road map presents the full scope of work for releases after the 0.1.0 release that occured in April 2017. Once this roadmap is approved by key stakeholders, highest priority items from this roadmap will be pulled and placed into Milestones by the development team, with story point estimates, so that length of work can be predicted. Note that priorities may naturally shift and change order as the team completes work, or as new resources and team members become available. MapStory is an agile open-source project that relies on constant communication and collaboration across the designers, developers, users and key stakeholders involved.

  1. Quality Assurance
  2. Story Composing & Publishing Improvements
  3. Community Editing Improvements
  4. Data Import & Management Improvements
  5. Explore & Content Discovery Improvements
  6. Profiles & Social Features
  7. Next Plateau
  8. Developer Community
  9. Community & Identity
  1. Data Improvement and Management Improvements
  1. Beta Baseline and Testing

Quality Assurance

Tests

  • Completing the automated testing suite and increase test coverage from 57% to as close to 100% as is possible and practical.
  • Enforce test passage before deploying code
  • Deploy health check service and tie to notifications so users know if services should be down
  • Audit current error messages and improve to ease user frustration and confusion.

Infrastructure Improvements

  • Get back up to core GeoNode
  • Get back up to latest on OS-Geo Importer
  • Fix build process to work better with OS-Geo Importer
  • Get up to latest Geogig release (1.1)
  • Get up to appropriate Geoserver version
  • Transition to Docker based deployments
    • This will make testing various deployment scenarios easier (e.g. exact clone of Production)
    • GeoNode and other dependencies are starting to use Docker, so it'll be easier if we follow
    • Minimize differences between Prod and Test environments
    • Long term, splitting up all of the components into separate containers will ease horizontal scaling

Data Migration Completion

  • Migrate all legacy user accounts from old mapstory.org site to new mapstory.org site
  • Migrate all legacy layers that were not broken, test or incompatable to new data structure to new mapstory.org site

Github Management

  • Create a process and roles/responsibilities for systematically addressing user identified bugs in Github so that bugs are regularly addressed but don't derail new development efforts. Define a system of classifying bug severity to help the team better prioritize and address bugs.
  • Finalize and commit to issue management and reporting/labelling conventions as specified in this Wiki in order to make it easy for new developers to engage with our project

Editing Story Composing and Publishing Improvements

Rewrite existing Composer in StoryTools w/ new UI

To enable scaling and long-term sustainability, the existing composer needs to be re-written in StoryTools instead of existing MapLoom. The composer re-write should support all the workflows in the current composer unless changes have been decided upon by Product Owners, development leads and designers during the user testing, design and development phase.

  • For a summary-view of requirements for the existing composer, review the "Beta Baseline" list here.
  • For a detailed list of user requirements for the existing composer, review the User Survey on Story Composition in the Beta Tester Guide here.
  • For design mockups driving the composer rewrite, reach out to @darinacosta for access to Invision

Next Gen Composer Requirements

Storytelling Templates

Storytelling templates will make it easier for a storyteller to compose and publish a mapstory that communicates what the storyteller intends to communicate.

Template User Story Statements

What kind of MapStory do you want to tell?: The following statements describe the most common different types of scenarios we imagine storytellers being in.

  • Base: "As a user I want complete control over my story. Just show me everything of what’s possible!" (Current composer design)
  • StoryPin-Centered: "My story aims to show just a handful of key events. I have media and text for each of these events. Therefore, I need template options that makes it easy to create StoryPins, and let me pick nice base layers(s) as background for the StoryPins displayed" (Rey’s “A” Templates).
  • Feature-centered and static: "My story aims to present lots of features at a single point in time. I get that MapStory is about change-over-time, but really I just need a static map that represents a single point in time." I.E. Freeze Frame (Rey’s “B-1”)
  • Feature-Centered and Dynamic: "My story aims to present layer features as they change over time. All that other stuff - frames, pins - is less important" (Rey’s “B-2”).
  • Feature-Centered and Mixed: "My storm aims to present layer features as they change over time on top of another layer that doesn’t change. For example, I want to show an explorer’s journey animate over a historic print map" (Rey’s “B-3”).
  • Timeline-Centered "My story is really about showing lots of features on a timeline. The map is important too, but I’m more interested in the timeline showing my events" (Rey’s “B-4” templates).
  • Aspirational!: "For my story, I want the features on-the-map to interact with charts or graphs (statistical data) off the map" (Rey's C templates).

Template Concepts that Achieve the User Statements

  • See Rey designs.

New Cross-cutting Engineering Priorities Required by Templates (Draft)

  • Enable StoryFrame specs (time and zoom level) to be derived from a StoryPin location.
  • Allow for StoryPin content to exist off-the-map in a sidebar
  • Enable storyteller to “Freeze Frame” a layer used in a chapter. This means that on story playback, the layer will show the features from a specified moment in time for the duration of a chapter
  • Allow storyteller to customize placement of timeline. Currently the timeline has one fixed location and behavior.
  • Allow users to further customize their legend. Right now the legend is purely derived from the layer data, which may not make sense in all story cases.
  • Let me customize ("mask") the feature-info pop-up that appears for my features. I want to be able to choose which attribute fields show up in that pop-up and mask the attribute headings.
  • Enable automated chapter transitions (related to Museum Mode)

Composer UX enhancements separate from the Templates

These UX enhancements to composer respond to user pain points with the existing composer:

  • Let me see a full preview of my MapStory before I publish
  • Let me more easily see all the elements I’ve added to my mapstory in composer (i.e. Table of Contents)
  • Improve the StoryPin time picker, and make sure StoryPins can extend to the full time range that StoryLayers can (geologic time)
  • Allow me to search/find features from a layer while in a story composer session from map or table view
  • Let me copy StoryLayers to different chapters, if I want to use the same StoryLayer twice, rather than having to go back to the search modal again
  • Allow me to select styles created by other storytellers and apply them to the same StoryLayer in their story
  • Provide advice to users on styles that work well with particular types of layers edit story in CSS which is directly editable, for users that are comfortable with CSS

Playlists

A playlist is several mapstories strung together. So, in a museum display setting you could have several mapstories be playing on a continuous loop without user interaction.

Ideally, a user could “create” a playlist from their Profile or Organization Page. Creating a playlist would involve giving the playlist itself a name, and selecting the mapstories that will be part of the playlist, and saving. The playlist would then appear on the Profile or Organization Page where visitors of the Profile or Organization Page could play it themselves.

Improvements for the MapStory Viewer & Story Details Page

  • Promote discovery by showing “similar” stories from detail pages or in search results (see Discovery Section for detail).
  • Generate animated thumbnails and Twitter card outputs for MapStories to enable social sharing that communicates the motion inherent in MapStories
  • Make sure basic social features (comment, message, flag, favorite) are on MapStory detail pages

Other

  • Revamp saving model for mapstories on a "draft", "staged changes" and "published" model.
  • Enable download of entire story as a geopackage

Community Editing Improvements

MVP Spec for Layer Editing

The first goal is to provide the minimum baseline of community editing in MapStory so that users can begin to edit layers and provide evidence to inform future redesign and improvement. Therefore, a user should be able to:

  • upload a layer and have it be "community editable" by any logged in user
  • Generate a unique geogig repo for each layer
  • Click "edit features" from a layer detail page and be taken into the maploom-based editing interface (use of current maploom editor until a story-tools based redesign is built upon user feedback)
  • Click on a feature to see its attribute information
  • Click on a table view to see all attribute information at once in a table
  • Add or delete a feature
  • Modify the geometry or attribute information for a feature
  • See all additions/deletions/modifications in an Edit History log
  • Zoom to a feature from the edit history log
  • See the before/after diff for a feature that has been edited
  • Have layer edits persist to the updated playback for the layer in the layer viewer
  • Have an edit history on the layer detail page that shows how often the layer has been edited and by what users.

Layers as repositories

The key conceptual shift for the next generation editing implementation is that a single StoryLayer in MapStory is, in effect, a repository of its own. This enables workflows for layer creators and layer editors as follows:

Layer creators:

  1. User can create a new layer by uploading data or creating an empty layer with the "create layer" option
  2. Once created, user becomes the "owner" of this layer/repository
  3. User has option to define rules for the layer. These options include:
  • Will the layer be editable by the whole community? By no one besides owner? Or by select invited users? If by select invited users, these users should receive a notification when they've been invited. On the public layer detail page, all users with edit privileges should be shown for transparency.
  • Will edits require review by the layer owner, or be automatically merged into the layer?

Layer editors:

  1. If a user seeks to edit a layer, they can go to the layer's page
  2. When a user begins editing, they essentially create a "branch" off the layer master. This is sort of a "sandbox" for layer editing.
  3. The user can either make individual edits in the browser or upload (append) many features into the sandbox.
  4. When the user is ready, they can "submit" their edits (similar to a pull request). Depending on the permissions that have been set by the Layer Owner, these edits could be automatically added to the layer, or added after review. If automatic, the user should see their edits immediately after submission without having to refresh. If review, user should receive a notification when their edits have been approved.
  5. The user could also save the edits in that sandbox session and return later to submit them.

The editing experience

Users have expressed a desire to build on the existing editing experience in the following ways. Please see this doc for a complete set of Layer Editing userstories:

  • Make edits from a table rather than just on the map. This would make it easier to edit text attributes, for example.
  • Allow searching and sorting in the table, so I can find all the features that have a particular place name that I want to edit
  • Allow layer owners to add new attributes to a layer after it has been created or uploaded (Right now users can't change attributes of a layer once its been imported or created)
  • Allow user to "flag" individual features to encourage editing. Users could filter for all "flagged" features.
  • Add exact time-of-day an edit is made, rather than only the day as is currently done.
  • Explain more clearly that red means delete, yellow means modify and green means add.
  • Provide more tooltips and guidance for user when editing (i.e. a welcome 'training model' at start of session).
  • Allow users to add data sources to individual features, rather than only at a metadata level
  • Users should be able to toggle the basemap that is used in an edit session
  • Allow users to add notes about their edits. For example, an editor may want to note that evidence they have to support an edit, or uncertainty that they have despite making an edit.
  • Stretch Goal: Users should be able to pick and choose a style (i.e. lens) they want to view data in during an editing session. This will require creating some kind of style creator in the editor as well. So an editor could generate a style, save it and share it for others to apply to the layer when they are viewing or editing a layer.

Layer Viewer & Detail Page Improvements

  • When gazetteer work is done, FeatureBoxes should also include “did you know” info
  • Show the frequency and density of edits on a layer (like the Github heatmap and sparklines on repos and user profiles) on the viewer page, and provide similar summary information on the Layer card.
  • Show edits by the usernames that have the most edits, in addition to showing by most recent edits made
  • Let any user that contributes an edit to a StoryLayer also edit the metadata (all metadata edits need to be versioned and tracked by users)
  • Let a viewer toggle the basemap they are viewing the layer in
  • Stretch Goal: Let a viewer select the style or "lens" they want to view the layer data in.

Implications for stories

  • In the area on MapStory detail page where we list the layers used, the "story owner" view of the page should have information on the latest edit updates to the layer and an option to "use the latest version of the layer".
  • A story owner could also opt to get notifications whenever a layer they use in their story is edited/updated
  • A story owner could also select to "automatically update my story when layers I used are updated". The default would be for the story to use the version of the layer as it was when the story was published and only be changed if the storyteller manually decides to update. Updating layer versions could very well disrupt alignment with StoryPins, StoryFrames and other elements of the story that that storyteller will need to be address to make sure their story looks correct.

Administrative powers

  • Administrators can change editing powers on a layer (i.e. change edit-by-all to edit-by-owner only)
  • Administrators can roll back layers to previous versions
  • Editors can unpublish layers and have a notification sent out to owners of stories that use the layer.

Data import and management improvements

Currently users an import data into MapStory either by creating an empty layer with a schema, or by uploading CSV or Shapefiles. We need to build on this basic workflow in the following ways:

Initiative Driven Importer

  • Configure the Importer as "Initiative Driven". This means that:
    • data imported could be "cross-walked" to an Initiative schema that has rules for how data included in the Initiative must be organized. (This is a pre-req to the Gazetteer work discussed below)
    • An Initiative Lead can be set who determines the Initiative schema rules
    • The "append" option is integrated into the importer workflow to encourage users to add features to existing layers that are very similar, rather than create new. Ideally, add machine learning over time: "your layer looks very similar to this one. Rather than create a new layer, would you like to append your features to this existing one?"

Gazetteer

A gazetteer is an extension of an Initiative-Driven Importer. Right now layers are "islands" with no linking of features across one another. Features that a gazetteer implementation will make possible include:

  • Add "Did you know?" hooks to FeatureBoxes that appear on StoryLayers and MapStories (in edit, composer and viewer modes)
  • Add Open Linked Data API information to search indexes so that a search for a “place” generates results showing, for example, all the StoryLayers and StoryScapes that reference that “place”
  • Enable "zoom to place" search in mapstories (that aren't in Museum Mode)
  • Add pre-set schema support to importer, so that if a user has a "place name" in their import, they are coached to present that place name in accordance with a format supported in the gazetteer
  • Add "eras" support for time

Notes for the gazetteer effort are available here.

Raster Support

  • Test and document support for geotiff individual files and zipped sequences.
  • Relaunch and support warper.mapstory.org to allow users to upload unscanned maps and warp them to be georeferenced
  • Establish seamless sync between warper.mapstory.org and MapStory Importer so that georeferenced images don't have to be downloaded from warper and re-uploaded to mapstory but instead can be added to mapstory in a single process.
  • Integrate logins across mapstory.org, warper, and other tools
  • Rasters cannot be version edited
  • Rasters are more like another form of base map. When added to composer, there should be an option to "view for duration of chapter" or "view for a specific length of time (start to end).

Remote Data Feeds

The MapStory importer should support users in accessing streaming data, as well as data manually uploaded via the MapStory importer. Remote data feed priorities include:

  • GeoRSS
  • KML network feeds
  • GeoSMS

Managing Time Information

  • All users should have a time field in their vector upload, even if they don't yet have time info for their features.
  • For Raster layers, the time information should be provided in the metadata for the layer.
  • Make sure time is displayed without added levels of granularity on playback. I.E. don't add days, hours, minutes if the data doesn't have that information.
  • Support data imports with time information extending to 4.5 billion years BCE
  • Gazetteer questions around eras for research
  • StoryPins timepicker needs to support the same temporal extents as layers so that you can tell stories with all layers in MapStory

Additional file types

  • Add KML support and document workflow for users
  • Add geojson support and document workfklow for users
  • Research other potential data types and consider integrating based on user demand

Explore & Content Discovery Improvements

Add geospatial and temporal search to aid in discovery

  • Allow users to search StoryLayers by time, perhaps by constraining a timeline and showing layers with start/end dates that fall within those bounds
  • We should also consider the use of Eras in temporal search as a way to standardize time outside of conventional cartesian time
  • Allow users to search StoryLayers by geographic areas, perhaps by drawing a bounding box on a map interface and showing layers with a bounding box that falls inside those bounds.
  • A big leap forward for MapStory search would also be the ability to search at a feature level, rather than just layers and stories. The advent of the Gazetteer will generate linkages between individual features, also opening up possibilities for feature-level search.

Add UX to search to show editing status of StoryLayers

  • Let user filter for layers that are community editable versus only owner-editable
  • Provide visual treatments on layer cards to indicate editing permissions (editable or non editable)
  • Provide sorting treatments so users can sort by layers with the most edits

Add "related" hooks to MapStory and StoryLayer detail pages

  • On the StoryLayer detail page, show MapStories that use this StoryLayer
  • On the StoryLayer detail page, show StoryLayers that have the same tags
  • On the aApStory detail page, show other MapStories by this Storyteller
  • On the MapStory detail page, show MapStories that have the same tag

Leaderboard filter for search

  • A filter within storyteller search that lets me see things like:
    • user that have made the most edits
    • user with stories with most views

Profile and Social Features

Individual Profiles

  • Improve profile UX based on Glynnis design
  • Improve activity feed based on user research
  • Let users control the order and display of their StoryLayers and MapStories on their profile
  • Let me see my notifications in a profile section, as well as just by email.

Organization / Initiative Profiles

For Organization Pages, the goal is to promote participation by organizations who are thinking in terms of curating an organization page over the long term, not as a short term project management tool. Users that simply want to pool content under an Organization heading can use Tags for that.

The basic pitch to an Organization is that registering an Organization Page provides:

  • a public presence at a secured URL that is easy to find and share
  • an opportunity to present content not as a real name, but as an Org name. MapStory has a real names policy, but understands that oftentimes organizations prefer to present content under the header of their org not an individual.
  • Ability for users to search for the Organization in the Explore
  • a way to group all members of the Org in a common space
  • analytics and notifications (down the line)

MapStory administrators will work to make sure Organization URLs are only given to those Organizations registered with that name. For example, I can’t secure mapstory.org/organization/worldbank just because I requested it first. To enable this, there should be a manual activation of an organization page once the requesting org has submitted payment information.

Since the goal is primarily to provide Organizations with a public channel, and not to provide them access to lots of proprietary software, the price point will be low. Organizations are in the habit of subscribing to Social Media like Instagram, Facebook and Twitter for no cost. In our marketing, we can emphasize that subscribing to an Organization page is part of what sustains MapStory and ensures that content on MapStory is not subject to commercial influence.

As a starting frame, we recommend 3 pricing points:

  • Nonprofit/educational
  • Small business (under 10 employees)
  • Corporate

If a nonprofit/educational or small business org page were to exceed a certain threshold of data added to it, we would automatically move them into the Corporate pay level.

We want to encourage Organization Pages that are long-standing, rather than lots of quick pop-up and take-down pages created for time-bounded projects. Again, for this users could just create a Tag to group content. Thus, the payment model would encourage long-term commitment. For example we could:

Organization Page requirements:

  • A pre-req is that multiple authors be able to be assigned as authors of a story. This will enable an organization to represent a story as being by a storyteller, and by the Organization. This will also be helpful in situations where an agency or organization funds someone to produce stories. They will be able to be credited as an organization owner/author of the story.
  • Org Profiles would display all of an organization's layers, all their researchers’ stories, and would serve as a good outreach mechanism to disseminate their research and show their progress and effort
  • The organization profile should be at a simple URL, like www.mapstory.org/OrgName
  • Organization Page can be created by using a subscription/payment page directly on MapStory
  • A user should be able to be given "admin rights" over an Organization Profile. This empowers them to edit the Organization Page profile and add storytellers to the profile. Similar function to a Facebook organization page.
  • The Org profile design should feel like a "home page for an organization". We should consider a nice carousel for layers and stories the Org wants to feature.
  • Admins can add storytellers to the profile
  • Admin should be able to:
    • Add content to the "Featured Content" area (other users' StoryLayers and MapStories)
    • Removing or deleting/undoing any of the above
  • Organization Page should have an avatar that Admin can customize
  • Organization Page should have a place to put "about" information about the Organization
  • Organization Page should provide a place to link to social media accounts and other "links"
  • Organization Page should have an activity feed
  • Organization Page should show icons uploaded and tied to the organization account.
  • Org Pages should be discoverable in general Search
  • Stretch goal: Provide organization profile owners with an "analytics digest" that can be shared with Org Page administrators. The analytics would provide intel on use of layers by users across the site, edit history, stories published, data downloads, and other items of interest to Org Page administrators as we learn needs over time. This is an "Org Page" specific set of notifications.

Once an Organization Page baseline exists, the code can be used to create a similar baseline for an Initiative Page. Initiative Pages will be similar to Organization Pages, but rather than represent the identity of an organization or company, they will represent the identity of a priority content "area" that the MapStory Foundation is promoting. Initiative Pages will be run by "leads" set by the MapStory Foundation.

In future, Initiative Pages will likely emerge features distinct from Organization Pages that are appropriate for building community and promoting 'crowdsourcing' (i.e. leaderboards, activity stats, etc). Also, Initiative Pages will tie into the "Initiative Driven Importer" work that will increasingly make Initiative "content" more rule-based and automatic, rather than arbitrary and manually defined as it currently is.

Community Blog

The community blog is designed as a place for all registered users to author posts that can be shared with the community.

  • Add WYSIWYG editor (bold, italics, underline, headers, ordered and unordered bulleted lists, blockquotes, hyperlinks)
  • Let author upload images as part of their post.
  • Let any author add tags to their post. Have auto-complete for tags to promote common spellings
  • Let administrator add tags to any post
  • Let administrator set select posts as "featured", which keeps them at the top despite publishing date
  • Let reader target posts by clicking on tags and filtering content

Notifications

  • Let user control whether they are notified by email, or via my personal profile, about certain actions that occur on MapStory.org
  • review and update notification options currently allowed for in GeoNode
  • Create a notification summary space on the profile so the user can see notifications there as well as receiving email
  • Make sure users can track any activity on content they created
  • Make it easy for users to follow activity on issues they care about ("Watch this StoryLayer"). This means they would be notified any time a layer or story with the interest tag is published

Peer Review tools

  • Add existing peer review tools to MapStory detail page:
    • Rate story
    • Flag story
    • Comment on story
    • Send message to story author

Next Plateau

3D MapStories

  • Enable 3D Mapstories
  • There are several cool WebGL toolkits that may let us view MapStories not just in 2D but in 3D, over time. We should incorporate these so that users can render data that shows height. Cesium is the top of the list.
  • To do this truly right there's some backend infrastructure in GeoServer/GeoTools to enable. And there's some cool w3ds stuff being done in GeoServer. Be able to bring in collada models and the like potentially.

Crowdsourced Translation

  • Translate MapStory into many languages
  • Implement i18n tags
  • Start a crowd-sourced localization effort
  • Contribute translation effort to GeoNode and OSS community where possible
  • Transifex is the library GeoNode uses for translation. We have it enabled. Just need to ensure tags are there for all strings.

Developers Tab on Details Pages

  • Add a developers’ tab to StoryLayer and MapStory detail pages (like 'share', ‘contributions’ etc.)
  • Filtered capabilities endpoint for each layer, or we'd figure out on the server side how to group the layers in a map in one capabilities document
  • Display the capabilities endpoints
  • Display self-documenting snippets for that layer, showing how to use it on Open Layers, Google Maps, and with demo requests.
  • Static image at a time slice (use a WMS reflector request, then they can play and learn about WMS)
  • Dynamic map in Open Layers and/or GeoExplorer, ideally working with time animation properly.
  • Google Map at a time slice, show the exact javascript to use with Google Maps API, at a valid time slice.
  • Possibly KML - though it'd be good to get time working automatically in GeoServer. Should be able to, all the plumbing is there, just not connected.
  • WFS Query, likely best to do a couple to get across the power. With both GeoJSON and with XML. And CQL for filtering, make it simpler
  • Desktop GIS, like described above with capabilities end point. It is less 'developer' so maybe call the tab something else or put this in another tab.
  • Tile access, just some sample tile requests, to TMS or XYZ tiles
  • May need to do some GeoServer WPS calls and possibly make some processes to get sample values.

Tools.mapstory.org

  • Organize a suite of tools that will help MapStorytellers get their data "mapstory ready". The first of these tools is already in development - warper.mapstory.org. This tool helps users with raster maps geo-reference them so they can be imported into MapStory as raster layers.
  • Future tools could include:
    • a geocoding service so that tabular data with addresses can easily become geocoded

Developer Community and Modular Development

Overview

Reusable Modules

Mapstory consists of a suite of components, including Django modules. Geonode provides the baseline for these components, and increasingly Mapstory will provide extended functionality. Much of this functionality may however be backported to Geonode (or developed first as Geonode or plain django modules then integrated into MapStory)

Modules themselves may have resources and plug-ins provided by the mapstory application - or by sub-modules - for example osgeo-importer may have MapStory specific configurations, or the django-skosxl module provides RDF output mappings that can be used by the django-rdfio module.

Examples are:

Geonode specific:

  • osgeo-importer (customised by mapstory with plugins)
  • django-gazetteer (could also supports GeoDjango)

Mapstory functions relevant to Geonode

  • elasticsearch
  • timeline viewer
  • composer

General scope:

  • icon-commons
  • django-skosxl (definitions dictionary using SKOS semantic model)
  • django-rdfio (RDF export for django ORM and Linked Data support)
  • uriredirect
  • historical-eras (SKOSXL extension to support spatio-temporal era definitions)

Requirements for reusable modules

  1. Mechanism to include additional modules in deployment build without breaking mapstory code base update cycles (i.e. avoid hacking local settings files manually)
  2. Ability to have a module-specific provisioning script included in provisioning process. *e.g. ansible role) - this will need to be compatible with both Geonode and Mapstory provisioning processes for both development and production deployments.
  3. Migrations to be specified to be run when module is updated (ansible controlled?)
  4. Unit tests to be run on installation
  5. Documentation to be included in site online documentation (ideally including module-specific API specs for automated API documentation systems)

Each module needs to be able to be included in the lowest level application scope (e.g. basic django, geonode or mapstory) using appropriate deployment mechanisms. (basic django can be manual configuration and running ansible scripts - but geonode and mapstory should be idempotent processes that preserve content.)

Geonode upgrade path

Mapstory is both an application and a site - in both cases there is scope for an upgrade path for GeoNode deployments to include elements of Mapstory functionality, or to become a node in a distributed network contributing to MapStory's global offering.

Requirements:

  1. re-usable module methodology (see above)
  2. Common, or additional, provisioning scripts compatible with both enviroments
  3. Catalog of available modules (preferably machine readable - and GeoNode could offer a plug-in manager module?)
  4. Mapstory functions factored as modules
  5. Federation model for mapstory (possibly simply harvesting and integrating Gazetteer/Linked Data metadata, and offering choice of search targets?)

Extension Module Template

Once a module plug-in capability is available, then a tutorial template module should be provided to assist developers putting all the right things in the right places.

Deployment Guide

Provide guidelines on how to deploy new functions and improvements into a reviewable beta stage so that community contributions can be assessed. (the alternative is you need a developer to run an install, find content, understand the functions and then explain to the wider community what is good/bad about it without something to point at)

Community & Identity

MapStory is much more than an app for making MapStories. As a community we encourage sustained participation in the curation of data that is available for mapstorytelling.

Community Initiatives & Projects

Community Initiatives are a tool to promote community building and contributions to MapStory. An Initiative has a set landing page at a simple URL, such as mapstory.org/initiative/americanpolitics. The page can be created by a user in a similar workflow to a creating a normal individual profile, but has to be "approved" by an administrator before going live.

  • Functionally, Initiative Pages serve as sort of a "rich" version of a custom explore page. Their function is to show all the layers and stories that are "part" of the initiative, while also providing some additional community-building tools to promote contributions within the initiative contenxt.

  • Initiatives have "leads"...owners of the Initiative Page that can customize how they look.

  • Initiatives have "Leaderboards"...listing of the top users that have contributed layers, edits or stories within the initiative

  • Initiatives have "stats"...summary statistics. More research TBD. I.E. "total number of edits to the initiative.

  • Initiatives have "projects"...projects are a sub-topic within the larger initiative. For example, the "American Politics" initiative may have projects for Political Parties, Gerrymandering, Presidential Elections, etc. Projects could simply be a visual grouping of StoryLayers and MapStories that have a tag for the project. I.E. everything tagged with gerrymandering could show up under the Gerrymandering project section on the Initiative Page.

Community Journal

The Journal is designed as a place for all registered users to author posts that can be shared with the community.

  • Add WYSIWYG editor (bold, italics, underline, headers, ordered and unordered bulleted lists, blockquotes, hyperlinks)
  • Add basic filters for finding posts like “most recent” vs. “most read”
  • Let author upload images as part of their post.
  • Let any author add tags to their post. Have auto-complete for tags to promote common spellings
  • Let administrator add tags to any post
  • Let administrator set select posts as "featured", which keeps them at the top despite publishing date
  • Let reader target posts by clicking on tags and filtering content
  • Let reader target posts by toggling between "most recent" or "most read"

Improve Notifications

  • Let user control whether they are notified by email, or via my personal profile, about certain actions that occur on MapStory.org
  • review and update notification options currently allowed for in GeoNode
  • Create a notification summary space on the profile so the user can see notifications there as well as receiving email
  • Make sure users can track any activity on content they created
  • Make it easy for users to follow activity on issues they care about ("Watch this StoryLayer")

Peer Review tools

  • Needs more definition and requirements, good opportunity for heuristic evaluation and user research
  • Star rating and flagging layers for inaccuracy, violation of terms, or being broken currently exist
    • What other peer review tools might help users understand completeness/accuracy of a layer?

Data Improvement & management Improvements

A key part of building on MapStory's initial foundation is to hone in on our fundamental data model across the platform. This includes:

Gazetteer

A gazetteer will enable linked data mappings on features across layers. Right now layers are "islands" with no linking of features across one another. Features that a gazetteer implementation will make possible include:

  • Add "Did you know?" hooks to FeatureBoxes that appear on StoryLayers and MapStories (in edit, composer and viewer modes)
  • Add Open Linked Data API information to search indexes so that a search for a “place” generates results showing, for example, all the StoryLayers and StoryScapes that reference that “place”
  • Enable "zoom to place" search in mapstories (that aren't in Museum Mode)
  • Add pre-set schema support to importer, so that if a user has a "place name" in their import, they are coached to present that place name in accordance with a format supported in the gazetteer
  • Add "eras" support for time

Importer Improvements

  • Connect importer to remote data streams like WMS, GeoRSS, KML, etc. and allow syncing to keep them up to date. -
  • Support/enable Initiatives' schemas and encourage users to support Initiatives' efforts/themes
  • Support Raster data upload (images, old print maps, etc)
  • Allow KML upload
  • Provide Common Reference Data (like states or countries)
  • Allow uploads of styles and statistics that can join to common geometries
  • Support all common projections

Features to enhance Initiatives

Community Initiatives help a community of users crowd-edit data around a defined schema that one or multiple layers abide by. In 2017 we need to make it easier and more common for users to strengthen existing schemas rather than creating new ones that are similar to what exists. This includes:

  • Enable Community Initiative Leads to define pre-set Schemas for data imported or appended to initiative StoryLayers
  • On import, show users which initiatives their layer could be a part of, and provide intelligent suggestions of what changes they could make to their layer's schema

Robust Support for Geologic Time

  • Support data imports with time information extending to 4.5 billion years BCE
  • 4.5 billion years exceeds carbon dating technology, but as an iterative step we could create themes for dealing with time, for example: volcanic events, elevation change models, paleomagnetic change, carbon dating data
  • This might help us know better what kind of data we want to support. For example: US geological society data structure for fossil data that might give us a way to show those date formats on a timeline without having to create a computer science model from scratch (we’d have to invent our own time structure because these aren’t epochs)
  • The Holocene Era is attainable, the most recent era prior to human history. It's not 4.5 billion years of support, but with an iterative approach we could add new eras one at a time, starting with most recent first. Starting with the Holocene Era would handles all of carbon dating time.
  • Would these timelines be incorporated into the current timelines, or would we use a completely different timeline model that can’t be mixed with modern day time supported by the standard date time model?
  • First effort: use ASU students to develop test data with plate tectonics as a sample we can work from
  • Gazetteer questions around eras for research

Warper Integration

  • Relaunch and support warper.mapstory.org to allow users to upload unscanned maps and warp them to be georeferenced
  • Establish seamless sync between warper.mapstory.org and MapStory Importer so that georeferenced images don't have to be downloaded from warper and re-uploaded to mapstory but instead can be added to mapstory in a single process.
  • Integrate logins across mapstory.org, warper, and other tools

MapStory.org Beta Baseline and Testing

Baseline Description

In 2015 we began a re-engineering of the MapStory prototype site which had previously soft launched in April 2012 and opened up for public registration in January 2013. This table represents the features checklist that informed the "MapStory Beta" re-engineering effort, which we aim to stamp as a 0.1.0 release in April, 2017. The Roadmap represents the development agenda for further releases beyond the 0.1.0 baseline in 2017.

There are 10 current ‘core components’ that encompass the Beta 0.1.0 release:

  1. Data importer – allows users to upload openly licensed spatio-temporal datasets as “StoryLayers”
  2. Icon Commons– allows user to upload openly licensed icons into a commons that all registered users can use in the MapStories they publish
  3. Create StoryLayer tool – allows users without data to create a new StoryLayer directly in the platform and then begin adding features to it
  4. Collaborative Version Edit tool – allows users to contribute edits to StoryLayers and track these changes by user accounts
  5. Append tool – allows users to add multiple edits to a StoryLayer at once
  6. Composer – allows users to style StoryLayers and add boxes, pins, and chapters with the goal of presenting a geospatially based narrative (MapStory).
  7. Publisher – allows users to have confidence that their published MapStory will be able to be viewed by anyone, either on the platform or as an embed elsewhere, and will appear as they designed it to appear in Composer
  8. Search - allows users to find StoryLayers and narratives by filtering through a set of categories and
  9. Peer Review & Peer Support – allows users to provide feedback on StoryLayers and MapStories created by other users and to provide help and documentation that helps other users succeed on the platform
  10. Profile Management – allows users to manage the content (StoryLayers and narratives) they produce and to represent themselves to the rest of the user community.

Table

KEY:

  • Y: Functionality works
  • N: Functionality not working
  • F: Future release
  • 1 (high priority), 2 (lower priority), 3 (lowest priority)

Table Current as of 25 Jan 2018

Component Feature Live on MapStory.org Live on Beta Priority
Data Importer Import SHP files Y Y
Data Importer Import CSV files Y Y
Data Importer Importer Raster files N F
Data Importer Enable users to download datasets Y Y
Data Importer Provide good documentation to user on importing Y Y
Icons Commons Upload icons as svg Y Y
Icons Commons Upload collections of icons as svg N N 3
Icons Commons Use icons to style a story Y N 2
Create Layer tool Let new user create layers Y Y 1
Create Layer tool Let created layers be version editable by owner Y Y
Create Layer tool Let created layers be version editable by other Users N N 1
Collaborative Version Edit tool Let layers be version editable by other users Y Y 1
Collaborative Version Edit tool Enable all edits to be tracked by user accounts (versioned editing) Y Y
Collaborative Version Edit tool Enable user to manage editing permissions for their layer N F
Collaborative Version Edit tool Enable administrator to activate and deactivate community editing on a layer N F
Append Tool Enable user to upload large numbers of edits to a StoryLayer tracked in version history N N 2
Composer Enable user to compose MapStory with styled StoryLayers, chapters, boxes and pins Y Y 1
Composer Enable user to customize the title of the StoryLayers as they appear in their MapStory, as well as determine which attributes in a StoryLayer will appear as part of the legend Y Y 1
Composer Enable user to create StoryPins that extend to the same time extents as StoryLayers N F
Composer Enable user to upload many StoryPins at once Y Y
Publisher Enable user to publish a MapStory to the public Y Y
Publisher Enable user to publish a StoryLayer to the public Y Y
Publisher Enable published MapStories to persist styles and settings defined by user in Composer Y Y
Publisher Enable published StoryLayers to persist the zoom extent, timeline, legend and feature types as set by user who uploaded or created the StoryLayer Y Y (with Polygons) 1
Publisher Enable MapStory to be played on a continuous loop Y Y (for single chapter stories 1
Publisher Enable MapStory or StoryLayer to be viewed on a desktop of tablet Y Y
Search Enable published StoryLayers or MapStories to be filtered by categories Y Y
Search Enable published StoryLayers or MapStories to be filtered by tags Y Y 2
Search Enable published StoryLayers or MapStories to be filter by spatial and temporal filters N F
Peer Review & Support Enable users to flag layers Y Y 2
Peer Review & Support Enable users to provide threaded comments on content N (MapStories) N (MapStories) 2
Peer Review & Support Enable users to rate content on a 5-star scale N (MapStories N (MapStories) 2
Peer Review & Support Enable users to send direct private messages to one another Y Y
Peer Review & Support Enable users to author journal articles for all users to read Y Y 2
Peer Review & Support Provide introductory trainings for users Y Y
Peer Review & Support Provide a way for users to join a Volunteer Technical Community Y Y
Profile Enable users to manage a profile that presents all of the StoryLayers, MapStories, journal entries, and icons and activities a user taken the platform Y Y
Profile Enable a group or organization to manage a profile that presents the users involved in their group, and their respective StorLayers, MapStories, journal entries, icons and activities taken on the platform Y Y

Tester Guidelines and Links

MapStory Beta Testers Guide

Thanks for taking time to test the MapStory.org beta release! Our development team has worked really hard to get it ready for you to test, and stands ready to respond to feedback as quickly as possible. This guide can be used as a reference to help you test with efficiency and productivity. Depending on the complexity of the data you’re testing with, or the mapstory you aim to tell, testing should be able to be completed in an hour or less.

Quick Background

MapStory is a platform with four main purposes: hosting spatio-temporal data ("StoryLayers), version editing these StoryLayers for completeness and accuracy, telling "MapStories" that use StoryLayers and other types of information, and discovering all this content quicklty and easily. We've broken up the testing into these sections so you can target testing at the tasks you're most interested in.

Before you start testing, do these 3 things:

  1. Get acquainted with the MapStory vision by watching the Get Started videos
  2. Review the feature specifications that drove the [MapStory Beta development]https://github.com/MapStory/mapstory/wiki/2017-MapStory-RoadMap-Archive#baseline-description)
  3. Read the 2017 Roadmap to see what we’re already working on to improve the beta.

Once you’re ready to test:

  1. Open one of our surveys, follow its prompts, and enter your answers. All testing will be done on the mapstory.org site.
  • If this is your first time testing, you should start with this survey focused on account creation. After completing this, you'll be able to move on to the other testing areas.
  • If you interested in testing the data commons aspect of MapStory, use this survey.
  • If you're interested in testing the versioned editing aspect of MapStory, use this survey
  • If you're interested in testing the MapStory composition aspect of MapStory, use this survey
  • Finally, if you're interested in testing MapStory content discovery, use this survey
  1. As you complete the survey, feel free to submit “Feedback” tickets with our UserSnap tool to explain any problems you encounter in a more visual way. Just click “feedback” button at the bottom right of any page on mapstory.org. Watch this video for more information.
  2. If you feel comfortable, go further and report bugs or feature ideas directly into our Github repository. Remember to follow our guidelines for creating bug reports or feature requests in Github.
  3. Check in anytime with the progress of our development team on our Waffle board.

Project Vision

User Personas

Beta Baseline and Testing

Creating Issues

How to Contribute

Project Architecture

MapStory Road Map

Clone this wiki locally