Mobile Apps | Feature

A Mobile Education: Student-created Apps

Involving students in the development of mobile apps requires institutions to decide what they want to achieve from the partnership—and to know what to expect.

• By Dian Schaffhauser
• 01/01/11

Since 2008, when iStanford stormed onto the college scene as the first campus mobile app, schools from Amarillo College (TX) to Vanderbilt University (TN) have rushed to create their own offerings. Some have elected to do the work in-house; others have licensed the software from a vendor (see "Alternatives to In-House Mobile Apps," below). Still others hope to bottle the same magic that made iStanford such a hit--by turning to their own students for help.

Inviting students to the mobile party definitely poses risks, but it also holds the promise of significant benefits. Students have a chance to participate in a unique educational experience (and possibly to jump-start their careers), while institutions can garner positive PR as well as insight from student developers, who probably know the end user better than university staff.

The key to success lies in forging a relationship that allows students to be students--creative, idealistic, and passionate--while still meeting IT's goals for quality, security, and performance. There's no set formula for what will work: The skills that each side brings to the table will vary from institution to institution.

App-y Go Lucky
Stanford University (CA) stumbled onto its blockbuster more by happenstance than hard planning--which may in itself explain its success. In early 2008, Tim Flood, a senior technology consultant at Stanford, was brainstorming with his boss, Tom Black, the university's associate vice provost of student affairs and university registrar, about their newly purchased iPhones. "Tom held up his phone and said, 'I wonder if we could do anything that would connect to our enterprise systems,' " recalls Flood. "I said, 'Why not? When I get weather on the iPhone, I'm connecting to some big enterprise system somewhere with all the weather information all over the world.' "

To Black and Flood, the project was essentially an experiment. And by approaching it as such, they managed to shield it from the institutional bureaucracy that might have killed it. "If we'd started out saying we were going to develop a mobile application that was going to do all these powerful things and reflect our brand, imagine the sign-offs and permissions we'd have had to get," marvels Flood. "We were just being playful and trying something new because we thought it would be of value."

Given how much media attention has been focused on the student aspect of iStanford, it's ironic that Black and Flood didn't set out to involve students. In April of 2008, Black asked the campus Apple representative, Silvia Herrero, if she could identify a resource who could assist in an experiment. Herrero introduced the two administrators to Stanford sophomore Kayvon Beykpour and they were "immediately impressed with his maturity and strong interest," says Flood. "We established the overall parameters of our working relationship then and there."

The Stanford administrators outlined what would become the first four "tiles" of iStanford: an app encompassing athletics, courses, a directory, and maps. Beykpour was part of a group of five students who made up the entire staff of Terriblyclever, a development company that created Facebook applications using the Facebook API. Apple had just released its software development kit for the iPhone and iPod touch. While the team of sophomores hadn't done any mobile development before, they were enthusiastic about taking on this new project.

By taking a quasi-experimental approach to the project, Stanford achieved something else: It ensured that the students had leeway to brainstorm. "We were given the freedom to imagine what would make sense," says Aaron Wasserman, a Terriblyclever partner (and student at the time) in charge of doing conceptual design and business development.

"By no means was this an exercise in following a scope of work as laid out by Stanford," he recalls. "iStanford was a project that broke a lot of rules, giving students access to data that the university owned, and letting them do with it what they wanted."

That approach, unburdened by institutional requirements, allowed the development team to create an app that would appeal to other students. "It should be user-friendly," says Flood. "It should be approached from the standpoint of the end users. What kind of experience would they want? I would have thought like an administrator because I am an administrator. The students said, 'I just want to find courses.' And they approached it from a complete innocence."

Growing Apps from Seed
A similar process has worked well for the University of Michigan, which has developed a de facto greenhouse program to foster student-built apps. The university recently ran a "Mobile Apps Challenge," in which students, as well as faculty and staff, were invited to enter their apps and win prizes such as iPads and gift certificates.

In October, the school also hosted its third 48-hour mobile apps "hackathon," where students came together to build mobile apps for the Apple iOS and Google Android platforms. Among the apps created: One helps drivers find campus parking lots that mesh with their parking permits, while another allows Android users to print to any university printer from their mobile device. The university is also developing programming interfaces for use by developers of mobile and non-mobile apps.

From the university's standpoint, the student-built apps have been a great way to jump-start in-house development. In 2010, for example, the Ann Arbor school acquired an iPhone app named iWolverine that was created by two students. According to Cassandra Carson, mobile applications product manager, the school's Information and Technology Services department then began work on an Android version of the app, expected in 2011, as well as additional apps for the campus community.

Now the U-M Mobile Center, U Michigan's Web site for mobile applications and development, provides a link to the latest version (1.0.2) of what has been renamed Michigan, as well as descriptions of other upcoming campus apps, including MFile (which will provide users with secure access to institution-hosted files), MPrint (for printing to campus printers from a mobile device), and Student Academics (which will provide a schedule of classes).

