A need for improvement of our website is recognized. More and more users are using a wider range of devices and screen sizes and the mobile website is no longer effective.
We went to numerous conferences and webinars, including those hosted by eduWeb, Environments for Humans, Higher Ed Experts, Knowbility, Texas DIR, and SXSW. We started collecting and comparing a number of frameworks, SASS versus LESS versus "are we going that direction," and JS plugins that we might consider useful.
Look at other universities and sites, find ideas for layout, organization, functionality. If you find something great, steal the idea and make it your own! Sources of inspiration: www.edustyle.net and http://erikrunyon.com/highered-rwd-directory/
One thing we kept asking ourselves is "When do we go responsive?" We had to check what our audience was using in terms of browsers (and their versions) and devices. We were also aware during much of this time in our campus computer labs that we had to stay on a lower version browser for our version of Blackboard. Part of our planning to move to responsive was dependent on when our Blackboard would be upgraded to a version that was compatible with more current browsers. Our main focus was our students, and we didn't want them to jump through hurdles just to get to the Tarleton website.
For a while, we were hovering over Twitter Bootstrap and Zurb's Foundation. While these two had a lot of goodies, they also seemed rather overwhelming from an implementation standpoint. We looked at less complex frameworks after that, and we decided to build upon a very generic HTML5 Boilerplate. Our desire in the planning phase was to create unique classes that would not accidentally be overwritten by outside products embedded into our website. As we looked at layout design, we also wavered over the grid system, be it 3, 4, 6, 8, 12, or even 16, and how many breakpoints we wanted. We would not "finalize" these (knowing that they would change during programming and testing) until after the first sketches were being drawn.
With initial research being completed, the decision was made to move forward with the project. Next steps included performing user testing, focus groups, and deciding on a responsive framework. The original plan included breaking the content up by internal versus external, however, we were not able to gain support/resources from ITS for this effort, so that part of the plan was set aside indefinitely.
There were five in-person focus group sessions with 4-13 participants in each. There were a total of 32 in-person participants and 5 that completed an online questionnaire covering the same topics. Audio and transcripts were recorded. Daphne Hunt led all focus group sessions, Karole Schroeder and Eric Kilburn typed transcripts. Each session began with the same general set of questions about Tarleton’s website and other university websites. As conversation evolved, varying types of questions were asked by the focus group leader in order to discover additional information. Question topics included website organization and structure, ease of locating information, most commonly sought after information, using the search box, influence of Tarleton’s website in making academic and involvement decisions, positive/negative experiences, and more.
Draw out concept designs of what should be on the homepage and main subpages off the homepage.
As we worked on the storyboards, going between mobile and desktop main views, we asked ourselves how many views we'd really have, how many breakpoints. At first, we thought only about Mobile, Tablet, and Desktop. But as we shifted things around at different screen sizes, we decided to also include "Mini" (between Mobile and Tablet, in reference to iPad Mini, in case other tablets of that size had issues) and "Widescreen" (after Desktop for those of us who use large monitors). Later, we added "Super Widescreen" due to issues seemingly awkward when viewed on a television sized monitor. We decided on a 12 grid because the math was easier to break down (3+3+3+3, 6+6, 4+8, 12) to the columns we'd want in any given module we planned to build. We decided to give them unique class names, such as cu1, cu2, ..., cu12 (meaning column unit) we didn't expect embedded scripts to contain and overwrite.
Create first wireframe HTML pages of the homepage and subpages. This is the beginning of our implementation of the grid system based on the storyboards we had drawn up. These would be modified throughout the testing and planning period, but it also gave us something to show people when they asked what responsive was and how it worked or benefited Tarleton.
To keep our users from critiquing areas we were not focused on, we generated multiple versions of storyboards using Balsamiq with slight variations to the layout to determine preference of locations for certain information.
We presented our Google Analytics and focus group results to DMAC (Digital Media Advisory Committee) as well as to the Executive Cabinet in order to gain support for the endeavor.
To avoid receiving criticism on minute details of the layout that we normally receive, we decided to try out Style Tiles, which provide the committee with an idea of what patterns, colors, fonts, and buttons we are considering using. Each student intern, for experience, and full-time employee submitted an anonymous Style Tile to DMAC to see which one would be approved. DMAC took ideas from multiple designs, but most of the approved elements came from this version. The intent is not to commit any design exactly, knowing programming and other issues may change the design layout later.
There were two in-person, current student, focus group sessions with 5-7 participants in each. The third and final focus group contained 19 prospective students and 7 of their parents. There were a total of 38 in-person participants with two different sets of questions. Transcripts were recorded. Morgan Hammond led all focus group sessions, while several of our interns typed transcripts. Each session started with a general set of questions about Tarleton’s website. Question topics included website organization and structure, ease of locating information, most commonly sought after information, using the search box, positive/negative experiences, and more.
There were two wireframes tested with one slight modification made on the second wire frame to test the viability of the audience menu for all user groups, as well as logical placement of content among the navigational items we placed in the wireframe(s). Current Students were asked a separate set of questions applicable to real-life situations/tasks. Morgan Hammond led the testing by asking a series of task based questions. Two interns recorded answers and any additional feedback from the user. Only the questions below were asked as to not “lead” the user. Clarification was provided if the user did not understand the task or question being asked.
After the elements were approved, we still needed to know how they would look on the page with the respect to the wireframes. We did reassess our original wireframes and colors due to further research into responsive design and focus groups. We also had DMAC compare various details of the layout to determine which route would be the best.
Ask the groups what they like about the current Tarleton website and if they can find the same things on the prototype. Test brand recognition, location or path of specific information, expectations, and current issues need to correct on the prototype.
After a great deal of testing, we launched Homepage 1.0 and awaited the reaction from the public. We included a Website Feedback form for any issues users reported during this beta testing period. We began work on resolving feedback issues at this point. Compared to our last major implementation, we received very few complaints about the new design and most complaints were focused on common issues. Special functionality added to the new responsive template included dynamically generated header panel link sections, the footer, and mobile navigation in order to reduce the number of times the entire responsive website was republished to the live website. The old template took days to publish, so we wanted to improve maintenance speeds. Before the TAC 206.70 update regarding speed of various devices to open or view content, Ernesto Martinez also added Lazy Loading to all images. This would later be connected to Content Module Blocks as images were inserted in Data Definitions in Cascade to control image use and load time.
With the programming of Homepage 1.0 completed, the page's programming needed to now be moved into Cascade Server. We decided to move forward with all responsive pages inside Sites which will have more functionality in the future. The homepage template, later named "Stacked" due to the pancake layout, would need to be cut into chunks of code called modules that would be re-used code chunks throughout the future website. Doing so required making the first "fillable forms" called Data Definitions (XML format) which would be rearranged into the proper code through Formats (XSLT format). The goal of these new moduler pages was to reduce the problems associated with building multiple Configuration Sets and Content Types by making Stacked templates a single Configuration Set (fleshed out template) and Content Type (template with respect to the main DEFAULT Data Definition).
While we received very few complaints about Homepage 1.0, we did have some issues to resolve based on the feedback we received from our form. Some issues would take longer to resolve, including issues with specific browsers, operating systems, and devices. After this implementation, we began development on Homepage 2.0.
Collected interesting modules and navigation from other websites. Research more specifically was based around responsive websites and the listing available at http://erikrunyon.com/highered-rwd-directory/
DMAC created a Subpage Task Force to look at ideas for the subpage look, including whether breadcrumbs would be useful, location of departmental navigation, and more. Karole Schroeder created mockups in Photoshop for potential subpage modules, including currently existing modules. Navigation was a huge part of this design and we wanted to make sure the content was read before users went to the navigation for answers. This is the origin of the "right nav" template.
Focus was geared towards desktop version of navigation, since each website's navigation would be expanded on the mobile version via the three bar button where they are used to viewing the other menu options. In one set of testing, users were given a tablet and sent to a flat image via our hotspot application where they were asked to answer a number of questions that would allow us to determine if the navigation was in the appropriate place. In another set of tests, we sent them to http://www.tarleton.edu/usertest/ and had two student interns record their thinking process and Morgan Hammond asked the questions.
We picked a set of modules (not all) to program and convert over to Cascade Server.
The original campus map and virtual tour created by Karole Schroeder using Google Maps was replaced with CampusBird. This implementation provided better customization of categories of locations as well as a better display of images, videos, and descriptions of locations.
Ernesto Martinez implemented the new "search engine" on the Tarleton website's search box that combined the results of multiple categories into a single search results area. This included Google's Custom Search Engine results, the Website Directory (A-Z Directory), the People and Departments directory (phone, email, fax), and News releases. Karole Schroeder implemented the first XML file through Cascade Server to assist in the search of the A-Z Directory listing, implemented in the Common Site via Common Links (trackable redirect pages).
As we looked at analytics, focus group results, and all our research on response design layouts from other universities, we found more and more supporting evidence to restructure the marketing strategy for our degrees. We presented our proposal to DMAC and our extended Dean's Council organization and received approval to proceed.
As Karole Schroeder built the modules inside Cascade Server for the subpages, Morgan Hammond assign the student interns to collect information already available about the degrees and add them to the new website. Requests for faculty assistance to add additional information and photos went out at the beginning of this project. The original degree website included PDF documents provided by the Welcome Center/School Relations office. Ernesto Martinez scraped them off an XML file for the new Degree Search.
The original Content Module Blocks were assessed for patterns that could be turned into Data Definitions in Cascade Server that web maintainers would fill out. Formats in built in XSLT would flesh out each Content Module Block to provide the flexibility we wanted to provide our web maintainers. These would be used initially by our web team to add content into Cascade. They would provide feedback of any bugs or improvements to be made.
Putting all the degree content in Cascade Server for associate's, bachelor's, master's, and doctoral degrees.
Ernesto Martinez began the conversion of the single CSS file that made up the responsive template styles into the multiple SASS (or SCSS) files that allowed the web team to develop CSS in a better test environment and also compare design ideas more efficiently. When the SCSS files were finished, some updates needed to occur on all Content Module Blocks, so Ernesto Martinez and Karole Schroeder ironed out the changes to each Content Module Block's Data Definition and XSLT format, including fixing any pages affected by the changes to the updated CSS.
Ernesto Martinez and Karole Schroeder worked on technical updates as well as bug fixes for various devices, operating systems, and browsers. Some technical pieces were set up in preparation for the new subpages that were being built for the new degree website in development.
Morgan Hammond and Daphne Hunt devised a new web update request form in Wufoo that connected to Asana via Zapier to provide the web team better tracking and prioritization of requests. Morgan Hammond would review the requests and assign them to student workers or web staff.
While the basic Content Module Blocks were built for Stacked and Right Navigation Templates for homepage and Degree Site implementation and maintenance, the Right Navigation still needed textual content areas planned, tested, and designed. For example, the Degree Site pages required the Tall Aside Feature Panel to handle more complexity than originally planned. This complexity flowed into the templates for both Stacked and Right Navigation Content Module Blocks.
After receiving feedback that content was too spaced out on the website, Ernesto Martinez began to develop a gutter on the sides of almost all the Content Module Blocks. This would allow us to reduce the breakpoint concerns we had when designing for larger screens.
End of June was last day of support for Windows 2003, which the Tarleton web server was running. The project consisted of multiple tasks to properly transition to the new server. Student FTP accounts had to be cleaned out, faculty FTP accounts needed to be moved into Cascade using the old website template or an external web hosting solution, applications had to be checked for Perl scripts and other deprecated scripting solutions, leaving PHP and ASP on the new server. The entire server had to be backed up and tested once switched over.
Karole Schroeder took the Google Tag Manager Fundamentals course in order to figure out how to implement GTM in place of the original Google Analytics tracking code in order to learn more about visitor activity. Ernesto Martinez collaborated with Karole Schroeder to find a way to track visitor searches on the Degree Site, which allowed us to learn the degree interests of our population, including any keywords not displaying for appropriate degree pages and any degree interests the University did not provide at the time. Failed attempts brought additional solutions: link "click" activity on all responsive web pages to determine what buttons or links visitors were selecting, even if they left the Tarleton domain.
Karole Schroeder built accessibility compliance checking into two areas of Cascade Server. The WYSIWYG editor warns web maintainers inline about deprecated HTML tags, inappropriate usage of HTML tags, and use of the style attribute, since most of the styles are defined in the classes. The page previews in Cascade warn about larger problems, including the misuse of HTML tags (especially regarding line breaks, headings, bold, italics, underline, and extra spaces and other punctuation marks), non-unique link text, web addresses for link text, and inappropriate alternative text. These do not capture all issues, since they are CSS/XSLT-based checks, so other common issues for Tarleton web maintainers like text-heavy images, poor color contrast, improper capitalization / punctuation / grammar on alternative text, missing appropriate closed captioning, or missing appropriate table headers are not checked.
Ernesto Martinez finished the gutter placement, and Karole Schroeder shifted Locations to the side and removed Highlights for a single highlight rotating on a row: Spotlight. The Degree Site became searchable from straight off the homepage. Additionally, this set up the foundation for search functionality for college, department, and location websites based on keywords.
Instructions included how to build a website in a Cascade Site and how each of the Content Modules work, including ideas for usage.
During Hannon Hill's Cascade User Conference in Atlanta, attendees competed for three contests. One was "If I had a Magic Wand" that could make Cascade Server do something, what would it be? Karole Schroeder had built into the WYSIWYG editor's CSS and XSLT formats some proactive accessibility checking, like a word processor for misspelled words. However, this is a bit odd looking in the user interface, so Karole handed her code to Hannon Hill and asked them to find a way to better implement accessibility checking inline. The competition was tough, so the award wasn't announced in Atlanta. This was considered the best web maintainer autonomy submission, so Karole received her award after landing back in Texas.
With the completion of Content Modules for both Stacked and Right Navigation templates, Web Services was able to begin the conversion of websites into the Right Navigation template. The priority was the Outreach Locations as well as AOE (Academic Outreach and Engagement) which provided Service Learning and Continuing Education at that time.
Karole Schroeder and Morgan Hammond proposed a better marketing funnel for the inquiry forms on each of the Outreach Locations and College of Graduate Studies websites to include the Degree Site. This involved making updates to the links to Wufoo forms using pre-populated info that would then pass into GlassPanel.
Ernesto Martinez and Karole Schroeder worked on implementing metatags that could be read by social media platforms like Facebook, Pinterest, and Twitter, and display our webpages in social media "cards". Karole Schroeder added a default metatag set for all webpages inside Cascade Server, along with a special social media block in case a specific image was desired on a responsive webpage. Ernesto Martinez worked on the Press/News Release application as he off-boarded as a full-time employee and worked on a contract basis.
We'd love to hear from you. Please send questions or feedback to the below email addresses.
Before contacting us, you may wish to visit our FAQs page which has lots of useful info on Tiki-Toki.
We can be contacted by email at: hello@tiki-toki.com.
You can also follow us on twitter at twitter.com/tiki_toki.
If you are having any problems with Tiki-Toki, please contact us as at: help@tiki-toki.com
Close