Expanded story: Data dashboards - Revision history

Jeddcohen at 22:41, 10 June 2016

2016-06-10T22:41:31Z

← Older revision		Revision as of 22:41, 10 June 2016
Line 1:		Line 1:
	''Written by Mica Pollock, Jedd Cohen~~, and Josh Wairi~~ for the dashboard project, with initial dashboard development by local technologist Seth Woodworth and next development for piloting by David Lord of San Diego.		''Written by Mica Pollock and Jedd Cohen for the dashboard project, with initial dashboard development by local technologist Seth Woodworth and next development for piloting by David Lord of San Diego.

	Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.		Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.
Line 52:		Line 52:
	'''Turning point: The Teacher View		'''Turning point: The Teacher View

	Josh ~~Wairi~~, a 5th grade teacher at the Healey, got interested in the dashboard design when we stopped by his classroom one day after school in the winter of 2011. Looking together at his computer and printouts, we realized he was already creating spreadsheets of student data from X2 by hand. He was interested in quickly displaying and sorting basic data, to supplement his face-to-face and phone conversations with students and parents. His work showed us the need for what would become the “Teacher View,” a version of the Administrator View in which all the students come from the same homeroom.		Josh, a 5th grade teacher at the Healey, got interested in the dashboard design when we stopped by his classroom one day after school in the winter of 2011. Looking together at his computer and printouts, we realized he was already creating spreadsheets of student data from X2 by hand. He was interested in quickly displaying and sorting basic data, to supplement his face-to-face and phone conversations with students and parents. His work showed us the need for what would become the “Teacher View,” a version of the Administrator View in which all the students come from the same homeroom.

	Between this stage and the latest version of the admin and teacher views (below), Mica, Seth (our project technologist, who had stepped up to tackle dashboard development in 2010 while assisting with many other OneVille projects), and Jedd met with Principal DeFalco several times during the 2010-2011 year and new Principal Vadhera beginning during the summer of 2011 to figure out the highest priority data fields for the admin view and to brainstorm potential uses. Based on DeFalco’s feedback, and with Seth’s programming skill, we developed a dashboard to transfer data from X2 to a user-friendly view. Seeing Greg’s initial prototype, above, sparked DeFalco to suggest additional data fields: years at Healey, score growth on the MAP, ELL status, MEPA scores (English language learner assessments), IEP status, and afterschool program name (in the end, we did not add program name to the dashboard, because it was never made a real field in X2.) From this feedback, we developed the view below (names are fictional to ensure anonymity):		Between this stage and the latest version of the admin and teacher views (below), Mica, Seth (our project technologist, who had stepped up to tackle dashboard development in 2010 while assisting with many other OneVille projects), and Jedd met with Principal DeFalco several times during the 2010-2011 year and new Principal Vadhera beginning during the summer of 2011 to figure out the highest priority data fields for the admin view and to brainstorm potential uses. Based on DeFalco’s feedback, and with Seth’s programming skill, we developed a dashboard to transfer data from X2 to a user-friendly view. Seeing Greg’s initial prototype, above, sparked DeFalco to suggest additional data fields: years at Healey, score growth on the MAP, ELL status, MEPA scores (English language learner assessments), IEP status, and afterschool program name (in the end, we did not add program name to the dashboard, because it was never made a real field in X2.) From this feedback, we developed the view below (names are fictional to ensure anonymity):
Line 106:		Line 106:
	In addition, she noted, students with IEPs and 504 plans sometimes need accommodations on the MCAS, and she often spent “hours” going over the paper lists and checking with the teachers to ensure that everyone’s accommodation needs had been met. Our tool could allow her to sort by IEP and 504 status, so that all these students appear together, and, as she said, “so we don’t have moments when things fall through the cracks.”		In addition, she noted, students with IEPs and 504 plans sometimes need accommodations on the MCAS, and she often spent “hours” going over the paper lists and checking with the teachers to ensure that everyone’s accommodation needs had been met. Our tool could allow her to sort by IEP and 504 status, so that all these students appear together, and, as she said, “so we don’t have moments when things fall through the cracks.”

	Principal Vadhera and Josh ~~Wairi~~ both suggested that the dashboards could enhance teamwork among educators: In staff team meetings, access to each view could allow teachers and administrators to collaboratively assess a student’s needs, design and discuss targeted interventions, and, if desired, record their plan by submitting it as subject-specific comments that would get archived in the homeroom (lead) teacher’s email. Such team conversations could involve the school’s “student support team,” a standing group of educators that Purnima described as “the central nervous system of the building,” including Purnima, the Vice Principal, Nurse, and Adjustment/Redirect Counselor. Josh explained that another advantage to the individual view was that in contrast to his whole-class spreadsheets, it could allow him to present a single student’s data in one of these team meetings without revealing all the other students’ grades unnecessarily (a breach of confidentiality). Finally, reviewers noted that another relevant team that could use the dashboard to look at data together (even remotely) was each student’s individualized group of supporters, e.g. their homeroom teacher, Special Ed or ELL specialists, and reading/math resource room staff. Josh expressed interest in piloting the dashboard this way.		Principal Vadhera and Josh both suggested that the dashboards could enhance teamwork among educators: In staff team meetings, access to each view could allow teachers and administrators to collaboratively assess a student’s needs, design and discuss targeted interventions, and, if desired, record their plan by submitting it as subject-specific comments that would get archived in the homeroom (lead) teacher’s email. Such team conversations could involve the school’s “student support team,” a standing group of educators that Purnima described as “the central nervous system of the building,” including Purnima, the Vice Principal, Nurse, and Adjustment/Redirect Counselor. Josh explained that another advantage to the individual view was that in contrast to his whole-class spreadsheets, it could allow him to present a single student’s data in one of these team meetings without revealing all the other students’ grades unnecessarily (a breach of confidentiality). Finally, reviewers noted that another relevant team that could use the dashboard to look at data together (even remotely) was each student’s individualized group of supporters, e.g. their homeroom teacher, Special Ed or ELL specialists, and reading/math resource room staff. Josh expressed interest in piloting the dashboard this way.

	'''<font color=red>¡Aha!</font color> The families whose children most need assistance are often the hardest to reach with technology, but they are also the most in need of such rapid access to information.		'''<font color=red>¡Aha!</font color> The families whose children most need assistance are often the hardest to reach with technology, but they are also the most in need of such rapid access to information.

