Website update plus secrets

Just a quick note on the Website republishing that I spent three weeks warning you about:

It seemed to go fine. Please check your pages at your earliest convenience to see if that’s true.

The only two things that you might notice now are these:

  1. The icon for the “In This Section” has changed to match the menu icon for the Quick Links. This is just being more consistent in our visual vocabulary.
  2. The copyright date is now 2020 instead of 2018. I kept meaning to change it, but now it seemed silly to change it just to change it again in less than a couple of weeks. So it’s a little ahead. Meh.

Super secret project, shh don’t tell anyone

Take a sneak peak at the new faculty/staff directory. I’m still taking feedback, but this “beta” is probably totally ready for public use. There are a few technical things about updating the files it uses that are still being sorted, so we haven’t added this to the main menu yet, but basically it’s ready to go.

Know that these are some intentionally-imposed limits to reduce SPAM and Phishing:

  • It stops at 20 results
  • It requires a couple letters at least before it searches
  • You have to hit return or press the search button before it will find anything

These are some things it does that maybe aren’t obvious:

  • It uses exported Banner data and matches email addresses against those used in Profiles, and if it finds a match, links back to a Profile.
  • In addition to linking, it also displays the full name set on the Profile. (So if you prefer “Dr. Bob Smith” over Banner’s “Bob Smith,” that’s what it will use.)
  • It searches all fields, not just the name. So if you need Tim in Strat Comm but can’t remember his full name or even what his department is really called, “Tim Strat” will be enough to get you Tim Hart in Strategic Communications

These are some features that we have contemplated but haven’t decided about yet (though we kind of lean away from all of them):

  • Should we offer a way to narrow the search to just search certain fields, like “name” or “job title” or “department,” or is that just complicating things and making phishing easier?
  • Should we roll in Profile pictures? The look and feel of this isn’t really designed for it and it feels like maybe overcomplicating its directory existence, but it might be cool.
  • Should we make the email link a form? It might be more secure against a very sophisticated SPAM or Phishing attack, but to get past the 20 cap results and actually having to search for something to start with, they’d have to be human-level AI type sophisticated to get everyone, and even then … And this is about letting the public contact us, so it has to be something that humans can do. And human nature seems to push people to not use contact forms: they don’t get to keep a copy; that they don’t trust that it will actually work; it would still require the user to put in a valid email address to be contacted, and they are very bad about that; a bot could still abuse a form.

Anyway, if you guys have any thoughts on that let me know; or just want to use a really fast, convenient faculty search, there it is.

Also, I don’t really care if you tell anyone, but everything is more exciting when it’s forbidden.

Secretly Update your MultiEdit links

Before you get worried about all the type and diagrams below, let me just point out that this optional thing only takes like 30 seconds, and you don’t even have to publish the page. The video I made ( https://youtu.be/Rc-5-OaNUy4 ) is 45 seconds because I had to explain things while I was doing them.

If you have any links in the MultiEdit content of your pages, you should update those so that they use the Dependency Links. When our site was set up, that wasn’t possible. But we updated things a few months ago so that we can. This is for Hero Images and any links set in MultiEdit. Updating the links only takes about 30 seconds, but can save you from broken links in the future.

Long story short: if it is a link to a page on wichita.edu, then you should make it a Dependency link ( { {f:1234567} } ). When pages get moved or renamed or deleted, the Dependency link will alert people that your page is linked to whatever is being changed. If you don’t use a Dependency link, they’ll have no idea that doing those things will break your page.

Links can have several forms:

  • Dependency links: These look like this: { {f:1234567} } This is what we want them to look like if they are internal. We don’t need to do anything with these.
  • Off-site links: Something that doesn’t go back to www.wichita.edu, which could be anything such as https://google.com or https://learn.wichita.edu … We don’t need to do anything with these.
  • Shortcut links, which start with https://wichita.edu/ but end with something that doesn’t exist in OU and is redirected, such as https://wichita.edu/websupport … These links can optionally be left alone, but you might need to make sure that if an on-site page is moved or renamed then the shortcut also needs to be updated. This is not automatic. You can replace the shortcut with a link to the real file if you’d like to use the Dependency link.
  • On-site links that are full urls: Anything that starts with https://wichita.edu/ or https://www.wichita.edu/ and goes to a real page or folder, such as https://wichita.edu/academics/index.php or https://wichita.edu/academics/ … These links should have everything before wichita.edu lopped off and changed to a slash (“/“) and the end of it should be pointing to a file, not a directory … so if it’s going to a directory, type “index.php” before you click the link button.
  • On-site links that are relative urls: These simply start with a slash (“/“) and go to a folder or file. Like above, they should go to a file and not a directory, so you may need to type “index.php” before linking.

That’s a lot of words for something that takes only seconds to do. But here’s a video of literally the same thing wherein I handle basically all of the above situations:

I was hoping that the latest republishing of the site would correct these links for us, but it did not.