Four keys to effectively communicate your site’s problems

My name is Rommel and I am relatively new to the Web Communications team. If there is anything that I have learned in my first few months in Web Communications is that they have their own lingo – I dubbed it “WebSpeak.”

I guess that every work environment has its own shoptalk that only those that have been around a while can comprehend. I’ve witnessed WebSpeak first-hand while working in Web Communications. At first I was overwhelmed with learning the lingo, however, I realized that all shoptalk is universal; you just have to find a way to incorporate your perspective. Once you get your bearings, you’ll find that WebSpeak is easy to learn.

I also realized that learning the lingo is only half the communication. Some of the requests that come in to our inbox contain only bits of information. There is enough to figure out what the request is, but finding “where” on the site takes a bit of  detective work. Of course, there are some clients that are more versed with WebSpeak and their requests are easier to locate and identify. But for others, I’ve compiled a list of recommendations that, hopefully, helps them communicate the needs of their website.

Key 1: Provide the URL

The first key is very easy. If your site is having trouble, copy the URL (Web address) of the page with the error/issue and include that in your message to web@wayne.edu. If it’s a specific link in a page, please provide that as well. The more information you provide about which Web page you found the issue, the easier it will be for us to identify and fix the problem.

Key 2: Provide a deadline

Provide a deadline. Clearly suggesting your expectations on when you want the task to be completed can help us immensely. Depending on the amount of work we currently have, we can provide feedback if the project will take longer than your expected deadline.

Key 3: Allow for time

Please allow for time. There are always tasks in our work queue and some may take longer than expected and it pushes the rest of the queue back with each delay. So please bear with us.

Key 4: Learn the lingo

  • Website – An allocated space in the Internet that has its own domain name.
  • Sub-site – A separate site but still within the domain of a website. Larger sites can use this to separate different areas of their site.
  • Web page – A document displayed in an Internet browser window in HTML format, a computing language. This single page constitutes one Web page.
  • Homepage – The main page of a site or a subsite (the “index” page). I think of these as the lobbies.
  • Child page  – A child page is a Web page that is subordinate to another page, usually a home page.
  • Menu items – These are the navigation items to your site which link the homepage to the child pages. The menu remains, most of the time, static, within a site.
  • Sub-menu items – A menu item within a menu item.
  • Template – A template is ‘what separates the content from presentation in a Web design’ (thank you Wikipedia). If content were the entree, then the template would be the plate.
  • Content – These are the images, words, events, links, etc. of a Web page. I compare this to the “meat” of the site.
  • CMS – The Content Management System is an interface used by Wayne State University for clients to manage the content of their website. Clients provided with site access can log in using their WSU AccessID and password.
  • Copy – These are all the words within a Web page. You can usually select these words and they are editable through the CMS.
  • Image – Any non-text element within a Web page. These could be GIFs, JPEGs, JPGs, etc. (all image file formats).
  • PDF – These files are like snapshots of documents; some are editable and some are not while some can be created with fillable areas. This file format is widely used and not specific to an operating system.
  • Link – Also known as hyperlinks, links act as portals from one Web page/website to another. These are used to navigate Web pages/websites.
  • Text Link – Text links, also called “anchors,” are links within a page. These can be used to navigate a large amount of text within a page
  • Promotional Areas – Think of these as spaces or items within your website (usually the homepage) that can showcase things/events that you want to promote. These are always designed by a graphic designer and are programmed into the site’s main template. There are different forms of promo areas but as I will be using wayne.edu as an example:
    • Main Promo – These are the big images that are usually on the homepage and take up a lot of space.
    • Promo Boxes – Standard, square-shaped boxes with rotating images, usually used to showcase featured events.
    • Promo Buttons – These are unique static images that stay on a page that link to an promotional event/form/site. On wayne.edu, these would be the Apply buttons below the menu.
    • Promo Item – A singular promotional item/image.

I admit, it is not a comprehensive list but rest assured that I will keep adding things each time I learn a new phrase or word.

