Monday, October 25, 2010

Key Findings from 2010 ECAR Study of Undergraduate Students and IT

The Educause Center for Applied Research (ECAR) Study of Undergraduates and Information Technology, is a longitudinal study of students and information technology. The study focuses on what kinds of information technologies these students use, own, and experience; their technology behaviors, preferences, and skills; how IT impacts their experiences in their courses; and their perceptions of the role of IT in the academic experience.

The 2010 results are now available. It is based on 36,950 respondents from 127 academic institutions.

Some random key findings:

- 94% use their library web site for research; 1/3 several times a week or more
- 90% use presentation software and course or learning management systems
- 90% use texting or social networking for interactive communications; only 30% use them in courses
- 89% own a laptop or netbook
- 80% gave themselves 'high marks' on the skills in searching the Internet efficiently and effectively
- ~50% own mobile device; 43% of those use them daily for accessing information and/or email
- 40% use VoIP services, like Skype
- 36% use web-based productivity software
- ~33% are online more than 10 hours a week; the same percentage spends between 11-20%; 9% spend more than 40 hours
- 1.4 % use virtual worlds, like Second Life Sphere: Related Content

Monday, October 04, 2010

The Go.OSU URL Shortening Service: Agile Development in Practice

About a year ago, I wrote about the idea of a creating a University-branded URL shortening service. Late last month, a small team that I collaborated with at Ohio State launched such a service, called Go.OSU.

Right after I wrote my post last year, I created a short project description and shopped the idea around to potential partners. My primary selling point was that the service would leverage the authority of the OSU brand to the shortened URLs that are included in social media, publications, etc. Although I received a lot of positive feedback about the idea, many potential partners were caught up with other projects.

Since there was so much positive feedback on the idea, this Spring I shopped the idea to the Office of the CIO. While receptive, the OCIO suggested that I build a business case document for them to consider. The idea would be vetted through their review process and, if it past that first level of review, the idea would be placed on a list along with other projects seeking funding. The project would move ahead into development if it received funding, or if other support was identified.

Although I appreciate the reality that projects at that level of an organization need to fit into processes and workflow, my gut said that this review process could take at least a year. It wasn't a very agile approach for a such a lightweight project.

Later in the Spring, I was walking through a hallway at a conference on campus when I heard my name mentioned. It was Beth Black, a University Libraries colleague, and Ted Hattemer, from University Marketing Communications, talking about the idea. I jumped into the conversation. In literally 10 minutes, a decision was made that the project would be developed jointly by UL and UMC and that Ted was on board as our (very supportive) sponsor.

No committee consensus.
No formal meeting.
No user survey / needs analysis.

A few weeks later Jim Muir, a developer on Beth's team, demoed for the project team a working prototype. A few weeks! How agile is that?

We pounded on it for a couple weeks and sent Jim all our feedback so he could make changes. Ted brought in one of his designers, Jim Burgoon, to assist the other Jim with the interface design. The project didn't move ahead too quickly over that next couple months due to competing priorities. The project regained momentum in the early summer and was finally launched after we addressed security and legal issues.

Libraries are always talking about the need to be innovative and to take advantage of emerging technologies. Yet, they slow it all down by forcing ideas and fledgling projects to go through formalized systems. As this project shows, innovation is not born in committee and through process. It is born from half-baked ideas and serendipitous meetings and grows by NOT adhering to formal processes or traditional methodologies.
Sphere: Related Content