Getting access to edit pages on the website

We’re making an effort to bring this blog back! Wanted to start today with a quick note about getting editing control of your website.

On the old website, pages were organized into “folders”, and we’d provide access to the entire folder at once. On the new website, access is actually set on a per-page basis. This is a bit of a pain for us, since it means we need to add users individually to every page, but it opens a lot of flexibility for you.

There’s a couple areas where we’re still trying to work out how editing permissions are going to work. The first has to do with pictures & uploaded files. The media system on the new website is wildly different, and I’m still not sure how to assign permissions correctly. We can still provide permissions to pages with images, but it sometimes takes some work to make it happen, and so far there’s no way for most people to upload images or files to the site.

The other area is the types of pages that are available to edit. Most standard pages can be edited, but program pages and steps to enroll pages are  two where we’re not assigning permissions yet. For now, please continue to route those through us.

If you’d like to get involved with making edits to your site, reach out to and we’ll help you get started.

The Employee Directory

Our website has nearly fifty pages with the word “Contact” in the title. For us, this has actually been our standard for a long time: we’ve always tried to make the bottom link in a menu a contact page. But, in designing the website, we started to believe this was the wrong approach.

First, many department homepages work better as contact pages. Why  make someone click a link, just to see what the phone number for a department is?

Second, many of those contact pages ended up reproducing pages in the employee directory. Why have duplicate pages? And, since the employee directory updates directly from Banner, it’s much less likely to be out of date than a manually updated page.

On the new site, we’ll be introducing the support block on pages, and eliminating many of those contact pages. Here’s an example of a draft support block on the Continuing Education site:

New support block, showing contact information for CEThe support block supports a little bit of variation, and we’ll be able to do things like showcase people, include logos, and add additional yellow buttons. We’re hoping this will result in a standardized look and feel for our contact information, while allowing us to substantially reduce the size of the website.

Of course, this means we need to fix any data quality issues in the employee directory. Be sure to check out your listing in the directory, and use the edit button at the bottom of the page to make corrections. For extra credit, check your department’s listing, and see if anything is missing.

On the importance of events in the new site

One of the changes we’ll be introducing in the new website is a better integration with 25 Live, our event scheduling system. If you’re hosting and event, and would like to get it on your website, rather than asking us to do it, and going several rounds via email to get something on there, you’ll instead schedule it on 25 Live (which, to reserve a room, you’d do anyway) and tag it so it shows up on the website. That’s it – somewhere around fifteen minutes later, the event will just show up. It’ll look like this:

Screenshot of an events feed, showing three upcoming facilities council eventsYou see the problem: it looks like we only have one governance council. Going forward, if your event is open to the public, it’s going to be incredibly important to make sure to get that scheduled on 25 Live. If you don’t, it simply won’t show up.

But here’s one potentially confusing thing: that “More Events” Button takes you to our all events age, rather than taking you to a list of events tagged like in the view (in this case, governance events). That might be something we reevaluate in the future, as we better understand the capabilities of the new integration, but it will be several weeks yet.

Clarification on Forms

Since we first announced the freeze, most of the questions we’ve received have been about webforms. That’s understandable, since forms are complicated, but often critical to our workflows. They need to just work. This post is going to try to provide some clarification.

Moving our forms into the new website

Unfortunately for all of us, the migration scripts can’t move webforms from the old to the new website. That means we’re going to need to rebuild each form individually. How we do that depends on if a form only contains transient data and the form is part of a workflow.

When we get to a point where we’re starting to build forms, our first step will be to disable form editing across the site, to make sure none of the forms change while we’re moving them. This will only impact form editing: you’ll still be able to view form results, people will still be able to submit forms, and you’ll still be able to edit form submissions (if that’s something you do).

The simplest cases are forms that only contain transient data. Often these are contact forms, like the advising contact form or the Board contact form. Submissions to those are relayed to an email address as soon as someone hits submit, and then the submission can essentially be forgotten. For these forms, we’ll build them on the new site, and they’ll go live at the same time as the new site.