Honoring the Code
Using student-built apps as a foundation for in-house development doesn't always work. That was the case at Southern California's Cal Poly Pomona, where Shawn Irvin, a student in the computer information systems program, created Cal Poly Pomona Central, an app with typical mobile campus features that could be downloaded for free in the Apple iTunes Store.

Impressed by Irvin's initiative, Curtis Clark, director of the university's Division of Instructional and Information Technology Web Development, offered him a job as a student assistant in the department. Clark hoped Irvin would start work on a Android version of his program, while the other members of the department worked on Web services to replace some of Irwin's somewhat manual processes. Irvin turned the job down, opting instead for a position with another software company.

Part of Irvin's decision was based on his desire to retain the rights to his code. "He was afraid that he'd turn the code over to us, we would have him working with us for a while, and then we'd lay him off," Clark says. "I could assure him that we wouldn't do that, but I won't always be the director of the department. And there was no way we could buy his code--we don't have the money to do that."

The university's decision not to buy the code went beyond money. For starters, Clark was concerned about how Irwin had developed his data sources. "Developing the mobile app itself is a much less difficult part of the process than developing the data sources," he notes. "That was one of the things that Shawn ran into." For the app's directory, for example, Irwin "scraped" the data out of a publicly availably PDF phone book. Clark offered Irvin access to the XML file that's used to generate the campus directory, but the student didn't take him up on the offer.

Second, Clark was concerned about the quality of the code. After examining it, he determined that there was nothing in it that couldn't be duplicated more professionally by the department's own developers. "If we were to develop it from scratch, we'd develop better data sources," he explains. That meant that workarounds created by the student to handle static data wouldn't be necessary.

The school now has opted to create its own app in-house. The campus developers have access to the code used to create interactive maps on the university's Web site, a major step up from Irvin's static map. They have other ambitions, too, such as adding functionality that lets users point their mobile camera inside a building and have the app guide them to such destinations as the closest restroom.

Keeping It Simple
Still, if an institution's goal is to involve students--for educational reasons, for PR, or as a recruitment tool--then static data sources are okay, says Stanford's Flood, who believes that keeping the specs simple early on helped iStanford get off the ground.

"If you try to do something complex, people get bewildered because it's a new technology to begin with," he says. "If you say we'll use existing data, it makes it easier." To generate a list of courses, for instance, Stanford provided an extract from a PeopleSoft application. To create a contacts list, it provided an extract from the LDAP directory. Like Irwin's Cal Poly Pomona app, there was really nothing dynamic about the first edition of iStanford. It was only later on, Flood says, that "we began to produce more timely extracts so you could get information that was live and up-to-date."

Even when the specs are kept simple, it's important for institutions to understand that the tech department will still have work to do. In Stanford's case, Flood knew that the students' lack of knowledge about PeopleSoft would have to be reconciled. The students' initial design didn't really have a way of specifying in which term a course was being offered, which was a requirement for the course listings. "They weren't knowledgeable about the how the real back engine works," says Flood. "But the key elements of their design were very refreshing."

It's also worth remembering that a student will approach a development project with a different mind-set than a professional programmer. A student who codes a mobile app is typically more anxious to get it done than to get it right. At least, that's what Gregory Jackson, Educause vice president for policy and analysis, has observed in his 13-plus years as CIO at the University of Chicago (IL) and four years as director of academic computing at MIT. That makes working with student programs a challenge for professional coders. According to Jackson, the person who has to adapt the student code often says, "Gawd, this is awful code. Let's go back and do it right."

It's frequently that second programmer--the one who isn't in such a hurry--who does the work to make the app worth disseminating. That's the person who will often work with data sources to provide dynamic information--the actual GPS location of the bus rather than a static shuttle schedule--giving the app the "cool" factor.

The Company You Keep
As much as Stanford's Flood stresses the need to give students plenty of room to think and dream, he says he would not have undertaken the project the way he did if the students didn't have a company behind them--or a signed contract. Otherwise, the risk is that the students may lose interest, be unwilling to accommodate institutional needs, or simply make mistakes.

"These are young minds--very bright people--but they don't have experience," Flood notes. "It's different from doing a lab assignment or homework or a project for class, because this is something that's going to exist. You can have a student develop an app as a volunteer, temp, independent contractor, or company. We feel the latter provides a better chance of ensuring better results--results that are sustainable beyond the student's years on campus."

Despite the fact that they were working with a company, Flood and Black never lost sight of the fact that they also had a role to play as mentors. "We introduced Kayvon and [the] team to the Intellectual Property and Information Security offices," recalls Flood. "We made sure the branding of the app conformed to university policies; we worked with the students and our procurement people on a contract with a statement of work. We explained to the students that they would become our vendor. But at the same time, we enjoyed a special relationship with them because they were students."

Regardless of whether iStanford succeeded because it was the product of students, an outside company, or both, the fact remains that it has exceeded all expectations. At last count, 64,000 people--44,000 more than attend or work at Stanford--have downloaded the app. It has also been featured on Stanford's home page multiple times as part of the university's branding. As for the students at Terriblyclever? In July 2009, their company was bought by Blackboard.