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.

We’re frozen

Last Friday night I officially locked out edits on most of the pages mentioned in our previous post, and then Sunday night I shipped all the locked nodes off to be imported into our new site. Here’s our timeline right now:

12/4 – Site Frozen
12/6 – Database sent off to development
12/7-12/8  – Database migrated into the new site
12/9 – Initial training in the new site, and the start of the QA process
12/18 – Second training in the new site, finalize QA
Early January – Migrate the site to the campus data center

For us, one of the most intense parts of the web design process starts this upcoming Wednesday. When our content is migrated into the database, it’ll be stored close to how it is now. For each of the 2061 pages we’re migrating in, Lori and I will need to reformat them using the design components we’ve been provided, rework the content, add media, and appropriately add them to our menus.

I’ve been asked a number of times this last week when we expect things to go live, and right now the answer is: we don’t know. That will depend entirely on how quickly we can get that content work done.

The last few days last week were one the busiest periods of edits we’ve ever had. Thank you to everyone that helped squeeze those in, since they saved us from double entry!

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.

Should links open in new windows?

In a word: no. As stated by the WAI, new links can be “…disorienting for people, especially people who have difficulty perceiving visual content”.

As with anything else on the web, there’s always an exception, and you should definitely check out the link above to read about some specific scenarios where opening a new tab/window can be appropriate. But those scenarios are rare. People know how to use the back button. Depend on that, rather than a new tab/window.


An audio captioning guide

Today’s post is a quick one, to share this awesome captioning style guide from Humber College, which I found while trying to figure out the appropriate way to caption a choir singing a round acapella (I still don’t know the answer). In addition to the most helpful information I found on captioning music, also included are suggestions on timing, dialog, sound effects, and accents. Since we need to caption almost every video on our website, it’s worth a quick glace to get an idea of how it should be done.

Creating an inaccessible website

Recently I found a post which explores some of the limitations of automated website accessibility checking tools by building a site that scores a 100% on Google’s accessibility checker, while being completely inaccessible.

That post explores the very real limitations of automated tools. Tools like that can be useful, and help us by checking some of the low hanging fruit. But they never do a great job. For instance, just to highlight one obvious example mentioned in the post, here’s some examples of alt text on a logo which links to the homepage which would pass an automated check, but are really terribly inaccessible:

  • alt=”logo”
  • alt=”logo.png”
  • alt=”Picture”
  • alt=”The Lane Community College Logo”
  • alt=”Lane Community College”

You know what some good alt text would be? “Visit the LCC homepage” – it’s a linked logo, so provide the purpose of the link.

When it comes to automated accessibility tools, use them to give you an idea of the overall accessibility of a page, but always double-check some items yourself – particularly ones that are difficult to for a computer to check, like link purpose.

Looking for more on alt text? Check out a decision tree for alt text

Welcome back!

I know, I know, we’re in week 4, and I’m finally putting out my first post of the year. But it’s 2020. It’s that kind of year.

Last week the web team attended the 2020 HighEdWeb annual conference. This is one of my favorite conferences, and it was even better this year because it was absolutely free online (though in central time, which made for some early mornings). Here’s some gems:

Plain Language Matters.

It’s an accessibility issue. It’s an equity issue. People skim online. If we make that hard for them, they leave. Take a look at our previous plain language post.

Resource pages & emails don’t work.

One of the groups at Miami University did a lot of extensive testing. People don’t self serve. If you have a lot of links and resources that you want to put out there, consider a drip campaign to slowly provide those links at a pace people can digest. Use social to highlight different resources at different times. Include titles that highlight the problem the resource solves (“Looking for a tutor late on a Sunday night before class? Look no further!”). Track what you do to see what works (and reach out if you’d like help setting that up!). Rather than a resource page, consider a blog, where those resource links can be provided in context, and do some content marketing for you. We’ve also covered resource pages in the past.

Stop posting flyers and event posters online.

Especially now, when we’re not going to see them in person. Flyers and posters are designed for print, and don’t translate well to digital. If you’re considering putting a flyer or poster online or on a digital sign, reach out – we’ll connect you with some graphic design resources, and help design for the medium you’ll be promoting on.

