wiki:developmentSchedule

See: Dilbert's "Delivery Schedule", and Never Enough Funding:)

This page provides insight into the planned versions. This includes a rough work break down for that version's goals with an estimated completion date. Please see the Support Schedule page for information about adopter support.

Version 3.0 - new dataset structure

3rd Round of Testing, full NM data migration to production: End of 2019?

Version 3 does not provide any major features. This is an admin backend data release and basic view app conversion to the new structure and latest dependent libraries. The schedule aligns with NM availability which will provide the time needed to go through and scrutinize all page types, polish the user interface, and perform the data migration from 2.3 to the new data structure. See 3.0 Design Goals for information about what version 3.0 is trying to accomplish (See Current Design Thoughts for current ideas).

Breakdown Once NM End User Testing Begins:

  • 1w - Walk through all major page types. This includes analyzing web statistics, cost to maintain, information that can be better communicated, user interface, page layouts etc.
  • 4w - Implement UI findings.
  • 1w - Final round of SQL script and data mods
  • 4w - Query system updates for integrated indicator and query result data structure. This effort includes data sources and general cleanup. It will likely include minor Java, kendo and leaflet tweaks as needed.
  • 1w - Final Admin App UI updates. This includes a scrutinization session.
  • 1w - View app IP updates
  • 1w - View app CP updates
  • 1w - Test and clean up UI, CSS, XSLT code (hardening).
  • 1w - Working with Lois and Paul help/implementing nm

==> 17 weeks ==> 5 months with time off and adopter support.

Future Versions ?

  • Trending and user defined comparisons
  • Ability to edit and save user defined dataset comparisons along with improved saved data queries UX/UI etc.
  • Better searching. The current search uses Google and presents a list of pages that it thinks is most applicable to the search criteria. The google result page is hosted by google which causes the user to leave the IBIS site. It also does not provide any filtering or other discovery type options that would be available with a custom search engine. For example a user might want to find a query dataset that has the CDC as its datasource with demographic dimensions.
  • Clean up the query modules. Many query modules contain hard to maintain configurations. Newer techniques are available to allow sharing and conditional importing of xml files. This effort will be started with core v3.
  • IBISQ to IP dataset Integration. This includes referencing a dataset query and displaying the result data alongside/with related indicator dataset data. This also includes importing of query data into an indicator dataset.
  • Do in depth analysis to determine if there are better techniques and processes to present rolled up record level data. This could include putting data into a relational database, processing with "R" , and utilizing R's web API to query data.
  • Update the IBIS query builder interface from "steps" to a "walk the user through" wizard type interface. New interface would handle dependencies dynamically.
  • Merge the query builder and results interface (especially considering query data analysis and possibility of using "R").
  • Replace the admin app with a modern front end. This would use current technology which would provide better data validation, deletion capabilities, consistent editing and publishing of all content including query modules, html content, indicator datasets, etc. This could also be implemented by doing away with the admin app and creating an "edit" feature within the view app that allows inline editing and management of content.
  • Better, more integrated content management and publishing (see above).
  • Data interfaces with external sites. This includes pushing IBIS data to other apps like Socrata as well as query interface with allows users to retrieve and display outside data inside their IBIS site (CDC api etc).
  • More mapping options with Chloropleths, weighted heat maps, and other thematic maps. This could also include multiple simpler, smaller, lighter maps as well as integration with ESRI mapping etc.
  • Advanced Visualization dashboards. This could include:
    • Integrated data table/chart/maps (similar current interactive indicator views but with inclusion of the mapping and other display control options like playing a slider or walking a chart/map through a set of years).
    • Health topic or indicator story boards,
    • Side by side comparisons,
    • Inclusion of various datasets,
    • Demographic widgets.
  • Ongoing software security patches and dependency updates
  • User experience updates. Navigation, responsive layouts, more white space with appropriate graphics etc.
  • State UI and ADA standards updates
  • Better utilization of social media to help drive usage and users to the site
  • Migration of the view app to use current industry UI/UX standards. This includes using standard css frameworks and other libraries/tools).
  • Training
  • Documentation and hand off
Last modified 2 weeks ago Last modified on 02/01/19 20:04:08