Mobile App Policy
In 2013, UMass Boston engaged Modo Labs of Cambridge to build the university’s first mobile application. Modo Labs has previously developed apps for Harvard University, Dartmouth, NYU, Barnard, Brandeis, UMass Amherst, and other universities.
Modo Labs develops mobile apps and offers a mobile platform, Kurogo, that enables universities to build upon the original app as needed, adding new modules. Kurogo is a web-based platform, meaning that users will continuously get new information from the app, so long as they are connected to the Internet. This platform will allow UMass Boston to expand the app over time to include more features that meet students’ needs.
App: The downloadable software package that users download from an app store (in this case, either the iTunes App Store or the Android Google Play store).
Module: Within the app, different modules allow users to access different types of information or perform different tasks (e.g., Maps, Dining, News).
Table of Contents
- The UMass Boston Mobile App
- Mobile App Advisory Committee
- How Can I Be a Part of the Mobile App?
- Guidelines for Mobile App Development
- Process for Application
To maintain branding standards and ensure a high quality of user experience (including ADA compliance), the Modo Labs app is and will be the only app officially authorized by UMass Boston. This is the only app that will carry the UMass Boston branding and be identified in app stores online as UMass Boston-approved.
Individual colleges, departments, and other campus entities may request to include their content in the UMass Boston-approved mobile app via the Mobile App Advisory Committee, but they may not create their own apps.
The Mobile App Advisory Committee will serve several important functions as the mobile app expands to include more modules.
- The committee will set priorities for incorporating new features and modules into the university’s app.
- The committee will review suggestions for features and modules proposed by members of the staff, faculty, and students.
- The committee will determine whether features and modules can be produced in-house or if they need to be produced by Modo Labs.
- The committee will review any third-party software applications that have the potential to be integrated with Modo Labs (this includes software that university departments currently use, as well as mobile-only software that departments wish to incorporate into the app).
The mobile advisory committee will consist of members of the Office of Communications and IT Web Services, including
- Anna Pinkert, Digital Communications Specialist
- DeWayne Lehman, Director of Communications
- Jim Wyse, Webmaster
- Linda Modiste, Assistant Vice Provost, IT Application Services
Any proposed changes or additions to the mobile app should be directed to firstname.lastname@example.org.
The Mobile App Advisory Committee will consider modules, features, and functions proposed by faculty, students, or staff at UMass Boston.
Before proposing a module or feature, please download the UMass Boston app from the App Store or Google Play store and familiarize yourself with the current available features.
Before writing a proposal, please see the guidelines below and consider how mobile technology could best help your constituents. Guidelines have been adapted from Villanova University's mobile app guidelines.
Adding features or modules to the mobile app may require additional labor, software licenses, or assistance from Modo Labs above and beyond our current contract. These additional costs will need to be covered by the department requesting additional features or modules.
1. Understanding Mobile
Connecting with mobile users typically occurs through mobile websites (the mobile web) and native mobile applications (mobile apps, native apps, or just apps). Apps can be stand-alone (fully self-contained software downloaded and stored on a mobile device) or hybrid (software downloaded and stored on a mobile device that pulls data from remote servers when it runs). An app can provide key features of a traditional website, but is optimized for a mobile environment and often takes advantage of the unique hardware and features now found on typical mobile devices (e.g., GPS, camera, microphone, or gyroscope). Depending on the goals and objectives of the developer, one or more of these solutions may not be optimal or even appropriate. Finally, some mobile applications are meant for the general public, while others have utility only for a small number of consumers. The UMass Boston app is designed to be useful for members of the campus community – particularly students, faculty, and staff, as well as alumni, visitors.
The UMass Boston app is a hybrid app. The university can add information to the app in the form of new modules, which may contain information distributed by UMass Boston, or information distributed by another, third-party application.
2. Mobile Apps Should Add Value
Any module developed for UMass Boston’s mobile app should demonstrate tangible utility that relates directly to a campus unit or university-related function over an extended period of time. Colleges/departments/offices should be able to answer the following questions for developers:
- What group of individuals comprises the target audience?
- How will the envisioned module make the lives of these individuals easier or better in some way?
- How will the module enhance customer service operations such as more efficiently delivering information or enabling user-verified functions?
- How will the mobile app be maintained and upgraded to remain functional and relevant?
3. Mobile Apps Should Not Be About “Visibility”
The primary objective behind developing a mobile application module should not be to increase public awareness of the university or one of its campus units. Traditional paid media used to advertise or promote is vastly more cost-effective at increasing visibility and attracting attention than the development, launch, and continuing maintenance of the mobile app.
4. Mobile Apps Can Be Tricky
Adding modules to the mobile app sounds “fun” and “cool,” but the developmental process leading to launch of even a modest app can be perilous. The professional mobile app business is competitive and well-funded. Moreover, the mobile app user base has uniformly high expectations. Absent a significant commitment of resources both during the development of an app and after its release, the end product will likely be less than stellar. Importantly, a mediocre (or worse) UMass Boston-branded feature will do nothing to build affinity for the university or enhance its reputation.
5. Bottom Line: First Do No Harm
Creation of a mobile module should be a thoughtfully considered part of a larger digital marketing strategy. A well-researched and -executed mobile app module can enhance UMass Boston’s image because it meets a need and delivers value. Conversely, a mediocre app module can be derided for its failings and also can cause wider collateral damage to UMass Boston’s other digital marketing efforts by negative association.
All modules must make proper use of the UMass Boston brand, as laid out in the university’s brand manual.
2. Web Governance
All modules must follow the guidelines that cover web governance, including those policies that relate to messaging, visual content, and accessibility. The app is a component of UMass Boston’s overall digital media efforts.
3. Style Guide
All module content must adhere to UMass Boston’s web writing style guide, which includes guidelines for titles of university units, punctuation, grammar, and other guidelines for web writing.
The app’s primary audience is students currently attending UMass Boston. Secondary audiences include staff, potential students, alumni, faculty, and campus visitors. Any new modules, features, and functions must enhance the existing UMass Boston app experience for those audiences.
The app is not a replica of the umb.edu website. It is a separate platform; a good module will include content that is curated for the mobile user.
5. User Experience
Any new modules or features must provide a seamless user experience. Users should be able to access information in a simple and touch-friendly interface. There should be a minimal number of steps for a user to reach the desired information, or to perform a desired task. The design of the module should not impede the user’s ability to read important text, load screens, or navigate between different areas of the app. Touch functions like swiping and scrolling should line up with the mobile platform’s standards.
6. User-Submitted Data
Users should not need to input excessive amounts of data to access pertinent parts of the app. Any module that requests personal information or requires passwords from individuals will undergo special scrutiny from the Mobile App Advisory Committee. At no time should users be prompted to share personal data that will then be sold to or shared with entities outside of UMass Boston.
After submitting an application form to email@example.com, you will receive a confirmation email. The Mobile App Advisory Committee will review the form and schedule a meeting with the applying department to discuss details in depth. For questions about the application, contact firstname.lastname@example.org.
The applying department will meet with the Mobile App Advisory Committee and discuss all elements of the application, and collaborate on a solution that is compatible with the current mobile app. If the Mobile App Advisory Committee determines that the applying department’s request is (a) practical, (b) cost-effective, (c) beneficial to our audience, and (d) sustainable, the committee will develop a plan of action.
3. Plan of Action
The Mobile App Advisory Committee will develop a plan of action that involves both design and technical implementation. The plan of action will include plans for implementation and plans for sustaining and maintaining the app module over time.
Some types of implementation will require that an applying department provide funding. This could include purchasing software and images. It could also include costs paid to Modo Labs for particularly complicated implementations.
4. Implementation and Maintenance
After the plan of action has been reviewed by all parties, IT and Communications will work together to implement the app module. The newly implemented modules will be submitted through the Kurogo system after a review by all parties.
The plan of action will specify which departments are responsible for maintaining the content of the app module. Modules that are not maintained and populated with content may be brought offline.