Micapollock at 03:50, 20 July 2012

2012-07-20T03:50:33Z

← Older revision		Revision as of 03:50, 20 July 2012
Line 1:		Line 1:
	''Written by Mica Pollock, Jedd Cohen, and Josh Wairi for the dashboard project, with initial dashboard development by local technologist Seth Woodworth and ~~final~~ development for piloting by David Lord of San Diego.		''Written by Mica Pollock, Jedd Cohen, and Josh Wairi for the dashboard project, with initial dashboard development by local technologist Seth Woodworth and next development for piloting by David Lord of San Diego.

	Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.		Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.

Micapollock at 03:49, 20 July 2012

2012-07-20T03:49:41Z

← Older revision		Revision as of 03:49, 20 July 2012
Line 1:		Line 1:
	''Written by Mica Pollock, Jedd Cohen, and Josh Wairi for the dashboard project, with initial dashboard development by local technologist Seth Woodworth ~~and Evan Burchard,~~ and final development for piloting by David Lord of San Diego.		''Written by Mica Pollock, Jedd Cohen, and Josh Wairi for the dashboard project, with initial dashboard development by local technologist Seth Woodworth and final development for piloting by David Lord of San Diego.

	Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.		Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.

Micapollock: /* Development process and future prospects */

2012-07-16T13:15:35Z

Development process and future prospects

← Older revision		Revision as of 13:15, 16 July 2012
Line 126:		Line 126:
	David estimates that 60-100 hours of work remain to finish building the "tubes" from Somerville's data system to our teacher and admin dashboard views, for 100% accuracy in the data display. Given that the teacher and admin views are now ready to integrate with an individual view, David estimates that finishing the individual view, which is not as far along, would take 220-330 hours. Adapting the tool to another district's student information system (if not X2) would involve rebuilding most of the tubes, and some elements of the display, so it would likely take closer to 480 hours.		David estimates that 60-100 hours of work remain to finish building the "tubes" from Somerville's data system to our teacher and admin dashboard views, for 100% accuracy in the data display. Given that the teacher and admin views are now ready to integrate with an individual view, David estimates that finishing the individual view, which is not as far along, would take 220-330 hours. Adapting the tool to another district's student information system (if not X2) would involve rebuilding most of the tubes, and some elements of the display, so it would likely take closer to 480 hours.

	The ultimate lesson here involves the timeline of software development, and the risks associated with community-based design research if one is literally designing a new technological tool from scratch. Developing a software application from scratch means lots of work on the developer's end before any immediate use by the community partner; it also means that the developer's work assignments can shift according to community desires. The reality is that part-time technologists creating these products to community specifications, working alone on our limited budget, couldn't quite create a financially sustainable tech solution for Somerville's data viewing. We might lose confidence in local open source development, but we've learned the hard way ~~that some developers move faster than others and~~ that the basic need is sufficiently budgeted development hours; the future of such open source dashboard development may lie in large, experienced teams designing and troubleshooting such tools together. And, while building "from scratch" is not truly free, it may remain far less expensive than storebought tools, and so more attainable with district budgets: the reality is that a tool for easily seeing data "all in one place" otherwise may not exist in Somerville for some time due to the expense of "off the shelf" tools. We're optimistic that next developers can pick up right where we left off, rather than starting from scratch like we did. That's how open source development works, in fact. The code for these dashboard products is now available online and free to the next developer. See '''Technological How-Tos''' in '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] ''').		The ultimate lesson here involves the timeline of software development, and the risks associated with community-based design research if one is literally designing a new technological tool from scratch. Developing a software application from scratch means lots of work on the developer's end before any immediate use by the community partner; it also means that the developer's work assignments can shift according to community desires. The reality is that part-time technologists creating these products to community specifications, working alone on our limited budget, couldn't quite create a financially sustainable tech solution for Somerville's data viewing. We might lose confidence in local open source development, but we've learned the hard way that the basic need is sufficiently budgeted and planned development hours; the future of such open source dashboard development may lie in large, experienced teams designing and troubleshooting such tools together. And, while building "from scratch" is not truly free, it may remain far less expensive than storebought tools, and so more attainable with district budgets: the reality is that a tool for easily seeing data "all in one place" otherwise may not exist in Somerville for some time due to the expense of "off the shelf" tools. We're optimistic that next developers can pick up right where we left off, rather than starting from scratch like we did. That's how open source development works, in fact. The code for these dashboard products is now available online and free to the next developer. See '''Technological How-Tos''' in '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] ''').

	Our goal has always been to launch an open source dashboard design that could contribute not only in Somerville if it proved useful, but elsewhere through iterative development. While our "product" in the end is code instead of a finished piloted product, we believe that the community design process we began will serve next design efforts for "data display."		Our goal has always been to launch an open source dashboard design that could contribute not only in Somerville if it proved useful, but elsewhere through iterative development. While our "product" in the end is code instead of a finished piloted product, we believe that the community design process we began will serve next design efforts for "data display."

	Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.		Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.

Micapollock: /* Development process and future prospects */

