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.