On the other hand, you may have a form that collects submissions for a period of time, and then you download them all at once and don’t use the form for another year (e.g. an event registration form). For these, we’ll rebuild the form, but not take it live until we know you’ve been able to download your responses (if applicable) and are good with us switching over.

The most complex forms are the ones that have hidden fields that you use as part of a workflow. An example might be a form where someone submits it, and then you edit a hidden field to note that you’ve reviewed the submission and approved it. For these, we’ll rebuild them, but again work with you to make sure you’re good with us switching them over.

We don’t anticipate any interruptions: forms should continue to function and be available throughout the entire process.

Old submissions

Unfortunately, there’s no way for us to migrate form submissions from the old site to the new site. In some forms, this doesn’t matter. But if you do want to save old submissions, at some point you’ll need to download them to your computer. But there’s no hurry yet: we’ll send out reminder emails in the spring.

Drupal Webforms vs Softdocs

I’ve been asked a lot of questions about if a certain form should be moved to Softdocs, if Softdocs is more secure, if Softdocs is going to replace Drupal, and if Drupal webforms are going to go away.

Softdocs is an authenticated form and lightweight workflow solution. Drupal is a generalized content management system, with a bunch of plugins that can be used to make it do almost anything. While, superficially there’s some overlap, in reality they solve different problems. We need both.

Softdocs will hopefully replace a lot of the PDFs we have on campus, and  lead to more efficient workflows since it directly integrates with Banner. It provides authenticated forms, which legally meet the requirements for an e-signature. If you have a form where you need to verify the identity of the person submitting it, and you’re certain anyone submitting the form will have an L Number, you want to use Softdocs.

Drupal will continue to have a webform component. It will never integrate with Banner. There’s a limit to how complicated the forms can be (Softdocs allows you access to the HTML, so you can do much more). But since the forms are branded, integrated into your website, never require authentication, and are quick to create or edit, they’re very appropriate for collecting information from people not yet affiliated with the college.

Neither one is really more secure than the other – one just provides identity verification.

If you have a form that requires identify verification, is more of an internal process, or a form which would be improved by integrating with Banner, then you should move it to Softdocs.


Redesign Progress

Last week, we finally got a glimpse at the new website, live and working in browser. Things look great! This first look was just to make sure there wasn’t anything on the backend that would keep us from being able to work on content throughout the rest of December. We’re looking forward to having greater access later this week.

Please continue to email us any updates to your website.

Content Freeze

As we enter December, we’re also entering a new phase of our website redesign. Very soon – possibly the end of this week – we’ll be entering into a content freeze. Editing privileges to the sites listed at the bottom of this post will be suspended as soon as we enter the freeze. I’m really, genuinely sorry I can’t provide an exact date here. Some difficulties unique to 2020 has made that impossible. I hope to know the exact date a little later this week.

Where we are and what’s next

Our redesign firm is putting the finishing touches on our website. Next they’ll import our current content, and we’ll start testing. Lori and I will try to test the new website on every possible combination of Chrome, Edge, Firefox, and Safari on Android, iOS, Mac OS, and Windows. We expect that testing to last for a few weeks, as we go back and forth fixing problems and testing again.

While we test, we’ll be working on reformatting the imported content. Our current website is built around one giant text area (the “body” field), with things like pictures or videos inserted in it. The new website will be built around reusable content blocks, like accordions, videos, or image galleries. It will take some time to reformat into the new system, but once we’re there, we should be a lot more flexible and consistent across our pages.

As part of the redesign process, the firm identified some areas where we’re lacking content. In addition to reformatting and rewriting existing content, we’ll also be doing some content development. And of course, we’ll be hunting for images to use all around the site. Don’t be surprised if we reach out looking for a higher resolution image from your pages!

While this process is a lot better than the last time we did this (when we had to hire someone to copy and paste, full time, for over a year. She was bored out of her mind!), it does create a problem: after we import all the current content into the new website, there’s going to be a multi-week period where if you make an edit to your current site, it won’t automatically be moved into the new site. That brings us to the freeze.

The freeze

