Monday, August 11, 2014

Responsive Design Next Level: Entirely Modular Pages

You may have heard we are converting the Tarleton website to responsive design via our Project Squishy website. A lot goes into designing a new website, its layout, functionality, and interactivity, so we decided to provide you with a window into the designing and programming process involved in this very complex project. You may have already read Ernesto's post on our design for the new search engine and what he did to program it (if not, go check it out!). Today's post is going to be more focused on what you will be able to do with the new responsive design in Cascade Server, our Content Management System (CMS): modular pages.

How We Got Here

Before we moved to a CMS, web maintainers were able to design their websites, sometimes with the assistance of Web Services for website layout:
  • Full control: Maintainers control website layout and content
    • Adobe Dreamweaver
    • Microsoft Frontpage
    • Mozilla Composer
  • Partial control: Maintainers control content in an editable region on each webpage
    • Adobe Dreamweaver
    • Adobe Contribute
A screenshot of the Financial Aid website as seen in the Layout view of Cascade where editable regions are shown as three columns on the page.
Three editable regions on one of the first
page layouts made available in Cascade.
Web marketing strategy was very lax at that time, since everyone was able to set colors, logos, navigation, and content up any way they wanted. When President Dottavio came on board, though, he wanted to improve the marketability of our degree programs and usability of the Tarleton website, so he directed Web Services to approach websites in a consistent manner, look and feel. This would, in turn, help us also meet legal requirements regarding accessibility of content, security of information, and intellectual rights of content owners.

Our solution moved us into Cascade Server where web maintainers have control over smaller editable regions of their web pages. We started out very basic, since users were already used to a large editable region on each page and called us to help update the navigation. Many of them had full control of their websites before, so they had access to do much of what they did before, however, not every web maintainer is tech savvy. We wanted to give our web maintainers more control without making them learn how to program a web page, a simplified approach to content updating and web page creation.

A screenshot of the Band website as seen in the Layout view of Cascade showing the complexity of a modular page.
Multiple editable regions are available in modular pages,
however, depending on the programming needed,
Web Services has to maintain specialized modules.
We started to create more specific pages to meet those needs, such as:
  • frequently asked questions (FAQ)
  • faculty/staff listings
  • news listing
  • many, many, many more
This wasn't enough, either, because web maintainers needed content before and after a FAQ or maybe two FAQ sections, or a FAQ and a news listing all on the same page.

The Need to Change Course

Each new page we created made building a new website a longer process. What pages do the web maintainers need? Does Web Services need to build each page that could be possible? Does Web Services need to program more specialized pages each time a web maintainer requests the content modules be placed in a different order on a page?

This is when I started pondering modular pages, a way for web maintainers to decide what content module (i.e., FAQ, news listing, directory listing, or basic content such as paragraphs, lists and tables) goes where without worrying about programming any of it.

With the new design in Project Squishy coming into view, we weighed the good and bad of modular pages.


  • Web maintainers will be able to update content modules without programming skills.
  • Content modules can be arranged on a page in multiple ways without requesting Web Services create a brand new page layout.
  • Content will be created more accessibly without extensive training for the web maintainers.
  • Screenshot of the content modules that make up the Tarleton homepage's main content section.
    Content module folder containing the content modules
    (or blocks) linked to the Tarleton homepage
    that make up the main content area on the page.
  • Web maintainers will have the assistance of Web Services to provide recommendations of best practices for content.


  • New pages will be created initially by Web Services, not the web maintainers. 
    • Upside: Web Services will consult with maintainers on content strategy for the pages first, so web maintainers will only need to update content, not worry about layout.
  • Editing a page will really mean editing content modules that are located in content module folders separate from their pages. This will be a new process for almost all web maintainers who are used to clicking on a page inside Cascade and then clicking the Edit tab for that page.
    • Upside: Content modules are re-usable, so a number of maintainers who may need content they don't personally own can include other maintainers' content modules as opposed to duplicating content. This cuts down on outdated information available on Tarleton's website and the time it takes to make duplicate copies of content.

What Content Modules Will Be Available in Project Squishy?

There are well over 200 options for modules on our current website, however, a majority of them will not be transferable to the Squishy website.

