Making Announcements: On-Site vs. News Blog

We’ve recently had to put up a couple of announcements due to some patches and upgrades on our library website server. Right now, I’m doing it the way I’ve seen it done on most library websites and that’s to simply put up an announcement on the front page.

Ryerson Home page with Announcement

However, there are numerous downsides to this method.

First, the way I’ve done it, it only shows on the home page, and no other page.

Second, you have to visit the website beforehand while the announcement is up in order to know that the site will be down later.

Using the Blog

One way to get around the second problem at least, is to use the blog. Posting on the blog automatically pushes the downtime announcements to the homepage feed, meaning that anything following the feed will see the notice even without visiting the site. On our blog, we can also automatically push to Twitter and Facebook if we choose to do so.

On the other hand, it’s very much time sensitive, and if the person doesn’t visit the site during the early hours of the morning, they wouldn’t even notice. Is it something people really need to be notified off-site? If someone visits often enough, they’ll see it.

Notification Bar

To fix the first problem though, I have been pondering the use of a notification bar. Much like the ones you see when your JavaScript or Cookies are disabled (see the stackoverflow example below).

Example of Notification Bar with Stack Overflow's site

Of course, best practices seem to be to only use notification bars for browser related issues.

Pop Up

What might work better is to have a in-page popup on first visit (once the announcement is set), with the option to dismiss it. Using cookies, you could then locally store a simple variable to see whether the person has dismissed that particular announcement already.

Ideally, we could do it in such a way that it will work across the entire domain rather than just the one site.

Branding the Library Website: Making a Flexible WordPress Theme

In moving our website to WordPress, I wanted to create a theme that could be used by our staff when working on online projects which would sit outside our main website, but in which we would host. Obviously they have the option of using other themes, but then someone (likely from our team) would have to make sure it meets accessibility guidelines, and as there are very few of those, I thought it best to just make our theme flexible.

No CLF

This is just a disclaimer that the main reason we could even do this is because we do not have a Common Look & Feel policy from the university administration, which most universities do. On the flip side, that’s one reason I wanted to do it. I would like that the library “products” are recognized as such. Doing it through a theme would also provide a more consistent user experience across the sites that use the library’s theme.

The Header

Our existing site already used a consistent header. However, it also includes the “Ask Us” logo, which would take you to the “Ask Us” page with all the myriad ways to contact the library for help. For other sites, it’s more likely that they will want to list specific contact instead, so I added an option to remove it.

new site header
New Header with Custom Menu and Google Search Bar

In addition, of course, for any sites using the theme, they will want the name of their site in the header, so I added a text box input for that in the options page and used font-face to pick a different font to make it stand out a little more.

The Menu

The navigation was built into the original theme so that you can either use a custom menu or it will fallback to using pages. However, the way our sites are made, some of the subpages menus would have been so long as to go past the end of the page, so I added the option to take out submenus.

new header with subsite title
Header with Subsite Title, Fallback Menu, and WordPress Search

Finally, the original website search bar redirects the user to the university’s Google search of the library’s directory, so I made the option to change it to the standard WordPress search bar to search within the current site.

The Footer

Since each site may have different links in the footer, I also made an option to include custom links in the footer, such that the ‘Home’ link is the only hard-coded link (which is always the link of the home page of the site you’re on).

new full footer
Full Site Footer with Custom Links and Social Media Icons

While it’s possible to make the social media buttons customizable, until there is a demand or need, I decided to simply put in the option to take them all out.

new basic footer
Hardcoded Part of Footer

The rest of the footer (copyright) is always there. Again, unless there is a demand or need, I didn’t make the copyright holder changeable.

Templating

As many sections of our website (e.g. catalogue/OPAC, Research Guides) are not part of the CMS, I am currently working on taking the WordPress template (minus the options) and creating a plain HTML and then a ColdFusion template to use in those sections.

New Site: Moved to WordPress CMS

We moved our site this morning to a new domain and it’s now running on WordPress. After a few issues with the redirect that central IT had to fix, it seems to be running smoothly.

There is still a lot of work to be done in terms of cleaning up content, especially since there are still many pages using tables for layout purposes (insert big cringe here). I also still need to finish going through the accessibility reports (only did the front page so far), and writing guidelines for staff. Training has still yet to happen for staff as well (since we focused on getting the site up first).

Spot the Differences

The website has actually changed very little on the front end. Think you can spot all the differences?

old home pagenew home page

I’ve made an answer key if you care to play (red = added/removed, blue = moved, orange = small difference).

Rationale

I think most people will understand the rationale in going to the CMS. The move in this case was much more for internal reasons, primarily so that staff can update pages. Of course, this actually should have a positive impact (at least in theory) as staff will be assigned pages and be responsible for keeping them current. Putting this system in place should also free up time of those involved in maintaining the website to do other things.

Ryerson Going Google with Google Apps: The Run Down

UPDATE: See my more recent blog post if you’re looking for my supplement materials (to the Ryerson Google site) on sync’ing Google Apps.

I attended a session to address concerns with privacy and security concerns in adopting Google apps at the university. Half of the session was actually a general how to protect your own information and your responsibilities as a user. I’ll focus more on the project itself than the second half since there’s a ton of resources about protecting your information already out there.

Google Apps

For the implementation, Sada Systems will be dealing with the actual implementation and migration. Roll out will be done in stages starting with the first four, and the rest will have to go through the evaluation process first.

  • mail
  • calendar
  • docs/drive
  • contact
  • chat
  • mobile
  • sites
  • app engine
  • plus
  • video

Options

  • Faculty and students will have an opt-in option for mail.
  • Staff, however, will be migrated (i.e. not optional).
  • Everyone will be moved to calendar in order to be rid of Groupwise (yay!).
  • Everyone will still keep their @ryerson.ca so there is no change in the email address itself.

Timeline & Next Steps

In a nutshell, there is none, and that’s because the legal agreement hasn’t actually been signed yet.

Once it does get signed, then alpha testing will be done with the CCS group (central IT) and then beta testing with a larger community group. They’re still hoping for a fall rollout though.

Legal Concerns

Most privacy and security concerns revolved around lawful access and warrantless searches with storing data in the US. It was explained that basically, it doesn’t make a difference. Canada has similar legislation and the Mutual Legal Assistance Treaties (with many countries) is a binding agreement to share information under lawful access or warrantless searches, which means the same thing will happen if your data is stored in any of the countries part of the agreement.

Privacy & Data Protection

To alleviate some concerns, the organizing group assured everyone that a Privacy Impact Assessment is done using the international standard, Privacy in Design and ensures that there are no breaches to:

Additionally,

  • all incoming mail goes through the university servers first
  • not opting in means that email stays on the university servers
  • opting in means the emails are then sent and stored on Google servers
  • students emails will not be visible in the global (internal?) address list
  • minimum identifying information (username, name) is used for authentication
  • drives/docs is private by default
  • calendars display only free/busy by default (as in Groupwise right now)

As I mentioned, in the second half of the presentation, we were all reminded that most email/information/data breaches are due to users, not email systems or hardware, and that email is not secure (although they’re looking into encryption for sensitive information). We got the usual spiel on our responsibilities not to include sensitive information in emails, having secure passwords, being careful of phishing, making sure websites use https, etc.

We’ll see how quickly they get things going, but I’m sure many staff will be happy to get rid of Groupwise (which likes to crash at least a couple of times a week and cancels shut down) at the very least.

For more updates, there is a dedicated blog for project updates.