Possibly as soon as the end of this week, we’ll be turning on a new module which disables edits on the list of sites found at the bottom of this post. If your site is in the list, and you absolutely must make a change to your content, reach out directly to Lori instead of doing the edit yourself. She’ll make the change on both the old and the new sites simultaneously, so we don’t lose any of the changes. This will significantly increase Lori’s workload, so please try to limit changes to what’s absolutely essential.

One question we’ve had already is forms. There are a number of departments with a critical form they need to access. If your site is frozen, you will still be able to log in and use your forms. This freeze only impacts the ability to edit your page content. For now, we’re keeping the ability to edit your forms, but may need to disable form editing when we reach the point where we’re migrating forms into the website. Unfortunately, the migration process cannot move forms, so we’ll be recreating those manually. If your form will eventually be moved to SoftDocs, it will not be migrated to the new site, even if it isn’t ready in SoftDocs when we launch the new site. The old form will continue to work for some time in the old site, but I encourage you to move it to SoftDocs as soon as possible.

If your site isn’t in the list below, then nothing in this post applies to you. We’re only migrating student and prospective student oriented content to the new website, and if your site is primarily staff oriented (ATC, FPD, PD, etc) or is largely administrative (COPPS), then we’ll probably be leaving it in the current website for now. You’ll continue to have access, and continue to be able to make changes as normal. Sometime next summer we’ll hopefully start adding functionality to that site, and work toward having a true intranet.

After Launch

While we won’t be able to nail down the exact launch date for the new site until after we’re in there reformatting and redeveloping content, we expect it to be some time late in winter term. Since we’ll be doing double entry for all website changes, it’s in our interest to get there as fast as we can.

When we launch, we plan to very slowly add new users to the site. There’s a number of reasons for this caution. Some are technical, like the all new permissions structure. But we’re also trying to create a more consistent voice on the new website, and think that’s going to be very hard to do if we bring in all 148 current website editors. Details to come as we get a little closer.

Thank you for being understanding of our need to keep everything somewhat flexible this year! If you have any questions, please feel free to reach out via email.

The List

There are some sites on here which are hybrids. For instance, Academic Technology’s site has some student pages, like the SHeD, but is mostly employee oriented.  We’ll be working with those sites  to try and unfreeze parts of them midway through the process.

While this list should not be considered final, here’s the list of sites we’re planning to freeze right now:

  • abse
  • academictechnology (LETS and SHeD pages)
  • accreditation
  • admissions
  • advising
  • advtech
  • als
  • alumni
  • apprenticeship
  • artgallery
  • arts
  • Arts and Humanities
  • aslcc
  • aviationacademy
  • bond
  • budget
  • business
  • calendars
  • cc
  • ce
  • cec
  • cfe & lcfc
  • cit
  • collegenow
  • commencement
  • cooped
  • cottagegrove
  • covid19
  • ctecc
  • culinary
  • dentalclinic
  • disability
  • diversity
  • downtowncenter
  • engineering
  • eorp
  • esfs (not the document submission form or degreeworks FAQ pages)
  • esl
  • español (undocumented students pages)
  • facilities transportation (excluding motor pool) and event scheduling pages
  • fec
  • financialaid
  • firstyearexperience
  • florence
  • food
  • foundation
  • gec
  • governance
  • healthclinic
  • healthpe
  • honors
  • hp
  • hr (employee recruitment and affirmative action pages. hr sub-terms, such as employment classifications may not be impacted)
  • hsconnections
  • information technology student computer labs pages
  • international
  • laneonline
  • leadership
  • learningcommons
  • llc
  • longhouse
  • math
  • mcc
  • mediaarts
  • mhwc
  • mpr/success
  • newsroom
  • pathways
  • perarts
  • pie
  • psd
  • ptk
  • qcc
  • rtec
  • safelane
  • schedule
  • scholarships
  • science
  • scp
  • seniorprogramming
  • sexualrespect
  • socialscience
  • speaker-series
  • sss
  • studentconduct
  • studentemployment
  • studentlife
  • sustainability
  • testing
  • trio
  • tutor
  • va
  • wc

12/6 – This post was edited to add accreditation and budget to the above list, and to add notes to the esfs, español, facilities, it, and hr sites.

Website Redesign Check-in