Many are based on program scripts that are no longer maintainable, such as a number of our slideshows, because their program authors dropped these projects. Think of it like anticipating what you will be able to still use when Apple or Microsoft pushes out a new operating system. Software companies have to make updates to their applications to make them compliant and functional with the newer operating systems, but if those software companies go out of business, the software becomes obsolete.

A screenshot of an unresponsive feature we will not be implementing across the website.
The Tarleton F.O.C.U.S. uses a light box feature that is actually unresponsive (does not properly change dimensions depending on screen size or device orientation). The scope of this solution is limited to the homepage due to the complexity of the programming required.
Other modules just do not function on a responsive level, so they would be inappropriate to move over to the new design layout. For example, a light box (as seen on the desktop version of our website when clicking on a testimonial or picture on the Tarleton F.O.C.U.S.) is not responsive because it tries to (a) provide the entire content in a predetermined shaped box that cannot be reshaped or moved and (b) center it on the page, however, screen dimensions differ across devices. The solution we pulled off for the Tarleton F.O.C.U.S. only works because the content is connected to a database that dynamically generates pages for mobile phone screen sizes. If we implemented the same solution across the website, since our web maintainers do not have database access to store images, we would have to create each and every page for the individual images.

So What Can We Expect in Project Squishy?

Screenshot of responsive directory listing content module.
Mockup of redesigned directory listing that is responsive
on all devices and seen here as the mobile version.
We are doing a lot of research on what modules would work for our website and our users. We will start with a small set of options and add more when we are able to build them. Each one requires a lot of planning because we are trying to determine their behavior on varying screen sizes. You've already seen some modules on the homepage that are being considered for use on the rest of the website:
  • Highlights: a rotating set of pictures linked to valuable information or calls to action
  • Slideshow: a rotating set of pictures and their captions that can be used for testimonials as well as calls to action
  • Calendar: currently linked to content automatically generated from the Online Calendar System, our plan is to also include a manual feed for websites that don't have specific categories of events related to them.
  • Statistics: a rotating set of pictures and stats that show off the points of pride for any department or program.
  • Testimonials: currently only one design for testimonials is available. This version is a panel with a huge quote and a picture of the person cited. A new one will be available that rotates through multiple testimonials on the side of textual content.
However, we're missing the most important modules that focus on textual content. We are creating some with options for adding pictures, colorful blocks of content (asides), rotating content on said colorful asides, and more (see the above new directory listing). As we get ready to finalize modules, I'll post the new ones.


Friday, August 8, 2014

Coming Soon: New Features in Cascade Server 7.12

Cascade ServerHannon Hill announced on August 6, 2014, that Cascade Server 7.12 is available. We are on the queue to upgrade Tarleton's content management system at 7:00 AM - 8:00 AM, on Wednesday, August 13, 2014.

In general, this upgrade consists of new broken link reports, improvements to drafts, and filter options for stale content checking.

Broken Links

We have had some issues with page specific broken link checking. You may have noticed when you have external links, you see every single one of them pop up in a broken link report once you submit your page after editing it.

This is a problem for multiple reasons. The potential for false positives, or links that aren't broken are considered broken, is very high. Since you'd have to check every single link each time you edit and submit your page, you are less likely to go through that long link check process. Meanwhile, pages you are not focused on editing may now have broken links, but since you don't edit them, you never know about these issues.

Hannon Hill is now providing "site-wide" broken link reports (we will discuss "Sites" benefits in more detail as we convert your websites over in Project Squishy), so you don't have to click on individual pages to check for broken links. These should circumvent our current false positive issue on page related link checking.

"Link Report" will become a new tab on your dashboard when we upgrade, and a dashboard widget option will be be available when we move you into Sites.

You may be aware that our student technicians and interns are contacting you about broken links on a regular basis. We are using SiteImprove to provide you with those results, however, they only work when the pages are published to the live website. Cascade Server will check all your link content, published or not, on a periodic basis.

It will provide you with the pages the broken link is located on, the number of times they occur, and what type of broken links they are, so you can easily find and correct your links, putting you back in control of your content. As you fix your issues, you can change the Status of each broken link, so these issues don't continue to alert you in the Link Report.


When you are editing a page inside Cascade, your changes are automatically saved as a Draft. Often when you are typing or clicking on something, you'll notice your editing area shift around as Cascade informs you that you currently have a Saved Draft. This disruptive behavior will be no more!