2012-07-16T13:13:11Z

Development process and future prospects

← Older revision		Revision as of 13:13, 16 July 2012
Line 120:		Line 120:
	While we asked for our local technologist to be done with development for piloting by September 1, the tools were still in development by mid-October, 2011, after the Ford funding had ended. The prototypes of the administrative and teacher views appeared to be nearly complete pending new data from the District (which required building final "tubes" to the district's student information system), and the word on the individual view was that it was "nearly complete." These delays prompted a district administrator to reconsider the pilot, even as Josh, families, students, and supporting teachers were still ready to test the dashboard in fall 2011, as were their principal and local afterschool providers. By that time, our budget for development was spent down, and we were fortunate to find another technologist, David Lord, based in San Diego, to bring the admin and teacher dashboard views to near completion for free.		While we asked for our local technologist to be done with development for piloting by September 1, the tools were still in development by mid-October, 2011, after the Ford funding had ended. The prototypes of the administrative and teacher views appeared to be nearly complete pending new data from the District (which required building final "tubes" to the district's student information system), and the word on the individual view was that it was "nearly complete." These delays prompted a district administrator to reconsider the pilot, even as Josh, families, students, and supporting teachers were still ready to test the dashboard in fall 2011, as were their principal and local afterschool providers. By that time, our budget for development was spent down, and we were fortunate to find another technologist, David Lord, based in San Diego, to bring the admin and teacher dashboard views to near completion for free.

	David spent 200 hours rebuilding the three dashboard views our original developer had worked on in order to clean them up, i.e., to make them easier to combine and debug/modify in the future, and develop them closer to completion. The goal was to create work and code that other developers elsewhere could ultimately use for new projects (one of OneVille's ultimate goals with tech development). He also "cleaned up" work-arounds in the original code and designed both the admin and teacher views to be compatible with an eventual individual view.		David spent 200 hours rebuilding the three dashboard views our original developer had worked on in order to clean them up, i.e., to make them easier to combine and debug/modify in the future, and develop them closer to completion. The goal was to create work and code that other developers elsewhere could also ultimately use for new projects (one of OneVille's ultimate goals with tech development). He also "cleaned up" work-arounds in the original code and designed both the admin and teacher views to be compatible with an eventual individual view.

	The biggest challenge was simply the scale of the work. Listening to local community members' desires to see a variety of data types quickly and clearly in one place, we had expanded any original vision of a single, hyper-simple dashboard to three more complex views; after the original budget ran out, the project still required several months of full-time development work, rather than a few days or week, and David did the work pro bono after his actual job ended. A secondary challenge was that both the prior OneVille PI, Mica, and the current dashboard project manager, Jedd, understood education data but had no significant experience with technology project management -- i.e., understanding the scope of developing tools from scratch. The full series of technologists working on the project, in turn, didn't know details about education data -- the format of student data in the district's system, information necessary in order to finish the "tubes" to the system 100% accurately. All this too had to be learned from scratch across our team. Features that a non-technologist would consider trivial, such as creating logins for different teachers, ended up requiring substantial reworking of the code. Similarly, while we knew what subset of student data people wanted to see, we learned that the district's data set had many more kinds of information to track and parse in order to make sure that no unknown values caused errors in the dashboard display.		The biggest challenge was simply the scale of the work. Listening to local community members' desires to see a variety of data types quickly and clearly in one place, we had expanded any original vision of a single, hyper-simple dashboard to three more complex views; after the original budget ran out, the project still required several months of full-time development work, rather than a few days or week, and David did the work pro bono after his actual job ended. A secondary challenge was that both the prior OneVille PI, Mica, and the current dashboard project manager, Jedd, understood education data but had no significant experience with technology project management -- i.e., understanding the scope of developing tools from scratch. The full series of technologists working on the project, in turn, didn't know details about education data -- the format of student data in the district's system, information necessary in order to finish the "tubes" to the system 100% accurately. All this too had to be learned from scratch across our team. Features that a non-technologist would consider trivial, such as creating logins for different teachers, ended up requiring substantial reworking of the code. Similarly, while we knew what subset of student data people wanted to see, we learned that the district's data set had many more kinds of information to track and parse in order to make sure that no unknown values caused errors in the dashboard display.

Micapollock: /* Development process and future prospects */

2012-07-16T13:06:50Z

Development process and future prospects

