A change of pace

Due to the discovery of mold and asbestos in the area the AVL was storing gear while waiting for a more permanent location, all that gear needed to be relocated--quickly. With a deadline of Tuesday to clear the area, a new temporary storage area was assigned on Monday morning.

Moving and Setups was involved in moving the large items, but extra hands were needed Monday morning to clear shelves, sort items for surplus, move smaller items, etc. So, I spent about two hours helping with the relocation. Since I'm at a lull in my project, I had some time to volunteer to help out, which was very helpful for the AVL since some staff members were on vacation this week and some others had an important tour scheduled.

After lunch, I was able to get back to working on scenarios. I still have a few to write, then I'll do some editing and refining, but they're coming along nicely. It was actually nice not to be stuck staring at a computer screen, trying to write scenarios, all day.

Writing scenarios isn't as simple as it sounds. I have a very thin skeleton for each (e.g., anthropology professor looking for related projects), but actually imagining the who, what, and why of each situation requires thought. Scenarios are better if they are logical, if they are something that someone might actually do.

The anthropology professor example above? That's a 3-paragraph scenario as currently written:

An anthropology professor has attended a Digital Humanities Workshop and is interested in working with the AVL. She remembers seeing examples of projects that other researchers have done and thinks there are ways to do similar projects with her research, but wants to explore some of the projects on her own.

A staff member referred her to the Showcase portal, so she begins by searching for “anthropology” to find projects in her particular research area. “Anthropology” is mapped as a synonym for the tag “social sciences”. Her search results show all the social sciences projects in the Showcase.

The professor peruses the projects, selecting some to view more information. She opens a handful of the projects to see the full project rather than a text overview. While exploring, she is most interested in the digitization of objects and the different ways to display them: 3D printed objects and augmented reality. With this in mind, she contacts the AVL to talk to a staff member.

 It takes time to think through what the scenario is, why someone would need to find the information required in the scenario, who that someone might be. How is easy. It's building the situation that's hard.

Most of my scenarios involve staff members, the main audience for the Showcase portal. But I did include the above scenario to show how a client might use the Showcase. There is also a scenario that involves someone using the Showcase to demonstrate how their organization could benefit from digitizing objects, what some of the options might be, how digitization has been used. I can see it being used as a way to convince TPTB that it's worth pursuing.

I'm not sure if the Showcase will be used this way, but I wanted to consider future possibilities because that helps inform the current design. If those use cases and scenarios aren't considered, it won't be designed for growth, which would limit the useful lifespan of the portal.