Also, your old drafts (if you accidentally made multiple on the same page) will be discarded as soon as you submit your edits. You won't get confusing error messages about that mysterious person who has a draft of your page as well leading you to believe you might not want to submit those changes. Draft changes will include a sanity check: timestamps will be available on your draft versions.

Stale Content

Some content doesn't need to be checked every week, month, or whatever arbitrary time period we have marked on your whole site. After all, the university catalog gets a refresh once a year, so why should you be yelled at by a stale content checker every month asking you if you've updated your course rotation schedules yet? That's unnecessary worry.

You will be able to organize your content by folders, and these folders will have different shelf life settings, so things like course rotation schedules don't have to be checked but maybe once a year. News content (because we want to know the exciting things your department is doing right now, not a year ago) would be checked far more periodically.


Monday, August 4, 2014

New Workshop: Making Updates in Cascade Server

Cascade Server
Web Services invites you to attend our August Workshop:
"Using Cascade Server to Make Timely Web Updates,"
led by Morgan Hammond, Web Content Specialist for the Office of Web Services.

The workshop will be @ 3:45P on August 15, immediately following the Cascade Training.  It will be held in the Library Training Center, which is accessible from the new Library Commons area on the main floor of the Dick Smith Library. 

This workshop will allow you to spend an hour making your web updates alongside other web maintainers and Web Services Employees. You can ask questions and get one-on-one help with those hard to make edits. This is a great way to get out of your office and away from distractions to make those much needed updates!

Should I attend this workshop?


  1. If you regularly write and make updates to a Tarleton site, you will learn about the latest updates to Cascade Server, the effective use of Cascade tools and get solutions to common problems you have struggled with over and over while making updates to your site.
  2. If you have been tasked as a Web Maintainer and already attended training this workshop is an easy way get a jump start on those edits, or build your confidence.


  1. If you have not already attended training, this workshop will leave you with more questions than answers.
  2. If you want a course in HTML writing, Web Services does not provide training or courses in HTML.
  3. If you want to redesign or change the layout of your pages, please contact Web Services to schedule a consultation.

Take Aways

While our one hour training sessions are a great start, we realize that most learn from doing. You will be able to build your confidence, get advice from the experts, and be able to make updates faster after attending this one hour workshop.

Cascade Training

If you are interested in attending a training session, you can see a list of scheduled training sessions on our website. To RSVP to a scheduled training, send an email to Please be sure to have your immediate supervisor request your access to Cascade and fill out the Cascade Server User Agreement prior to your training.

Monday, July 28, 2014

#MondayFunday: Cappuccino Lays

In order to make our Monday morning a little more bearable, I brought in the new Cappuccino Lays chips to do an office taste-test.

The only person who really liked the chips was the same person that does not like potato chips OR coffee. Go figure!


Thursday, July 17, 2014

Other universities in the media

(Photo from nicolasconnault)
Web Services' staff is tasked with evaluating Tarleton's web pages and vendor-contracted web pages/technology for accessibility, copyright, and security issues. This is a tedious yet necessary responsibility that the university is required by law to perform. As we have learned more about these federal requirements, we have over time made our evaluations more stringent.

We have observed the ramifications of what happens when a university ignores its obligation to abide Section 508/TAC 206, U.S. Copyright Law, and TAC 202. We do not want similar actions taken against Tarleton, which is why we adamantly check our websites, software, and other technology for compliance.

Doing these evaluations does take some time. Sometimes I would rather be working on web graphics or designing web layouts. However, if we do not take the time to evaluate, a reprimand (or worse) is just inevitable.

