wiki:CoPCallAgenda

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.


CONFERENCE CALL

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

Dial-in: +1 (571) - Meeting ID/Access Code:

Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/ First GoToMeeting?? Let's do a quick system check: https://link.gotomeeting.com/system-check


AGENDA ITEMS

  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. Setup an admin app detailed walk through meeting. This is a good time to learn about the new app and to help scrutinize all the pages for usefulness, formatting, help text etc. Some issues to discuss:
    • Review all the different places DATA_NOTES and DATA_ISSUES are defined. How/when should each be used? When does one override the other? Would it be better to call them different names? If associated with a chart or map does it make more sense to have those notes/issues included in the CHART/MAP_NARRATIVE?
    • Define the rules to build the IP, IPV, chart/map titles.
    • Need to decide which admin app fields need help popups (and what that help text should be).
    • Need to decide which fields can/should have mouse over help if not a popup (and what that text should be).
    • Order of all fields, is the amount of space allowed approp?
  4. 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)?

STANDING AGENDA ITEMS

IF TIME & INTEREST or FUTURE AGENDA ITEMS


ALL COP MEMBERS: PLEASE BE PREPARED TO DISCUSS YOUR TICKETS.

  • 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 4 days ago Last modified on 04/19/18 16:31:43