Anatomy of a Great Faculty Website

Steve: For those who haven't met me, I am Steve Ryan and I am a web developer for ASU Engineering. I have been doing WordPress in my personal life for about 10 years or so. I have been doing it for ASU for the last four years. Today I wanted to talk to you about faculty websites. I wanted to start with a basic question.

I asked this to a bunch of people in the Slack environment. If someone asked you this question - can you build a faculty website for me? How would you respond? Most of the time, the answer is a flatout no. It is frustrating but understandable. It is hard to dedicate yourself to do this kind of work for other people. There is an inability to provide maintenance and support, content development is a hard part as well. Some places offer them in specific instances for faculty members like the need to publish something important or the need to go after some money to form research labs independency and things like that. Some universities are lucky enough to have a self service area for this offering. But even then the typical answer is no, I can't do it for you, but you can go over here and do it yourself.

As you are answering that question and having that internal dialogue with your team or yourself, and you are trying to figure out if it is a good investment of your time with what we have to offer. It is hard to come up with positive things to say about faculty websites. We don't push traffic towards them. We don't usually post links to personal sites. The content is typically really hard to digest. It is written for very focused academic consumption. There is no clear call to action within these sites. It is information about the person or about the lab and that is about it.

I think the biggest sticking point is that faculty websites tend to help promote the needs of the faculty member individually instead of the university or college as a whole. That is hard to invest your time in something that will only help one person.

At ASU Engineering our answer was yeah, sure, why not? We have said yes to that particular question for awhile. The biggest reason is that when we were asked the first time we didn't want to say no. We consider it a point of pride to find a way to say yes and continue to deliver those services and be engaging for our faculty members and students. Who could say no to these smiling kids? By saying yes, it helps keeps the faculty and students happy and keeps them all engaged in what they are doing. We were asked this question initially in a different way. Sometimes faculty members have come from other places with their personal sites in hand and ask if we could post these for them. Yes, we can definitely figure out a way to host their content and put it out there so people can see it.

In the beginning, our initial offering was simple. We said yes to almost anyone who asked that question. But the next sentence we said was, please don't tell anybody. We will do this for you, but nobody else. We said that to about 80 people on campus. We hold that mentality that we try to keep it less of an official offering. We have told people a hard line. We don't use any technology other than WordPress. We know how to support it. We have stuck with default themes. We had 30-40 sites running 2012. The magic hand off or the idea was that we will help you build it and get it up and running and you will maintain the conduct and code. You will handle it from there. We will at least get you started.

You know what? It worked! We kept things running that way for a long time. We handled requests for content updates on all our sites, not just the big ones but also the smaller faculty sites as well. We tried to make it work. During this period of web offerings, our boss was a one woman show. She probably slept 4 hours a night to keep up with everything. There were all kinds of different requests that came in. I think she is happy to have more help now.

Then the wheels fell off and problems ensued. I think you can figure out where this is going. Eventually, scalability becomes a factor. You can't invest that much time and energy into something that doesn't scale well. We had a server related problem. The place where we were parking all these websites were housed and maintained by ASU people but eventually that service reached the end of its life. The maintenance of the servers became an issue as well. The content withered and if we don't take care of it, it withers on the vine. We also inherited problems. We deal with engineers who have the ability to make websites and do it themselves. But we tend to have problems that come along with it.

Our faculty website total which was 60-70% of our portfolio and it was costing a ton of money and energy to maintain. We needed to look at other things as we were doing different kinds of marketing.

When you get right down to what faculty websites are, they can be totally awesome. Especially when they get our attention. We can do some amazing things with the content that comes out of these particular sessions. There was a faculty oriented website that was really awesome. The best ones required our attention and when we gave them attention, we made it awesome. It requires really good high quality images and a really good sense of design in order to pull something like that off. It requires our attention in terms of maintenance to keep the content fresh.

The bad and the unloved sites don't look this pretty. I was going to call on a couple of our faculty members and put their sites on this slide. This happened yesterday 300 yards from our office. It was an actual train wreck that could be seen from 20 miles away. This is really what happens to websites when they just die. You don't have that kind of involvement, then that is what happens.

We are going to rebuild. We decided we needed to do something about this problem. We had websites that were not speaking well to what we represented. They had inconsistent branding, navigation, imagery, names and the content was wrong. The context was almost completely obliterated on most of these things. It didn't conform to our branding in any way. It is really hard to really understand that you are still on an ASU domain because it looked way different. The images for faculty websites run from mediocre to just downright awful. We get things from screen captures, Power Point presentations, research posters that are two pixels on the screen. Text is captured in an image. If it is the worst possible practice on the web, you will find it on a faculty website. That is just what happens. From an accessibility standpoint, they are terrible. We were letting them run the show for awhile so even the basics of accessibility was not enforced or really even a concern for the most part.

