We view the web as a broad platform for delivering applications. Programs such as Google Apps, ProgressBook, Schoology, Public School Works – all are accessed via the internet and run using a variety of coding languages to deliver the function. Hosting applications on the web has the distinct advantages of being device agnostic whereby any device (phone, Chromebook, tablet, etc.) can run the application. Even better, much of the coding language is open and available for anyone to learn. The tools are there for the gathering.
While I don’t want to understate how incredibly cool and versatile the web as a platform is, we do face two distinct problems in the education market.
1) Applications are Terrible
Standards and norms change. New technologies create greater effeciencies. There is a strong tendency for software companies that provide education products to not change. Dated software carry a host of issues – from functionality to aesthetic design (ProgressBook is a great example of a crummy application).
2) No Application
Often there is a need but no application. Equally likely, there IS a solution but it’s really only 1/2 a solution and this solution adds layers of complexity to the end user. For example, we’re currently working at a sychronous solution to curriculum maps. A few companies offer solutions for lesson planning (and some of them are quite impressive), but they don’t necessarily fit our objectives.
Given these two issues, what might a decent sized district do?
We go 21st century and create.
Keith Millard wrote up a nice summary of the “evolution of the doh” (it’s worth checking out – it features an early stab at a role based portal). Suffice to say, this development process started back in 2012 and continues to this day. We started with a simple web page as a portal. After this Christmas break, we will have our first role based portal.
A portal implies a walled garden that collects information. A better analogy for what we’re creating is canvas that allows us to host applications that are pertinent to our district. In this regard we’re taking the lead from the very popular program WordPress. WordPress has a “core”. Plugins are then developed to work with the core.
Our platform has a core as well. Off the core developers can create modules. Modules function as their own applications.
What kind of application/modules? Here are some of them (all in various stages of development):
Really, the skies the limit on what we can develop. The limitation is time and developers.
One way to solve the capacity limit is to open-source the project. We’ve added a GPL-3 license to the code. By making the platform open for others to use, they can contribute to the code as well. I realize that not many districts have resident coders on their staff. But all it takes is a few individuals with some degree of commitment. And, for that matter, contributors don’t have to be staff. Our platform is predominately coded in PHP, a very common language. Computer science minded students could contribute as well.
Every good project needs a solid name. Instead of Portal 3.0, we’ve named this platform Abre. The name is short, simple, and means “open” (which captures some of the intent for the platform). Our goal in the next few months is to release Abre to a public Git.
January 2016 will feature the official launch of Portal 3.0 powered by Abre. We’ve beta tested the past few months and feel confident in going live for second semester. We will continue to add features and refine issues as they arise.
Feedback continues to be appreciated and valued. We’re kindly asking staff to not hesitate in letting us know what they think the new portal needs.
Zach is an Educator, Tech Geek, and Adoptive Father. When he has time, he likes to write @ Edlighten.