Technologies, Assessment, and the Future of Student Affairs

Technology is already a significant component in all facets of student affairs. Technology has played a role in student affairs for several decades as Kevin Guidry shares in this blog post about student affairs technology competency.  Moving forward, the new types of technologies and how quickly they evolve will pose challenges and opportunities. This blog post includes what I see as changes in the landscape of consumer technologies and how campus information system providers will need to change their approach in designing applications for devices and how end-users may interact with systems in ways they don’t do today. It will also talk about assessment, the limitations of current systems towards a complete analysis and evaluation of data from different sources, and how to potentially overcome these constraints.

The future of student affairs will include consumer technologies including mobile, data, sensors, social media, cloud, wearable computing, and location-based systems. This possibility is by no means a stretch if one is to consider what already exists outside the world of academia and follow consumer technology trends. I’ve written a couple of  blog posts about possible scenarios in the near future of student affairs using technologies I mentioned above. This blog post and this also talks about how I think wearable computing, specifically Google Glass, can be used in student affairs. The use of consumer technologies can no longer be ignored by IT and other campus service providers. For one, there are privacy, policy, and ethical considerations that must be addressed as data freely from one device to another enabled by cloud services (Dropbox, Google Drive, etc) and increasing availability of internet connectivity. In addition, the design and development of campus systems must consider how consumers of these systems expect them to work. As it is, legacy systems designed before the wide use of mobile are not mobile-friendly, and campus IT and vendors are still spending their time retro-fitting these systems to provide mobile interfaces.

As the development of enterprise campus systems like learning management systems, residential management systems, student information systems, and other administrative systems take years to complete, it’s probably wise to think ahead of what consumer technologies may  be available two or three years from now and design for them. I believe one of the major considerations when designing these systems is how users interface with the systems. Most systems available now are through graphical user interface (GUI) such as web sites. However, developers must also think about presenting systems through Conversation User Interface (CUI) which provides user interaction through voice. Apple’s Siri, Google Now, and Microsoft’s Cortana are three technologies that are now available via CUI.In addition to GUI and CUI, developers must also provide users the ability to interface with systems using gestures, which I consider to be part of the Natural User Interface (NUI) approach. Consider the fact that a user can now wink when using Google Glass to take pictures or that a user can use Leap Motion or Kinect to control objects on a screen.

Another consideration is the possibility of how data that may have been designed for a specific use today may be used differently in the future. For this reason, it’s wise to design applications to provide these data through services that can be consumed separately and in ways that may not have been thought of before. For example, one set of data that is commonly used across student systems is student demographic data. While in the past, this set of information may have only existed on the campus student information system (admissions, registrar, financial aid), increasingly, functional systems (judicial affairs, housing, etc) often provided by vendors, are now using this information for operational use as well as for assessment/reporting purposes. The older (and most likely used today) is to provide extracts of this data set, and send it to departments responsible for managing these systems via text files, which they then import. A more effective way would be to expose these data through API (application programming interface) including web service which can be used by these other systems without manual actions, given proper permissions.

One topic that has gotten more attention in student affairs and involves enterprise systems that cross campus units is assessment. The need for assessment is because of the seemingly greater need for accountability by the government in light of questions surrounding the purpose/effectiveness of higher education as well as to show the value of the work student affairs do. This is in addition towards efforts by departments to improve how they conduct their business (operational) and how effective they are towards meeting student learning outcomes. A major obstacle towards a complete campus assessment, or just within student affairs, is the fact that so many of the systems including student health, counseling, judicial affairs, disabled student programs and other student service systems are not designed to be able to seamlessly communicate and exchange data with each other. This is one of the challenges I discussed in this blog post about Higher Education and Data Liquidity. Moving forward, there has to be a way for these separate systems to be able to communicate and exchange data. At the least, there has to be a way to combine these data into a central database for analysis. One approach to solve this issue would be to have common data format that these systems can use, similar to a common eTranscript system by Parchment which enables high schools and colleges to exchange transcripts electronically. Additionally, a proposal I had recommended is to create a common markup language that can be used across all types of learning institutions. This is a learner centered approach which accounts for the fact that students are no longer receiving or completing their education from a single place, also called the student swirl.

It would also be wise for student affairs practitioners as well as IT departments providing support to student affairs units to lead the discussion when it comes to how vendors should design their systems to overcome the constraints above. As it is, there really are not too many vendors focusing on student services who are developing systems that can accommodate the needs of student affairs as whole. A company that can do this would need to have domain expertise in areas within student affairs that are so distinct (student health vs residential life) from each other to be able to develop systems that go beyond just a department or two. I think NASPA and ACPA, the two student affairs national organizations, should lead this charge as they should have a better perspective on what the general needs are across institutions. In leading this charge, they need to work with other organizations representing specific functions within student affairs to understand the specific needs within these areas. These organizations include but not limited to  AACRAO, ACUI, ACUHO-I, and NACE to name a few.

There are so many more topics and questions to discuss when it comes to the use of technology in student affairs. This post is just a small piece of that discussion, though I hope it provided readers, like you, some ideas and questions to think about when it comes to the future of student affairs.

2 thoughts on “Technologies, Assessment, and the Future of Student Affairs

  1. Pingback: Blogging as Part of Identity Development/Exploration | Joe Sabado - Student Affairs & Technology LeadershipJoe Sabado - Student Affairs & Technology Leadership

  2. Pingback: Likely Scenario with the (Near) Future of Student Affairs Technology | Joe Sabado - Student Affairs & Technology LeadershipJoe Sabado - Student Affairs & Technology Leadership

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>