← Older revision		Revision as of 13:06, 16 July 2012
Line 118:		Line 118:
	We planned to pilot our three “views” at the Healey in fall 2011 and report out what we learned. As Principal Vadhera explained about our planned incremental approach to implementation, “A lot of ideas start like THIS (gestures big with hands). And then they fail. This is a guinea pig, Josh could always share back, move forward in small increments. Teachers might just want to get on board with this!”		We planned to pilot our three “views” at the Healey in fall 2011 and report out what we learned. As Principal Vadhera explained about our planned incremental approach to implementation, “A lot of ideas start like THIS (gestures big with hands). And then they fail. This is a guinea pig, Josh could always share back, move forward in small increments. Teachers might just want to get on board with this!”

	While we asked for our local technologist to be done with development for piloting by September 1, the tools were still in development by mid-October, 2011. The prototypes of the administrative and teacher views appeared to be nearly complete pending new data from the District (which required building final "tubes" to the district's student information system), and the word on the individual view was that it was "nearly complete." These delays prompted a district administrator to reconsider the pilot, even as Josh, families, students, and supporting teachers were still ready to test the dashboard in fall 2011, as were their principal and local afterschool providers. By that time, our budget for development was spent down, and we were fortunate to find another technologist, David Lord, based in San Diego, to bring the admin and teacher dashboard views to near completion for free.		While we asked for our local technologist to be done with development for piloting by September 1, the tools were still in development by mid-October, 2011, after the Ford funding had ended. The prototypes of the administrative and teacher views appeared to be nearly complete pending new data from the District (which required building final "tubes" to the district's student information system), and the word on the individual view was that it was "nearly complete." These delays prompted a district administrator to reconsider the pilot, even as Josh, families, students, and supporting teachers were still ready to test the dashboard in fall 2011, as were their principal and local afterschool providers. By that time, our budget for development was spent down, and we were fortunate to find another technologist, David Lord, based in San Diego, to bring the admin and teacher dashboard views to near completion for free.

	David spent 200 hours rebuilding the three dashboard views our original developer had worked on in order to clean them up, i.e., to make them easier to combine and debug/modify in the future, and develop them closer to completion. The goal was to create work and code that other developers elsewhere could ultimately use for new projects (one of OneVille's ultimate goals with tech development). He also "cleaned up" work-arounds in the original code and designed both the admin and teacher views to be compatible with an eventual individual view.		David spent 200 hours rebuilding the three dashboard views our original developer had worked on in order to clean them up, i.e., to make them easier to combine and debug/modify in the future, and develop them closer to completion. The goal was to create work and code that other developers elsewhere could ultimately use for new projects (one of OneVille's ultimate goals with tech development). He also "cleaned up" work-arounds in the original code and designed both the admin and teacher views to be compatible with an eventual individual view.

	The biggest challenge was simply the scale of the work -- the project required several months of full-time work, rather than a few days or week, and David did the work pro bono after his actual job ended. A secondary challenge was that ~~just like~~ the prior OneVille PI, Mica, the current dashboard project manager, Jedd, understood education data but had no significant experience with technology project management -- i.e., understanding ~~exactly~~ the scope of developing tools from scratch. The full series of technologists working on the project, in turn, didn't know details about the format of student data in the district's system, information necessary in order to finish the "tubes" to the system 100% accurately~~; all~~ this too had to be learned from scratch. Features that a non-technologist would consider trivial, such as creating logins for different teachers, ended up requiring substantial reworking of the code. Similarly, while we knew what subset of student data people wanted to see, we learned that the district's data set had many more kinds of information to track and parse in order to make sure that no unknown values caused errors in the dashboard display.		The biggest challenge was simply the scale of the work. Listening to local community members' desires to see a variety of data types quickly and clearly in one place, we had expanded any original vision of a single, hyper-simple dashboard to three more complex views; after the original budget ran out, the project still required several months of full-time development work, rather than a few days or week, and David did the work pro bono after his actual job ended. A secondary challenge was that both the prior OneVille PI, Mica, and the current dashboard project manager, Jedd, understood education data but had no significant experience with technology project management -- i.e., understanding the scope of developing tools from scratch. The full series of technologists working on the project, in turn, didn't know details about education data -- the format of student data in the district's system, information necessary in order to finish the "tubes" to the system 100% accurately. All this too had to be learned from scratch across our team. Features that a non-technologist would consider trivial, such as creating logins for different teachers, ended up requiring substantial reworking of the code. Similarly, while we knew what subset of student data people wanted to see, we learned that the district's data set had many more kinds of information to track and parse in order to make sure that no unknown values caused errors in the dashboard display.

	David estimates that 60-100 hours of work remain to finish building the "tubes" from Somerville's data system to our teacher and admin dashboard views, for 100% accuracy in the data display. Given that the teacher and admin views are ready to integrate with an individual view, David estimates that finishing the individual view, which is not as far along, would take 220-330 hours. Adapting the tool to another district's student information system (if not X2) would involve rebuilding most of the tubes, and some elements of the display, so it would likely take closer to 480 hours.		David estimates that 60-100 hours of work remain to finish building the "tubes" from Somerville's data system to our teacher and admin dashboard views, for 100% accuracy in the data display. Given that the teacher and admin views are now ready to integrate with an individual view, David estimates that finishing the individual view, which is not as far along, would take 220-330 hours. Adapting the tool to another district's student information system (if not X2) would involve rebuilding most of the tubes, and some elements of the display, so it would likely take closer to 480 hours.

	The ultimate lesson here involves the timeline of software development, and the risks associated with community-based design research if one is literally designing a new technological tool from scratch. Developing a software application from scratch means lots of work on the developer's end before any immediate use by the community partner. The reality is that part-time technologists creating these products to community specifications, working alone on our limited budget, couldn't quite create a financially sustainable tech solution for Somerville's data viewing. We might lose confidence in local open source development, but we've learned the hard way that some developers move faster than others and that the basic need is sufficiently budgeted development hours. And, the reality is that a tool for easily seeing data "all in one place" otherwise may not exist in Somerville for some time due to the expense of "off the shelf" tools. We're optimistic that next developers can pick up right where we left off, rather than starting from scratch like we did. That's how open source development works, in fact. The code for these dashboard products is now available online and free to the next developer. See '''Technological How-Tos''' in '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] ''').		The ultimate lesson here involves the timeline of software development, and the risks associated with community-based design research if one is literally designing a new technological tool from scratch. Developing a software application from scratch means lots of work on the developer's end before any immediate use by the community partner; it also means that the developer's work assignments can shift according to community desires. The reality is that part-time technologists creating these products to community specifications, working alone on our limited budget, couldn't quite create a financially sustainable tech solution for Somerville's data viewing. We might lose confidence in local open source development, but we've learned the hard way that some developers move faster than others and that the basic need is sufficiently budgeted development hours; the future of such open source dashboard development may lie in large, experienced teams designing and troubleshooting such tools together. And, while building "from scratch" is not truly free, it may remain far less expensive than storebought tools, and so more attainable with district budgets: the reality is that a tool for easily seeing data "all in one place" otherwise may not exist in Somerville for some time due to the expense of "off the shelf" tools. We're optimistic that next developers can pick up right where we left off, rather than starting from scratch like we did. That's how open source development works, in fact. The code for these dashboard products is now available online and free to the next developer. See '''Technological How-Tos''' in '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] ''').

	Our goal has always been to launch an open source dashboard design that could contribute not only in Somerville if it proved useful, but elsewhere through iterative development. While our "product" in the end is code instead of a finished piloted product, we believe that the community design process we began will serve next design efforts for "data display."		Our goal has always been to launch an open source dashboard design that could contribute not only in Somerville if it proved useful, but elsewhere through iterative development. While our "product" in the end is code instead of a finished piloted product, we believe that the community design process we began will serve next design efforts for "data display."

	Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.		Click here for the '''[[Summary: Data dashboards\|<font color=#0000FF>Summary</font>]] '''on this project; click here for the '''[[Overview and key findings: Data dashboards\|<font color=#0000FF>Overview and key findings</font>]] '''on this project.

