Wrapping up the project

I was able to start UX testing today on a prototype of the site. I'll hopefully wrap up UX testing tomorrow, write up my findings, and add a small section on the results to my final project document and the infoshare slides. 

I'm scheduled to present to the team on Monday, an "infoshare" where I'll talk about the project and demonstrate the (prototype) interface. There's still some development work that will be done, but my role in the project is coming to an end.

Overall, it's been a good experience taking a project from the info gathering stage through (some) development. In classes, I've mostly worked at a theoretical level, designing something without ever talking to the stakeholders. In the IA classes, I've created personas and sitemaps and wireframes and all the various things I've done in this project, but I've never seen the project actually implemented. I haven't my designs translated into reality.

The challenges have been the types of challenges that occur in any working environment: coordinating schedules, gaining consensus, needing to revisit work that's already been done.... 

This semester has been very rewarding and has provided me with valuable experience. 

Moving toward the end

A few posts ago I had a list of tasks to complete. Most of those tasks are done or as done as they can be at this point.

• Personas - DONE
• Finalize controlled vocabulary - Most DONE; category terms sent to manager
• Synonym file - DONE
• Finish use cases and scenarios - DONE
• UX testing - Prepped; testing to be done next week
• Finish project report - In progress

Most of the final project report is done, but the section on UX testing won't be completed until after testing is done next week. I can't report results until I have them! Also, I have some of the technology section done, but I need some details from the developers to flesh that section out.

So, what's left to do?

UX testing

UX testing will be done next week. It looks like I should be able to do both phase 1 (testing the administrative project entry interface) and phase 2 (testing the portal interface). For a while, it looked like only the administrative side would be complete enough to test before the end of the semester, but all the fields have been added to the database, so we should be able to seed it with projects and test the search functionality.

Infoshare

The last item on the internship schedule was an infoshare and staff training. For the infoshare, I will need to present to the group about the project. I'm not quite sure what is expected (there are several ways to present the project, depending on the focus), but I have another week to work that out. I'm sure Tassie, my supervisor, will be able to help me prep.

Staff training

I am not sure if there will be time for staff training before the end of the semester. At the very least, I can probably come up with some 'best practices' for project entry that will make search work better. Having standardized formats and such will ensure that the data are consistent. And consistency simplifies a lot when it comes to search!

Project report

My project report, as noted above, is almost complete. The last bits will get added as I finish UX testing and after I get more information on the custom analyzer, filters, and such for the technical section.

I think that's all I have left. 

I've had a pretty good internship experience. There were a few challenges (scheduling meetings and such, getting feedback mid-semester when people were out of the office, etc), but it's been very positive. All the AVL staff members have been very helpful, answering my questions. I've felt like I belonged, like I was part of the group. 

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. 

Creating config files

The semester is rapidly coming to an end and there is still UX testing to do on the AVL Showcase. I spoke to the developers yesterday about the timeline, and they are hoping to have something I can do UX testing on done by the end of this week or beginning of next week.

To help them reach their goal, I worked on some of the files needed to create the tables in the database and the synonym file. The campus file, the simplest of the tables for the database, was already created by the lead developer; I followed the format to create the files for discipline and category.

The campus file.

The synonyms may be inserted into the custom analyzer, as the example below shows, or it may be read from a file. Either way, I was able to create a file that can be used externally or copy and pasted into the analyzer. 

Synonym format.

The sample synonym code is just an example, not our actual values. The syntax sets up terms that may be entered in search and the term they should result in. For example, if 'usa' is the controlled vocabulary term, a search for 'united states' would check the synonym file, change that to 'usa' and show search results for 'usa'.

The way this file is set up would contract a search. There is another format that would expand a search, which is helpful if there is no controlled vocabulary or the approved term has changed over time. (In that case, the format would be 'united states => united states, usa' and a search for 'united states' would match either 'united states' or 'usa'.)

It has been very useful working on these files. I had read the documentation, but working with the data and values helps clarify what it all means. I have a much better understanding of what is happening with the analyzers from working on this.

I'm really excited to see the project coming together. There should be at least a prototype available to show at the end of the semester when I have to give my presentation.

Working through my list

I had set a list of tasks to finish by the end of the week:

