Opened 13 years ago
Last modified 7 years ago
#77 new Enhancement
Include only community, state and U.S. on CHH graph
Reported by: | Lois Haggard | Owned by: | |
---|---|---|---|
Priority: | Unknown | Milestone: | 3.0 - Feature Set Definition |
Component: | View-App | Version: | 3.0 |
Severity: | Unknown | Keywords: | Community, highlights |
Cc: | kneerings@… |
Description (last modified by )
As I am looking at the new Community Health Highlights (CHH) reports and I am not liking the ranking of the graph bars by indicator value. (Especially when I look at it by race and ethnicity.) Originally, we had hoped to highlight the community bar and anchor the NM and US bars at the top or bottom of the graph (see attached Graphtn.jpg). But we didn't have $$ for so many bells and whistles, and got a graph with sorted values, but no highlighted bars, etc. (see attached Graph2.png).
In light of those limitations, I think it would be better to sort by alpha (the category sort order). This would get us away from the "ranking" mentality. Plus, the dashboard gauge is depicting the community comparison to the state. It has nothing to do with the community ranking in the graph.
Ideally, it would be great to allow states to choose among the following options for each community report, 1) sorted by indicator value, 2) sorted by category sort order, or 3) include only the index community, the state and the U.S. values. For instance, for my county reports, my health councils want to see all counties. But for my tribal reports, I will be able to include the index tribe, and the state and U.S. comparison values only. (We cannot display all the tribes in the graph - tribal health information can not be released to other tribes.) This way, we could put the tribal report under the secure login and they would not see anyone else's values on their report.
This doesn't solve the problem of the tribal view that will be necessary on the indicator profile main report (unless we can put that indicator.view URL under secure login) - but it gets us closer.
Attachments (2)
Change History (16)
comment:1 Changed 13 years ago by
Owner: | changed from utah to Garth |
---|
comment:2 Changed 13 years ago by
Description: | modified (diff) |
---|
Changed 13 years ago by
Attachment: | Graphtn.jpg added |
---|
comment:3 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Garth to Sam, NM |
comment:4 Changed 12 years ago by
Milestone: | IBIS-PH View2 → Ideas for Version 2 Enhancements That Are Not on the Current ToDo List |
---|
comment:5 Changed 12 years ago by
Owner: | changed from Sam, NM to Garth |
---|
comment:6 Changed 12 years ago by
Owner: | changed from Garth to Java Developer |
---|
Analysis and design are needed. In all likelyhood the solution will involve new UI and backend Java code as well as some XML changes. Not difficult but it won't be a quick feature to implement.
comment:8 Changed 11 years ago by
Milestone: | → Unassigned |
---|---|
Owner: | changed from Java Developer to unassigned |
Severity: | → Unknown |
Version: | 2.0 → Unknown |
comment:9 Changed 11 years ago by
Cc: | kneerings@… added |
---|
comment:10 Changed 11 years ago by
Keywords: | Community added |
---|
comment:11 Changed 11 years ago by
Priority: | -Low → Unknown |
---|
comment:12 Changed 11 years ago by
Keywords: | highlights added |
---|
comment:13 Changed 9 years ago by
Might need a new charting package to get different colors for key values. This would involve allot of time to ID a suitable package that could do this as well as the other features that are required. One way is to kludge a solution using the agilblox charts by using several series to handle the different coloring.
For the small table that Lois described in a fall 2013 email the data table is built using the comparative values XML? To do a histo like this involves a new java controller/data service and possibly new XML structs or at least interfacing with the CP XML compare values structs.
For either If we're going to spend the time to do this it would be best to do the analysis and find the new charting package that supports json and client side charting. We could then hook it up to the table and have those values populated that way. We're going to be doing this at some point.
If the current charting package solution is going to be used almost all of this code will be throw away code when moving to a new charting package or new IP dataset structure. It seems crazy but there's allot of work to ID and hook in a new package - like a month or two and possibly more - if you get into it and found limitations the package can't deal with.
Securing an IP with row level security is yet another issue that will not be trivial.
comment:14 Changed 7 years ago by
Milestone: | Unassigned → 3.0 - Feature Set Definition |
---|---|
Version: | Unknown → 3.0 |
Something we want to address in 3.0
We could allow users to choose which additional communities or views to include.
Graph style we wanted.