Micapollock: /* Design Process */

2012-07-16T12:55:54Z

Design Process

← Older revision		Revision as of 12:55, 16 July 2012
Line 48:		Line 48:
	[[Image:Greg_nadeau_view.jpg]]		[[Image:Greg_nadeau_view.jpg]]

	Before we worked on making the dashboard version of this view “live” by connecting it initially to X2, the school’s main need at the time was entering updated data into the Excel spreadsheet -- by hand. We knew that we would eventually develop a dashboard to automatically transfer data from X2, but the school needed to integrate the data sets immediately. So Susan Klimczak, from the South End Technology Center at Tent City, who would later become the lead organizer for the [[eportfolio]] project, did some valiant handiwork at the principal's request, assisted by colleague Al Willis, the original proponent of the OneVille dashboard project. They cleaned up the current year’s spreadsheet and added new data typically not kept in X2 that the principal also wanted to see, like disciplinary referrals and afterschool enrollment. We also had some regular meetings via phone conference with Greg and the principal to consider the patterns the principal wanted to see and the new "fields" for data that the principal felt needed to be created permanently in the district student information system (e.g., attendance in the afterschool programs. Afterschool programs weren't keeping this data in Somerville's core data system, X2, and still don’t.)		Before we worked on making the dashboard version of this view “live” by connecting it initially to X2, the school’s main need at the time was entering updated data into the Excel spreadsheet -- by hand. We knew that we would eventually develop a dashboard to automatically transfer data from X2, but the school needed to integrate the data sets immediately. So Susan Klimczak, from the South End Technology Center at Tent City, who would later become the lead organizer for the [[eportfolio]] project, did some valiant handiwork at the principal's request, assisted by colleague Al Willis, the original proponent of the OneVille dashboard project (who also ended up later helping to realize the [[eportfolio]] project). They cleaned up the current year’s spreadsheet and added new data typically not kept in X2 that the principal also wanted to see, like disciplinary referrals and afterschool enrollment. We also had some regular meetings via phone conference with Greg and the principal to consider the patterns the principal wanted to see and the new "fields" for data that the principal felt needed to be created permanently in the district student information system (e.g., attendance in the afterschool programs. Afterschool programs weren't keeping this data in Somerville's core data system, X2, and still don’t.)

	'''Turning point: The Teacher View		'''Turning point: The Teacher View
Line 54:		Line 54:
	Josh Wairi, a 5th grade teacher at the Healey, got interested in the dashboard design when we stopped by his classroom one day after school in the winter of 2011. Looking together at his computer and printouts, we realized he was already creating spreadsheets of student data from X2 by hand. He was interested in quickly displaying and sorting basic data, to supplement his face-to-face and phone conversations with students and parents. His work showed us the need for what would become the “Teacher View,” a version of the Administrator View in which all the students come from the same homeroom.		Josh Wairi, a 5th grade teacher at the Healey, got interested in the dashboard design when we stopped by his classroom one day after school in the winter of 2011. Looking together at his computer and printouts, we realized he was already creating spreadsheets of student data from X2 by hand. He was interested in quickly displaying and sorting basic data, to supplement his face-to-face and phone conversations with students and parents. His work showed us the need for what would become the “Teacher View,” a version of the Administrator View in which all the students come from the same homeroom.

	Between this stage and the latest version of the admin and teacher views (below), Mica, Seth (~~a local~~ technologist who stepped up to tackle dashboard development while assisting with many other OneVille projects), and Jedd met with Principal DeFalco several times during the 2010-2011 year and new Principal Vadhera beginning during the summer of 2011 to figure out the highest priority data fields for the admin view and to brainstorm potential uses. Based on DeFalco’s feedback, and with Seth’s programming skill, we developed a dashboard to transfer data from X2 to a user-friendly view. Seeing Greg’s initial prototype, above, sparked DeFalco to suggest additional data fields: years at Healey, score growth on the MAP, ELL status, MEPA scores (English language learner assessments), IEP status, and afterschool program name (in the end, we did not add program name to the dashboard, because it was never made a real field in X2.) From this feedback, we developed the view below (names are fictional to ensure anonymity):		Between this stage and the latest version of the admin and teacher views (below), Mica, Seth (our project technologist, who had stepped up to tackle dashboard development in 2010 while assisting with many other OneVille projects), and Jedd met with Principal DeFalco several times during the 2010-2011 year and new Principal Vadhera beginning during the summer of 2011 to figure out the highest priority data fields for the admin view and to brainstorm potential uses. Based on DeFalco’s feedback, and with Seth’s programming skill, we developed a dashboard to transfer data from X2 to a user-friendly view. Seeing Greg’s initial prototype, above, sparked DeFalco to suggest additional data fields: years at Healey, score growth on the MAP, ELL status, MEPA scores (English language learner assessments), IEP status, and afterschool program name (in the end, we did not add program name to the dashboard, because it was never made a real field in X2.) From this feedback, we developed the view below (names are fictional to ensure anonymity):

	[[Image:Admin Dash 2012-01-25.jpg\|1000x500px\|Admin Dash 2012-01-25.jpg]]		[[Image:Admin Dash 2012-01-25.jpg\|1000x500px\|Admin Dash 2012-01-25.jpg]]