I hope this helps people get more acquainted with WebSpeak!

 

Taking action requires knowing the next step

Having a clear next step is essential to someone taking it. Next steps are easy to find online, banners, large rounded corner buttons and “Read more” links seem to be everywhere. But next steps go beyond the Web, if you have a problem with your home Internet, the next step is probably to call customer support. When you know the source of the problem it’s easy to know who to call.

Decentralized Web

Not all next steps, though, are easy to determine, especially in a decentralized Web environment like we have at Wayne State.

I recently saw a demo for a product called SiteImprove which aims to help automate quality assurance on a website. I was impressed by the product and mortified by the results at the same time. In the 1,700 pages that were part of the demo we had 445 broken links and 180 misspelled words. I expected some, but not that many issues with our site. I want to make it clear this isn’t an endorsement for the product, I have not used it, just received a demo.

I bring it up because it opened my eyes to a major problem with the decentralized Web, and specifically with “crowdsourced” Web content management, which is a more fitting description for the WSU environment.

Lots of eyes but no one speaks up

We get millions of visitors each month. A good chunk of them are internal audiences who read the content on our pages. I’m willing to bet that people are seeing these misspellings and broken links but they don’t know who or how to tell someone about them. There is the old trusty “webmaster” email address and we do get a fair number of emails there, but they are often from students who stumble on broken links they need and it is their last resort. Obviously we don’t want prospective students to get to this point.

Most often someone on campus has interacted with one of us in the Web department to set up their website. Which means they probably interacted with me, a designer, a developer and a content administrator at the very least. They know the drill, and that the content of a website is the responsibility of the department. So they often don’t think of contacting us to fix it and although we ensure the “Contact Us” area is prominent on every website it is often used for student recruitment and there may be many hoops before messages get to the Web person in the department.

The next step to alerting someone of the problem isn’t clear, therefore problems often don’t get reported.

Who’s responsible for QA?

At the end of the day, the Web Communications department is responsible for the overall user experience on the Web. There may be a lot of factors that go in to what is actually produced but if there is a problem we are charged with fixing it. Although the content on every page isn’t originated by us, we need to ensure it building the university brand instead of hurting it.

How to report a problem

I have posted in the past about how we handle dozens of support requests per day without a ticket system and that has worked well for the past few years. We are now employing the same technique to our phones. Everyone in the Web department now has a single phone number. This way if anyone is out of the office or away from their desk the phone can still be answered and get handled in an appropriate timeframe. If someone leaves a voicemail it goes to our group email account that everyone sees. It’s been a week so far and the simplification has really helped to filter all requests through one person, our project manager, and only assigned/disrupt a staff member when they are needed.

The Web Department is now acting as a single point of contact for the campus community to know their next step. They no longer have to remember a staff members name, phone number or email address. Once a problem is reported we are able to determine who is the owner of the website and the quickest route to get it fixed. We will do all the leg work to ensure it gets corrected even if the website isn’t in the main university system.

But what about the public?

The process for the public to alert us is a little trickier. In the past if we added a feedback form or email address to a website as a “feature” it tends to get used by people who simply can’t find information or to ask a basic question. This would flood the IT staff with general questions instead of actual problems. The easier it is for the visitor the contact someone the more likely it is for them to use the contact info instead of using the website to find the information they need, they often look past the purpose of the form. That being said we are hesitant to put a “Report a problem” link on the page, even if it only shows if the visitor is on campus.

We are currently testing different options and should have a solution in the next few weeks.

Contacting Web Communications

Phone: 7-9707
Email: web@wayne.edu

 

So you want an HTML newsletter?

The types of projects our department takes on seem to go in waves. A bit of a history lesson takes us back to an abundance of websites which pushed us to build the CMS. The many events that followed gave us the idea to write and centralize them all in to a university events calendar. Then came the RSVP’s for those events. We got fed up creating hundreds of forms so we wrote an RSVP system for the events calendar. After that the campus community could maintain their own websites, and create events and RSVP’s by themselves. They then asked us to create pretty HTML emails to announce all of these components and we did that for a while before crafting the self- serve HTML email creator.