In studying our particular problem and trying to figure out how we do faculty websites better, we set aside 30 days of pausing the new requests pipeline of stuff related to faculty websites to build some kind of a better theme to handle all of this. We broke it down. We figured out the common areas between the good stuff and the bad stuff and came up with this pattern that we will do.

We will build a theme that catered to 80% of what we discovered in two basic use cases. The first use case was a website for an individual faculty member that was mostly accomplishments. We wanted a website for a small to mid size lab group. It would be one to two faculty members working with a few students to conduct research.

Our goals for the theme that we built was to reduce the need for the end user to focus on the page layout and design. We wanted to deliver something that was prepackaged and out of box. Images are a problem and they are hard to come by. We wanted to make our design and the product we build reduce the emphasis on the need for a large scale image to tell stories. Some don't exist and others are hard to find. We wanted to make it really easy to use. The most basic baseline WordPress site. That was actually something we pulled out of the pile that used the default. Default are easy to use since there are less features there. We wanted to use something similar.

We wanted a relationship between the context there as well. We wanted to make 80% of the content that we knew would be there. When we studied these faculty websites, they were the same pattern. We built the ASU labs theme and it is active in 30 different properties at the moment. We plan to grow it up with another 50-70 different sites we have that meet the need of that pattern. We are growing at 1-2 sites a week. Even all this time, we are not doing mass communication to all our faculty. We let word trickle out that we have this thing. It has been working so far.

When we did our content study of the good, the bad and the ugly that we talked about before we realized that most faculty websites come from a common place. They want really basic stuff. They need a good way to do it. The basic content type is people. They need to be able to have a page that represents a person or multiple people on the site, usually the PI, students, or other faculty members or staff. They need a record of the research from the lab or the project. Either the projects are ongoing and need help, or they are completed and it is a report of what they just did. It also needs a publication list of some kind. Either all the published works from a particular lab or published works from a particular person. Some list should be there. I looked at that. If faculty websites were sporting events, the publications are the scoreboard.

One thing we noticed when we did our survey was that there was clearly relationships between these different content types. The people being mentioned in a faculty website are related to the research that is going on in the place. The person does the research project and the research project does spawn a publication which is also written, authored, and sited by a person. When we looked at what we had produced we realized all that stuff was there but it was difficult to see the connection if there was more than one person involved. A faculty website may mention one or two faculty members and 7-10 grad students working together in one place. It is hard to figure out which grad student was working on which project and which publication came from which set of people. We wanted to make sure that what we built featured content and the connections between the content. That was really important. Once we had that connection established, everything that came on top of that needed a curated home.

We delivered a couple of these things right away with our first offering. Some of them are still pending. We are waiting for other people to express interest in this feature. We realized that if we organized our theme and featured the content in this way, that all of these bits and pieces would have a natural place to fall.

This is what we built. We built a theme for WordPress. No big surprise there. That is the product. The theme we call the ASU Lab theme. We are bad at naming things. It features a bunch of different templates. I will talk about some of them here.

The first content type was the person. We wanted to put people right at the forefront of this site. We built a page template that centered around a person. It is one big image and a lot of text. We wanted one thing and then everything else was not dependent on it. We wanted the picture to be a square portrait style. We wanted to reduce design clutter. There is nothing that goes all the way across the screen.

We offered professional portraits as a service once or twice a month to get their picture taken. When stuff gets better, we hope to be able to continue that.

We had a big link back to the official directory for all the people in ASU. We wanted this to feel right away like an connected ASU service so you could get back to something that would feel like an official ASU statement. Your email address, your phone number and things like that would be there as well. You could put a description of themselves, or pictures of their cats and stuff like that. It runs the gambit to professional to personal. That is fine. We wanted people to have free range on that.

On the back end, we made a decision early. This was pre-Gutenberg. We decided early that we would be okay with metaboxes in the Gutenberg interface for awhile. We figured out that this particular interface or form just lists the first, last, middle name has a place in the back end to put all the bits and pieces of content you otherwise have to define and figure out how to format in your site. We wanted it to be simple.

Meta boxes was a thing. You will see there is a lot of them running through here.

One of the things we decided to do right away was spending time on this particular archive page. A directory is something that can be built out of individual pages that feature people. We wanted to make an archive page as Philip Fantastic and then you are done with that particular piece. That has been a big success. You are good to go there. Later on we added nuances with plug ins that do that. You can order the people on the archive page, categories, and you can feature somebody at the top of the page.

