CoP Call Agenda

IBIS-PH is website software that allows public health practitioners access to publicly-owned health data. The IBIS-PH Community of Practice (CoP) is the stakeholder group for the software. Monthly CoP conference calls allow CoP members to communicate with each other and the IBIS-PH contractors who provide software development and support.


Monday, June 18, 2018 - 3:00 to 5:00 EST (1:00 to 3:00 PM MST) UT Hosting.

Dial-in: (‪US‬) ‪+1 (786) 535-3211‬ - Meeting ID/Access Code: 'Code: 460-460-541#‬'

Update Change to Google Meet

Hangouts Meet


  1. Review agenda and add items as needed...
  2. Updates
    1. Training Videos Status Update
      • Adding an area labels layer to your map, editing GeoJSON in QGIS (Chris Wenker)
      • Modifying an IBIS map definition - choropleth groups and colors, adding new map definitions (Lois Haggard, Paul Leo)
      • Creating Dynamic Grouping Variables for an IBIS Query (Tong Zheng)
      • Wiki Formatting - When, Where and How It's Used in IBIS-View (Kim Neerings)
      • The Subversion (SVN) file repository - basics (Lois Haggard, Paul Leo)
    2. IBISQ Testing (Lois, Paul, Tong)
  3. Discuss Tableau. Lois and Paul attended a 1 day presentation (Lois/Paul?).
    • Intro - what is it? Data visualization tool - for making charts, maps and dashboard web pages.
    • Likes? - Powerful data interface - e.g., can read a SAS datset, Excel, RDB, etc.
    • Dislikes? -
      • Weak mechanisms for public health context.
      • Data must be clean coming in. They do provide some data cleaning utilities/tools.
      • Costs could get up there if you want several users and a server license.
      • Online version, most public health departments would be wary because of need to house data in the cloud. But the data could be aggregated first, as with IBIS admin type data.
    • Capabilities? -
      • Charts, maps, and combinations of charts and maps for dashboards.
      • Strength: Can build data views on top of a transactional database or data warehouse - the dashboard updates automatically.
      • One thing that interested me was a feature where I would get an email alert if a measure exceeded a certain value.
      • Can build in user interactivity such as filters.
    • Impressions? - Some nice features. Flexible for designing charts, colors, dashboard layout.
    • Cost?
    • Vision - how might it fit/integrate? Good question. We could use it to build views of data in Admin DB. ??
  4. Quick note: kendo_charts.xml file for changing graph styles and colors. (Lois)
  5. Discuss *NEW* NJ way of managing content (Paul/Garth?):
    • Public facing View app that the IT group controls and locks down.
    • Private DOH app server that sits behind a firewall and that the public facing view app gets the content from.
      • Contains all static content like PDFs, images, docs etc.
      • Contains all the XML content needed by the view app (HTML_CONTENT, Indicators, Query Modules).
      • Hosts the Admin app.
      • Hosts the Development Content View app.
    • Private DOH web server that sits behind a firewall and that the public facing view app can make IBIS-Q/SAS query requests to.
    • The content will have at least 2 main content directories: 1) Development 2) Production
    • The Admin app will publish indicator XML to the "Development" content area.
    • Users will develop and test other content in the "Development" content area.
    • Once "Development" content is tested, that content is committed to a repository and the "Production" content is updated from there.
    • Using the repository makes sure everything is versioned and logged. It also makes it possible to have a QA process (that most IT shops implement) injected in the middle.
    • This approach has a number of advantages with only a few disadvantages:
      • + Public facing view app doesn't need to be touched much.
      • + Easier to deal with IT
      • + Easier to manage content - no problematic copying files around.
      • + Follows a proven development, test, then to the public content process.
      • - More complex to setup - more app servers, firewall holes (which is needed for IBIS-Q anyway)
      • - Slower as files must be served up over a network and not directly from a local hard drive.
    • Thoughts? Let's discuss/think about the different environments - windows, linux, IT concerns, which repository, which tools, do we build the repo content management into the admin app?, do we need the admin app to have the "approved" step - probably not, etc.
    • A graphic would be nice to show the parts. Anyone want to fund a day to create a graphic?
  6. Admin app status and quick demo (Garth). Some items might include:
    • Minor formatting updates - selected row, tab colors, responsive
    • Better input validation
    • Help popups
    • Review Datasets vs Views. Lois can provide her perspective to current IBISPH-Admin adopters on what this is about and how it works?
    • Review new way of handling DATA_NOTES, DATA_ISSUES, DEFINITION, and NARRATIVES.
    • Review help popup capabilities - describe the possible content that can be placed within help. The help popup should match the training docs (and the training doc should be provided as a link) (Lois, Maria, and Kim are currently working this effort so it would be good to hear from them).
    • Review the rules to build the IP, IPV, chart/map titles. Titling is needed for: selection of the indicator, selection of the view, each indicator report page's "Section" title, and each map/chart visualization title. The main pieces are TITLE, CONCISE_TITLE, MEASURE, and the dimensions.
    • Review site navigation order and organization.
    • Review all list page fields.
    • Review all detail page field ordering, size, hints, help, and general organization.
  7. The agenda has had a "set a detailed walk through meeting" for months now. This can still be done but a potentially better approach is:
    • Use the public NM test server to actually run the app for usage (and help test for bugs).
    • Use Lois's usage/work guide to step through the process.
    • Keep track of the issues and questions.
    • Have a follow up training where issues and questions can be addressed.
  8. Setup a view app meeting to discuss what really is needed/wanted/effective. Some discussion points could include:
    • Discuss latest usability updates. This includes:
      • Really wide text blocks that are unnatural/hard to read.
      • Left context navigation menu effectiveness.
      • Keeping menu items as short and concise as possible while still communicating something meaningful. If a menu item is not clear then help popups can be applied to explain the action/option.
      • Navigation level depths need to be balanced between flat and too many options. To deep and users get lost on where they are. To flat and it is disorganized and to much for the eye to easily pickup.
      • Site navigation and general usage is about expected behavior and recognition - not recall and reading.
      • MUST have meaningful, logical, consistent structure.
    • Define the user base and each major user group's needs.
    • What current features are useful/most used?
    • What current features are required?
    • What operations take the most time/what are the biggest time consumers for an adopter?
    • Think through what is really needed/wanted/useful for data dissemination. Trending, comparisons, indicator reports, topics.
    • Logical organization/effective site navigation (3 click rule and users getting lost if more than that v.s. everything driven through topics).
    • Does it make sense to drive everything through topics? Does our current topics, indicators, community (or should it be comparison), dataset query organization make sense to us and the users?
    • Discuss interactive v.s. static type pages and how users navigate/are driven to the various data pages. Example consider the current topics, indicators, community (or should it be comparison), and dataset queries organization. We have topics, indicators, and potentially basic comparisons that are static e.g. the user doesn't have to "build" a definition to get somewhere - they simply select from a list and/or an index (BTW, this allows for search engines to index the pages and allows for pages to be quickly and easily shared). We also have dataset queries which are totally interactive. The current future versions of comparisons and indicators can be interactive and could have a blurred line without clear separation.
    • For the above how integrated? When does the line blur? Should it blur?
    • Think through "how" interactive for dashboards, current data pages, and future data discovery features - e.g. how to navigate to and are there options on the report pages?
    • Are what we call "reports" really more like what others call a story? Should each topic really be more like a story?
    • Long pages vs short multiple pages.
    • Large vs small charts and maps. Most data sites do not have large choropleth maps or large charts - they're smaller and more basic. We've have feedback that charts intimidate some users so maybe smaller charts are just as effective and for those users that want to include a data chart in a presentation they simply export the data and create their own chart in Excel. Smaller charts and maps also help content to be contained within blocks that flow on the page better. For large monitors our text fields are really wide and not easily read. Blocks scale much better between different screen sizes.
    • How much text is really needed and required and should it be front and center or should it be more optional?
    • Titles - how to effectively title blocks. Can we/should we rely on proper page titles? Is it even possible to to make portions of a page immune to potentially being taken out of context.
    • Should we consider removing intro, contents and usage, and other similar pages to simplify and streamline? Or keep them since they're already created and "can" provide value if kept up to date (plus it keeps consistent)?
    • Left nav needs to house Kendo table filtering options, chart control options, period constant selections, map control options etc.
    • Mega menu selections need to be obvious that they are items/links. Applies to all selection lists and any generic link.




  • When you submit a ticket, leave the Milestone=Unassigned and Version=Unknown and the ticket will come up on ticket report number 1 New Tickets for CoP Review
  • If you have new or open tickets please review them and be prepared to discuss them on the CoP call. You can run the {1} New Tickets for CoP Review report to see current tickets. The purposes of discussing tickets are to a) communicate an idea to the community, and b) to identify and track IBIS-PH software issues. (Note that once a ticket has been marked to be worked then that ticket is only discussed on the CoP call for the purpose of moving the effort forward.)
Last modified 38 hours ago Last modified on 06/18/18 13:14:34