wiki:designGoals

Version 3.x Constraints and Design Goals

ABOUT IBIS-PH V3: Sustainable system that can meet 80% of the basic needs for next 3-5 years (2020) on limited resources. IBIS-PH has never been about data warehouses, business intelligence, big data - it is and always will be about presenting the basic, simple data with the fewest resources. v3 is NOT adding any breakthrough capabilities. It is simply an enhanced (more options) potentially more manageable (easier configuration and definitions) version of what is already available with the current 2.3 version.

See: Dilbert "Hodgepodge of Complexity" and Too many Features

See the Backend Design and UI Design for current development notes. The Development Schedule has the best guestamates and rough work breakdowns for projected development timelines.

Givens

  • IBIS is indicator based with content being Health Indicator Centric. From the beginning and going forward, the IBIS the apps have been "Health Indicators". IBIS should not be viewed or used as a general DOH data portal or an umbrella for all data - it should only be used for Health Indicators.
  • Indicator datasets are either static profiles or dynamic queryable SAS datasets.
  • IBIS Health Topics are an umbrella over health indicators.
  • Community reports are really comparison reports and are 100% based on indicator profile type datasets.
  • In some future release the query datasets and profile datasets *might* be integrated to be discoverable and comparable. However, in light of limited development resources this is not something that is a high priority.

Main General New Features

  • Trending. All datasets will have an associated period dimension. This will allow all data views to be trendable. What this means is that for any given view that does not have a series or category that is a period, those charts and/or maps will be able to be stepped through by period or could hold a series/category static and chart the dataset by period. Periods also provides better/more accurate data comparisons.
  • Data Discovery (ability to find reports and datasets by user selected dataset characteristics. There could be several interfaces like a builder page or a less intimidating wizard that walks a user through the process of locating the data and/or indicator reports. For example a users want to locate all datasets or indicator reports that contain their county or ethnicity etc. Some uses want to see all datasets that have a given datasource. Some users will want to locate datasets/reports based on a type of measure (for example I want to see everything that deals with an Age Adjusted Rate for every 10,000 people in the population).
  • Comparisons. Community reports are all about comparisons. The reports are currently crudely implemented and have fragile indicator profile dependencies. The configurations are difficult to maintain and do not allow the end user to define their own selections to be compared. The new v3.0 structure lessens the fragility and provides the user the ability to leverage data discovery to create their own comparison dataset that can be charted and/or mapped. They will then have the ability to save that definition and share it with others like is done with the saved query. This is one way that a system admin could actually use the app to build their community reports.
  • Multiple Target Values. Need to have the ability to have multiple target values displayed on charts.
  • Demographic Data. Community report pages need to show their demographic data. This data will be in the form of a regular health indicator dataset so it will have a period and can be trended via charts and map views.
  • Advanced Visualizations. This includes interactive integrated map, chart, data table dashboards. Heat map layers over the standard choropleth layers are also needed that will allow multiple dataset values to be displayed on a map.
  • User defined set of indicator reports and ability to save a report definition and then share with others or post on social media. This is similar to comparisons except that it allows a user to produce their own community profile indicator report and share it.
  • Better Topic, Indicator Report, Query Integration. Need to have links in each type of associated data being presented. For example an indicator report have links to the topic(s) it is associated with as well as any queryable datasets or saved queries. Likewise the query module needs to have links to an associated indicator profile report(s) and topic(s).

Major New Characteristics

  • Common IP and QM data storage structure that provides cleaner, enhanced/more capable trending and comparisons.
  • Tighter IP dataset, topic/metadata, and query result integration (related linking).
  • Cleaned up numeric data with new structures for control (no special characters which require kludged code and processing rules).
  • Community demographic data which can be used for display, comparisons, and selections.
  • Enhanced charting and mapping trending options. Can animate or allow users to "fix" a dimension when charting or mapping.
  • Provide data discovery where a user can find datasets based on demographic peers or dimensions.
  • Data exchange, consumption, and update integration with QMs and outside data providers like CDC's EPHT data API.
  • More user "saved" definitions. This can include set reports, community comparison definitions etc.
  • Multiple adopter defined targets which can be used in comparisons (goal but not high priority).
  • Integrate with social media and provide sharing options.
  • Use of social media to be the new RSS.

Continued Efforts

  • Improved usability - simpler, more meaningful, and less confusing UI.
  • Enhanced/integrated mapping, data tables, and graphics.
  • Maps enhancements like Hi/Low/Same?, tighter layer label control.
  • Maps need to provide other adopter created layer options - like a custom layer that shows population density that is not associated with a standard geo area etc.
  • Support for all modern user devices (smart phone - high resolution desktop).
  • Keep main feature navigation within 3 pages/3 clicks
  • Keep pages easily book markable
  • Keep pages easily printed
  • Keep system as clean, consistent, and open source based as possible
  • Keep pages easily searchable and indexable to web crawlers

Other

  • Smaller, quicker feature set development cycles.
  • v3.0 needs to provide current 2.3 functionality and maps - e.g. no loss of security, CP, PHOM reports etc.
  • Work for both admin and view app must be completed within the current funding (appears to be 2.5 years starting 1/2015).
  • Least impact to indicator profile/dataset admin editors.
  • At least one site fully implemented/converted with basic docs (videos) and training for support so that all adopters can adopt as wanted/needed.
  • Better testing. Need to start the creation of a test sets that test all the apps features and special considerations (e.g. bug tests).
  • Easier, more consistent content management and publishing (goal but not near term).

Misc

  • Keeping updated with the ever changing website attack safeguards.
  • Keeping updated with the ever changing OS, app server, dependent library version changes.
Last modified 19 months ago Last modified on 12/15/17 00:01:17