It’s been a while since our last redesign post, but don’t think we haven’t made some progress. We’ve been averaging about one video call per week, and are getting closer and closer to development work.  Some of the things we’ve done:

Developed Batch 1 Designs

Our first batch of pages included the homepage, a career community page, and a program page. Our assumption is that these are some of the first pages most prospective students are going to look for, so we wanted to dive right into them. Our homepage is definitely going to shift direction, and be focused very narrowly on prospective student.

User Tested Batch 1

To be certain that we were on track with design and the information architecture, we did some intensive testing with some real prospective students. Users were asked to perform specific tasks, with people watching exactly what they did and seeing where they struggled.

Finalized Batch 1 Designs

We made some changes to the designs to address issues uncovered in user testing. Some were easy to address, but one has been a particular thorn.

Lane has a lot of different offerings, and people are confused by them. We have degrees, 2 year certificates, 1 year certificates, less than 1 year certificates, career pathways certificates, and non-credit credentials. There’s even more variety within the certificates. Some are financial aid eligible, some are not. Some are stackable with a degree, some are independent. Some are stackable, but you choose between multiple options. Some are technically stackable, but are marketed to a different market segment than the degree. We’ve gone several rounds with trying to balance standardization of design (to reduce confusion) with the flexibility to accommodate all our programs (to stay accurate). We’ve landed on a layout we think will work, and we hope to test it again, but it’ll be difficult to know if it’s worked for all programs until well after launch.

Reviewed Batch 2 Mockups

Our batch 2 pages included some Registration and Tuition related pages. While we’re pretty happy with the design of these pages, they’ve helped highlight a problem for us: our internal organization doesn’t always match how people think about us. For example, consider how students pay for college. We have a lot of departments that deal with money: a Financial Aid office, a scholarship and student employment office, a veterans benefits office, a bursar, and several people that work with sponsored accounts. There’s probably more. There’s really good reason for splitting them apart, and each requires a ton of very specific expertise. But if I have a question, and I’m not sure which of those areas can answer my question, who do I call?

Started Batch 3

Our Batch 3 designs relate to the application sorter and steps to enroll pages. We’ve done quite a few versions of these since our last redesign in 2013. For instance, our sorter page swapped from being person type oriented to goal oriented. Yet, despite all those changes, our sorter continues to be one of the least liked pages on the site. Our new design is going to try to leverage some of that experience, and include information that can help you navigate either way, while simultaneously emphasizing the most commonly used enrollment pathways.

Content planner

Our greatest amount of work has been the content planner. This maps content on our current website to the new website, and identifies where the gaps are. We’ve got a bunch of folders and empty documents set up in google docs right now where we’ve been starting to develop new content and rewrite some old content. There were more than a hundred pages which we need to keep, but which don’t have an obvious home in the new website, and I’ve been slowly making my way through. Some of the rewritten content will be launched before we launch, while most of the new stuff won’t be launched until the whole site is ready.

Meanwhile, as we continue our review of every page on the website, Lori’s been aggressively working on some of the recommended page merging and deletion. Thank you to the dozens of you that have helped us delete old pages!

What’s next?

After we finalize batch 3 this week, we’re hoping to do another round of prospective student testing. Very soon development will start, and while the site is being built, we’ll continue our work on content.

One of our big challenges will be photography. Normally for a website redesign you’d schedule a couple of professional photo sessions on campus, but due to COVID-19, that’s tricky. Before launch, it’s unlikely campus will look quite as busy as it would normally, we won’t see groups of people together, and the people we do see may be wearing masks. I’ve been trying to make it out to campus once in a while to get some photos, but there’s only so many empty shots of campus we can use. If you have any amazing photos – ideally where everyone in the picture has signed a photo release – and you’d be willing to let us use them, send them our way!

One of the campus turkeys in front of the center building
One of the photos from my weekend adventures shooting photos on campus

More accessible phone numbers

In the last post, I learned that not only does phone number format matter from an SEO perspective, but phone numbers can be really annoying to the blind. Depending on the screen reader, a phone number like 541-463-3000 could be read as “five hundred forty-one dash four hundred sixty-three dash three thousand”. That seems terribly annoying.