Everything goes digital

Now we are on the age of transitioning traditional print newsletters to digital pieces. These are a little more complex than the standard email and sometimes connect to a broader website with more information. In the last four months we have literally transitioned more than ten complete print publications to online editions. I would love to say that in those four months we created a self-service system for the entire campus to create and maintain publications, but I can’t. They all seem to have some unique factor that required individual attention.

Multiple flavors

Requesting a new HTML newsletter can result in a 2 hour or up to a 40 hour project. It’s important to know what you need before starting the process. Let’s walk through the process of the newsletter request and I hope I’ll be able to shed some light on the reason for the complexity.

Simple single column email

The most basic email is just a single column with a single message and any action items go off to existing websites. The types of emails have a custom header that identifies your department or group and is reusable at your leisure.

Here are a few examples of single column emails we have done:

Multiple column email

Typically a multiple column email is required when there is a single message that needs to be communicated and the content warrants “action items” on the side. These can be: upcoming deadlines, buttons for next steps or just “for your information.” They’re a little more complex but offer some flexibility to highlight multiple items “above the fold”. (BTW, there is no fold on the Web.)

Here are a few examples of multiple column emails we have done:

Multiple column newsletter

Using the same format as the multiple column email the newsletter takes it one step further and keeps a consistent format but with categories and articles feeding in to compile a complete email. Typically the format is set up and each month/semester/year a new “publication” is created which consists of article titles, teaser descriptions and links off to more information.

If the links for each article go to existing stories already published on the Web it gets the user to interact with multiple areas of your website and possibly explore things they otherwise wouldn’t have without being prompted by the email.

Here are a few examples of multiple column newsletters we have done:

Newsletter Web page

Lastly the most complex and time consuming is the HTML newsletter that has a stand alone website which features the full text of each article and is organized like a newsletter with editions and archives. This approach is really driven by the print mentality of compiling an entire edition of articles and publishing the entire thing at once. It wraps up the email and website into a single package for the user to experience. One of the downsides, just like a printed newsletter/magazine is once the user receives it and browses through, they typically recycle it or close the window and never come back. Their only reason to come back in the future is when their next email comes in. It isn’t “sticky” and doesn’t build continuous engagement, but in the end it’s what most traditional writers are comfortable with.

Here are a few example of newsletter websites that we have done:

Thinking about requesting an HTML email?

Make sure you have thought through how you want it to work and be prepared to answer some tough questions by our team. Just because “email is free”, aka you don’t have to pay postage, it doesn’t mean that your audience will engage the same way they have in the past.

Project Insights: Business Scholarship Application

By far the most complicated forms that we create are applications. Most recently we create the School of Business scholarship application. What makes them complicated is the overall structure of the form, they are huge. Typically broken into multiple steps with the ability to save progress along the way. Each step in itself contains pretty basic information but when you combine it with validation and overall flow from page to page things can get rough quick.

Planning the form

Before we start any project like this we take as much time as possible to plan the entire user experience from beginning to end. This is done by getting the physical form that students use to fill out and determining every single field that needs to be submitted.

People interact with web documents completely differently than physical pieces of paper so we don’t even consider the structure of the printed document in the planning stages. We start by grouping the fields in buckets of related information, these will become the steps in the form.

When logic is involved

From there we determine the order of the fields on the page and if there’s going to be sub groups within the page. Once the fields are laid out we then start to talk about logic. We ask, can any fields that can be hidden from the start? The less fields on screen the less intimidated people are to start and complete a form. We try to show them only the things they need and display any additional if necessary.

Keeping track of attached documents

Right when someone fills out their personal information they are essentially creating an “account” for this application. They get an email with a password and link back to the application as a reminder. From here on out their progress is tracked and all documents uploaded go into a temporary directory. The last thing we want to do is to loose user documents so each step verifies the actual documents are still in the temp directory before moving on.