The following are examples of universities who have been reprimanded/sued/reported for not complying with accessibility requirements. I think you will be surprised!
Here is an example of a situation where the owner of non-popular blog was sued for copyright infringement on one image. And no, universities can not claim "fair use" on images posted on it's public website - they must follow the same rules.
Due diligence is the key here. And even though these are requirements by law, shouldn't we at least feel morally obligated to provide equal rights to services and prevent theft? I think so!


    Wednesday, July 16, 2014

    Code Reader versus Screen Reader

    I came upon an interesting article by Tracy Mitrano whose intent was to describe the evolution of the definition of accessibility through laws and court cases as technology changes, including its place in cloud computing. Towards the middle of the article, Tracy hits on something that I think we've all been explaining incorrectly, and it's probably why our users don't understand why we say certain issues are inaccessible.

    What is a screen reader? When the average visual person reads those two words, it seems to mean that what you see on your computer monitor is what this software program is reading to a blind user. This is more the goal than the actual service provided.

    Yes, we'd love for screen readers to provide all the information we place on the web pages to the blind. Seems like a fair deal, right? But how do you do that? And what are they actually getting? Keep in mind, they are listening to a textual description of the content, not seeing a visual interpretation.The textual description blind users receive is based on the code that makes up the page  of all its content and functionality.

    For example, we have a piece of code that basically says, "Computer, please put this image file on the web page." A picture now appears on the page.

    "Computer, please put that image on the left side of the page." The picture appears on the left side of the page.

    "Computer, please resize the image proportionally to be 300 pixels wide." The picture appears on the left side of the page proportionally resized to 300 pixel width.

    We don't say that much when we program, since that would be a lot of typing, but you get the idea.

    Most of the "code" mentioned above only speaks to visual characteristics of the image on the page. No blind user is going to be concerned what size the image is nor will they care which part of the page it is located on. Right now, they still don't even know what the image "looks" like. That's where alternative text comes along.

    When we ask the computer to place an image on a page, we have code for alternative text, so screen readers can tell blind users what an image "looks" like at that place on the page.

    "Computer, please provide alternative text for this image: Baby laughing at a playful kitten tied up in yarn." Though you just read it, you have a visual image already in your head. That is what blind users "see" in their own way.

    Instead of reading what the screen shows, our computers are reading what the code provides. That means that only when we properly code our web pages do blind users receive a similar experience to that of a visual user looking at a computer screen.

    What do Screen Readers read?

    Code. First and foremost, you must understand that what you see visually is an interpretation of code by a browser that you are using (and if you've opened a website in multiple browsers, you'll note they show content a little differently from each other). A screen reader reads the code behind all the fancy visual effects of the page from top to bottom. No matter how it is positioned on the page, for the most part* screen readers provide code on a first-come, first-read basis.

    *This only changes if there are real-time interactions, like those on a social media account where a notification pops up telling the user they might want to take immediate action.


    A screen reader will read everything, and I mean everything. If every web page on a website has long navigation at the top of the code on their page, that blind user will have to listen to it every single time.

    This is different for visual users, since we can gather a lot of information by scanning our screen. We quickly move to the area of the page we want to focus on with our eyes.

    Screen readers provide similar scanning functionality through tools we visual users like to call shortcuts. They are the primary way blind people use the website, so web maintainers are recommended to accommodate them.

    The good news is that if we use web page semantics properly, we benefit blind and visual users at the same time.


    Using Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, and Heading 6 on your website correctly can help all users scan, or skim, your web page easily for content. Since many users don't like to read, or they are in a bit of a rush, skimming is a common practice. Using these headings sets off content for visual users as well as blind users.

    Blind users have a shortcut that lists out all the headings on a page. They can perceive importance and relevance of information quickly by scanning this list.

    Screen readers introduce headings, along with their heading level, and read the text for that heading.
    • DO use headings to separate chunks of content.
    • DO use headings hierarchically (i.e., first Heading 1, then Heading 2 without skipping around).
    • DO NOT use headings to visually increase the size of text.


    Screen readers have a shortcut that lists all the links on a web page. That means the links are pulled entirely out of the context of the page.

    They introduce the link and then read exactly what is in the text of the link or the alternative text on an image that is a link, not the titles on either one.
    • DO state where the link is going via a call-to-action or other direct text (i.e., "Apply Now to Hug Kittens!", "Kitten Hugging Application Form", "About the Kitten Hugging Program").
    • DO NOT use "here", "click here", "more", or other text that does not provide relevant information about the link.
    • DO NOT use the web address, or URL, as for the link's text.


    Unless an image has alternative text, blind users completely miss out on the important information or context it provides a visual user. Rarely should any images be considered "decorative," and given our need to reduce load time on the Tarleton website for users with slow connection speeds, we reserve the right to remove any unnecessary images including those without alternative text from Tarleton web pages.

    Screen readers introduce images and then read the alternative text for those images. If the alternative text is too long (over 140 characters), web maintainers should provide an alternative means to describing an image which Web Services can assist on.
    • DO keep descriptions as simple and concise as possible without losing the action, mood, and/or tone that should be interpreted from the use of the image.
    • DO keep alternative text descriptions of logos simple (i.e., "Tarleton State University - Member of The Texas A&M University System", "Texas A&M University", "Kitten Huggers - No Reason, Just Because").
    • DO NOT create text-heavy images that cannot meet the alternative text character limit (140 characters) and generally avoid them if possible.
    • DO NOT include introductory words like "Image of", "Symbol of", "Picture of" to inform blind users they are at an image, since the screen reader already informs them.


    Keep your content meaningful. Screen readers allow blind users to skim paragraphs by reading only a few words at the beginning of the paragraph before moving on to the next one.

    Screen readers pause for punctuation as well as for the end of the paragraph.

    Some screen readers read words in all uppercase word as initialisms (i.e., CIA, FBI, TGIF, ICYMI, BTW), so it can become aggravating to hear each letter sounded out. Others read all uppercase sentences as shouting which is considered inappropriate internet demeanor.

    Bold and italics are interpreted as important content or content with emphasis. When entire paragraphs are marked up as bold or italics, interpreting the important pieces becomes impossible.

    Screen readers cannot discern the difference between extra characters and punctuation for aesthetics or setting off important information. They will read each punctuation symbol or space individually which will cause confusion.
    • DO create meaningful content in small chunks.
    • DO use proper grammar and punctuation.
    • DO use all uppercase letters for acronyms but avoid them anywhere else that may deem it shouting.
    • DO NOT bold or italicize entire paragraphs.
    • DO NOT add spaces or other characters for aesthetics.
    • DO NOT add extra punctuation (i.e., "!!!", "**", "------", "---->") to denote importance or emphasis.

    Lists (Unordered and Ordered, or Bulleted and Unbulleted)

    Lists are great for setting off chunks of content and improve readability on web pages. Blind users take advantage of them in a way visual users typically don't: screen readers give blind users a head's up on how many list items are in each list before reading them off.
    • DO use lists for content that can be appropriately set off in small chunks for speed reading.
    • DO use lists for sets of links instead of paragraphs.
    • DO NOT use lists for content that is more readable as a table.


    Table layouts are notorious for being inaccessible as screen readers cannot determine the direction their content should be read appropriately. Tables should only be used for tabular data.

    Screen readers go into a table reading mode that excludes content not typically a part of a table.

    In table mode, screen readers will inform blind users of how many rows and columns are in a table, similar to the functionality of viewing a list.

    In order to interpret direction and location in a table, screen readers turn to table headers for the meaning of table cells and the scope of cells the table headers define or support. These table headers are introduced before the contents of each cell are described.

    Table headers are often misconstrued as bold text or Heading (Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, and Heading 6) text in a table cell. The reason for this confusion is because semantics do not carry over correctly from Microsoft Office documents to web pages.
    • DO make table header cells of the "cell type" Table Header for proper semantics.
    • DO request assistance from Web Services to clean tables copied/pasted from other documents.
    • DO NOT create table header cells using bold text or Heading (Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, and Heading 6) text.
    • DO NOT create tables specifically for layout purposes.

    Other Semantics

    Since Web Services maintains the code for much of the other content, I won't go into detail on forms or buttons. Screen readers do have a form reader mode, similar to the table mode. Forms are more complex, given the many form field types and the need to provide labels and instructions for each one in different manners. If you ever need a form, please contact Web Services to assist you.

    Examples of Screen Readers in Use


    Monday, June 30, 2014

    End the Bloodletting in Digital Visibility

    Over the decade I've been working in web design, I've come across multiple complaints from staff telling me a student or parent called about being unable to find something on their webpage. I come over to their office, so we can look at their webpage together, and we notice that the content is really there, so the next question is typically: how do we get people to notice this information?

    I've seen a very common "knee-jerk" reaction to this issue that reminds me of the days of bloodletting. No, I'm not old enough to remember it firsthand, but if you will recall from your history books, doctors used to believe that the reason people were sick was because something bad was in their blood. If they removed the infected blood from a person's body, that would cure them of their ills.

    Now, it's true, you likely do have a lot of bad stuff running through your blood when you are sick, but what else is in running through your veins at the same time? Good blood cells that are fighting off the bad bacteria and viruses. Those doctors didn't know that at the time, so they would continue to remove good and bad blood from their patients' bodies. Did that help? Sometimes, but they likely also killed many patients in the process. It was an inefficient solution.

    Archaic Solution for Digital Visibility

    I often see similar solutions when it comes to making content more visible to users of websites. Web maintainers are constantly told to do the following to make content more visible:
    This is really important information. I mean, important. Like, come on now. You need to read this!
      Okay, well, that didn't work. Let's try:
      This is really important information. I mean, important. LIKE, COME ON NOW. You need to read this! 
        No, still didn't work. Let's try:
        ***This is really important information. I mean, important. LIKE, COME ON NOW. You need to read this!***
          On occasion, this seems to cure the problem, right? You seem to be getting fewer questions about it which also seems to prove that your technique worked. As you can see from the above usage of bold, italics, underline, color, font size, and extra characters, you may have solved the visibility problem of one portion of your content, but you may have created potentially many others.

          What else might be happening? Users are now calling that they can't find some other content that you and I both know is on the same page as the content we just fixed.

          Why is this Not the Solution?

          What common purpose do all these techniques shown in the above examples actually have on your page? All of the above techniques are merely aesthetic modifications. Granted, when we think about aesthetics, we think about what we see with our eyes, visual cues to direct our brains to pay attention to specific content. However, if there are multiple regions of content applying these techniques, our brains can only focus on the content temporarily, as they notice another region and then another, and may not record this information into memory.

          Your content is going through a visibility war. Each piece is now in competition with the next piece of content. From an accessibility point of view, this is very bad for users with permanent or temporary mental disabilities (see Simulations of Mental Disabilities), such as attention deficit disorder or TV combined with a screaming child. And considering these modifications are for people who can see, what purpose does font size or color have for catching a blind person's attention?

          The Modern Solution for Digital Visibility

          This isn't a design issue, this is a content issue. That is, you need to rethink how you write your content before resolving that the issue is aesthetic. Here are some tips for making your content more visible.

          Page Flow

          Your users should be able to easily scan your page top-down for information. If they pop around on the page, they will lose focus.
          1. Be clear and concise, and keep your paragraphs short.
          2. Turn your content into consumable (small) chunks of information.
          3. Use tables and lists over paragraphs to make content easier to understand.
          4. Separate your consumable content with short headings for easy scanning and comprehension.
          5. Keep It Simple


          Your users need to be able to understand what you are saying. This goes beyond spelling and grammar.
          1. If your audience for this page is external, avoid using jargon that external audiences will not understand.
          2. If jargon is needed, define jargon after you have led users to your content with commonly understood terms.
          3. When speaking to a general audience (i.e., parents and potential students), make sure your content is readable at a sixth grade level.
          4. Summarize complex content first before introducing such content, if it is required on your page.

          Content For Your Users

          Think about who is reading your content, their personas. Each page your create must serve a purpose for your target audience(s).
          1. Change the purpose of content from what you want to see on the page to what your audience wants to see.
          2. Cut any content that does not serve a valuable purpose, that isn't benefits or value driven, or a call to action for your audience.
          3. Organize your content based on the importance of the information to your audience. 
          4. Write to your audience instead of using third person, so your audience can connect with your message.
          5. Keep the tone of your message upbeat, and rephrase your message in a way that makes "bad" news, or a negative call to action, look like "good" news, or a positive call to action.

          More Information

          We can't put everything and the kitchen sink in one blog post (similar to the issue with overloading web pages with content), or you would stop reading! However, if you need to reference more information, put it at the bottom of your page, so when your users do have the time to read, they will come back here and check out these valuable links.

          Simulations of Mental Disabilities

          These videos are simulations of how the environment can affect a person with a mental disability. A physical environment is no different from a virtual environment as both have sights and sounds. Web designers often talk about a layout being "too busy." Think about what you see and hear in these videos and how this may affect layout of content on a web page.

          Caution: These may trigger reactions for those with autism, Aspergers and other mental disabilities.