department menu

Mobile App Procedure

CSUSM Mobile App Procedure

Approved by CSUSM Mobile App Advisory Committee, July 2016


CSUSM Mobile App Purpose

The CSUSM mobile app is a university-wide tool that makes the campus accessible with the touch of a button.  The purpose of the app is to provide students with current and real-time information, offer simplified access to online services, and serve as a continual point of connection to campus. Driven by student input and user feedback, the app will continue to add new services and evolve in both content and functionality.

Background

In 2016, California State University San Marcos engaged Modo Labs of Cambridge, MA to build the university’s first mobile application. Modo Labs has previously developed apps for a number of CSU campuses including Northridge, Cal Poly Pomona, and Fresno as well as other universities across the country including Harvard, Norte Dame, Dartmouth, NYU, Indiana State University and others.

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, as long as they are connected to the Internet. This platform will allow CSUSM to expand the app over time to include more features that meet students’ needs.

Important Terms

  • 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, and News).

CSUSM Mobile App Branding

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 CSUSM. This is the only app that will carry the CSUSM branding and be identified in app stores online as CSUSM-approved.

Individual colleges, departments, and other campus entities may request to include their content in the CSUSM-approved mobile app via the Mobile App Advisory Committee, but they may not create their own apps.*

*This requirement was approved by the Information Management Steering Committee, July 27, 2016.

Mobile App Team

The Mobile App Advisory & Implementation Team will serve several important functions as the mobile app expands to include more modules.

  1. The team will set priorities for incorporating new features and modules into the university’s app.
  2. The team will review suggestions for features and modules proposed by members of the staff, faculty, and students.
  3. The team will determine whether features and modules can be produced in-house or if they need to be produced by Modo Labs.
  4. The team will review any currently-used or proposed third-party software applications that have the potential to be integrated with Modo Labs.

The Mobile App Team will consist of members of the Office of Communications, Instructional and Information Technology Services (IITS), and Student Affairs including:

  • Becky Hunt, Director of Software Development and Solutions
  • Tyson Bizzigotti, Team Lead, Systems Development
  • Amanda Umphrey, Content Strategist and Accessibility Specialist
  • Andrew Reed, Digital Content Specialist
  • Current CSUSM student
  • Ad Hoc: Cathy Baur, VP University Advancement & Kevin Morningstar, Dean of IITS & Chief Information Officer

Any proposed changes or additions to the mobile app should be directed to the Mobile App Advisory & Implementation Team at mobileappteam@csusm.edu.

Being a Part of The Mobile App

The Mobile App Team will consider modules, features, and functions proposed by students, faculty or staff at CSUSM.

Before proposing a module or feature, please download the CSUSM app to your mobile device 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. These guidelines have been adopted from best practices at other universities and colleges.

Adding features or modules to the mobile app may require additional labor, software licenses, or assistance from Modo Labs that goes 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 and native mobile applications. Apps can be stand-alone (self-contained software stored on a mobile device) or hybrid (software downloaded and stored on a mobile device that pulls data from remote servers when open). 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, such as a gps or microphone. Depending on the goals and objectives, a mobile website or mobile app may not be optimal or even appropriate.

Some mobile applications are meant for the general public, while others have utility only for a small number of consumers. The CSUSM app is designed to be useful for members of the campus community – particularly students, faculty and staff, as well as alumni, visitors.

The CSUSM app is a hybrid app. The university can add information and functionality to the app in the form of new modules, which may contain information distributed by CSUSM, or information distributed by another, third-party application.

2. Mobile Apps Should Add Value

Any module developed for CSUSM’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 providing useful 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 Complicated and Expensive

Adding modules to the mobile app sounds fun and easy, but the developmental process leading to launch of even the simplest app can be complicated. The professional mobile app business is competitive and well-funded and today’s mobile app user base has high expectations. Without 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 poorly functioning 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 well-executed mobile app module can enhance CSUSM’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 CSUSM’s other digital marketing efforts by negative association.

Guidelines for Mobile App Module Development

1. Branding

All modules must follow CSUSM’s branding guidelines.

2. Audience

The app’s primary audience is students currently attending CSUSM. Secondary audiences include potential students, staff, faculty, alumni and campus visitors. Any new modules, features and functions must enhance the existing CSUSM app experience for those audiences.

The app is not a replica of the csusm.edu website. It is a separate platform. A good module will include content that is curated for the mobile user.

3. 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.

4. 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 Team. At no time should users be prompted to share personal data that will then be sold to or shared with entities outside of CSUSM.

5. Module Function Types and Purposes

In a mobile app, there are four potential types of modules:

  1. Content: A content module is generally static information or other content that does not change on a regular basis and requires manual updates.  Examples include general program information, descriptions/instructions, and statements that do not change. Static content is the least desirable module for an app – this type of information belongs on a website.
  2. Information: Live information modules change or update on a daily, hourly, or even minute by minute basis. This type of module is intended to provide real time status information for the app user so that they can plan or act based upon what is happening now.  Examples include the number & location of currently available computers in a lab, hours of operation if combined with real-time open/closed status and queue length, or upcoming feed from events that may include an live news/updates or current scores from an athletic game.
  3. Service: Allows the user to interact with a campus resource or service.  These are simple opt-in, yes-no, day & time types of services.   Examples include access to PeopleSoft or Moodle, viewing & scheduling an appointment, reserving a study room, or reporting a facilities problem.
  4. Transaction: The highest level function for an app is to allow someone to do something that they previously would have had to do in-person or via a browser. These are functions where the app streamlines access, as the user may already be authenticated and allows for interaction with the university to accomplish a task. Examples include registering for a class, completing a payment transaction, purchasing a ticket, or registering & checking in at a ticketed/tracked event.

As a best practice, the Mobile App Team will be focused primarily on developing Service and Transaction level modules.  Informational modules will be considered if they provide a service to the entire student population or campus community. Outside of special events, rarely will static content modules be approved for inclusion in the app, as a statement showing a high value to the student or campus community will be required. Module submission requests should keep these functional levels in mind and the requestor should indicate which level they believe is appropriate for the proposed module. The submission form must also include sufficient information to substantiate the requested classification.

Sources cited:

Villanova University. (2016). Information Technology Policy and Procedures. Villanova, PA: Stephen Fugale and  UCIT Committee. Retrieved from: https://www1.villanova.edu/content/villanova/unicommunication/_jcr_content/pagecontent/download_1/file.res/mobile_app_development_policy.pdf (June 2, 2016)

University of Massachusetts, Boston. (2013). Mobile App Policy. Boston, MA: Mobile App Advisory Committee. Retrieved from: https://www.umb.edu/news_events_media/communications/web_resources_feedback/mobile_app_policy (June 2, 2016)