I started out trying to implement the solution at the end of this blog post, but then my curiosity got the best of me, and I got digging deep into CSS speech modules. It looks like support is limited even though they’re so cool! But the limited support means I’m going to stay away.

Instead, we’re back to the regular expressions replacements, using the Drupal custom filter module. Currently, we look for

/\((\d{3})\) (\d{3}-\d{4})/

And then replace it with

 <a class="telephone_link" href="tel:+1-${1}-${2}">${0}</a>

Over the last few days, we’ve changed that to grab each number individually:

/\(((\d)(\d)(\d))\) ((\d)(\d)(\d)-(\d)(\d)(\d)(\d))/

and replace it with something much, much longer:

<a class="telephone_link" href="tel:+1-${1}-${5}" aria-label="${2} ${3} ${4}. ${6} ${7} ${8}. ${9} ${10} ${11} ${12}">${1}-${5}</a>

It’s a bit of an ugly regular expression, but not only will this hopefully make a better experience for screen reader users, it’ll also introduce a new phone number format as currently recommended by the AP: 541-463-3000.

Progress on the Website Redesign

We’ve been working on the website redesign for a while, but I’m afraid that I’ve totally dropped the ball at posting updates to this blog. Things have been much busier than anticipated. Though I’m sure I’m missing some parts, here’s a quick overview of what’s happened so far.

Completed a brand and identity inventory

In order to help iFactory get to know Lane as a college, we answered a multi-page inventory covering basic items like what our roles are, questions on our market, our programs offerings, and even our guided pathways efforts.

Hosted an on-site visit by the iFactory team

Three iFactory employees came to campus to get to know us even better, eat some delicious Eugene food, and conduct focus groups with students and employees to learn more about what the campus thinks is important in the website. Afterward, they surveyed more than one hundred current students for their thoughts about our website.

Developed four personas to make sure our web content meets everyone’s needs

Well, at least as many needs as we can. Think of personas as pretend people which you can use to evaluate the site. For instance, we have Colleen, a traditional high school student interested in taking some classes at Lane to save money before transferring to a 4-year college. The other three are even more complicated, with tricky backstories. While we’ll never capture every unique situation at Lane, our personas are different enough to make sure we look at every piece of this redesign from at least four very different perspectives.

Evaluated six different mood boards to see which images and designs most feel like Lane

Having collected a lot of information about the college, we were presented with six different mood boards. You can think of these like Pinterest boards for the college, with different collections of pictures and screenshots of other college websites. We provided feedback on each one, and explained why they did or didn’t feel like Lane.

Evaluated three different mockups of potential homepage elements, to get a feel for the design language which will eventually build our site

From the mood boards, some simulated pieces of a  new site were created for us to critique. We provided feedback again on which directions we wanted to pursue.

Provided feedback on two rounds of information architecture for the new site.

While working on some of the design tasks, we were presented with two iterations of an information architecture (IA). The IA is how the site is going to be structured, and starts to provide some structure to the navigation on our site. While we’re pretty confident the IA we’re going to use is roughly correct, it’s still being polished.

Completed a content inventory

We were provided with a spreadsheet of more than ten thousand different URLs that are a part of the Lane domain. While they weren’t all part of the Lane website, they were each linked somehow from the Lane website and a part of our domain. Our job was to determine what to do with each page. Was the content correct? Could it be merged elsewhere? Should it be archived? This task took several weeks of near full time work, and resulted in our cleaning a lot of content. Due to the sheer number of pages to look at, we weren’t able to consult with everyone on each page, but I did talk to dozens of people about their content throughout December and January.

Provided feedback on several rounds of wireframes of possible college pages

One common step in website development is to draw a rough layout of content, without putting any color or pictures in it. The goal is to get you to stop thinking about the appearance of the content and instead think about the layout and the flow of the text. Some wireframing software will even make the lines look like they were drawn with a crayon or thick marker, just so that you know immediately that we’re just roughing in content elements.

Evaluated two different homepage mockups (with help from 44 of you!) to see what direction we want to go with the college homepage.

This is when things got really exciting. Finally, in the last month, we’re starting to see some fairly polished concepts of what the new homepage might look like. We’re still finalizing some of the language, so they’re not quite ready to share, but we’re getting close.