Micapollock: /* The Details of the Work */

2012-07-16T12:49:53Z

The Details of the Work

← Older revision		Revision as of 12:49, 16 July 2012
Line 16:		Line 16:
	Throughout, we also became convinced that a dashboard shouldn’t just show data more clearly – it should help people communicate about it. Our rationale: Data displays in schools have traditionally been a) on paper and b) one-way. Think a report card or a quarterly report on one’s “scores”: schools or districts just “display” student scores to students and parents or show parents their child’s absences. Since OneVille’s goal is to support diverse partners in running communication about pursuing the success of young people, we wanted to make sure that parents could communicate back ABOUT data, to teachers -- and that tutors, teachers, and parents could over time communicate with one another. So, we designed the individual view to allow users to upload commentary, and future iterations of the admin and teacher views would also allow for qualitative notes.		Throughout, we also became convinced that a dashboard shouldn’t just show data more clearly – it should help people communicate about it. Our rationale: Data displays in schools have traditionally been a) on paper and b) one-way. Think a report card or a quarterly report on one’s “scores”: schools or districts just “display” student scores to students and parents or show parents their child’s absences. Since OneVille’s goal is to support diverse partners in running communication about pursuing the success of young people, we wanted to make sure that parents could communicate back ABOUT data, to teachers -- and that tutors, teachers, and parents could over time communicate with one another. So, we designed the individual view to allow users to upload commentary, and future iterations of the admin and teacher views would also allow for qualitative notes.

	In talking to families, teachers, and other service providers, we realized that just "getting data" on a student is never enough: people need to then converse (online, in person, or otherwise) about how the young person is doing and how they might be assisted. Just knowing how many days a child is absent is the first step, but then you need to have a conversation about why and what to do about it!		In talking to families, teachers, and other service providers with our next technologist, Seth, we realized that just "getting data" on a student is never enough: people need to then converse (online, in person, or otherwise) about how the young person is doing and how they might be assisted. Just knowing how many days a child is absent is the first step, but then you need to have a conversation about why and what to do about it!

	We ultimately found the project of building a finished data dashboard for actual ongoing use by a district's educators and families to be beyond the capacity and resources of our single-technologist staffing and two-year funding plan. The future of open source dashboard development for districts and communities may well lie in large, more experienced developer teams constructing and then troubleshooting free dashboards together for pay. (If we had focused our Ford grant fully on the dashboard's development, we perhaps could have supported such a team.) But having almost finished usable dashboard products relying on two individual, part-time young developers in sequence, we consider our work to be evidence that the goal is worth pursuing and can be attained -- with the resources described in our final section below, "Development process and future prospects." In the following sections, "The Community's need for the work," "Design process," and "Feedback on the design," we describe the tool as it was designed to work.		We ultimately found the project of building a finished data dashboard for actual ongoing use by a district's educators and families to be beyond the capacity and resources of our single-technologist staffing and two-year funding plan. The future of open source dashboard development for districts and communities may well lie in large, more experienced developer teams constructing and then troubleshooting free dashboards together for pay. (If we had focused our Ford grant fully on the dashboard's development, we perhaps could have supported such a team.) But having almost finished usable dashboard products relying on two individual, part-time young developers in sequence, we consider our work to be evidence that the goal is worth pursuing and can be attained -- with the resources described in our final section below, "Development process and future prospects." In the following sections, "The Community's need for the work," "Design process," and "Feedback on the design," we describe the tool as it was designed to work.

Micapollock: /* The Details of the Work */

2012-07-16T12:45:18Z

The Details of the Work

