1. Web content management: a centralized service in a decentralized environment Kyla Hoffman, Technical Lead Simone Knapp, Business Analyst Earl Fogel, System Administrator

2. Overview • Introduction • Overview of Successes • Service Description • Service Process • Challenges and Responses • Measuring Success • Conclusions • Questions

3. Introduction • Distributed/Federated IT model • 17 colleges and schools, many administrative units • 160,000 public webpages on main webserver • Other units/colleges manage local webservers • Web Content Management System • ~35,000 pages • ~230+ sites • ~1,000 user accounts • 1.7 FTE

4. Overview of Successes • Six-month pilot (Feb-Aug 2008) • ~ 30 sites started; 22 published • Within 12 months units began moving from local systems • In the last year have seen a shift towards insourcing

5. Overview of Successes • Clients of service include: • 12/17 colleges and schools • 3 affiliated colleges • Senior Leadership • Main U of S site (www.usask.ca) • University Library • Huskies (Athletic Teams) • 11 Administrative units • 10 Centres • Research groups/labs

6. Overview of Successes • Publishing to our portal • 10 channels • Managing events for 12 calendars in our Dates & Events calendar • Managing Course Catalogue

7. Sites Published and in Development

8. Service Description • Website advising • U of S-branded templates • Desktop and mobile • Training and support • Technical and non-technical

9. Service Description • System administration • Coordinating WCMS and central webserver • Maintenance and configuration • Support data coordination and integration • Portal channels • Dates & Events calendar • Course Catalogue (in progress)

10. ServiceProcess

11. Challenges • Categorized as: • Political • Technical • Resource based • Usually presented as a combination • Philosophy • Partnerships = success

12. Challenges - Political • Federated IT model • Several units involved in product selection • Free and opt-in • Central support and maintenance • Local site and webserver management • Developer training • Lack official web policy • Free service uses the “official” U of S templates • Focus on partnerships • We are successful only if we all succeed

13. Challenges - Technical • Varied skills and physical distribution • Group meetings (treats included!) • Code sharing and standards • Official website framework • Code repository • Developers wiki and mailing list • Escalation of issues

14. Challenges - Technical • Limitations of the system • Provisioning sites • Developed a copy script • Web design vs. technology

15. Challenges - Technical • Resource restrictions and limitations • Balance ease of use with resource implications • Dynamic banner images • Events publishing • Navigation management

16. Challenges – Resource Based • Training and support volume (~1,000+ accounts) • Central and local support • Online documentation • Moving to Training Services unit • Development for institutional services • Course Catalogue (in progress) • Dates & Events calendar • Website frameworks – out of the box and a base site

17. Challenges – Resource/Technical • Non U of S branding • Fee for service • Support and training • New branding – demand and transition • Change in layout • Added complexity • Retraining • Retroactive application • Support doubles for each site

18. Challenges - Resource/Technical • System Administration • Site management • Local “config” page • Accounts and permissions • Local user and group management • Developed script for CAS authentication

19. Challenges - Resource/Technical • System Administration – continued • Publishing • Local webserver admins • Developed script for “housekeeping” • Expiration of accounts • Resource audits • Support team wiki

20. Challenges – Resource/Technical • Mobile • Mobile position created • Lack of awareness and resources • Implementation – official templates • Included with official framework (standardization) • No backward compatibility • Local management of desktop vs. mobile content • Auto redirect managed centrally

21. Challenges - Combined • Managing expectations • Clarify roles and responsibilities • Clearly scoping the service • In-person consultations • Explicit online documentation

22. Measuring Success • Definition of a “site” • No institutional standard for “unit” • Use total count not percentage • Developing system for maintaining stats • Survey

23. Conclusion • Flexibility is key • Manage diversity of user skills and priorities • Relationships with campus web community • Cohesion of our team • All vested in the success of the service • Celebrate successes AND deal with setbacksas a team • Trust

24. Questions?