Skip to Main Content

GODORT Best Practices for LibGuides

Creating/Managing Content 101

  • Before starting a new guide, check to see if existing templates exist. Check out the "Creating a Guide" section to learn more about creating guides.
  • Keep in mind that LibGuides allows only one level of subpages. This is why complex guides, like the Government Information for Children (GIC) Committee or State Agencies have individual guides collated on a main guide.
  • Check for rotted links at least two times a year.

Pages and Boxes

In your guide, a page is what contains your content. Each page is laid out in one or more columns, with each column containing one or more boxes. Inside of each box are the individual content items (such as rich text or assets, including links, books, databases, etc.) that users will read and interact with.

Every page appears as a link in your guide's tabbed or side-navigation menu, allowing visitors to easily browse between pages. When setting up your guide, consider using pages to organize similar content. For example, if you have a subject guide for History, you could start with an overview page about the discipline, then have additional pages focused on databases, primary vs. secondary sources, citations, and so on.

If needed, you can create a hierarchy of top-level and sub-pages. A top-level page is what displays in your guide's tab or side-navigation menu. A sub-page can be nested under a top-level page and will display in a dropdown when users hover over the top-level page's link. This provides another level of organization, especially if you have a guide with a lot of pages.

You can make a sub-page when initially adding a new page to a guide, or when reordering your guide's pages. Learn more:

Based off of guidelines provided by Springshare:

Headings

Why do I need to use headings in my LibGuide?

Headings are an important part of navigating pages for internet users who use screen readers. Screen readers will typically read out all of the headings in a page and then allow the reader to select the sections they wish to read. This way, the screen-readers avoid reading out the entire page when they are only interested in one section of it. Without heading markup, users of assistive technologies are not able to skip through irrelevant content and navigate the page effectively. Some users will have to wade line-by-line through a web page with missing or improper section headings.

Headings are ranked <h1> through <h6>. Content creators sometimes use these ranks arbitrarily according to their visual appeal or simply use bold on Normal (<p>) text to demarcate headings. In order to make pages navigable by low-vision and blind internet users, both of these common mistakes must be avoided. Simply using bolding on paragraph text makes it impossible for screen-readers to break the page up into sections, while choosing heading ranks arbitrarily confuses the structure of those sections.

In LibGuides, the title of the page uses the <h1> heading rank while the section/box headings use <h2>. Any headings within these sections/boxes should use <h3> through <h6>. These ranks are always consecutive: for example, you should never go from a <h3> rank to a <h5> rank. See the section below for an example of proper heading format.

How do I arrange my headings?

Use headings as indicators for sections and sub-sections in your guide. This not only provides hierarchical organization and formatting, but also makes it easy for screen readers to scan and jump to different content areas.

  • Your Libguide's title automatically uses Heading 1.
  • Your LibGuide's box titles automatically use Heading 2, so start with Heading 3 (<h3> tag in HTML) and then Heading 4 in the text editor.
  • Higher-level Headings should be placed above lower level ones, otherwise your hierarchy gets confused. 

A helpful way to approach is to do so as if these headings make up a detailed table of contents for your page. While most users won't interact with it, this virtual 'table of contents' will help screen-reader users navigate your page far more easily.

"Good" Example

On the following example, "Volcanic Hazards Mitigation and Government Information" is the <h1>, "Summary", "Legislative History" and "Relevant Resources" are <h2>s, and Resources 1 through 3 are the <h3>s. If we were to make a table of contents based on these, it would look like this:

  • "Volcanic Hazards Mitigation and Government Information" (Heading 1)
    • "Summary" (Heading 2)
    • "Legislative History" (Heading 2)
    • "Resources" (Heading 2)
      • "Resource 1: United States Geological Survey" (Heading 3)
      • "Resource 2: National Oceanic and Atmospheric Administration"  (Heading 3)
      • "Resource 3: Department of the Interior" (Heading 3)

This is a helpful summary of what the contents of the page are. Sections are clearly separated, their functions are clear, and there is no chunk that is excessively long. As a result, a user who is read off these headings first knows where they need to go for what.

Based off of the following guidelines:

Images

Managing Images

Personal images are stored under Content > Image Manager on the top orange menu bar.

Adding Images

Images can be added to any Rich Text / HTML content block (by selecting the the Image icon). You're able to upload an image, reuse existing image already uploaded into the Image Manager, or point to an external image that already exists in the GODORT site or another site.

Sharing Images

Images can be shared with other GODORT LiGuide account holders via the LibApps Image Manager, a central place to upload and store images, which you can then reuse throughout LibGuides and LibApps. There are two types of image libraries where you can store images:

  • Your personal library contains images that only you can manage and reuse.
  • The shared library allows admin users to upload images that all users in your LibApps system can reuse.

Additional reading:

Image Alignment

Setting the alignment is not necessary in all cases but helps you to set the image to the left or right of text. This controls position of the image relative to text. If you want to center the image on the line, you must edit the HTML source code (but be careful about editing HTML code!).

Alternative Text

Completing the Alternative Text field to provides brief descriptions of information contained in the image. This is a very important step for accessibility. A good suggestion for what to write for alternative text is to imagine you were describing the image in a short phone conversation.

Learn more about accessibility by checking out the Accessibility section of GODORT Best Practices for LibGuides.

Need Assistance?

Don't hesitate to contact GODORT Tech for help: godorttechnology@gmail.com

Based off of the following guidelines:

Reusing Content: Create Once, Edit Once, and Avoid Duplicate Assets

When reusing content, pursue Mapping/Linking:

  • Go to the Assets library (Content>Assets) to review and manage content assets in all of your guides, including: links, RSS feeds, documents, books, media/widget...etc.
  • Deduplicate Assets: Type your name in the Owner column to sort and find all the assets owned (created) by you. If you found duplicate assets:
    • Find the duplicate(s) and click on the number in the Guide Count column.
    • Click on the guide title to go to the guide.
    • Remove the duplicate asset from the guide.
    • Add the correct asset by reusing the existing links or other asset to the guide.
    • Go back to the assets page and repeat this process until the Guide Count of the duplicate asset(s) is at 0.
    • Delete the duplicate asset(s) from the assets page.

The reason Mapping/Linking and using Assets is better than Copying is because it's easier to maintain consistency and currency of your guide content

For additional guidance, see GODORT's best practices on assets.

Based off of the following guidelines:


Accessible Text and Style

Write for how your users will read the text.

  • ​Users will skim over text, unless it catches their interest.
    • SpringShare advises “Think journalism (not academic writing)”.
    • Share the most important part first, then the details.
    • Use common language, not library jargon. Write like you’re talking to the user.
  • Research shows that readers’ eyes will track over your page in a roughly F shape.
    • The readers won't read every word – this is where judicious use of the bold feature can help bring attention to part of the text.
    • Put your most import information across the top of the page and down the left side.
    • Research also shows some preference for side navigation LibGuides.
  • Screen readers scan LibGuides column by column, which could be confusing to someone encountering a LibGuide for the first time.
  • Write explicitly to avoid unnecessary linking when/if possible. 

Spell out all acronyms within a page.

  • First occurrence should spell it out with the acronym following it in parenthesis.
  • Additional occurrences should use the abbreviation tag (<abbr>) if possible.
    • In LibGuides, toggle to the "Source" view in your editor.
    • Find the acronym in the HTML.
    • Add an opening abbreviation tag before it, with a title attribute that spells out the full name.
    • Add a closing </abbr> tag at the end of the acronym
      • Example: <abbr title="Grand Valley State University">GVSU</abbr>

Based off of the following guidelines: