-
Notifications
You must be signed in to change notification settings - Fork 41
2018 MapStory Roadmap Final
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. 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.
- 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.
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
- 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
A clear and sustainable/migratable data model must be established for the project in 2018 in order to avoid past failures to maintain user data as site updates occur. StoryLayers are the base unit of content on the site, and along with narrative elements called StoryPins, one or more StoryLayers can comprise a MapStory. Thus Data Model considerations relate to each.
StoryLayers support three classes of geometry:
- Points
- Lines
- Polygons
Furthermore these geometries must be projected in a well known EPSG projection. click here for a list of supported projections
Currently, we only support strongly-typed geometries. Future consideration should be given to mixed-type geometries (such as points and polygons in the same file). this is of particular concern for KML and geoJSON files.
Each StoryLayer is assigned a unique ID and within the StoryLayer, each feature has a unique ID. These IDs are used when edititing the layer.
See [Below](link to time section)
StoryLayers may or may not contain additional attributes for context. These attributes can be strings, datetimes, integers, or real numbers.
Furthermore, attributes can be used to populate contextual information (such as StoryPins) and used for styling of the layer based upon user-defined rules.
Attribute information should be defined within the data quality statement and users should be encouraged to use standard naming conventions where applicable. This could be done via a dialog within the import process that requires the user to define each attribute field or have the option to ignore attributes for import.
Each StoryLayer may have one or more styles attached to it by individual users, including user who are not the original author of the StoryLayer.
Each StoryLayer also contains metadata to maintain data quality:
- Category (used site-wide to group StoryLayers into related categories)
- These categories should be a special class of
Tags/Hooksused to discover related content
- These categories should be a special class of
- Summary (A brief explanation of what the story layer is about)
Purpose (A breif explanationof why this StoryLayer was produced)- Data Source (A StoryLayer Level citation of who generated the dataset)
- Data Quality Statement (A description of any data related consideration ie confidence level, resolution, assumptions and/or models used to generate the data)
- Some Data Quality Statements should be required or separated out into multiple metadata categories. for example, the Data Quality Statement should contain the Schema definition.
Users should be able to attach tags to StoryLayers. These tags would serve as a form of searchable metadata.
An Initiative Lead can create a StoryLayer “Schema” file that allows individual users to create additional datasets that can be seamlessly appended to an existing StoryLayer, creating the opportunity for a community of users to promote the growth of large-scale StoryLayers and minimize duplication of similar layers. Available schemas will be listed in the Import module so users can select to ‘append’ their data too, rather than conduct a separate upload.
Location and Time/era information in a StoryLayer can also be tied to pre-set gazetteer hooks at the point of import, using the LinkedData API. This will help to drive location and time/era searches at an individual feature level across large collections of linked StoryLayers through the Explore interface.
NOTE: StoryLayers can also be temporal sequences of rasters, or an individual raster in “freeze frame.” For these StoryLayers, the Time, Metadata, and Tags sections above still relate.
MapStories are comprised of one or more StoryLayers and narrative elements called StoryPins, StoryFrames, Timelines and Legends, that can be packaged in to one or multiple Chapters.
Each MapStory will apply specific Styles to each vector StoryLayer in the MapStory.
StoryPins will annotate the MapStory as narrative elements.
StoryFrames provide the sequence of spatio-temporal views through which a MapStoryteller wants a viewer to see the MapStory.
Chapters are packages of StoryLayers, StoryFrames, StoryPins, Legends and Timelines. A MapStory can have one or multiple Chapters.
Each MapStory also contains metadata to maintain data quality:
- Category (used site-wide to group MapStories into related categories)
- These Categories should be a special class of
Tags/Hooksused to discover related content
- These Categories should be a special class of
- Summary (A brief explanation of what the MapStory is about)
Purpose (A brief explanation of why this MapStory was produced)- Data Source (A MapStory Level citation of who generated the Narrative)
- Data Quality Statement (A description of any data related consideration ie confidence level, resolution, assumptions and/or models used to generate the data)
- Some Data Quality Statements should be required or separated out into multiple metadata categories.
Users should be able to attach tags to MapStories. These tags would serve as a form of searchable metadata.
As the site gets more traffic and real-world use, importer enhancements. 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:
Add supprot for the following Vector Formats:
- GeoJSON *
- KML *
- GeoPackage
- GML
* already supported by importer, however client side default styling, etc, does not support multiple geometries
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
Raster StoryLayers should be made possible by the upload of:
- GeoTiffs
- 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).
- Sequence of GeoTiffs with temporal metadata
- Warper Exports
- Both temporal sequence and stand-alone.
- 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
When series of time formatted rasters are uploaded, the importer should handle a gZIP or ZIP of these files.
Additional consideration should be given to other Raster formats such as ADRG/EDRG, ERDAS .IMG files, and USGS .dgr when time and user-requests allow.
- Add animated-thumbnail auto-generator for StoryLayers and MapStory thumbnails
- Animated thumbnails should appear in social media cards as well
- onece auto-generated animated thumbnails are in palce, the
user-uploadfeature of thumbnails should be removed
Importer should enforce that geometries and incoming data have either well formatted time attributes or provide a mechanism to add a time field to the schema at import.
Null time values should also be allowed durring import.
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
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
The MapStory model should include the following base components
- Layers (StoryLayers)
- Basemaps
- Timeslider
- Timeline
- Legend
- Chapters
- StoryPins
- StoryFrames
- Versioning and Update
- Playback Options
Enable download of entire story as a geopackage
As a user, I expect to be able to create custom styles with the StoryLayers I use in my story.
- Implement styling framework called for by Rey's mockup with consideration for Glynnis' existing mockups
- Editor must support .SLD and MapboxGL as appropriate.
- Have styling "templates" that can be reused with other layers and attribute variables
- Custom icons in Scalable Vector Graphics, animated GIFs, and other formats should be supported for point data from the
IconsCommonsmodule. - Detached resuable shareable styles that show upin StoryLayer Detail Page as associated styles.
StoryFrames allow the narrator to focus on or highlight a time and place within a story. StoryFrames should have their own settings for zoom, playback speed, duration, etc.
- Enable StoryFrame (time and bounding box) to be derived from a StoryPin location.
- 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 or StoryFrame.
StoryPins add additional information that links to the content within a story by showing attribute data, highlighting an event, or linking to external content that is relevant to the story that is not within the layer data. A way to focus attention and provide more context.
- Allow for StoryPin content to exist "off-the-map" in a sidebar
- 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.
Allow storyteller to customize placement of timeline. Currently the timeline has one fixed location and behavior.
Allow users to further customize legend. Right now the legend is purely derived from the layer data, which may not make sense in all story cases.
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)
Users should be able to work together with other users to make MapStories, and those other users should get credit for their help.
- Allow the original creator of a MapStory to add additional users as "Story Authors"
- Any user added as an Author to MapStory has the draft accessible on their profile and can enter into sotry composing to make changes
- Add a change history log in MapStories to track which Story Author has made which change.
- 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.
The saving model for mapstories should include a "draft", "staged changes" and "published" model.
As a user, I need to make sure a MapStory can be played all the way through, without the need for user intervention.
StoryLayers will always default to Discrete playback in the Detail Page. The user can change the playback mode.
Allow user to define the default playback options for a MapStory’s StoryLayers, Chapters, StoryFrames, and StoryPins
if each MapStory’s data should be displayed cumulatively or discretely.
Enable “loop story” function (aka ‘Museum Mode’) that allows story to play from start to finish with StoryFrames, StoryPins, and chapter transitions occurring without the need for user interaction
The StoryTeller is responsible for making their MapStory "Museum mode compliant" by providing verbose playback options, durations of StoryFrames, StoryPins and Chapter transitions.
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.
Add “Playlists” feature to Individual and Organization Profiles. With Playlists, Profile owner can give playlist a name and add stories to the playlist. A Playlist can then play continuously without user intervention, like “loop story” but for multiple stories. Use case is a museum displaying a series of MapStories on a display.
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.
As a user, I expect all contributions on MapStory to be accompanied by source information.
MapStory should provide common geometries that can be extend with tabular data supplied by the user. these "Reference Layers" lower the barrier to entry for non-geospatial users. examples of Reference Layers include:
- political boundaries (Countries, States, Counties, etc)
- Natural History boundaries (geologic time)
- Phsyical geography boundaries (climate types, continental extents, marine bathometry).
Each StoryLayer and feature edit within a StoryLayer should be tied to an owner that represents him/herself with a ‘real name’. POLICY NOTE: Site Administrators have the power to delete, unpublish or roll back StoryLayers that do not abide by the real names policy. StoryLayer editors have power to roll back feature edits made by users that don’t abide by real names policy.
- All StoryLayers should have source information listed in the Data Source metadata field.
- All feature edits should have Data Source information listed in a ‘Source’ attribute field for the edit -These sourcing requirements should be enforced by the GeoGig version control mechanism.
- Any user should be able to ‘flag’ a layer if they see something that is broken, inappropriate, or inaccurate.
- The flag should denote which category is in dispute (broken, inappropriate, inaccurate, etc...)
- Site (or Layer Admin?) Administrators should receive notifications of new flags on layers
- Site (or Layer Admin?) Administrators follow a protocol to review and resolve flags
- Layer detail page should have a space to show whether there are pending/unresolved flags on a layer
- Edit activities should be published to the Activity Feed of the user doing the edits.
- Users should be able to follow the edit activity on a StoryLayer of interest by requesting ‘notifications’ be sent whenever the StoryLayer is modified.
- The StoryLayer detail page will also provide basic monitoring and metric information, such as: an edit history list; total edits made; date/time of most recent edit; number of unresolved flags; lists of contributors
Users expect to be able to make edits to StoryLayers that are tracked
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:
- Once created, each StoryLayer has its own GeoGig repository
- (Needs Review) StoryLayers have admins that can manage the StoryLayer's schema, update and commit strategy, etc., Furthermore the Owner is by Default a layer admin. StoryLayer admins can elevate other editors to admin status. Admins can also demote fellow admins with the exception of the StoryLayer owner. Organization and Initiatives can act as the owners of their StoryLayers. Additionally, site admins have StoryLayer admin access on all StoryLayers
- StoryLayer creator can set StoryLayer editing rules as either only owner-edited, edited-by-select-users or edited-by-whole-community. (Note - If StoryLayer is edited-by-select-users, these users will be listed on StoryLayer Detail Page for transparency. Invited editors receive a notification and ‘accept’ to become editors.
- StoryLayer owner can change layer between owner-edited or edited-by-select-user status at any time. But, once a StoryLayer is set to edited-by-whole-community this status cannot be reversed.
- If a StoryLayer is edited-by-whole-community, than edit contributions are automatically approved and published. If a StoryLayer is owner-edited or edited-by-select-users the StoryLayer Owner can set edits to be “published automatically” or “require review and approval”. If require approval, StoryLayer Owner and editors with approval status get notifications and can see pending edits in the StoryLayer Owner view of the StoryLayer’s editing interface.
- If a user seeks to make many edits to a StoryLayer they can create a “Branch” of the StoryLayer. In the Branch the user can upload multiple new edits and make other feature and attribute changes and then, when finished, submit a “pull request”. If the StoryLayer is owner-edited or edited-by-select-users, a owner will review and merge the pull request. If the StoryLayer is edited-by-whole-community the pull request will be automatically merged. If the pull request causes disturbances, another editor can roll-it-back.
- schema changes to edited-by-whole-community StoryLayers can only be preformed by site administrators in accordance with administrative guidelines
- Branch editing can be done off-site in a desktop environment such as QGIS and appended via the importer. Basic edits must be done on-site or within the tools.mapstory.org site.
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:
As a user, I expect to be able to propose edits to StoryLayers in a simple editing interface. The things I should be able to edit include: feature geometries, feature time information, feature attributes, and StoryLayer metadata. My edits to features should be able to be done through a map or a table view. And all edits should be tracked in a history. Finally, if I desire it, I should get notifications when my edits are changed by another user, or if a StoryLayer I’ve edited is changed at all.
Geographic editing involves:
- moving the location of a feature
- adding a feature
- deleting a feature
- modifying the boundary or path of a feature
Temporal editing involves changing the start-time or end-time information of a feature. Edits should be enforced at the same temporal resolution
Metadata editing involves changing the title, abstract, and data source information for the layer
Attribute editing involves adding new attributes to the layer schema, editing existing attributes, and adding/editing content within an attribute for a feature.
Whenever an edit is submitted, it should be accompanied by a ‘commit message’ that allows the editor to explain the nature of his/her edits. Commit messages and attribution should be displayed in the Editor History log for the layer. The time of edit and percent change should also be tracked
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.
As an editor, I can make geometry, time or attribute edits via a table view.
As an editor, I can make geometry, time and attribute edits by selecting features on the map.
The basic editor should provide detailed user feedback to support the editing process, including tooltips and messages prior to any submissions.
The basic editor should display layers with a default style. A simplified style editor also will enable editors to view the layer in additional ‘lenses’ that support editing. these styles (with common preset lenses) should be used for classification and data management within the editor (ie. sort by type, within a specific range, matching a given value, etc)
Users should be able to toggle the basemap that is used in an edit session
Current Implementation
Every StoryLayer should have at least one attribute that contains a date-time field.
This field should be in ISO 8601 format (2017-12-29T00:24:37+00:00) at any level of temporal resolution from within the full standard.
The temporal resolution of the data should be respected upon import.
Currently, mapstory supports up to two date-time fields; a start_date and end_date. Any changes to these temporal attributes should trigger any back end actions for dealing with time. (I.E. Updating the the datexd or datexd_parsed fields)
Furthermore, Temporal data that contains mixed resolution (ie some features with only Year Data, and others with Year and Month) should convert to the same resolution. Two Examples of how to accomplish this are:
- Maintain the coarsest grain resolution (ie drop the Month Data in the example above)
- Convert the coarser data to finer resolution for the entire range of the sub-unit. (ie convert the start date in the above example to YYYY-01 and end date to YYYY-12)
- Support data imports with time information extending to 4.5 billion years BCE
The user should have the option to select which method to use or be directed to the tools.mapstory.org data formatting tool.
Temporal editing involves changing the start-time or end-time information of a feature. Edits should be enforced at the same temporal resolution
As a user, I expect to be able to find content based on the time periods I am interested in.
- Add layer-level temporal search filter to Layer and Story Explore tab using eras definitions from gazetteer
- Add layer-level temporal search filter to Layer and Story Explore tab using eras definitions from gazetteer
- Add time-range text box tool to Layer and Story Explore tab that allows users to narrow to Layers and Stories with time spans within the defined range
As a user I want to make sure mapstories can be played on different websites besides mapstory.org.
- Make sure animated gif thumbnails show up in Twitter and Facebook cards
- Enable MapStory to be shared to local servers as a file, including all components:
- MapStory Configuration Options
- StoryLayer(s)
- StoryLayer Metadata
- Style(s)
- Version(s)
- Chapter(s)
- StoryPins
- StoryFrames
- Story Metadata
- 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.
- Add space with cards under the heading “more stories like this one”
- Add space with cards under the heading “more stories by this storyteller”
- Find place to add social features to MapStory Detail Page: flag story; rate story; comment on story; send message to story author
- Add “Playlists” feature. With playlists, Profile owner can give Playlist a name and add MapStories to the Playlist. A Playlist can then play continuously without user intervention, like “Loop MapStory” but for multiple MapStories. Use case is a museum displaying a series of Maptories on a display.
- Add feature on Individual Profile showing user activity density (IE Editing, composing, etc.), similar to Github activity graph
- Let users control the order and display of their StoryLayers and MapStories on their profile
- Add a new “Dashboard” or "Drafting Board" view for the Profile owner that is distinct from the public facing Individual Profile. The Dashboard will be the place to manage the public profile, to track notifications and messages, and to launch activities, such as authoring Journals, uploading data, starting MapStories, etc. It will become the “home page” for users.
- Let me see my notifications in a section of the dashboard, as well as by email notification.
- Add back integrated login to Wiki and Warper
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.
- Add subscription/payment workflow to Organization Pages
- Let Org Page administrators control the order and display of StoryLayers and MapStories on the Org Page
- Let Org Page administrators track notifications in the manage profile area, as well as by email notification.
- Integrate an Analytics section into Org Page manage profile area.
- 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.
- 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.
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, importer upgrades that will increasingly make Initiative "content" more rule-based and automatic, rather than arbitrary and manually defined as it currently is.
- Create workflow whereby Initiative Leads can establish ‘schema rules’ that newly uploaded layers can be merged into in order to promote large-scale common layers.
- Schema information will be articulated on the Initiative Page
- Schema information for active Initiatives will be promoted in the Importer to encourage users to tie new data uploads to Initiatives rather than create duplicate layers
- Create Leaderboard section within Initiative Members area to highlight users that have made the most edits to layers in the Initiative
Nothing new planned
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
- 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
- Support both Email and in-site notifications
Implement these for stories and on Story Detail Page (currently only on Layers). Otherwise, nothing new planned.
Users should be able to easily see which users are most active.
- In Storyteller tab, create “Sort By” fields for ‘Storyteller with Most Edits’ and ‘Storyteller with most viewed stories’
Add field for “Interests” on Initiatives and Organization Pages. Clicking an “Interest” should spawn a search with the Interest filter in the Team Type (Initiative or Org)
Add feature on Individual Profile showing user activity density, similar to Github activity graph
- 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)
Because MapStory is an Open Source project, as an extension of the GeoNode,, we should provide clear documentation and guidance on encapsulation of modules for use with the API. One such example is integrating Remote Feeds with projects such OpenSensorHub
MapStory should have a clearly defined API for the Layer Data Model, Story Composing, Layer Editing and Import/Export. Furthermore, A verbose set of documentation for both Developers and Users should be provided on the Github wiki and wikimedia page respectively.
Beta Baseline and Testing
- How to request a feature
- How to create a spike
- How to report a bug
- How to request a design story
- How to create a milestone
- Developer Setup
- Guidelines for Submitting a Pull Request
- HTML Styleguide
- CSS Styleguide
- Javascript Styleguide
- Python Styleguide
- Testing Guide
Project Architecture