• Personas
• Sending suggested controlled vocabulary to the manager for feedback
• Use cases and scenarios
• Prep UX testing

Here's where that list stands:

• ☑ Personas
• ☑ Sending suggested controlled vocabulary to the manager for feedback
• ☑ Use cases and scenarios
• ☑ Prep UX testing

I was also able to expand the project document. That isn't done (the project is still in development, plus I just haven't finished adding everything I can to this point). I have added an introduction to the project, defined the scope, and started working on the development section, which will need to be added to as the project is developed. I am also writing up some of the challenges and reflections. 

Along with working more on the project documentation, I want to help create the synonym file. I think that would be good for me to learn how to do, plus it would free up some time for the developers to get the backend developed. The sooner we have something functional, the sooner I can start UX testing. 

I think the UX testing needs to be done in two stages. We need to test both the project entry and search functionality. But to test search, we need some projects available to search! Thus, I think we need to have staff enter a couple of projects and test that side of things, then have them go back and search a couple of different ways. The problem with doing it all at once is that the first couple people testing would have only their projects entered, which isn't quite enough.

Monday I need to mention that to the developers.

Reading documentation and next steps

I have spent quite a bit of time reading the documentation for the database solutions mentioned previously. There is a lot to grasp, and it helps if I understand some of how crate.io and elastic.co work, especially since I need to help make decisions on how it is implemented.

Monday brought another project meeting. Dave and Patrick, the developers, were able to present their solution and talk about the proof of concept work they had done. They're moving on to the next steps. Hopefully we'll have a prototype that we can send to staff to test out, so I can do a little UX testing.

I need to do some prepping, deciding what UX testing is the most effective and reasonable for what we are doing.

On my plate right now:

• Finishing my personas
• Finalizing the controlled vocabulary
• Putting together the synonym file
• Finishing use cases and scenarios
• UX testing
• Expanding my earlier schema and structure report into a full report for the project

There is a lot to do in the next three or four weeks!

What I think I can get done this week:

• Personas
• Sending suggested controlled vocabulary to the manager for feedback
• Use cases and scenarios
• Prep UX testing

The reason that list is so long is because I am almost done with the personas, use cases and scenarios.

Takeaway this time around: my lull during development didn't last long. Development is moving faster than I had anticipated. Although the full portal may not be completed by the end of the semester, a lot will be done and there should be a working prototype at the very least! The things I have been working on in the meantime need to be finished so I can move on to the next stage.

Database solution

Thursday the lead developer presented me with the solution they had chosen for the database behind the Showcase portal. Finding the right database or CMS (or building one from scratch) that will do what we want it to do was a crucial decision. Search is hard, which is why most places leave it to Google or some other major company that has mastered search algorithms.

What Dave and Patrick have found is crate.io and elastic.co. There were a lot of factors that went into their decision. Friday they built a test version with very basic data. It works for the simplest of our fields. Next week they will move on and add more complicated fields, ones that include synonyms. That's a big factor in making this work.

At this point, though, they have the first step down toward proof of concept. It's pretty exciting to see a working prototype, even if it has fake data and limited fields.

As for my part, I am reading through the documentation on crate and elastic. There are decisions to make:

• Do we want to expand or contract the synonym search? (See below.)
• Do we want to apply analyzers and filters at the point of indexing, at the point of search, or both?
• We need to finalize the controlled vocabulary and synonyms so the synonym file can be built.
• Do we need custom stop words or stems?

These are some of the questions we will need to address in the meeting scheduled for Monday morning.

It looks like I will help build the synonym file once we decide if we are expanding or contracting. I have an Excel file started, but that isn't the format the working file needs to be in. I am not a programmer, but I am certainly capable of following the format to write the synonym file. And my working on that will speed up development since Dave and Patrick can concentrate on the rest of the code rather than taking time for a tedious task like that.

Regarding expanding or contracting, it isn't as simple as it seems at first. Here's an example:

In our synonym file, "physics" is a synonym for our term "science and mathematics". Projects will be tagged with "science and mathematics", so if someone searches for "physics", we want the search to actually match "science and mathematics".

If the search contracts, which seems like the logical choice, a search for "physics" would contract and return only projects tagged with "science and mathematics".

