Students: Michael Dula 220
Who is here and what do we use that incorporates students?
- FES: student faculty staff directory with photo update, CV, about, bio. Can generate pdfs for printed version if needed. Can update their own information as needed.
Events room reservation calendar, faculty staff student- reserve rooms and also feeds calendar to prevent double entry.
-Media equip checkout: Bass Library.
School of art, Undergrad org committee also use instances. They use student developers, student techs, manage shared computers around campus
-Faculty support department in School or Arts and Sciences: Provide them computers, support labs, software, hardware
-Physics: getting students info they need.
-Center of science and social science: electronic lab notebook project with ITS, primary support.
-Library: communicate what they have to anyone (faculty staff outside researchers)
-International and professional experience: studio abroad: Yale study abroad, simplicity: undergrad career.
What do students/faculty expect?
They're mostly occasional users. Student Developer Program started because students didn't see a program that worked for them, they would choose to build their own. Example: Blue book. Yale Facebook.
Make it easier for students to get information in a way that is secure to University because students will keep building. We don't engage them and we are too slow at doing it. Having a system available 24-7 or having transparency or communication that its being worked on. Creating a text list to send messages when network is down. Opt in system.
Electronic lab notebook: went down and had calls/emails within minutes.
Cloud services, various points of failure.
Faculty: email and backup ITS at Yale hasn't figured out, but other schools have opted out with crash plan. But faculty and students usually find back up solution on their own.
FES uses crash plan, once you set it up you never look at it again.
Closed out project proposals for FY15- it takes so long because there are 12,000 users, lots of money and time, Must make the right decision.
Be transparent with expectations of user experience and what May happen is they hypothetically are backing up there is always a small range for technical error.
Give a range of options with a basic level of documentation, let user pick the best back up or technology option for themselves.
Responsibility is not take for documentation- but this is why its hard for ITS to make a centralized decision for so many different groups, plus, implementing it. Then figure out how to wisely spend to serve all these different pieces. Faculty is same thing, people who don't even want to touch a computer to those who are building interfaces.
Where do we meet them? Courses? Email? Messaging system?
Send out personalized messages to faculty which was more engaging, and have been invited for faculty demos (electronic lab notebook).
How do we send the information out to not overwhelm, the right time to send, the right medium?
What is the balance?
Need to be able to try things and fail. Experiment more with different things. Pilot programs but then learn how to scale up when the green light is given.
Getting faculty to invest in a pilot when they feel it may be a waste of time if its not approved.
Sometimes you end up with a general product, vs one that is better for a specific type of scientist.
The problem with legacy systems. Students are not invested in the old systems, but some faculty aren't willing to let go of them.
Where do students live? Finding the systems they go to. Finding out for sure and not assuming.
Classesv2- starting to get used.