← Older revision		Revision as of 12:45, 16 July 2012
Line 8:		Line 8:
	'''Starting off, and developing our goals:		'''Starting off, and developing our goals:

	From start to finish, the dashboard project was a saga of not fully understanding the extent of work involved in creating tech tools from scratch. Our first technologist early in the project argued convincingly that simple, clear "dashboards" were key to including ordinary people in data discussions, so we jumped headfirst into a tech development area we knew nothing about. In fact, as we began the OneVille Project back in summer 2009, we actually proposed to create a “dashboard” displaying basic data linking multiple youth- and child-related databases in the city. That was because many policymakers and researchers have a sense these days that the more data seen by more people, the better (see our [[Research base]] page). But we quickly became unsure that “seeing everything” on young people was necessarily good – and especially, not clearly necessary at the level of the individual student and family (does a teacher actually need to know a student’s police record in order to serve him better? Who exactly should see health data on a child?). And anyway, the district was first interested in getting all of its own basic data viewable, quickly -- and that’s what we ended up working on in the end. Now that we understand more about tech tool development, it's likely that this multiple database project would have been very difficult to get close to completing with part-time, individual developers.		From start to finish, the dashboard project was a saga of not fully understanding the extent of work involved in creating tech tools from scratch. Our first technologist early in the project argued convincingly that simple, clear "dashboards" were key to including ordinary people in data discussions and, quite possible to create from scratch, so the non-technologists in the group jumped headfirst into a tech development area we knew nothing about. In fact, as we began the OneVille Project back in summer 2009, we actually proposed to create a “dashboard” displaying basic data linking multiple youth- and child-related databases in the city. That was because many policymakers and researchers have a sense these days that the more data seen by more people, the better (see our [[Research base]] page). But we quickly became unsure that “seeing everything” on young people was necessarily good – and especially, not clearly necessary at the level of the individual student and family (does a teacher actually need to know a student’s police record in order to serve him better? Who exactly should see health data on a child?). And anyway, the district was first interested in getting all of its own basic data viewable, quickly -- and that’s what we ended up working on in the end. Now that we understand more about tech tool development, it's likely that this multiple database project would have been very difficult to get close to completing with part-time, individual developers.

	We also moved away from any effort at multi “sector”-database linking because SomerPromise, the Mayor's new site-based initiative to provide comprehensive youth services, was also interested in tackling the issue of linking databases across agencies, and we felt they were better positioned to pursue that goal even as we worked to do R & D supporting the effort by creating administrative and family-level views of school data alone. So, the goal became to create a simple data display that could help educators and families of youth in a single school see some basic data from district’s data warehousing software, Aspen X2, in a single view. This included creating a translated display easily understandable by an immigrant parent.		We also moved away from any effort at multi “sector”-database linking because SomerPromise, the Mayor's new site-based initiative to provide comprehensive youth services, was also interested in tackling the issue of linking databases across agencies, and we felt they were better positioned to pursue that goal even as we worked to do R & D supporting the effort by creating administrative and family-level views of school data alone. So, the goal became to create a simple data display that could help educators and families of youth in a single school see some basic data from district’s data warehousing software, Aspen X2, in a single view. This included creating a translated display easily understandable by an immigrant parent.

Micapollock: /* The Details of the Work */

2012-07-16T12:38:50Z

The Details of the Work

← Older revision		Revision as of 12:38, 16 July 2012
Line 8:		Line 8:
	'''Starting off, and developing our goals:		'''Starting off, and developing our goals:

	From start to finish, the dashboard project was a saga of not fully understanding the extent of work involved in creating tech tools from scratch. As we began the OneVille Project back in summer 2009, we actually proposed to create a “dashboard” displaying basic data linking multiple youth- and child-related databases in the city. That was because many policymakers and researchers have a sense these days that the more data seen by more people, the better (see our [[Research base]] page). But we quickly became unsure that “seeing everything” on young people was necessarily good – and especially, not clearly necessary at the level of the individual student and family (does a teacher actually need to know a student’s police record in order to serve him better? Who exactly should see health data on a child?). And anyway, the district was first interested in getting all of its own basic data viewable, quickly -- and that’s what we ended up working on in the end. Now that we understand more about tech tool development, it's likely that this multiple database project would have been very difficult to get close to completing with part-time, individual developers.		From start to finish, the dashboard project was a saga of not fully understanding the extent of work involved in creating tech tools from scratch. Our first technologist early in the project argued convincingly that simple, clear "dashboards" were key to including ordinary people in data discussions, so we jumped headfirst into a tech development area we knew nothing about. In fact, as we began the OneVille Project back in summer 2009, we actually proposed to create a “dashboard” displaying basic data linking multiple youth- and child-related databases in the city. That was because many policymakers and researchers have a sense these days that the more data seen by more people, the better (see our [[Research base]] page). But we quickly became unsure that “seeing everything” on young people was necessarily good – and especially, not clearly necessary at the level of the individual student and family (does a teacher actually need to know a student’s police record in order to serve him better? Who exactly should see health data on a child?). And anyway, the district was first interested in getting all of its own basic data viewable, quickly -- and that’s what we ended up working on in the end. Now that we understand more about tech tool development, it's likely that this multiple database project would have been very difficult to get close to completing with part-time, individual developers.

	We also moved away from any effort at multi “sector”-database linking because SomerPromise, the Mayor's new site-based initiative to provide comprehensive youth services, was also interested in tackling the issue of linking databases across agencies, and we felt they were better positioned to pursue that goal even as we worked to do R & D supporting the effort by creating administrative and family-level views of school data alone. So, the goal became to create a simple data display that could help educators and families of youth in a single school see some basic data from district’s data warehousing software, Aspen X2, in a single view. This included creating a translated display easily understandable by an immigrant parent.		We also moved away from any effort at multi “sector”-database linking because SomerPromise, the Mayor's new site-based initiative to provide comprehensive youth services, was also interested in tackling the issue of linking databases across agencies, and we felt they were better positioned to pursue that goal even as we worked to do R & D supporting the effort by creating administrative and family-level views of school data alone. So, the goal became to create a simple data display that could help educators and families of youth in a single school see some basic data from district’s data warehousing software, Aspen X2, in a single view. This included creating a translated display easily understandable by an immigrant parent.
Line 18:		Line 18:
	In talking to families, teachers, and other service providers, we realized that just "getting data" on a student is never enough: people need to then converse (online, in person, or otherwise) about how the young person is doing and how they might be assisted. Just knowing how many days a child is absent is the first step, but then you need to have a conversation about why and what to do about it!		In talking to families, teachers, and other service providers, we realized that just "getting data" on a student is never enough: people need to then converse (online, in person, or otherwise) about how the young person is doing and how they might be assisted. Just knowing how many days a child is absent is the first step, but then you need to have a conversation about why and what to do about it!

	We ultimately found ~~that~~ the project of building a data dashboard for educators and families to be beyond the resources of our ~~staff~~ and funding, ~~but~~ we consider ~~out~~ work to be evidence that the goal is worth pursuing and can be attained -- with the resources described in our final section below, "Development process and future prospects." In the following sections, "The Community's need for the work," "Design process," and "Feedback on the design," we describe the tool as ~~though~~ it ~~already exists in order~~ to ~~convey that the finished product is, if not, "right around the corner," at least clearly attainable~~.		We ultimately found the project of building a finished data dashboard for actual ongoing use by a district's educators and families to be beyond the capacity and resources of our single-technologist staffing and two-year funding plan. The future of open source dashboard development for districts and communities may well lie in large, more experienced developer teams constructing and then troubleshooting free dashboards together for pay. (If we had focused our Ford grant fully on the dashboard's development, we perhaps could have supported such a team.) But having almost finished usable dashboard products relying on two individual, part-time young developers in sequence, we consider our work to be evidence that the goal is worth pursuing and can be attained -- with the resources described in our final section below, "Development process and future prospects." In the following sections, "The Community's need for the work," "Design process," and "Feedback on the design," we describe the tool as it was designed to work.

	=='''The community’s need for the work==		=='''The community’s need for the work==
