Documenting everything

For the past week I have been writing a project document that will cover everything in this project. While part of the project will be implemented before my internship is done, there will still be work to do. Additionally, the Showcase will need maintenance and updating over time, so it's important that everything be clear and written down.

A year or two down the road, the question might come up--why was this implemented this way? So, I'm trying to answer all those questions. My document has a section on challenges where those types of decisions are addressed.

Some of those challenges:

• Defining the scope of the project--the scope guides every other decision
• The struggle over controlled vocabulary--both gaining consensus and why we chose what we did
• How search is implemented

I think it's important, and my supervisor does as well, to document all of those decisions.

With the semester winding up, there isn't much time left. Hopefully there will be a prototype of the administrative interface, where staff will add, edit and delete projects, by the end of this week so I can do some usability testing. That portion will be fairly simple: each staff member will need to add, edit and delete a project.

The larger portion, the portal, likely won't be ready in time for me to test it, but part of my documentation includes a section on what and how to test the functionality and usability. Search is difficult, and the analyzers used to match strings are not easy to write. So, it's taking time to get that portion of the project to a point where we can really have staff try it. 

I'm very appreciative of what the developers in the group have been doing. I'm even more appreciative that they asked me what my timeline was. With the realization that development is taking longer than scheduled, they wanted to try to have something ready for me to be able to do some UX testing, so I can have that experience, before the semester ends. 

Week two: Diving in

Week two began with being thrown into the deep end.

No time for water wings!

One of the missions of the AVL is education. Several team members teach classes in addition to their daily work for the group, which led to my attending a virtual reality (VR) class to get a sense of both the VR facilities and the educational aspect of the group.

My intention was to sit quietly in the back, being as unobtrusive as possible, but this class session was hands-on and involved students trying several types of VR equipment. The three VR stations (the VCT, a room installation, and two Vives, head-mounted displays) were staffed, but an augmented reality (AR) station at the back of the room wasn't. After a quick, five minute lesson, I was put in charge of helping the students, giving instruction on how to use the HoloLens.

Takeaway: even though my project is completely different, as a team member, I was asked to step in and help out.

The rest of the week was much quieter, mostly involving typing up notes (a work station was finally installed at my desk), writing a draft of a survey for the project, and creating five proto-personas to be used in the design process. The personas are not complete. More exploration will help me flesh them out and possibly reduce them to two or three.

Next steps will involve talking to more team members, including a trip to IUPUI, meeting with the group manager and director, and hopefully moving forward with concrete goals and objectives for the project. One of the difficult tasks ahead is putting together an inventory of images, visualizations, and whatever other digital assets are deemed relevant.