If the search expands, a search for "physics" would expand and return results that match "physics" and "science and mathematics". Even though "science and mathematics" is the term that will be tagged, it is possible another field (title, description) could contain the term "physics", and we would probably want those projects to be returned in the search results first since they are more likely physics projects ("science and mathematics" would return biology, chemistry, etc). 

So, it seems like expanding is actually the way we want to go. The file is similar either way; it's the syntax that is different. 

Take away: There are a lot of decisions involved in the development side of this process. It's very interesting and useful to be included in some of those decisions and to see a little of how that side of things is done. That might be one of the more useful parts of this internship, actually.

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.

Academic fields and their relationships

As previously mentioned, I am currently tasked with determining the controlled vocabulary for:

• category
• field
• campus
• year

Campus and year are fairly simple. I feel like I have a pretty good handle on category, although that list might undergo minor changes. That leaves academic fields.

I had a rough list based on the fields of the 50 or so projects in my sample (some staff members shared projects, visualizations, and media that they work with; I have used those items to develop the list of keywords and filters that I have previously mentioned). 

Part of the trick with this project is making sure the controlled vocabulary can grow as needed. Currently, there are a few academic groups that the AVL has regularly collaborated with, which creates a bias toward those fields. Bearing that in mind, I started by creating a list of all the schools and departments on the eight IU campuses. 

There are a lot of fields represented by all the departments and schools.

Next step: I sorted all those departments and schools into broad categories: humanities, social sciences, natural sciences. There is a lot of overlap between humanities and social sciences. And natural sciences leaves out some important areas. Changing natural sciences to formal sciences (mathematics), physical sciences (chemistry, physics, earth sciences, space science), life sciences (biology), applied sciences (engineering, computer science, medicine, nursing, etc) is more useful, but also a lot of board categories, some of which really only have one field (yes, there are fields like microbiology, but the goal of this is to narrow the long list).

So I have settled on broad categories of humanities, social sciences, and sciences, with some fields further split out. While the list isn't quite done, I'm pretty happy with where it is right now. There will be some tweaking, but I feel like I have a good base. 

Part of creating this controlled vocabulary is testing it against my sample. I need test cases to demonstrate how the controlled vocabulary would be used. And there are a couple of items in my sample that don't fit any of those fields.

Now, athletics aren't necessarily an academic field, but sports are a big deal at a university. A couple of the visualizations involve Olympic or World Cup data on the Science on a Sphere. The athletic department might potentially be a client (the AVL has worked with the athletic department in the past). So I am considering adding athletics as a field. It's something to discuss with my supervisor, at any rate.

And that's where I am. Refining my lists, waiting to talk to my supervisor. 

Persuasion

Monday I presented my project progress to a small group, including the manager and director. One of the things I have been working on, as you know if you've been reading this blog, is coming up with controlled vocabulary terms for filters.

Filters, especially drop-down menus, get a bad rap from some folks, but they are actually very useful in helping website visitors to find what they are looking for. Without filters or some way to narrow down selections, a large collection of items, which this site will be, can be overwhelming. Yes, it's good to allow free text search, especially if someone knows exactly what they are looking for. But not everyone does.

Controlled vocabulary and filters aid browsing and serendipity.

In the presentation, I ran into some pushback on the idea of having a controlled vocabulary and having filters, because "I hate drop-down menus." So what was supposed to be an hour-long meeting where I presented my progress and we set down next steps became an hour and a half meeting wherein several of us spent about 45 minutes persuading the director that a controlled vocabulary was both necessary and useful.

We did convince him. He did agree that we could implement a controlled vocabulary in a way that would not be onerous and would make things work better.

We also agreed on the categories for filters and/or keywords:

• Category - What is the thing? The controlled vocabulary for this is pretty solid and might need minor tweaking.
• Field - What academic field(s) does the project apply to? I have a start on this controlled vocabulary, but there are a lot of possible fields, plus I want to limit the list to about 20, if possible.
• Campus - Since the AVL spans all 8 IU campuses, a project might be initiated at a particular campus. Controlled vocabulary for this will be fairly simple: we just have to decide on the format (e.g., IUB or Bloomington).
• Year - I think this will be a simple 4-digit year.
• Name - This would be a tricky one for a controlled vocabulary (it could be done). The agreement we came to was that this field would be free-text for data entry, which may or may not be the best. Hopefully we can set a standard (first name first or last name first? initials or full names?).

