Shoreline: Kickoff Meeting (January 29, 2020)

Shoreline is a geospatial materials platform based on GeoBlacklight, and is named after the Southern Pacific train that ran between Los Angeles and San Francisco from 1927 until 1931.

What has happened up to now?

In Fall 2019, the Shoreline team prepared for the product’s first development cycle (which is scheduled for February-March 2020).  During Shoreline Sprints 1 through 7, the team leveraged previous development work at UCSB to lay the technical groundwork and determined which features we would like for the product. The accomplishments are outlined below.

Technology Preparation

A few years ago, UCSB began preliminary development of a geospatial materials platform based on GeoBlacklight.  While the platform never became operational, the code was a good starting point for future development.  The Shoreline team moved the code into the Surfliner framework so that it could be developed and deployed among all participating campuses.  While this task was successful, the product was still far from being operational.  No local materials could be ingested into the platform.

Requirements Gathering

Simultaneously, the Shoreline team determined what a minimum viable product (MVP) would look like; in other words, what features should be included in a basic interface in order for it to be in production and shared with the public?  After performing a literature review, the team drew up a list of 117 possible features.  The team then evaluated seven existing GeoBlacklight interfaces at academic institutions and identified which of those features were already present in at least one other interface.  An additional 17 features were found on those interfaces and added to the list.  The team also identified which features the interfaces executed very well.

Determining the MVP

Once the code was stable within the Surfliner framework, the team then used the feature list to perform a gap analysis of the Shoreline platform as it stands.  Specifically, we identified which features the platform already has and which features it is missing, as well as what existing features are done better by other institutions.  For those features missing from the Shoreline platform, the team assigned them a value (must have, should have, nice to have, doesn’t need) with respect to an initial release of the interface, thus determining which features would be included in an MVP, especially those features that the Shoreline platform absolutely must have before its first public release.

Key takeaways from the initial work

• All features identified for the MVP are already included in at least one existing GeoBlacklight instance.
• Several features identified in the literature review are not currently included in any institution we reviewed; all of these were determined to be unnecessary for the Shoreline platform at this point.
• Once the Shoreline platform can ingest local materials, additional existing GeoBlacklight functionality may be enabled, thus activating features currently identified as missing from the interface.  

Where do we go from here?

During the upcoming workcycle, developers will work on implementing the features identified for the MVP.  At the very least, once the “must haves” have been implemented, an initial release of Shoreline can take place, but hopefully additional “should have” and “nice to have” features can be implemented.  When the MVP is ready, there  will be one central code base and two instances, one at UCSB and one at UCSD.

Following release of the MVP, work will continue in the future to add new features and improve the interface through incremental releases.