The second content bucket that we had was a research project. We definitely have a custom research project that looks like this. It is mostly a blank space. We added a couple of meta boxes to this custom post type to differentiate it between a normal page and a research page. The meta fields include a status for the project. It is a completed project, open, or we are actively working on it type of thing. We designed a small space for the post type image. We didn't want it to take over the page. We stuck it over the right hand corner. It is because images for research projects are hard to come by. You can take pictures of a computer screen or such but if you are writing code and doing something on a microscopic scale it is hard to find images that are notable. We reduced the size, stuck it up there and tested a bunch of types of images. If you put a research poster up there, it would still look okay.

We tied this page together with a couple of taxonomy. You can easily identify and tag a project. Also your research was a topic taxonomy that tied all these pages together. Rather than focus on an archive page for the research project like we did with the people, we instead decided to focus on this particular taxonomy as an overview page for all the products. We figured it would be easier for people to do this type of work.

There is a research theme taxonomy that runs all the way through here. You can publish the individual taxonomy term pages and get this result out of it with special formatting. This ended up being the 10,000 ft view of research going on in a particular lab or project. It was designed to be summarized in a sentence or two. We wanted it to be a lightning page for your research. I work in this lab and I am doing this project and this is the topic. Again, smaller images and smaller things all the way down the page and related topics and such filtering along it. As you tag the research project or publication and the theme, then all that stuff is connected on the bottom.

The third bucket are publications. We have people, research projects, and publications. The publications represent the individual pages that represent key publications for the site. We wanted people to help understand that the best value they can deliver is one single important publication, not a giant list of them. It is mostly an open page. We suggested that they copy and paste the abstract from their journal article and then link them up to other types of content that are there.

We also deliver the ability to upload a pdf of the individual publication. The pdf and the image of that pdf is what you would typically see in the upper right hand corner. It would download the pdf of the article and an easier way to see that. It gets tricky here.

We wanted to build an archive publication page. Right? That is the sort of holy Grail of faculty websites. They want a list that represents every publication they have. It becomes problematic quickly. If you make people publish this archive page, it means you are asking them to make one entry in their faculty website for every publication they have. That is a ton of content that we didn't really want people to have to go through that data entry problem to use this particular feature really well. This exists in the theme but it is not pretty. We realized quickly that it wasn't going to get adopted very easily.

We built those content types and the buckets that we talked about and started to think of a way to connect the three together. I dug up some old articles and found a blast from the past that was a plug in that was abandoned called Post to Post. I can't see the Thumb's up in the chat window, but I am hoping people have at least used this plug in before. It is amazing. It was abandoned in 2016. You turn it on, plug it in and it is working out of the box. It looks like the WordPress of old. It needs a facelift for sure but everything works out of it and it is amazing. Once upon a time, post to post was a way to connect content between your site. I have nothing but great things to say about that plug in. The fact that it is still working even after five years of abandonment says a lot. It allows you to have a meta box in the side bar that you basically click a couple of buttons and create a connection between the people and the research project that you are on. You click two buttons and you can associate a person with a research project and it manifests itself in really easy to maintain links and it ties together the buckets we made before.

You can link things from either place. If you have a research project and you want to link to a person, you can. It is like two clicks and then you are done. This particular feature definitely helped boost our adoption of this project as we rolled it out to other people since it was easy to use.

We made all this and rolled it out. People are using it and cheering from the stands. We are feeling good about ourselves. We took something that was a low priority product and we turned it into something important. We can have thirty sites with one theme and it is consistent and does what we want it to do. We are answering questions on this content based on a theme rather than helping to fix the content.

In developing good documentation to help people own it themselves and do it themselves is a big key. There is a lot of value in that, too. You turn this on, let people use it and they can feel empowered to do the things they wanted to do. We have other things that are in the pipeline. We are redesigning the theme to match a new set of brands that are coming down our pipeline. I think that will increase our adoption and the value.

There are blocks. We have to move away from the meta boxes that are great and work very well into blocks that should work really well. That is the future of WordPress and the big challenge we have along the way.

As we are doing this work and experimenting with the smaller set of people using this theme on our own, we are also realizing that there are other things we can squeeze out of this. Right? There are other values we might be able to do. We are finding even more value by coupling our theme in multisite. WPCampus community as a whole in helping us figure out where we are going with our multisite has been amazing and fantastic. I have learned a ton by watching you guys do what you do. You can log in to something. You can click a button and you are running. That is more automation than we have in the moment but it is heading in that direction.

