Page Comparison

Participation

Support:

The meeting is scheduled at 2019-09-29 3:00 pm - 5:00 pm CT. Hilton Austin Hotel, Room 408

Agenda/Meeting Minutes:

1. Terms of the Ed-Fi Community Intellectual Property Disclosure Policy 
   1. Intellectual Property Slides
2. Tech Evaluation Overview: Technology Landscape, what is available now
3. Ed-Fi Dashboard Overview: Pros and Cons
4. Roadmap goals
5. Questions
6. Next Steps

...

1. Ed-Fi Intellectual property community guidelines reminder.
2. Charter goals and updates - Slide 4 Phase I main goal or identifying priority use cases is now complete and can be viewed Use Cases Selection
   1. User Experience workgroup is working through user personas and functionality for the initial Student Discipline Use case.
   2. Evaluation of existing visualizations and Ed-Fi Dashboards is captured at a high level in the presentation. More detail available under the Technology Subgroup and the Ed-Fi Evaluation Subgroup links on presentation.
3. Technology Landscape - Slide 6 - 8
   1. More options available, with a focus on the separation of backend data management/concerns and UI visualizations as more independent of each other. Open source tooling, Off the shelf, and software as a service option.
4. Ed-Fi Dashboard - Slide 10 -11
   1. UI consistent since its inception in 2012, main updates to app architecture to make it more extensible and configurable.
   2. Costly to Implement & Maintain: Noted by the group that this is not necessarily unique to Ed-Fi Dashboards but a reality of another tooling as well.
   3. RVWG 2019-09-29 Meeting Agenda from INsite shared their journey to Ed-Fi ODS implementation + Dashboards:
      1. Took about 18 months
      2. Cost of ~ 900k.
      3. Had they had more in-depth knowledge of the data model, they could have saved some time, maybe 6 months. 
      4. The application follows complex patterns, but once you understand them it is easy to extend and maintain. In their case, it was harder to find resources with experience in known BI tools, but they had access to developers that can help customize and maintain.
   4. UI is non-responsive so newer monitors show a lot of blank wasted space. Not really usable in mobile devices
      1. Estimating ~ 250k to make UI responsive but no in-depth estimates have been gathered.

      2. ADA compliance is a challenge, there was an investment in v1.2 (2013) to address this but requirements change state to state with some being very restrictive. RVWG 2019-09-29 Meeting Agendashared that Kentucky has strict codes and as-is dashboards are not compliant. Group agreed that attempting to cover all possible requirements it's very complex but there is a need to keep in mind that visualization tools need to at least get implementations most of the way there.  

         Expand
         title ADA Compliance additional notes. Click to Expand...
         Image AddedImage Added For our on-going discussion… Here’s one of several high-level summaries of what WCAG 2.0 specifies. This is clearer than how I tried to explain it in our session. Ed-Fi couldn’t “adopt WCAG 2.0” because the Dashboards couldn’t comply with all of the guidelines. If “most governments target Level AA,” then there are those that desire more. However, Level AA might be a reasonable one for Ed-Fi to adopt. Then, as the discussion pointed out, local implementations could enhance as required. The same is generally true for other standards, which have levels of their own, and requirements that don’t apply directly to the Ed-Fi solution. https://www.wuhcag.com/web-content-accessibility-guidelines/ WCAG 2.0 levels The Web Content Accessibility Guidelines 2.0 are organised into three levels of conformance: Level A – the most basic web accessibility features Level AA – deals with the biggest and most common barriers for disabled users Level AAA – the highest (and most complex) level of web accessibility For most websites, Level AA plus some Level AAA is the best target. That’s because some of the highest level guidelines simply can’t be applied to all websites. However, one of the problems with the three-tier structure is that if people know they can’t attain AAA, they won’t even look through the guidelines to see where they can improve accessibility. With all of your projects, you should comply with all the guidelines you can, whether you want Level AAA or not. Starting with Level A is a great way to make progress and begin helping out your users. Level AA is the standard many governments are using as a benchmark as this level targets the most common and most problematic issues for web users. Billy Buchanan: I think AA is the bare minimum that would be needed.  Some of the standards in WCAG aren’t directly relevant to the dashboard work (e.g., including transcripts of audio/video in alt attributes for screen readers, etc...).  I think AA also sounds like a reasonable target level given that some of the issues (e.g., color contrast ratios) do not have a level A conformance standard; this may have changed since the last time I looked at things, but from what I remember there were only standards for AA and AAA for color contrast ratios. If our goal is to enable all educators to leverage data assets to inform decision making processes I think we need to make sure that any technology put forward enables all educators to do that.  If some organizations are using the dashboards to involve students/parents in discussions I think ensuring that some minimal level of accessibility is satisfied aligns fairly well with that goal.

         
         

5. Goals for the Group - Slide 13
   1. Noted that there is a need to support those that find value in Ed-Fi Dashboards in a way that moves the community forward and makes the best use of the limited resources of the Ed-Fi Alliance.
   2. A middle reporting layer makes sense and seems to offer a way to obtain stability overtime.
   3. FL Code shared a bit of their experience with a core Ed-Fi Dashboard implementation and a move to newer visualization tools:
      1. Initial implementation like Rosh shared was painful and expensive, eventually, the technology caught up to us and what we wanted to do was just easier to achieve with newer technology.
      2. ODS updates are a concern, so this middle layer starts to make sense. Implementations are doing some iteration of this but it would be nice to see a common layer that can cut that getting started time so you can get to the other issues that will come up.
6. After the discussion, attendees were asked to submit notes and comments to be shared with the group on what they think about the ideas and challenges discussed.

...