Recently the New York times published an article about how “Student-built Apps Teach Colleges a Thing or Two.” The thrust was that industrious students often leapfrog colleges and universities in terms of functionality around tasks such as course registration, advising, community building, etc. The trouble, it appears, is that bureaucracies are too slow to make these innovations themselves and IT offices “freak out” at some of these innovations.
For the record, I invite students to work with us in ITS to make their ideas for new services a reality. A great example of ITS collaboration with students is the Prospective Course Planning tool in Inside F&M’s Academic tab. A student came to us with the problem of trying to figure out what courses would practically fit his schedule; it’s one thing to know that you need courses X, Y, and Z to fulfill requirements (which DegreeWorks can tell you), but it’s another thing to know when each of the course offerings meets during the week. The student suggested creating a week-view display into which CRNs could be entered and the course’s meeting times visually displayed. We took that idea, had one of our web developers build a prototype, shared it with a few students, and then built it into a fully-fledged app hosted on Inside F&M. It has been a wonderful addition to the tools students have for planning their semester.
That said, there are a lot of issues that can hold back the realization otherwise great ideas.
The biggest obstacle to student development is that we will not provide the type of access to college data that a student developer might need to build some services. Financial, payroll, HR, health, and student data are all obviously off limits. We guard such data closely for both legal and ethical reasons that are presumably self-evident.
We also have a number of engineering and security standards for services that we endorse or adopt. For example, we expect that our services will work on a range of devices and web browsers. Another standard is sufficient accessibility for disabled users. Documentation of design and testing is important as well. Addressing these issues well are complex software engineering tasks. With the right training, our students are capable of accomplishing the required level of sophistication, but doing so takes a high and sustained level of commitment to the idea and its execution.
One particular challenge for IT departments who support student app development is what to do when the student developer leaves the institution or otherwise stops developing his or her app. At F&M, if the app is not built on technology we regularly use, our ability in ITS to keep it running is very limited. Yet, if the service meets a need and becomes what students or faculty consider a critical service, we find ourselves painted into a corner: we have an obligation to somehow keep the service alive though we may not have the knowledge to do so. That, perhaps, more than anything, is a fear that keeps IT offices from facilitating, much less embracing, student app development.
If you have ideas on how we could support student led or inspired app development, we’d love to hear them. Comment below!