We can dump assets in a multisite and offer that media library in connection with the local media library as a collection of global assets. Things like background textures and our logo and things we can dump in there and let people use them in collective without being uploaded individually.

I want to give a shoutout to the folks at Georgia Tech. I had sat at a presentation from WPCampus two years ago in St. Louis and listened to them talk about the process they used in order to go through and figure out which sites in their multi site were abandoned and needed attention. I have learned quite a bit from rewatching that session. As soon as we scale up to a point where it becomes a problem to do that, that will be the strategy we use to deliver that. Definitely worthwhile to go back dig through the archives and rewatch that presentation. I got a lot out of it when I did that.

Add more value. There is more you can do with this setup. You can deliver different kinds of connections between the different faculty websites. We can pull the latest projects hosted by our multisite. You can put them at the root site of the multisite or even somewhere else. Since we did our homework and we have a bucket for those things to go into, then we are able to do that.

A feature that we are going to build soon. A contact form on all these different faculty websites that functions more like an RFI. Part of the journey for grad students in figuring out where they want to land involves a journey through these different faculty websites. They are used as springboards to figure out what a faculty member is and what kinds of things they published in the past. They are definitely using these faculty sites as an introduction to the person and they can see themself there. As they reach out to see if there is funding available for doing what they want to do, their content form can function as an official RFI for the thing.

I want to be able to build a better publications plug in that handles that difficult custom post type we were dealing with. Handling those journal articles are hard to deal with. We want to be able to make standardized blocks for presentation styles. We want to make sure that archive pages are being able to be handled in the future. If anybody has that same need, I would love to partner with them and work on something that is applicable to more than just our faculty sites.

We spend a lot of time figuring out these nuances for a good faculty website. We delivered that faculty websites are the same throughout universities. I would be willing to bet that their needs mirror each other. If someone would like to work on a version of it or making what we have built child themable or customizable so it ends up being a reflection of your college or university, I am more than willing to decouple what we have done and put out a product that could be picked up by multiple policies. That would be amazing. I am all in with Post to Post. I have a lot of good things to say about it. I see a need for it. It may be a niche need. Post 2 Post represents an easy way to connect a content type with another content type. After Post 2 Post was abandoned, the different beta blocks for WordPress assumed that functionality. You can find it in the meta blocks plug in. You can find it in our meta blocks plug in we are using for our site, too.

Post 2 Post is an integral part of this. I would love to own it but I have no idea what that actually means. I would love to pull it out of the trash bin. I am hoping someone can tap me on the shoulder and tell me what I am in for if I decide to go down that particular road.

As we are doing our exploration, one more post type we came across. A need to publish data sets in particular as separate from research projects. The data you are using to conduct your research in a way that makes it accessible for other people is a great example why websites like this exist. As we are trying to accelerate the pace of research and as people are trying to validate your results, they need access to the data you drew your conclusions from.

Academic journals are great about putting out the actual conclusions. They will give you a little bit of the data. But the big chunky data sets they are using is hard to come by in that circumstances. Websites make a great foil for that. For those interested in publishing their own data, having a post site in this makes a lot of sense.

That is it. There is more than you realize was there. I would love to open this back up for questions if ya'll have any.

Eric: Thanks, Steve! We have under five minutes for questions. I will ask attendees in the chat to use the Submit a Question chat. I will attempt to get to one or two questions before the end of the session.

Steve: As people are possibly still trying to figure out their questions, I will add that I am around on the WPCampus Slack almost everyday. I have a passion for faculty websites. It is a super weird thing to be niche exploring. But I love them. I think they are great and I think you can derive a lot of value from them. The documentation for the theme is available in the slide you are looking at. The links to all this will be available in the WPCampus Learning Library in the future. I am happy to talk to you about it then.

Eric: A question came in about publications. For publications are you pulling any data from existing sources?

Steve: The answer to that is no. It is something we considered how to do. The reason we are not doing that at the moment is because the data resources we were presented with were different. We can pull some data from our system about the author. Most of our faculty that maintains those particular sites just have their list stored in a word document. Most of the time, maybe if we are lucky they will have a bit text file. We haven't written any kind of import or export script or looked at the format of the data. We couldn't find a really good format that we could standardize on and adopt across the way. I am definitely interested in doing that in the future. I think it would overcome the problem of data entry with this if there was a really good import/export service that organized a page or box that did that same thing.

No. It was considered, but no.

Eric: With that, it looks like we filled our time for the session. Thank you very much for your talk and the details and expertise you have shown. I know for me I am going to have to go back and reference this session a few times to pick up those tips and tricks to use back at Georgia Tech campus. Thank you very much!

Steve: Yep!