The college website is for prospective students. And those students know when they’re being marketed to.

Carlton did a great session where they detailed extensive user testing before their homepage redesign. They found things like:

  • prospective students (particularly Gen Z) think the entire website is for them. Even the section clearly labeled “Alumni”. But your homepage should be for them before any other audience: most other audiences search for something, then land on some other page. Prospective students are the most likely, by far, to land on the homepage.
  • they know when pictures are staged. They want to see people in place: shots that show what students actually do some place on your campus, and how that sets you apart. Person under a tree reading a book? Clearly staged. Dining hall shot? Every college has a dining hall. Candid shot of a class outside? Student learning to machine something? Much better.
  • Carousels don’t work. I think one possible exception is a photo gallery, but that’s tricky.
  • The large hero image on a program’s website sets the tone and creates a greater impression than all the text there.
  • From one of their slides: “Students want #nofilter, but we’re giving them #fellowkids”

FAQs don’t work.

While we may think splitting our content up into questions is easier for the student, it actually makes things harder to understand. Read your entire FAQ page, make groups out of the content and write a header for each one, and then rewrite the content in each group to paragraph form. It’ll work better for everyone. Here’s a page with the slides, a sample FAQ with real life before and after examples, and some other resources for why we should stop using FAQ pages. You can also review our previous post on FAQs.

2020 Site Archive now available

While I know I’d promised to put most blog content on pause, I wanted to make a quick post about the availability of our new site archive.

Every once in a while, we create a snapshot of the entire website. There’s a couple limitations to that. We can’t capture:

  • Files that aren’t linked from a page somewhere
  • Pages that aren’t linked from another page
  • Pages that are password protected
  • Some of the dynamic content (for instance, all the forms are disabled)
  • All of the changes that have happened since the last archive.
  • corrections to broken links (there were about a dozen internal links that are broken)

This type of snapshot, created using httrack, creates a standalone site that isn’t dependent on a content management system, meaning it’s very resistant to security problems, and is the only real option for creating a semi-permanent archive. I say semi-permanent, because while I intend to keep this archive up as long as possible, it’s possible, if not likely, that changes in browser rendering  will eventually make this archive difficult to view as intended.

This year’s archive will allow us to remove a bunch of old  content from the website, to further prepare for our new website. It also sets us up for splitting all the employee content out of the website: the current Lane website is monolithic, but under the new site, we’ll have audience specific websites.

Check out the 2020 Site Archive

Looking for an older archive? (you should! There’s some gems in there)



Helpful Plain Language Resources

Today’s helpful resource is the’s web language guidelines. While the whole thing is worth at least a skim, we’ve already covered a lot of the content in depth (see, for instance, the content redevelopment series). But I want to just briefly dive into the section labeled Follow Web Standards. There are four items that get their own subsection:

Avoid FAQs: We’ve talked about this before, but it’s worth revisiting. FAQ pages tend to be disorganized and hard to process. Try to eliminate them where you can.

Write effective links: We’ve also mentioned this in the context of accessibility, but it also makes a lot of sense from a usability perspective. Clear links are easier to use.

Repurpose print materials for the web: I think there’s some text here that’s worth quoting:

Don’t cut and paste the text of print documents to create web content. People are more likely to leave your webpage, potentially costing you time and money, because they will not take the time to find what they are looking for.

Print writing is different from web writing.

If you’ve created print materials, you’re going to need to rework them if you want them to be effective on the web. Make sure you’re speaking directly to the page visitor, and using conversational, but clear language. The purpose of print content is different than the purpose of web content.

Avoid PDF overhead: Here’s another quick quote:

The Nielsen Norman Group has done multiple studies on PDFs and has consistently found that users hate them and avoid reading them at all costs.

That should speak for itself. Avoid posting PDFs unless there’s no other option, or unless you need a document to print a certain way.

That’s it for this week, and also this year! Summer starts next week, so I’ll be taking a long break from blogging. Lots more to come this fall, along with lots of detail on the new website!