Line 48:		Line 48:
	[[Image:Greg_nadeau_view.jpg]]		[[Image:Greg_nadeau_view.jpg]]

	Before we worked on making the dashboard version of this view “live” by connecting it initially to X2, the school’s main need at the time was entering updated data into the Excel spreadsheet -- by hand. We knew that we would eventually develop a dashboard to automatically transfer data from X2, but the school needed to integrate the data sets immediately. So Susan Klimczak, from the South End Technology Center at Tent City, who would later become the lead organizer for the [[eportfolio]] project, did some valiant handiwork at the principal's request, assisted by colleague Al Willis. They cleaned up the current year’s spreadsheet and added new data typically not kept in X2 that the principal also wanted to see, like disciplinary referrals and afterschool enrollment. We also had some regular meetings via phone conference with Greg and the principal to consider the patterns the principal wanted to see and the new "fields" for data that the principal felt needed to be created permanently in the district student information system (e.g., attendance in the afterschool programs. Afterschool programs weren't keeping this data in Somerville's core data system, X2, and still don’t.)		Before we worked on making the dashboard version of this view “live” by connecting it initially to X2, the school’s main need at the time was entering updated data into the Excel spreadsheet -- by hand. We knew that we would eventually develop a dashboard to automatically transfer data from X2, but the school needed to integrate the data sets immediately. So Susan Klimczak, from the South End Technology Center at Tent City, who would later become the lead organizer for the [[eportfolio]] project, did some valiant handiwork at the principal's request, assisted by colleague Al Willis, the original proponent of the OneVille dashboard project. They cleaned up the current year’s spreadsheet and added new data typically not kept in X2 that the principal also wanted to see, like disciplinary referrals and afterschool enrollment. We also had some regular meetings via phone conference with Greg and the principal to consider the patterns the principal wanted to see and the new "fields" for data that the principal felt needed to be created permanently in the district student information system (e.g., attendance in the afterschool programs. Afterschool programs weren't keeping this data in Somerville's core data system, X2, and still don’t.)

	'''Turning point: The Teacher View		'''Turning point: The Teacher View
Line 54:		Line 54:
	Josh Wairi, a 5th grade teacher at the Healey, got interested in the dashboard design when we stopped by his classroom one day after school in the winter of 2011. Looking together at his computer and printouts, we realized he was already creating spreadsheets of student data from X2 by hand. He was interested in quickly displaying and sorting basic data, to supplement his face-to-face and phone conversations with students and parents. His work showed us the need for what would become the “Teacher View,” a version of the Administrator View in which all the students come from the same homeroom.		Josh Wairi, a 5th grade teacher at the Healey, got interested in the dashboard design when we stopped by his classroom one day after school in the winter of 2011. Looking together at his computer and printouts, we realized he was already creating spreadsheets of student data from X2 by hand. He was interested in quickly displaying and sorting basic data, to supplement his face-to-face and phone conversations with students and parents. His work showed us the need for what would become the “Teacher View,” a version of the Administrator View in which all the students come from the same homeroom.

	Between this stage and the latest version of the admin and teacher views (below), Mica, Seth, and Jedd met with Principal DeFalco several times during the 2010-2011 year and new Principal Vadhera beginning during the summer of 2011 to figure out the highest priority data fields for the admin view and to brainstorm potential uses. Based on DeFalco’s feedback, and with Seth’s programming skill, we developed a dashboard to transfer data from X2 to a user-friendly view. Seeing Greg’s initial prototype, above, sparked DeFalco to suggest additional data fields: years at Healey, score growth on the MAP, ELL status, MEPA scores (English language learner assessments), IEP status, and afterschool program name (in the end, we did not add program name to the dashboard, because it was never made a real field in X2.) From this feedback, we developed the view below (names are fictional to ensure anonymity):		Between this stage and the latest version of the admin and teacher views (below), Mica, Seth (a local technologist who stepped up to tackle dashboard development while assisting with many other OneVille projects), and Jedd met with Principal DeFalco several times during the 2010-2011 year and new Principal Vadhera beginning during the summer of 2011 to figure out the highest priority data fields for the admin view and to brainstorm potential uses. Based on DeFalco’s feedback, and with Seth’s programming skill, we developed a dashboard to transfer data from X2 to a user-friendly view. Seeing Greg’s initial prototype, above, sparked DeFalco to suggest additional data fields: years at Healey, score growth on the MAP, ELL status, MEPA scores (English language learner assessments), IEP status, and afterschool program name (in the end, we did not add program name to the dashboard, because it was never made a real field in X2.) From this feedback, we developed the view below (names are fictional to ensure anonymity):

	[[Image:Admin Dash 2012-01-25.jpg\|1000x500px\|Admin Dash 2012-01-25.jpg]]		[[Image:Admin Dash 2012-01-25.jpg\|1000x500px\|Admin Dash 2012-01-25.jpg]]