Digital signature

When someone has made it through all the steps and is ready to submit we ask for a digital signature. It’s nothing fancy but it does force them to agree that all the information in the form is true and they acknowledge once they submit they cannot go back and change information. It’s a great way to weed out bogus applications but at the same time it holds up a lot of people from making that final step. The idea that the form cannot be changed after clicking the button leaves many apps in a state of incompleteness.

What we’ve found is people start the application early but end up not submitting it till 11:30 pm the night of the deadline. This seems like a fact of human nature so we have to make sure the system can handle a large number of submissions in a short period of time right before the deadline.

Downloading the applications

After the application deadline passes it’s now time to gather all the submissions and disburse for review. Depending on the needs of the department we do this several ways. Some want the entire list as a whole, others export the names in batches. Regardless things come out the same way, we make a huge excel sheet with every single field as a column. As far as the documents are concerned we create a folder for each, “lastname_#” and place all the files attached to their application in it. From here we zip them all up into one single file. This allows the department to get a checklist that they can scan or import into another system while still being able to see all the files uploaded attached to the last name and ID of the application. We keep the same filenames as they were uploaded on purpose, the less we touch the files the better. If someone calls and they had an issue and rattles off a filename that we don’t have in the system it’s a lot harder to figure out what’s going on.

Archiving each semester

Last but not least each semester the forms change a little. We have to archive the current semesters data in one batch then update the form and relaunch the application based on any new fields. We try to keep the database changes down to a minimum and really just change the front end form so we don’t have to re-engineer the structure of the back end every time. So far this has worked out great and the tweaks have all been based on user feedback and optimizing how students fill out applications.

Realigning your Redesign Process – My Case V Presentation

I was asked to speak at the Case District V 2009 conference this last weekend. Below is my presentation, description and links of the sites I mentioned. If you have any questions about the presentation or topic feel free to email me, ndenardis [at] wayne [dot] edu.

Description

What is the first step to redesigning your site, where is it falling short and how do you fix it? Find out about a successful redesign process that has been refined over the past six years with over 350 web sites. See how an internal team can work efficiently and with little resources to launch a large number of quality sites. Walk through the redesign process to get tips and pointers to deal with difficult departments and people.

Links from the presentation

Inside the Wayne State University Homepage Redesign

It has been two months since the launch of the new wayne.edu and I wanted to take some time to give an inside look at the process, goals and results of the project.

The Wayne State homepage was getting to be a dinosaur. It was over six years old, which is at least three life times in web years. Our redesign process started 9 months ago, we pulled together a committee of people from around campus to get input and make decisions.

The goal of the committee was to determine the pros and cons of the current web site and some recommendations for longer terms goals for the homepage. We also sent a survey to current students with hopes to gather all the input we could about what was working and what needed to be fixed.

This is what we came up with.

Site Goals

  • Increasing the screen real estate used
  • More Wayne State branding and less “Event Driven” content
  • Gain more control when user search from the homepage
  • Quicker access to the administrative sites at the university

With these parameters in mind we came up with some wire frames and started testing them with the committee. We quickly discovered what worked and what did not, a few rounds later we had a solid direction. We then tested the design with everyone we could find, staff, faculty, current students and even high school students. From their input we made even further modifications.

Comparison of Old v. New homepage

Graphically the new site takes up more real estate, it also uses the softer color pallet and has more negative space to call attention to news and event items.

Run Down of Homepage Changes

Header, We opted for the the full width header with the horizontal Wayne State wording. We used our Stone Sans typeface instead of the wordmark because the student input showed it gave a more personalized feel.

Quick Search, Since we do not have the Google search appliance and certain pages do not come up at the top of the public Google search we added a quick search ability. For example if you start typing “summer” a drop down will show up with the Spring/Summer registration site and you can get right to it without having to go to the results page.

