Mobile
Building Mobile Apps for Faculty
The University of Wisconsin-Madison's application development team meets faculty mobile app needs by working collaboratively, managing goals and expectations, and emphasizing transparency.
Shutterstock.com
Recently, the application development team at the University of Wisconsin-Madison created a Web-based tool that allows students to explore genetic variation. Developed for a professor in the Biochemistry department, the application lets users manipulate a series of data in order to demonstrate the effect on a genome sequence.
"The faculty member approached us with an Excel spreadsheet and a series of equations," recalled Andrew Goldstein, the university's assistant director for Learning Solutions, DoIT Academic Technology. "This was a high-level concept of how he would like to present the data visually. Our team implemented the concept, combining the data and math with an engaging user interface, thereby enabling students to explore genetic variation in a graphic manner."
Working with Faculty
Creating mobile apps for faculty is the work of a full team of developers at UW-Madison, including six full-time and three part-time staff as well as the assistance of several students. "We emphasize faculty more than many other institutions," said Goldstein. He noted that about 80 percent of his department's time is spent on faculty software development. The other 20 percent is spent on learning management systems or research initiatives. "In other words," he said, "it's 100 percent faculty-oriented."
"For application developers," Goldstein observed, "working with faculty poses some unique challenges and opportunities." For instance, he said, because faculty members are usually very busy, getting their focus and engagement over the lifecycle of a software development effort can be difficult. In addition, they're generally not accustomed to the nuances, timelines and costs associated with custom application development. And their funding sources and intended audiences can introduce constraints and complexities into the process.
"On the other hand," Goldstein continued, "many faculty members have a high degree of comfort with experimentation, so the notion of iterative delivery and continuous improvement may resonate with them." On the whole, he has found faculty comfortable with leaving technical decisions to technologists. "They tend to allow software developers a great deal of freedom in how they go about achieving their results."
Like all collaborative relationships, managing faculty projects requires creative thinking, patience and, ultimately, the ability to get to the underlying problems that faculty are attempting to solve. "The goal of a software development project for faculty members might not always be one of efficiency or automation," Goldstein noted. "It could, instead, be one of exploration and innovation."
Goals and Expectations
With faculty, Goldstein observed, setting expectations starts right away. "Faculty members are in partnership with us. They don't just go away and come back again in a month and the project is done." The development team requires a commitment from faculty to provide feedback throughout the development process. "We have an initial conversation in which we unpack what the faculty want," he said. "Usually, the challenge is in the first 20 minutes of conversation. After that, we're able to get them on board if we are authentic about expectations — both on their side and on our side. We try to let them know everything up front."
Most of the department's faculty customers embrace this type of collaboration. The arrangement is verbal when the developers first meet with faculty; then after both sides commit to the work, the development team creates a charter with a statement of work, detailing the development project. Goldstein emphasized that this is not a contract, but that the written document creates a culture of collaboration. "It's something between a contract and a memo of understanding," he explained. "My goal is to build relationships, not to build projects. We have to deliver. We have to hold ourselves accountable. And we need some mechanism for holding the other party accountable."
If the collaboration is not a good fit, the development team may recommend that faculty go elsewhere for services. There are "small pockets" for service elsewhere on campus, or he may refer them to an external provider: "Sometimes they need a throat to choke," he said — for example, if there's a fixed deadline or if they need an ironclad guarantee.
The Responsive Approach
The development team tries to steer faculty customers away from native apps, in favor of Web technology and responsive tools. The responsive approach, Goldstein explained, is an acknowledgement that the proliferation of mobile and tablet devices in the market — coupled with the variety of vendors, screen densities and form factors available — make it a challenge to build applications that are usable and practical. The responsive strategy, he noted, utilizes a single code base and supports browsers on a variety of devices. The user experience is carefully curated.
"My preference is a nod to the fact that there is so much fragmentation in the mobile device market that native strategies often require too much complexity and redundancy to pull off," said Goldstein, who refers to the native app approach as "not dead or on life support, but in the senior citizen phase." Hybrid strategies, in theory, are written once and read anywhere. "But, in practice," he cautioned, "you miss out on some key aspects of user engagement if you try to accommodate all platforms."
"If faculty sign off on doing things responsively," he added, "we can spend our time focusing on developing the app — not on how it will be displayed."
Best Practices for Developing Faculty Apps
Goldstein and the UW-Madison development team offer the following tips for developing mobile apps to meet the needs of faculty:
- Try to stay away from preconceived notions. Often, faculty will reach for an analogy with existing tools. It's better to get at what is the intent and purpose of the application. Then, let the design fall where it may.
- Be transparent. Make sure faculty members know what it takes to build an app, and know their role in the collaborative process.
- Work iteratively, building upon simplicity. Start with a feature and build upon success. Use the UNIX philosophy as a guideline: "Write programs that do one thing and do it well." (— Doug McIlroy, Bell Labs)
- Feedback is a gift. "As software developers, we need and want feedback, both on the project and about our relationship with faculty," said Goldstein. "We can't get better unless we're willing to listen honestly."
- Leverage your students as testers. At the University of Wisconsin-Madison, there are 40,000 testers walking around campus. "We need to involve our students; otherwise, we're working on presuppositions and in a vacuum," said Goldstein. Embrace the student community. They're comfortable with change and with feedback. "Students are our beta testers."