My task for the rest of this week is to nail down the controlled vocabulary. I'm also supposed to work up some test cases to demonstrate how the controlled vocabulary will aid someone in finding an item.

The original schedule had me designing, which I had started, but they are less concerned with following that schedule than with getting this part worked out since this is where efforts at organization have failed in the past.

Take-away: Sometimes you have to step back and slow down to do things right. Rushing would get something done, but it might not be as long-lasting. Also, sometimes you have to stand up for what will be a better choice. 

Making decisions

At the beginning of last week, I had rethought my designs and added a fourth possibility. And by Thursday I realized that four designs was just too much. I was hired to work on this project, to assess the information needs and design the web portal. I'm supposed to make recommendations.

So I have reduced my design choices to two: 

1. a very simple design with a search box and one or two filters right off the bat and 
2. that design modified to include "easy buttons" at the top with quick links right to some of the project types. 

I like the first design for its simplicity, plus I think it will last longer. New projects and assets can be added in either design, but the "easy buttons" are something that would need to be addressed as priorities change. They are a big, bold way of showing what the top initiatives are so they would need to match that. And I have a feeling it would be more likely the number would grow rather than shrink, cluttering things up.

Priorities can be reflected in the filters, with the way the filters are prioritized and organized. And yes, the filters might need to be adjusted over time, but they are in both designs. I think they are less of an issue for future-proofing the site than the "easy buttons". (Also, the filters kind of do what the "easy buttons" are designed to do. Granted, there are times and places in web design to highlight something that might be buried in a menu, thus duplicating it, but this doesn't feel like something that needs to be done here.)

Monday I will present my progress on the project. Really thinking about what I need to say is what really helped me streamline my ideas down to two. Honestly, the major difference between option 2 and the two I removed was the placement of the filters. It's my job to make the call on where the filters should be, following best practices and design recommendations. And that's why I dumped those two options.

I have also been refining the main filter. I think I have a very useful list of twelve items for the filter that will cover a large majority of projects, including the areas of focus. Of course, the list is open for input at the meeting Monday, since I might be missing something the director or manager wants to emphasize. I may have also chosen a term that needs to be discussed. 

From this mess to 12 main terms.

One of the people I interviewed for the project was someone who might actually need to use the site to find some projects but is not an expert, not an insider. Her feedback on some of the terms was very useful. So, while some of the filter terms I chose may not be the most precise or correct, they are a broader term that will be more understandable to non-experts. As an example, stereoscopic 3D is a specific type of 3D, but the broader term 3D is better understood by non-experts.

There is a second filter I have been working with, which I really thought would be useful when I started. The longer I work on the project, the more I wonder if it will just clutter things up and not be helpful. So, I will present that filter but recommend that we consider not using it. (I'm open to adding a different filter if there is one that I have missed that would be useful.)

Finally, while I will need assistance from staff to gather all the assets for the website, I started a spreadsheet of the ones I have looked at so far (the ones that formed the basis for the keyword list I have been winnowing down). It will need some experts to check the metadata I have started collecting, but I thought it would be a good idea to have something to start with.

Take-away from this week: I'm being paid to make some decisions and recommendations; if the manager and director wanted to make all these decisions, they would be doing the work. I need to be confident in my choices, but I also need to be open to feedback and be ready to adapt. 

Assessing and reassessing

Last week I made 3 rough wireframes to show a few basic ideas for the AVL Showcase website. 

Then I had a weekend to think. And I thought about the idea that the director keeps referring to as his idea for the site. 

So Monday I went back to the beginning and really looked at that example and how the search and filtering work. I took a second look at some examples I had gathered of sorting and filtering. I really spent some time assessing the pros and cons of the differences in the sites and wrote up a brief to explain what I liked and didn't like about each option as it relates to this project. 

I also added a fourth rough wireframe based on that original site, something I hadn't really thought about before in the design.

A 4th design for the homepage

We have a meeting scheduled for next Monday where I will present what I have so far, and decisions can be made so I can move forward. I don't want to spend time wireframing further pages until we establish which of the 4 versions is the most suited. There are pros and cons to each, which I will need to talk about when we meet. 

Once that is settled, we need to prioritize the keywords and their categories, deciding which are going to be used in the filters because I will need those filters for the wireframing. 

Waiting to get feedback

This week involved a lot of looking at lists of keywords, arranging and rearranging them to try to make meaningful sense of all the possibilities. I spoke to a non-team member who might be the type of user this web portal will be designed for. Her feedback on how she would search for projects was very helpful, especially in terms of the labels for the main categories.

I also made some very rough wireframes of the idea I'm currently working with. And now I'm at a point where I really need some feedback.

I have 3 basic layout ideas, trying to balance "easy" buttons with the vast array of descriptors that will be used. Making a decision on which of those ideas to work from will allow me to start wireframing in earnest.

Version 3 of the basic layout

The second thing I need feedback on is my organization of the keywords and which should be used in filters and which just left to search terms. Or, do we leave all of them in a big tag cloud? Maybe not the best idea, but possibly closer to what is desired.

I also need to start gathering the assets that will go into the website. We need to organize the items, give them appropriate keywords, create a database or spreadsheet, write descriptions, etc.

So, I am waiting for my supervisor to look over what I have done and then we need to schedule a meeting with the manager and director so those decisions can be made.

And that's the take away this week: sometimes people are busy and you have to move to another part of the project you can do while you wait.

Looking to the future

Monday morning I attended my first group meeting with the AVL. The meeting was about looking at achievements of the past and looking forward into the future. After 20 years, the group has accomplished a lot but there are always new initiatives and new goals; the cutting edge moves fast. What was advanced visualization 5, 10, or 20 years ago isn't anymore. Technology changes fast and a group like the AVL can't rest of its laurels.

Seeing a glimpse of priorities for the next 5 years was helpful for me because it gave me an idea of some of the top level categories, some of the priorities, I need to use in my design. The site I am designing isn't about the initiatives but about the projects, so the trick now is to separate initiatives from projects.

Looking into the future... or a head-mounted VR display.

It was interesting to see how different folks in the group responded to changes that are happening, who was pushing back, who was on board. In my working life I've been in several jobs where the company has undergone major upheaval, much more than these changes in focus and funding. Changes at one company I worked at were so poorly received by staff that we were all required to read "Who Moved My Cheese" by Spencer Johnson and attend weekly meetings to discuss it.

It's always enlightening to watch the responses to change.

There are folks who push back and resist, who are comfortable with the way things are. There are folks who accept, maybe asking questions, who realize that moving forward involves change. There are folks who embrace change and see it as exciting, a chance to mold the future.

One of the initiatives moving forward that was mentioned at the meeting was my IA project to create a web portal for many of the AVL's projects. Everyone seems to be on board with the project, recognizing that there is value in having an online portfolio of the work the group has done.

Search vs filter

One of the big decisions I am working on for this project is deciding which keywords are for filtering and which will just be for search. 

My preliminary list has over 130 descriptors. That's way too many to work well for filters, but filtering is part of the essential plan for the site. 

So, I need to sort the keywords into groups, decide which are important to use in filters, which might be extraneous, and which we should still use in the metadata for searchability. I'm narrowing down which I think need to be used in the filters with help from staff via card sorting.

I also have started sketching a very preliminary wireframe, those famed boxes and arrows, to explain how I'm thinking about the design. It's helpful to have this when I explain what I want done with my index cards.

Preliminary pencil sketch

What I'm finding as I do this is that it's actually quite hard to group some of these concepts and determining which are important isn't always clearcut. 

In my first pass through the index cards, I created a group I called "purpose" which contained concepts related to how a type of technology might be used. Included in this group were keywords like "research", "preservation", and "virtual tour". 

Now, those might be terms that are useful as filters or not. They may be better left to search. But a conversation my supervisor had today with a potential client highlights how having those types of keywords could be valuable. The people she was talking to wanted to be able to create virtual tours of the library and the different spaces there. Since a virtual tour could be done in VR, panographic images, 360 images, and maybe other options, being able to search and find previous projects that are virtual tours would be helpful. 

So, I'm still sorting and resorting keywords, gathering data, and really thinking about how they might be used. Hopefully I'll have a clear idea by the end of next week so I can move on to designing the interface.

Week four: Descriptors and keywords

My focus this week is descriptors. Descriptors are the words used to describe the various assets, the words that may eventually become keywords. 

I say may because, for this project, not all of the descriptors might be useful as keywords. Some will be in the text description while others will be used as metadata on the items. It's really the ones that end up in metadata that are of particular concern. 

Deciding which facets are important to be able to search on is part of what my job is on this project. So, while there are many ways to describe the digital assets, not all are useful for searching, sorting, or filtering. It's my job, along with my supervisor and the manager, to understand which are useful and which aren't. 

Currently, I have 139 descriptors. I'm still conducting interviews so the list may grow, although each interview elicits fewer new terms. I have started standardizing some of the vocabulary (the original list of terms was over 150). One task I need to start is categorizing the descriptors. With such a long list, they need to be organized into facets or they will be too unwieldy to use. 

Tried and true

My idea is to use card sorting, which is often used to organize the hierarchy of a website, to sort the descriptors into facets. Using knowledgeable staff to help determine what category different descriptors belong to and find good labels will be much more productive than me trying to figure out whether a term should be, say, "technology" or "tool". I'm a fan of using physical cards, especially with a small group of people doing the sort, although there are online tools I could use. Looking into those tools to see if there is one that would suit my needs is on my plan for Thursday.

In classes, I've done some card sorting (in Z515, Information Architecture) and I've created a faceted vocabulary (in Z503, Representation and Organization), but those were mostly theoretical applications or with familiar domains. Actually taking a bunch of information from an unfamiliar domain and organizing it is a little intimidating but also a good test. And, I don't have to do it all myself. That's the point of having the staff participate in a card sort: they will help guide the final organization. They and clients (users) will need to understand the organization and structure, so it needs to be based in already established organization.

Conducting interviews

Part of this week involved a trip to IUPUI to see the facilities there. The facilities on each campus differ, so it was useful and necessary to see that in person. Also, because team members have different specializations, the types of projects that tend to be highlighted on each campus can differ (although all 8 campuses have access to the AVL's knowledge and facilities).

Tyler demonstrating the VIVE, head-mounted display VR.

This week's big step was to start interviewing team members and collecting samples of the visualizations and media that will eventually go onto the website. So far, I have interviewed 4 team members. I have found that an informal style with some questions for guidance works for me. I like to have a conversation, eliciting the information I need that way.

Jeff showing some of his work on the IQ-Wall in the AVL's IUPUI lab.

The types of information I am gathering in these interviews involve the team members' roles and specializations, what sorts of projects they work on, and specific examples of projects. The questions fulfill 3 purposes: 

1. What are the user requirements for this portal? 
2. Who are my subject matter experts? 
3. What types of descriptors (search terms) will we need? 

So far, from the examples I have gathered, I have a list of over 100 descriptors ranging from type of media to technology tool to fields and disciplines--and I haven't looked at some of the areas the AVL works in. There is a lot that goes into building the search terms and metadata that will make this site work. I'm glad I took Representation and Organization, as that will help with building a vocabulary and creating facets.

Next week: more interviews, collecting more example work, and gathering more descriptors.

What this project is and what it isn't

Monday morning began with a meeting with my supervisor, the group manager, and the division director. We went over the work I had done so far, with me leading the discussion.

The meeting was helpful in clarifying a few questions I had encountered about what the project is and what the project isn't. The proto-personas I created were well-received, so I will continue fleshing them out as I gather more information.

We were also able to agree on the next steps, which mostly involves interviewing each of the group members and collecting some representative samples of the visual assets that the project is about. The interviews are brief, about 30 minutes each, and are helpful in gathering requirements. Part of the interview is requesting information on representative samples, as mentioned above, so I can start creating a list of descriptors. The descriptors will be useful for search terms in the eventual site.

I was able to do the first interview Monday afternoon. I have two more planned for Thursday and another planned for Friday, when I'll finally make a trip to IUPUI to see the other facilities. Interviews will take some time to complete because I have to work around everyone's schedules.

There are plenty of things I can do in the meantime. I've been reading up on the Web Content Accessibility Guidelines 2.0 (WCAG 2.0). I have also been typing up my handwritten notes, which helps me think about what the notes mean. In typing them, I can add context and questions, and make connections.

Take away: Meetings aren't always bad. This was more of a work session than a meeting, with the goal of putting us all on the same page.