My WSU Tools, The primary audience for the homepage is prospective students but we understand that current students/faculty/staff have the site set as their homepage and use it every day. Pipeline was the most clicked link on the old homepage and instead of creating another barrier for our internal audience we added a quick login screen so they can get to the administrative areas of the university without having to go through an extra login page.

Navigation, We kept the same left column navigation so the user was not too disorientated because ~80% of the visitors to the homepage are returning visitors. A suggestion from the committee was to separate the Faculty and Staff menu items because they have different needs. We ended up separating these two menu items. We will be completely re navigating the site on the next homepage version.

Accomplishments Area, A Main branding area filled with student success stories, interesting programs, alumni stories, community and promotions for schools/colleges. Overall it is a feel good place for anyone interested in the university to pull them in and keep them interested.The idea is to give prospective students a feel of the university and programs they could be involved in.

WSU Impact, Things that impact WSU and the community which need homepage presence.

News and Events, No more descriptions, we found them to distract from the news/event titles.

Featured Events, Used for upcoming events that are open to the public, what the three panel did on the old homepage, it will randomly choose one at refresh and a user can choose to move to a different event at their own pace.

Break Down of Child Page Changes

Header, Cleaned up the header, the new child page header and menu match the homepage header and menu, this was not the case before.

Main Content, There is now a right hand impacting photo on each page with quick links on the left hand side. The purpose of the links are to get a user right to where they need to go.

Related Information, We added targeted information to each child page depending on the audience. Typically it is the events calendar, announcements and related links. All three pull in information from around campus related to the audience of the page.

School and Colleges Page, To bring more unification to the schools and colleges instead of just listing them with links we added a listing of all the degrees offered from each school/college. Having these degrees listed by Undergraduate and Graduate status helps students jump right to the program information without them having to go to the school/college web site and try to find their information all over again. Check it out the Schools and Colleges page for the example.

Results

Overall the initial feedback after the launch has been positive. We added a link to the bottom of the homepage which simply says “Like the new wayne.edu?” This goes to a feedback form where the comment box is all that is required. Even with the site launching during the summer semester we received over 150 comments. We read every one and responded if they left their contact information.

If you have not already checkout the new wayne.edu.

Also checkout the site on eduStyle.net to nominate it or rate it against other university web sites.

I will be following up with another post to go in depth about the statistics.

New features coming to the university events calendar.

The university events calendar has been around since 2004. It has gone through three complete re-codings since its initial release and it about to go through another. Although thanks to PHPSimpl it won’t be too painful. We are revamping how an event is added, not only help the student looking for events but also to get a handle on upcoming events and their needs.

The goal is to gather as much information as possible without being a burden on the user. Right now the required fields are minimal, we just wanted people to use the system and we would worry about the details later. It has worked, year after year events submissions have grown exponentially.

Creating a central events calendar is key to event promotion. We recently added the upcoming event list to the students Pipeline, the site they go to for all student services. Further expanding the reach of the events.

A new feature starts with an idea, the idea that we need to gather more information without being invasive and still adding value. Below is the initial sketch I made of the new work flow. All new ideas start out as a sketch on paper or the whiteboard.

Workflow in Progress: Adding an Event

From here it goes for review, we sit on the idea for a little bit to let it sink in and make any modifications. Then propose it to the approval committee and once approved we start on a plan to integrate it into the current system.

With limited resources and the flexibility to work on the development server we first limit the new features to internal IP’s. This helps us test the functionality on the development and production servers without having to replicate the whole system in house. It also gives us a realistic idea of the load it is putting on the server.

Large features usually have a pilot department and we work out all the bugs before releasing to general population but features like this we will use internally for a week or two until we feel they are production ready. Using the features on a daily basis is the best way we have found to get the bugs and annoyances out.

This feature is still in the approval process but as it evolves we will post more info about it. New features are always exciting, I am glad we have a place to talk about our design process and upcoming features. If there is anything you would like to see or have us talk about just drop us a line.