It's been a busy five months preparing to roll out a new news tool and planning for what's next. We're taking a moment to update the university community on all that's going on.

News tool rebuild update

We're finally starting to gear up for final testing with a plan to launch news in June. This was a major, multi-faceted project that also laid important groundwork for Phase 2 of our larger plans (rebuilding the front end and redesigning our UVM homepage and top tier pages).

What's New with News?

  • News stories hosted on our shared content server so that they'll be able to be syndicated in new and different ways in the future;
  • A rebuilt design grid using a wider format (the new website will follow this);
  • New taxonomy and classification choices permitting current and future ways to associate news stories with each other;
  • New news components that can be reused in our upcoming new web designs;
  • The first iteration of our design system, which catalogues all of the parts and pieces of design that comprise our website.

It's been an impressive several months of work containting a great deal of "invisible" milestones, but the main "product" that the university community will actually see when we launch news is a new way of adding news (a new form interface), and a new news landing page containing several new features. We'll keep you posted on whether we're going to hit our target date and will share all other info you'll need to know in order to be successful.

 

Web rebuild updates

While the development of news continues, a small team of us has taken on the task of identifying all design features needed on the top tier and homepage of the website. The process is slow because of its detailed nature, but in the past four months we've identified 150+ components that need to be built in order to solve design problems and best tell UVM's story on the web. This includes the current all-consuming work of creating a new navigational/menu system for the entire website. To give an understanding of what this looks like and how we approach this work, you can take a look at our Component Inventory (Excel spreadsheet); note that all hyperlinks to tickets, briefs and comps have been removed. This is just to give a general idea of scope. This doesn't yet include all special component needs at the unit level, and we're still in the process of designing the homepage and a few other components that won't yet be found here.

Process for designing components

To give you an understanding of the steps that go into designing one component—from conception to development hand-off:

  1. Identify a need. (This is done using data takeaways, current research, anecdotal information we have from webmaster and leadership needs)
  2. Write a component brief. (What are the goals of this component? What problem is it trying to solve? What kind of content does it contain? How can we make it more usable for more editors rather than a high-level one-off? General specs, inspiration, etc.)  EXAMPLE: Brief for a newly identified component we're calling "Player (Word doc)"
  3. Once brief is complete, create a ticket to conduct review with teammates of this discovery.
  4. Designers create wireframe. (This considers all existing more molecular designs to date—for example, if a thumbnail has been developed for use elsewhere, we'll assume its use in a new design rather than redesign it.)  EXAMPLE: Player wireframe (image)
  5. Review. (This can take several rounds of functional review—honing in on ideal mobile experience, accessibility concerns, exploring edge cases where this may break, image ratio, considerations around design economy, etc.)
  6. Designers create high-fidelity design. EXAMPLE: Player design (image)
  7. Review.
  8. Consider component in context of layouts.
  9. Review.
  10. Create the functional narrative—a document that shares all information about the use of this component, from design hover states to "what happens if?" questions answered.
  11. Prepare for development. (This can take days for a single component; the end product contains everthing the developer needs to know in order to build at many breakpoints.)
  12. Hand-off for development.
  13. Documentation, creation of usage guidelines for design system.

Wow, how will you ever get this done?

The good news is this intensive planning/designing phase will end up accounting for probably 75% of the components that we'll roll out to the units eventually, too. No doubt this work is incredibly intensive and slow, but it sets us up for super robust future template offerings.

 

Obstacles

Budget

We have been partnering with CoLab Cooperative since work started in earnest late November. They've proven to be extremely knowledgeable and collegial partners. However, high quality, hourly temp work is expensive. As a result, the last weeks have also been spent looking at all of the identified needs (the work mentioned above) and scaling back in places. Which of our planned-for features and components can we sacrifice and still accomplish our goals?

Drupal 7 end-of-life

After a lot of movement, there's been a final end-of-life date announced for Drupal 7 (UVM's current Drupal version)—November 2022—just a little over a year away. This comes at a tricky time. There's a big choice on our horizon, as a result.

  1. We can stay in Drupal 7 and assume the risks associated with being in an unsupported platform.
  2. We can cease our rebuild/redesign and focus on spending the next year getting our back end data into Drupal 9.
  3. We can invest funds into a parallel project where partners help us to stand up our new D9 back end and we're able to continue pushing on the redesign/rebuild.

After weeks and weeks of researching, we think that the third choice is the best choice. This situation has created an urgency where in order to put forth an estimate for this work, we have to stop and figure out—in detail—the scope of all work, such as: implementation of our unit templates and identification of all design needs for that phase 3 work; migration of all content (even that of our not-even-published news on the shared content server); landing on the exact components that will be built and how these translate into layouts; intensive research into whether or not Drupal 9 can work for our complex university permissioning, and other needs. So as we're scrambling to get out the news project and plan for all of the exciting new components, this other work has been extremely consuming for certain team members.

Size of team

We are still the same sized team, keeping all of the existing irons in the fire, supporting people at help hours, etc. Lack of human power continues to be our biggest obstacle.

 

Stay tuned for future updates.