slc dashboard presentation-boston_sep2012

Contains Company Confidential Material – Do Not Disclose

Educator Dashboard 101

Presenter: Takashi OsakoPrepared by: David Wu and Sivan Hermon

September 29, 2012Cambridge, MA


• Goals for this presentation• Introduction• High-level Architecture• Visualizing Data• Advanced Topics

o Working with the SLC APIo Configuration

Agenda


• Understanding why Dashboard was built• Give overview of Dashboard functionality

and architecture• Provide information for developers to find

their way around the code

Goals


Dashboard Introduction

What is the Dashboard?


• A highly-configurable reporting and visualization tool for students' data, provided by the SLC

• A web application• A "reference" client application for the

SLC platform

What is the Dashboard?


Allows educators to see information about their students individually or by class, school, and other organizational levels.



Allows staff (principals, IT admins, etc) to see and configure information about education organizations, schools, and students



Why is Dashboard a powerful tool for teachers?• Education technology is behind the rest of the tech

world• Data is often spread across different applications• Allows education leaders to create holistic views of

student data, for instructional purposes• Allows cross-correlations between different student

data (test scores, grades, attendance)



How is Dashboard configurable?• Dashboard pages are configurable by individual

states and districts• Waterfall logic - Districts can override state-level

configurations• Real-time - changes are immediately viewable



Profiles •Student, School, Teacher, Section, Ed-Org•Used for navigation and displaying information•Multiple pages in a profile•Multiple panels in a page

Dashboard Builder•IT admins can modify and configure content of profiles

Student Search

Dashboard Introduction - Main Modules


Live Demo


Dashboard Architecture

Architectural Overview


Drivers, Key Concepts•Robustness•Tested, reliable technologies•Familiar languages•Approachable, understandable to developers•Modularity, separation of layers•Performance•Ease of build and deploy•Cross-platform compatibility



Dashboard Technology

• Java• Spring / Spring Modules

o Robust, widely-used web app framework• FreeMarker

o Template for HTML generationo Lean, fast

o Maven



• jQuery/jQuery UI• jqGrid

o Base for client-side gridso Easy data binding and customization

• Bootstrap• Raphael• Angular.js

o MVC framework, with templating, 2-way data binding (model <-> view)

o Non-prescriptive - plays nicely with other frameworks and application code



Testing Tools•JUnit•QUnit•Cucumber•Selenium


How does Dashboard retrieve API data?•Controllers

o Handles incoming requests, calls Managers•Layout Assembly•Managers

o Use API Client to retrieve data, perform biz logic (e.g. filtering, aggregation, formatting)

•API Cliento Uses the SLC SDK for Java to communicate with API

Dashboard Architecture - Java Modules


Dashboard Visualization - Student Profile

Page (Tab)

Panel

Page (Tab)

Panel


Dashboard Visualization - Section Profile

Grid


Dashboard Visualization - Section Profile

Fuel Gauge Widget Tear Drop Widget Colored Text


Examples


{id : "attendanceHist", type : "GRID", name : "Attendance History", data :{

entity: "studentAttendance",alias: "studentAttendance",

}, root: 'attendance', items : [

{id: "col0", name: "Month", type:"FIELD", datatype: "string", field: "eventDate", width: 90},{id: "col1", name: "Attendance Rate %", type:"FIELD", datatype: "string", field: "attendanceRate", width: 100, formatter:

PercentCompleteFormatter, params:{low:91}},{id: "col1", name: "Attendance Rate", type:"FIELD", datatype: "string", field: "attendanceRate", width: 100, formatter:

PercentBarFormatter, params:{low:85, medium:92}},{id: "col2", name: "Absence Exc", type:"FIELD", datatype: "string", field: "excusedAbsenceCount", width: 70}] }


On the client side, Javascript is used extensively for visualization •Code is modularized in a similar way to server-side Java code•Separate .js files for panels, visual widgets, utils•Started using AngularJs for an MVC framework

Dashboard Visualization


Dashboard Advanced Topics


Working with the SLI API


Dashboard Advanced Topics

There can be more than one method of obtaining the same set of data.

Different methods will have different performance and complexity•Number of API calls•Network overhead•Code complexity


Best Practices

Make batch calls as much as possible•Use multi-level API calls

• e.g. students/<student_id>/studentSectionAssociations/sections

•Query for multiple entities at once, instead of one at a time


Example 1 - Students in a Section



Our initial implementation•Get info for the section

o /sections/<sectionId>•Get students in the section

o /sections/<sectionId>/studentSectionAssociations•For each student, get attendance data

o /students/<studentId>/attendances•For each student, get assessment data

o /students/<studentId>/studentAssessments•For each assessment, get cut points, meta data

o /assessments/<assessmentId>•For each student, get current grades

o /students/<studentId>/courseTranscripts



How we refactored it•Make a single 4-part URI call with optional view parameters

o /sections/<sectionId>/studentSectionAssociations/students?views=assessments,attendances,transcript

The difference?•Hundreds of API calls vs. a single API call•Reduced network overhead (improved performance)


Best Practices

Make focused API calls for the data you want•Instead of calling /students to get all students...•Let the user choose the section they're interested in first...•Then call the API for the students in that section

Take into account UX design and page load requirements•What needs to be shown at initial page load?•What can be shown after the page is displayed?


Example 2 - Population Widget



Initial implementation•Get all schools accessible to user

o /schools•Get parent ed-orgs of the schools

o /educationOrganizations/<id>•Get all sections accessible to user

o /sections•Get courses that match sections

o /courses/<id1,id2,...>

In Java, programmatically create a hierarchical JSON structure to pass to the front-end



Issues we ran into•For state-level users, there can be hundreds of schools, thousands of courses and sections. Performance issues loading it all up-front.•Using /courses/<id1,id2,...> notation with many ids runs into URL length limit in some web servers



Refactored implementation:Before page load,•Get schools accessible to user

o /schools•Get parent ed-orgs

o /educationOrganizations/<id>



Refactored implementation (cont.):When user selects an ed-org and school,•For school-level users

o /sectionso /courseso Match programmatically

•For state- and district-level userso /schools/<schoolId>/sectionso /courseso Match programmatically


Best Practices

• Use a REST client for ad-hoc API calls. Handy for debugging and testing.

• Know your query parameters - includeFields, excludeFields, views, offset, limit, sortBy, sortOrder, field-specific value matching

• Caching – use it if you need it• ehcache


• https://github.com/slcedu/dashboard

Open Source


What's on your mind?

Q & A