What’s next?

We’re currently working through wireframes and mockups for several other types of pages, and have started preliminary conversations with their developer. Soon, we’re going get an outside perspective on the actual content of our website, and see where we have some gaps. Quite a bit of time this spring is likely to be occupied with content development, since we know we have some content gaps.

I’d also like to share the first change that we’re confident that is going to impact our web editors. On the current site, almost all of your content is in one field called “Body”. This is great, in that it’s very customizable, and terrible, in that it’s very customizable, leading to broken, inconsistent pages. Best practices developed a few years after our previous launch suggest  providing reusable components that you can plug into any part of your site: a slideshow here, a callout quote there, some text over there. They also suggest making them remixable, so you can lay out your page however you’d like, using a common language of elements, letting your page be instantly familiar to everyone as a Lane page, but also customized to your content.

We’re going to be adopting that approach as a part of this website launch, which I hope will help meet some of the website customization needs I haven’t been able to meet over the last few years!

More details soon, honest!

Evaluating Goal progress, 17-18

All year we’ve been tracking progress on our web team goals. But now the year is over, and it’s time to reflect. We definitely made a lot of progress on some of our goals, but on others there’s only bad news.

1. Reduce the total number of pages on the Lane website by 5% (from 5550 to 5273)

We exceeded this goal, reducing the total number of pages by 18.3%, rather than just 5%. But it turns out this was not a well written goal. Of the 1,018 of pages we eliminated, 558 of them were Lane in the News items, which aren’t really pages at all.

This goal had a problem with language versus measurement. Drupal stores content internally as “nodes”. This is fairly easy to count – select count(*) from node. But there’s a number of types of content on the website that aren’t really pages but are nodes. Lane in the News items are one type, but we also have slideshow slides, FAQ questions, and landing page announcements. So while those content types count for the purposes of our metric, they probably shouldn’t.

Fortunately, we still deleted 460 actual pages, so we handily met this goal. But if we set a goal like this again, we’ll probably exclude certain content types (not only the ones previously mentioned, but also news releases and board policies).

2. Reduce the number of pages with more than 15,000 characters by 10% (from 249 to 224)

While we certainly met this goal, this count has increased yet again, from 144 pages last check-in to 145. These pages remain mostly meeting minutes and policy documents. If we do a goal like this again, we should probably limit what content types we look at.

It’d be really nice if there were an easy way to count words, rather than characters, but that ends up being a very difficult problem, especially when our content includes HTML mixed in.

3. Reduce the average character count of our pages by 10% (from 4650 to 4185)

For reasons similar to goal #2, we should probably have limited what content types we looked at. We wound up at 4,194 characters, which is close to our goal. This is likely not a goal we’ll continue though, as longer form content isn’t necessarily a terrible idea.

4. Improve the average age of our pages (the average late updated date) by 4 months (from 16 months to 12 months)

We’ve stayed steady on this goal since last post, at 17 months old. This remains one of our most difficult tasks. Despite the web team making more than 3,000 page revisions in the last year, more than 20% of the pages on the website haven’t been edited in more than 3 years – and many of the revisions we made were just link changes or typos. We’re often not qualified to do content changes. Please give us a hand!

Traffic Goals

We also had two traffic goals:

  1. Increase session counts for during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 3,228,904 to 3,390,349
  2. Decrease the bounce rate for during the period 6/14/17-6/14/18 compared to the previous year by 5%, from 37.05% to 35.19%

Unfortunately, we met neither of these goals. We fell the furthest behind on pageviews, where we fell 14.24%. We did improve our bounce rate by 1.11%, but that’s a long way from our 5% goal. We did have a couple of wins, which seem to indicate a more engaged audience. Average session duration is longer, people are viewing more pages per session, more sessions are from new visitors, and organic search traffic is up.

In retrospect, while these were a good first attempt at goals, future goals should be more carefully targeted to what we’re trying to accomplish on the web at Lane. For instance, we could look at the percentages of traffic that come via organic search or referral, or we could look at tracking the percentage of people who request information about the college.