Takeaways: 1) It's good to walk away from the computer and do something else from time to time. 2) Sometimes you do things that aren't necessarily in the job description. (Granted, if it were a regular occurrence, the job description would probably need to be rewritten, but every job I've ever had has had the occasional "we're all in this together" task.) 3) Because of the jobs I've had in the past, which were very much tied to productivity, I have to fight feelings of guilt when I just stare at a blank computer screen for half an hour, thinking. Eventually the words come and I type something, but time to think is a luxury I'm not used to in a job situation.

Use cases and scenarios

The end of this week was pretty quiet. I was able to put my headphones on and listen to podcasts while I worked on writing use cases and scenarios. I was able to put together a half dozen or so use cases (all very similar, but that's how use cases will be for this particular project). From those, I created a use case diagram, although it might not be particularly useful.

Showcase Use Case Diagram

The use cases are actually more extensions of a basic use case of "search portal", but I wanted to extend it to more specific types of searches. Also, the actor is generally a user, but there are three basic types of users who might use the portal, so I extended those roles. It isn't the best diagram; I'll probably make changes to consider more of the input and maintenance side of things. But it's a start.

From this, I wrote up the use cases specifying some of the actions to do each of these searches. These correspond with the ten or so scenarios I have started writing, which look at specific types of the use cases. For example, I have written a scenario of an anthropology professor looking for previous projects that might be in similar disciplines to get an idea of how she could use the AVL's resources and expertise for her own research.

I only have drafts of a couple of the scenarios written, so I need to work more on those next week.

In terms of use cases, there is plenty more work I can do, as noted above, by expanding to use cases and scenarios for input and maintenance. I want to finish the end-user scenarios first, though, because it's easier to concentrate on one thing at a time. Also, I find that letting a problem simmer in the back of my mind for a few days tends to help clarify it.

As for take-aways this week, it really comes down to being in a self-directed phase to some extent right now. At the last meeting we came up with a list of tasks for me to work on during the development phase so I have some things to work on, but I get to decide which to do each day.

The AVL is a group used to being somewhat experimental. Granted, they want their experiments to succeed, but when you push the envelope, sometimes there are failures. The point of failures is to learn from them. In that regard, working with the AVL has allowed me to take some chances and try things multiple ways if need be. Having the freedom to try something, then just redo it if I'm not happy with it, is kind of nice. It isn't seen as a waste of time and resources; it's a learning process, which is actually perfect for an internship.

Development phase

Just before spring break, I passed the schema and structure document to the developers on the team. They said the document I created was useful, which is good. I'm glad I was able to provide them with the information they need. 

They are researching the best way to implement the plans. There are a lot of tech considerations; there might be a solution that already exists that will get them most of the way there, or they might start from scratch. I might be able to follow along with some of their decision-making, but there isn't a lot I can do at this point in the project; development is their job.

I'm actually glad I don't have to make some of the decisions at this point. I'm glad there are developers who like to do the coding and all the other stuff involved with this part of the project. That is not my forte and not something I am overly interested in doing. So I am happy to hand the project off.

Basically, it might be a while before the Showcase comes back to me for UX testing. 

Time to wait....

So, what am I working on while the project is in development? 

• Synonyms
• Personas
• Use cases

Synonyms: I have a good start on this part of the project. There are three of the facets that require synonyms: campus (done), discipline (maybe done), category (I need the final vocabulary for this first). 

Campus was easy. We are using the format "IU Bloomington" for campus, so synonyms are "IUB" and "Bloomington".

Discipline is a little tricky. I settled on using the existing schools as the base, but that's still complicated because different campuses categorize fields a little differently. But, it's the cleanest way I could come up with the categorize disciplines. The synonyms, then, involve putting all the departments and certain institutes and such under the appropriate discipline (school). There are a few that I want to discuss before finalizing the list.

Category is not done at all. I am relying on the team to come up with the appropriate categories for technologies and initiatives (which may end up being the name for this facet). Once that is done, I can work on synonyms, but that will again require some assistance from team members as subject matter experts.

Personas: I have my proto-personas from earlier in the project. I didn't truly finish them, giving them names and personalities, so I will finally do that. 

Use Cases: One of the tasks I have been asked to do is come up with some use cases. I have a list of four or five that I will write up. I would like to come up with a few more. Basically, the point of use cases for this project is to think about who might need to find what types of projects and test that the interface has been designed such that those projects could be found.

If I finish the synonyms, personas and use cases before development is done, I think I can start some UX testing on low-fi prototypes. I have the wireframes I created, so I could work from that. 

Take away today: It's always good to have other things to work on. 

Structure and schema

Over the past two days I have been working on the documentation of the structure and schema for the showcase portal. I needed to get it done by the end of the day today since I'll be off next week and the developers need that information.

Schema: 
I defined the facets for the schema, described their inputs, what they will do in the entry interface and in the portal interface. It took some time to write up the descriptions. I had to consider whether or not each element was required, because not all elements will apply to all projects, and how each element would be handled in searches.

Boolean AND and OR make a difference in the advanced search. After considering how the elements work together, I defined the Booleans values thus:

            Selecting multiple facets in an advanced search should search with a Boolean “AND”; results will be returned for projects meeting all search criteria.

            Selecting multiple terms in a single facet in advanced search should search with a Boolean “OR”; results will be returned for projects meeting any of the search criteria.

The logic behind this is that if someone wants to search for a virtual reality (category facet) project in medicine (discipline facet), they want projects that meet both criteria. If someone is searching for projects that are virtual reality or augmented reality (both in the category facet), they want projects that fit either criteria.

Structure:
I also diagrammed the structure of the portal and made wireframes for each of the four page types.

Portal site structure

I had a rough draft of the home page that I was able to update based on the notes and decisions from Monday's meeting. I also wireframed the advanced search, search results and project description pages. I also took a sample project from that spreadsheet of examples and used the information to create a mockup project description page to show what an actual page might look like.

Now that some decisions have been made, I have felt very productive. Wireframes, sitemaps (the structure diagram), the detail of the schema--I was able to get a lot of work done in two days. I submitted the document to the developers this afternoon. Hopefully it contains the information they need to get started. And hopefully they will give me feedback after spring break if there was anything missing or if anything was unclear. 

The point of the internship is to learn and to gain experience. Most of the projects I have done to this point have been theoretical class exercises, so having feedback from actual developers on an actual project will be helpful for my future practice. Did I use correct terminology? Were the diagrams understandable? Did I provide the information they needed? Too much? Too little? Did I miss something? I look forward to hearing back from Dave and Patrick when I get back in to the office.

Movement

Monday morning included a meeting with my supervisor, the group manager, the director, and the two developers. We settled on the facets or types of data we will need for each item in the portal. We agreed to some formats and some of the controlled vocabulary. We have a pretty good idea of what the final product will be like.

The whiteboard.

The facets, the data that will be input with each item, includes a text title and description, plus year, campus, discipline, category (of technology or initiative), people (involved in the project), tags (any pertinent metadata that isn't covered in the other fields), and media (an image to represent the project and a URL to the project page).

At this point, much of the project turns over to the developers. They are researching database needs and a few other odds and ends. I will write up some documentation: description of the schema and the structure of the site. There will be two aspects: the input system and the public facing system.

I need to get documentation to them by the end of Friday before spring break begins. During the week that I am off, hopefully they will be able to get a start on the development side of things. The timing of spring break is actually working out well.

After spring break, I do have a few odds and ends I can work on while the project is in the development phase, but I'm coming to kind of a pause point. Once they have some of the development done, I should be able to begin some UX testing. We'll need to "seed" the new portal, so testing the input system first makes sense (because then we can start entering projects).

I'm not sure how much of the seeding I'll need to do. I can possibly come up with some recommendations for the project pages (the portal won't actually host the projects, just be a portal to access them; staff will have to create project pages on their personal sites).

Takeaway this time: There's an ebb and flow on projects. Working with a team, there are times when you're busy and the project is sitting in your hands, and others might be waiting on you. And then there are times when the project is in someone else's hands and you're waiting for your next steps. Luckily I have some loose ends I can tie up in the meantime (after spring break).

Versions 1 through 6

When I started working on the field filter, I made a list of all the schools and departments on all eight IU campuses. I then tried to create a "bottom-up" organization system, but I wasn't satisfied with what I came up with.

After five versions based on taking the departments and trying to organize them into established categories like science, social science and humanities, there were still about 15 fields and departments that weren't easy to categorize.

I decided I was going about this the wrong way.

The reason I started from all the departments was to try to make the controlled vocabulary robust, so it could accommodate the fields of future projects. Rather than have an ad hoc system for adding new fields as new projects are added, I want the fields to be ready for use when they are needed.

What occurred to me Thursday was that all those departments are already in schools. 

By starting at the school level, putting comparable schools from each campus together, I was able to create a sixth version of the controlled vocabulary for fields. And I like it. School level is still too broad for some areas (humanities, sciences, social sciences), but most schools are already narrow enough to work well. For the others, I want to expand them (science -> biology, chemistry, earth science, physics and astronomy).

Matching schools across campuses.

I realized that"top-down" is the best way to create this particular controlled vocabulary and organization scheme because:

1. When staff need to add a new project, they will know what school or department they were working with. Rather than artificial groupings, by using the organizational structure already in place at the university, it will be easier to categorize the projects.
2. If someone from a department or school is looking for projects that are in their field or a related field, they will have an easier time picking the "correct" field by being able to associate it with the school they are in.

I also used a few of the sample projects as test cases, listing what fields each would be tagged with. The differences between version three (the previous version I liked best) and version six are subtle if they exist at all. But the sample size is small, with biases toward particular fields. The big differences are in the fields that aren't as well represented in my sample. (The biggest difference is actually just the organizational structure and not trying to shoehorn fields into categories.)

I feel pretty good with version six. Which is good, because I need to present a solution at a meeting on Monday.

I also made a preliminary wireframe of the homepage based on feedback from the previous meeting and implementing the filters I have been working on. 

Takeaway: Sometimes you have to start over. Sometimes you have to step back and rethink. And it always helps to keep the audience and end users in mind, because that helps inform more usable choices. (Sometimes the best choice isn't the objectively "correct" choice.)

Fields, still

I'm still working on fields.

Next Monday, I am supposed to present a solution for the controlled vocabulary. And I'm still working on fields.

Part of the problem is that my supervisor has been away at a conference for the past week, and I'm at a point where I need some feedback. So, I'm waiting. Hopefully she'll be back tomorrow and we can meet, even briefly, to go over what I have so far.

I've had plenty to do trying to sort and narrow and expand fields. I created index cards so I could look at all the fields, move them around, see which felt closer and further from each other.

That's a lot of academic fields.

I have also been working in my spreadsheet, documenting how I am sorting fields so I can justify my decisions. 

A highlight of Monday: the new User Experience Office (UXO) gave a presentation to interested staff. They introduced what user experience is, talked about why this new office was created and elevated to cabinet level, rather than the afterthought that the IT communications office (ITCO) sometimes seemed to be. It's very exciting that UX is getting a lot of attention. They are going to be hiring some new positions soon. I need to keep my eye out for those postings, although I don't graduate until December. 

Take away this week: Sometimes working on a project can seem like spinning your wheels, especially when you have to wait on other people. But, opportunities can appear if you keep your eyes and ears open.