Migrating to Drupal: Open
Source Library Intranets
Nina McHale, Catherine Baird,
Jason Battles & Rachel Vacek
Internet Lib...
Our Agenda
 Introductions (Nina)
◦ Presenters and attendees
◦ Why libraries need intranets
◦ Successful intranets: the Ho...
…and you are?
 Name
 Title
 Place of employment
 Experience with Drupal
 Experience developing intranets
 Why you’re...
Why Libraries Need
Intranets…
The Problem with Email
http://theoatmeal.com/comics/email
Intranets Should…
 Be easy to use;
 Have functionality desired by their
users;
 Be thoroughly integrated into the
every...
Why is this Hard to Achieve?
 Varying needs of librarians and staff
members based on their job duties
 Varying levels of...
JWL Intranets Special Issue:
Findings
 Not all libraries have their first choice in
web development environments
 Free, ...
Case Study 1:
McMaster University Library
McMaster University Library’s
Libstaff
Collaborators:
Amanda Etches-Johnson & Catherine Baird
Legacy Intranet
Access & Security
2.0 Explosion
Project Planning
The Team
Staff Engagement
List of Basic Requirements
The Team & Timeline
 Marketing, Communications and
Outreach Librarian
 Co-op Student
 Support from User Experience
Libr...
Staff Engagement
 Online Survey
 All-Staff Forum
Easy content
creation
Dynamic
Allow for growth
Requirements List
Global...
Building the New Intranet in
Drupal
Why Drupal?
Mapping Requirements to Drupal Functionality
Drupal Modules: Our Picks
Why Drupal?
Mapping Requirements
Etches-Johnson and Baird (2010 : Table 1)
Drupal Modules: Our Picks
 Content Creation Kit
(CCK)
 Comment
 Contact
 Development
 FCKEditor
 Filters (Headings
A...
Navigation
 Content Types
 Taxonomies
 Views
Features
 Collaboration
 Scalable
 Polls
 Comments
 Search
Corralling 2.0
 Incorporating Blogs and Wikis
Roll-out
Roles
Staff Training
Roles & Permissions
Etches-Johnson and Baird (2010 : Table 3)
Training Wiki
Assessment
Post-Launch Survey
Usability Testing
Lessons learned
Governance Issues
Unifying Internal Staff Tools
Lose the Org Chart
Staff Engagement
THANK YOU!
Break Time
http://www.igougo.com/photos/journal/132x132/Carmax_LA%20-%2042.jpg
Case Study 2:
University of Alabama
Libraries
Designing and Building a
Collaborative Library Intranet
Jason J. Battles
Head, Web Services Department
The University of A...
Background
 The University of Alabama
◦ 30,000 students
◦ Alabama’s oldest public university (1831)
 University Librarie...
Web Services Department
 Responsible for libraries’ web
presence
 Four FTE
 Part of the Office of Library
Technology
 ...
Legacy Web Infrastructure
 Static HTML pages
 Limited access for contributors
◦ Client-based Adobe Contribute for editin...
Intranet User Design Goals
 Present all important organizational
information in a centralized,
accessible, and personaliz...
Intranet Technical Design
Goals
 Flexible design
 Easy management
 Granular access control
 Separate interface and dat...
Why Drupal?
 Powerful access control settings
 Easily modified themes
 Integrates with existing authentication
systems
...
One-Stop Shop
 Why move other content to the
intranet?
◦ Increase usage through improved access
◦ Minimize users’ need to...
Migrating Wikis
Modules
 Organic Groups Module
◦ Linchpin of our intranet’s organization
◦ http://drupal.org/project/og
 Editing
◦ CKEdi...
Other Modules
 Access
◦ Override Node Options – Enables non-
admin users to promote content to front
page
◦ Secure Pages ...
Information Streams
 Main Stream
◦ Latest pages updates and additions
 My Groups
◦ Personalized feed based on membership...
Intranet Home Page
New Features
 Room schedules
◦ Key meetings immediately viewable
◦ Custom-built Drupal module for MRBS
 Events Calendar
...
An Intranet for All
 Give all library employees capability to
easily access, contribute, and
collaborate
 Previous intra...
Access
 Use existing authentication credentials
◦ LDAP Integration module
 http://drupal.org/project/ldap_integration
 ...
WYSIWYG Editor
Implementation
 Content owners reviewed and
categorized content prior to move
◦ Move as-is – 50%
◦ Needs updating – 30%
◦...
Implementation – continued
 Beta phase
◦ Both new and old intranets accessible
◦ Feedback collected
◦ Multiple training s...
Assessment
 Dramatic number of new contributors
◦ Fewer than 10 in old intranet
◦ About 40 now
◦ Over 90 have signed into...
Lessons Learned
 Succeeded in pulling disparate
information silos together and
increasing participation
 Issues remain:
...
Future Plans
 Constant Reevaluation
◦ Conduct usability testing
◦ Review new technologies and
applications
 Additional f...
Case Study 3:
University of Houston
Libraries
Rachel Vacek
Head of Web Services
University of Houston Libraries
Intranet 2.0 from a Project
Management Perspective
UH Libraries’ Old Intranet
UH Libraries’ Old Intranet
Intranet Redesign Task Force
 Representatives from different areas
◦ Web services, instruction, administration,
human res...
Intranet Considerations
 Have interactive information
 Ability to share information easily
 Be interoperable
 Follow u...
Project Planning
 Chose Drupal as the CMS
 Timeline
◦ 6 months research, reorganize, and build
◦ 6 months for people to ...
Rollout
 Some areas were completely blank
◦ Had no content to move
◦ Started fresh with blank slate
 Some departments an...
What it looks like today
Modules
 Core: didn’t enable all of them
 Most useful: Views, CCK, Calendar,
Event & Event signup, cas, FCKeditor,
Webfo...
Images from the Marketing
Committee’s page
News from the Views within the
site
Users have
too many
options
when
creating
content
Users like
being able to
sign up for
events
Lessons learned
 Too many content types confuse users
 Consider usability vs. functionality
 Don’t use Panels on pages ...
Lessons learned, cont.
 Consider permission levels for access or
content creation
 Lock down your layout a well as other...
Next Steps
 Slim down total number of modules
 Upgrade to Drupal 7
 Install Admin Module
 Make CMS for intranet simila...
Contact Information
 Nina McHale
nina.mchale@ucdenver.
edu
FB & TW: ninermac
 Catherine Baird
bairdca@mcmaster.ca
 Jaso...
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Migrating to Drupal: Open Source Library Intranets
Upcoming SlideShare
Loading in …5
×

Migrating to Drupal: Open Source Library Intranets

3,467 views

Published on

Internet Librarian preconference session by Nina McHale, Catherine Baird, Jason Battles, and Rachel Vacek, October 23rd 2010

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,467
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • -I’m here to present our first intranet case study today about McMaster University Library’s intranet site which we call Libstaff
    -I’m sorry I couldn’t join you all in person today and hope that this virtual presentation serves as an adequate replacement
    -just so I don’t remain a faceless ghost in your minds for the rest of the conference, I’ll quickly add a visual to this slide
    -the collaborators on this project were myself and Amanda Etches-Johnson, McMaster’s User Experience librarian up until very recently
    -just to give you a bit of context about our organization
    -we have just over 100 staff members in McMaster University Library
    -after decades of a static organizational which consisted of very traditional areas such as Collections, Public Services, IT, McMaster was going through a period of drastic change with frequent reorganizations and an org structure very much in flux
    -this had many implications for the organization, one part of which was the library’s staff intranet, aka libstaff
  • -let me start off by talking about the legacy intranet, which was experiencing two main problems
    -to say the least, it was a neglected internal communication tool with access and security issues becomingly a daily frustrating for staff
    -increasingly out of sync with an organization very much embracing web 2.0 technologies

  • -here’s a screenshot of the old homepage of our staff intranet
    -it was a collection of dreamweaver created pages which were accessed from this single index page (if you were lucky)

    -issues? There were many: no search, no consistent site architecture, no global navigation, no breadcrumbs, often no way to get back to the homepage once you started digging around, no standard document format, no one in charge, difficult for individuals to update unless you were in our IT department and/or one of the few designated web editors, intranet site open to anyone with a campus IP address and there was no off-campus access to the site without the use of VPN

    Essentially, we were breaking every rule of user-centred web design you could think of, and probably a couple of more
    As an organization, we clearly weren’t thinking of our own staff as users - we were letting them fend for themselves.
  • Here’s an example of one of the most visited areas: an A-Z list of library committees, groups, projects, teams
    anything new got added to this A to Z list
    Everything was on this page from a project to implement a new discovery layer for the catalogue to a new department that had been formed due to reorganization to internal documentation for our IM chat service
    Some attempt to keep it organized by at least creating a separate A to Z list for old stuff
    Only consistency of information was the lead or key contact
  • -many of the library staff had participated in a Learning 2.0 project, led by our User Experience Librarian, Amanda Etches-Johnson, where they played and learned about many web 2.0 tools and increasingly started to use them in their daily work
    -this resulted quite positively in a 2.0 explosion at the library: any self-respecting library committeee from that jpoint on had a blog, a wiki, a Facebook page, and a static page on the library intranet to boot
    -this was really empowering for individuals and groups of library staff, but in terms of communication and clarity, in caused increasing confusion
    -so it was decided that the intranet had to change

  • So, let’s chat for a minute about planning the project. Who was the team, how did we engage staff in this initiative and what was the basic requirements list that we arrived at.
  • -the Marketing, Communications and Outreach Librarian (that would be me) was put in charge of the project, in particular because of my role faciltiating internal communication at the library
    -there was one co-op student who worked part-time on the project and was able to do a lot of the behind the scenes work in Drupal as well as migrating or copying and pasting existing content
    -we had the support from our User Experience Librarian who was responsible for our public website and had previous knowledge working with Drupal
    -it should be said that though I and the co-op student had some web design experience, we were pretty green and neither of us had worked with Drupal or a content management system before

    Timeline was very tight. We began the project in late Fall 2008 and knew it had to be completed by April 2009. With only a small team and little time, we definitely ended up taking shortcuts that we would have preferred not to have taken b/c of this tight timeline, but I’m sure that’s not an uncommon situation for most of us in that room.

    What we did to prepare:
    Inventory: needed to know what all we had so that we could figure out what we could group together, including the file format in the inventory
    Took a look at what staff were using and solicited more staff feedback through a survey
    Mocked up wireframes
    This process was particularly important for us because it helped us define the content types we would require for the site – will talk a bit more about that later
  • In addition to doing an analysis of current usage statistics, we also implemented a staff survey and presented at two all-staff forums in order to engage staff in the design process.

    The online survey asked the following questions:
    Why do you visit the Libstaff website?
    What do you like about the current Libstaff website?
    What don't you like about the current Libstaff website?
    What features would you like to see on a redesigned Libstaff?
    Do you have any other comments you would like to share about Libstaff?

    The all-staff forum events provided an occasion for us to show the “work-in-progress” intranet and get informal feedback on what staff liked and/or didn’t like about the work we were doing. At these forums almost all of the approximate 100 members on staff took advantage of the opportunity to comment.

    Basic requirements list we ended up with

    global navigation
    site search
    site authentication using existing staff login credentials
    customizable permissions with different levels of access rights
    simplification of content creation and maintenance
    dynamic content
    a flexible underlying architecture that would allow the site to grow and evolve in keeping with organizational changes



  • Drupal was free with a large community supporting it and we could customize it to work the way we wanted to.

    For us, the choice was pretty easy. We had just finished a major redesign of the public library website using Drupal. With that experience and the ease of having both websites running on the same platform, a second Drupal installation was created and the work on the intranet began.
  • Mapping requirements to Drupal functionality:
    global navigation > themes
    site search > nodes
    site authentication using existing staff login credentials > Drupal’s built-in authentication
    customizable permissions with different levels of access rights > Drupal’s user management
    simplification of content creation and maintenance > Drupal’s content types and user permissions
    dynamic content > RSS syndication
    a flexible underlying architecture that would allow the site to grow and evolve in keeping with organizational changes >
  • Modules:
    Content Creation Kit (CCK): Allows site administrators to create templates for different types of content. E.g. our committee template contains the following fields: committee name, chair/lead, links (optional), mandate, membership, start/end date, minutes (optional), additional information (optional)
    FCKEditor: WYSIWYG editor that allows site authors to format content using recognizable formatting icons (no knowledge of HTML required to add/edit site content).
    Filters: allowed us to H2 and H3 headings anchors and subsequently Tables of Contents
    Menu: Allows site administrators to easily customize and maintain global navigation.
    Path & Pathauto: Allows users to rename URLs and set up predetermined paths for certain types of content.
    Related Links: Displays links related to content.
    Upload: Allows individual site authors to upload files to pages. Particularly useful for committee minutes, etc.
  • Let me talk for a minute about how we created our global navigation. At first we used a combination of content types, taxonomies and views.


  • Departments, Services, Projects, Committees, Staff Training and Development, Policies and Procedures and Old Stuff: the labels of our global navigation
    Content types were very similarly labelled: Departments, Services, Projects, Committees, Staff Training and Development, Policies and Procedures
  • Here’s an example of one of our content types in action – the committee:

    For committee content type, we specified a number of mandatory fields such as committee name, chair/lead, mandate, membership, start date;
    Also optional fields such as links (where you could link to the project blog/wiki), end date, and additional information.
    You can see how this would bring consistency to all of our committee pages.
    Also, we can set the permissions on the intranet site so that only certain users can create and modify committee pages, I.e. librarians and managers
  • started with 3 taxonomies: browse all, old stuff, departments
    You can see that on the left hand side of the page
    As we added more and more pages to the site using content types, we would tag it using these taxonomies
    For example, we created a policy using the p&p content type - see right hand side of page
    Tagged it under the browse all taxonomy as a policy and procedure and then under the departments taxonomy as the Organizational Analysis department
    Both are hyperlinked: if you clicked on the p&p link here, you would get a page listing all of the policies and procedures on our intranet regardless of what department they are associated with
    If you clicked on the organizational analysis link here, you would get a page listing anything which had been tagged as belonging to this department (committee, project, regular page, etc.)

    Originally these 3 taxonomies helped us to generate the landing pages for our global navigation, but found that we didn’t need this extra layer of complexity and instead, used content types combined with views (The views module creates customized views of node lists) to accomplish this. Simplified the content creation for users.

    Old Stuff Taxonomy still being used
    In order to move an item into the “Old Stuff” section of the intranet, you use the Old Stuff taxonomy and a view.

  • Collaboration: easy collaboration has been achieved but also consistency with defined fields in content types; don’t have to ASK someone else to put content up on a webpage for you anymore; provides staff with the familiar the collaborative space they are now accustomed to with web 2.0 tools

    Scalable: useful for large-scale and small-scale projects (not previously captured except on local hard drives!)

    Polls: fun and function, real polls like how do you like the new site, some new functionality, or just plain fun polls like where’s the best lunch spot on campus

    Comments: changes, improvements, not yet the active watercooler we thought it might be, interesting to note is that we’re starting to see staff respond to one another’s comments and help each other out

    Search: usability shows us how important this is
  • Relationship between intranet and staff blogs/wikis
    Successful incorporation in some areas (staff newsletter blog, flickr stream)
    not so successful in other areas (liaison blog/intranet page
    Most definitely we have achieved a single starting off point for all internal library information
    though we may not see all of the 2.0 tools in use being syndicated and pulled into the intranet, there is at the bare minimum a link to show that such an online workspace is being used
    -people are gravitating towards using libstaff pages for new projects and committees rather than immediately starting a new blog, only to abandon it weeks later b/c all they really needed was one or two pages
    -we’ve reached a relatively happy 2.0 medium in our organization
  • -transition
  • -Who’s in charge:Roles and permissions
    Administrator (6)
    Committee/Service/Project Editor (36)
    Department Editor (21)
    Staff Training Editor (7)
    General Page Editor (18)
  • -small group sessions of customized training for the various “roles”
    -also provided general site orientation at this time
    -explained the roles concept with varying access levels to edit the site to all staff; new concept
    -took place in the weeks prior to the launch in Spring 2009
    -training wiki created as a reference tool, complete with step-by-step instructions and screenshots as seen on this screen
    -this level of training was essential because of the newfound editing power now in the hands of individual staff members


  • -results of post-launch survey: we asked the same 5 questions again

    staff reported liking that the site was easy to use; the new design; that it was easy to access from home; that it was secure; that it provided access to the staff newsletter; the good content; and, new items such as polls, comments, photos and a search function.
    staff did not like that they still had problems finding information (though in contrast to the last survey, no one said the site lacked organization); some did not like the new layout, the labels and the fact that there were multiple navigation areas; some did not like the default font size and colours.
    one outstanding feature staff requested (that was not rolled into the redesign) was access to documents in shared staff drives, a feature we are currently investigating for phase two of the redesign.

    Usability testing
    eight staff members from departments across the library attempt to complete nine tasks on the redesigned site. Findings from the usability testing include some accessibility and design issues with regards to the colour scheme, as well as some confusion over labels in use in global navigation.

    Card sort exercise helped with labelling and rethinking the global nav


  • Collapsed Department and Service under one global nav view and renamed this Department and Function

    Introduced user-generated tagging to help with some findability issues.

    Not visually represented on this slide: As explained earlier, we got rid of the redundant taxonomies

    Started to embed new library staff projects such as our LibrarECard reward program directly into the new site
  • Even with distributed editing, there needs to be central ownership of the intranet in order to realize complete adoption by individuals in the organization and become an invaluable tool. Since Drupal allows for distributed editing and content management, we naively underestimated the amount of post launch governance that would be required for the new staff intranet.

    Even with distributed editing, there needs to be central ownership of the intranet in order to realize complete adoption by individuals in the organization and become an invaluable tool. Since Drupal allows for distributed editing and content management, we naively underestimated the amount of post launch governance that would be required for the new staff intranet.

    Finally, despite everything we knew about the importance of resisting the urge to design an intranet around an organization's structure, we found ourselves frequently tempted to turn to the institution's organizational chart to inform our navigation and labeling decisions. On-going user testing and feedback from staff continues to help us resist this temptation, but it's a lesson we find ourselves learning over and over again on a daily basis.


  • Many thanks for your attention today. I’m sorry I couldn’t join you in person but hope that this presentation has been helpful and informative. At this point I’d like to turn it over to my co-presenters.
  • Migrating to Drupal: Open Source Library Intranets

    1. 1. Migrating to Drupal: Open Source Library Intranets Nina McHale, Catherine Baird, Jason Battles & Rachel Vacek Internet Librarian 2010
    2. 2. Our Agenda  Introductions (Nina) ◦ Presenters and attendees ◦ Why libraries need intranets ◦ Successful intranets: the Holy Grail? ◦ JWL Intranets Special Issue: Findings  Case Studies ◦ McMaster University Library (Catherine) ◦ University of Alabama Libraries (Jason) ◦ University of Houston Libraries (Rachel)
    3. 3. …and you are?  Name  Title  Place of employment  Experience with Drupal  Experience developing intranets  Why you’re here
    4. 4. Why Libraries Need Intranets…
    5. 5. The Problem with Email http://theoatmeal.com/comics/email
    6. 6. Intranets Should…  Be easy to use;  Have functionality desired by their users;  Be thoroughly integrated into the everyday work environment.
    7. 7. Why is this Hard to Achieve?  Varying needs of librarians and staff members based on their job duties  Varying levels of librarian and staff member comfort levels with web applications  No buy-in from: ◦ Administration ◦ IT (internally or externally) ◦ Staff generally
    8. 8. JWL Intranets Special Issue: Findings  Not all libraries have their first choice in web development environments  Free, hosted blogs and wikis (i.e., Blogger, PBWorks) can be difficult to incorporate into daily library staff workflow  SharePoint is nice and integrates easily into a Windows environment but is not perfect  Drupal requires a certain level of web expertise to deploy, but it is highly flexible and customizable
    9. 9. Case Study 1: McMaster University Library
    10. 10. McMaster University Library’s Libstaff Collaborators: Amanda Etches-Johnson & Catherine Baird
    11. 11. Legacy Intranet Access & Security 2.0 Explosion
    12. 12. Project Planning The Team Staff Engagement List of Basic Requirements
    13. 13. The Team & Timeline  Marketing, Communications and Outreach Librarian  Co-op Student  Support from User Experience Librarian  Fall 2008 – Spring 2009
    14. 14. Staff Engagement  Online Survey  All-Staff Forum Easy content creation Dynamic Allow for growth Requirements List Global navigation Search Authentication Access rights
    15. 15. Building the New Intranet in Drupal Why Drupal? Mapping Requirements to Drupal Functionality Drupal Modules: Our Picks
    16. 16. Why Drupal?
    17. 17. Mapping Requirements Etches-Johnson and Baird (2010 : Table 1)
    18. 18. Drupal Modules: Our Picks  Content Creation Kit (CCK)  Comment  Contact  Development  FCKEditor  Filters (Headings Anchors & ToC)  Forum  Menu  Path & Pathauto  Poll  Profile  Related Links  Search  Statistics & Google Analytics  Taxonomy  Taxonomy Breadcrumb  Upload  Views
    19. 19. Navigation  Content Types  Taxonomies  Views
    20. 20. Features  Collaboration  Scalable  Polls  Comments  Search
    21. 21. Corralling 2.0  Incorporating Blogs and Wikis
    22. 22. Roll-out Roles Staff Training
    23. 23. Roles & Permissions Etches-Johnson and Baird (2010 : Table 3)
    24. 24. Training Wiki
    25. 25. Assessment Post-Launch Survey Usability Testing
    26. 26. Lessons learned Governance Issues Unifying Internal Staff Tools Lose the Org Chart Staff Engagement
    27. 27. THANK YOU!
    28. 28. Break Time http://www.igougo.com/photos/journal/132x132/Carmax_LA%20-%2042.jpg
    29. 29. Case Study 2: University of Alabama Libraries
    30. 30. Designing and Building a Collaborative Library Intranet Jason J. Battles Head, Web Services Department The University of Alabama Libraries
    31. 31. Background  The University of Alabama ◦ 30,000 students ◦ Alabama’s oldest public university (1831)  University Libraries ◦ Five branch libraries ◦ 120 faculty and staff
    32. 32. Web Services Department  Responsible for libraries’ web presence  Four FTE  Part of the Office of Library Technology  Involved in wide range of web projects ◦ AquaBrowser discovery interface ◦ Mobile web initiatives ◦ Information literacy game development  Developed the libraries’ Drupal- powered public web site and intranet
    33. 33. Legacy Web Infrastructure  Static HTML pages  Limited access for contributors ◦ Client-based Adobe Contribute for editing ◦ Offsite access only via command line  Outdated and orphaned content  Disparate applications & information silos
    34. 34. Intranet User Design Goals  Present all important organizational information in a centralized, accessible, and personalized way ◦ Incorporate wikis and blogs ◦ Department and committee pages ◦ Policies, statistics, and meeting minutes ◦ Room booking ◦ Add features to promote collaboration  Improve and expand access  Make it easy to use
    35. 35. Intranet Technical Design Goals  Flexible design  Easy management  Granular access control  Separate interface and data layers  Content Management System (CMS) ◦ Which one? (http://cmsmatrix.org)  Drupal  Joomla  SharePoint
    36. 36. Why Drupal?  Powerful access control settings  Easily modified themes  Integrates with existing authentication systems  Open source ◦ Custom modules for specialized functionality ◦ Large user community  drupal4lib  ALA Drupal Interest Group
    37. 37. One-Stop Shop  Why move other content to the intranet? ◦ Increase usage through improved access ◦ Minimize users’ need to go to multiple sites for key information  Migrating wikis and blogs to Drupal ◦ Preserve collaborative aspects ◦ Retain content and improve editing ◦ Automate url aliasing and revisioning ◦ Use existing authentication system
    38. 38. Migrating Wikis
    39. 39. Modules  Organic Groups Module ◦ Linchpin of our intranet’s organization ◦ http://drupal.org/project/og  Editing ◦ CKEditor – http://drupal.org/project/ckeditor  Pathnames ◦ Pathauto – http://drupal.org/project/pathauto  User Interface framework
    40. 40. Other Modules  Access ◦ Override Node Options – Enables non- admin users to promote content to front page ◦ Secure Pages – Allows use of SSL  Content moderation ◦ Module Grants Revisioning  Custom content types ◦ Content Creation Kit (CCK)  File Management ◦ IMCE – Manages file uploading
    41. 41. Information Streams  Main Stream ◦ Latest pages updates and additions  My Groups ◦ Personalized feed based on memberships  Professional ◦ Conference presentations and reports ◦ Internal development opportunities  Technology instruction  Brown bag discussions
    42. 42. Intranet Home Page
    43. 43. New Features  Room schedules ◦ Key meetings immediately viewable ◦ Custom-built Drupal module for MRBS  Events Calendar ◦ Display conferences, webinars, etc. ◦ Open to all library personnel ◦ Uses customized calendar module
    44. 44. An Intranet for All  Give all library employees capability to easily access, contribute, and collaborate  Previous intranet limitations: ◦ Unique accounts for out-of-library access ◦ Editing only available through Contribute ◦ Limited number of personnel could upload files or edit pages ◦ All updates moderated
    45. 45. Access  Use existing authentication credentials ◦ LDAP Integration module  http://drupal.org/project/ldap_integration  Allows usage of Microsoft Active Directory ◦ Apache web server configured to use same method for out-of-library logins  Improve editing ◦ Powerful web-based WYSIWYG editor ◦ Instant publication of most content ◦ Secure upload capability for all users
    46. 46. WYSIWYG Editor
    47. 47. Implementation  Content owners reviewed and categorized content prior to move ◦ Move as-is – 50% ◦ Needs updating – 30% ◦ Delete – 20%  Web Services moved content into Drupal  Content owners took control at launch
    48. 48. Implementation – continued  Beta phase ◦ Both new and old intranets accessible ◦ Feedback collected ◦ Multiple training sessions covering:  Content creation  File uploading  Posting comments ◦ Training sessions also offered after launch ◦ Beta phase lasted about one month  Total implementation took three months
    49. 49. Assessment  Dramatic number of new contributors ◦ Fewer than 10 in old intranet ◦ About 40 now ◦ Over 90 have signed into the new intranet  Increase in usage ◦ 35 page updates in last month ◦ 14% overall increase in visits ◦ 156% more visits from out of the library
    50. 50. Lessons Learned  Succeeded in pulling disparate information silos together and increasing participation  Issues remain: ◦ Users remain hesitant to contribute ◦ Content providers do not always recognize their responsibility for updating pages ◦ Number of content types confuse some users
    51. 51. Future Plans  Constant Reevaluation ◦ Conduct usability testing ◦ Review new technologies and applications  Additional features ◦ IM Chat ◦ Water cooler section  More instruction ◦ Short Camtasia tutorials for basic tasks ◦ One-on-one and group sessions for more advanced editing
    52. 52. Case Study 3: University of Houston Libraries
    53. 53. Rachel Vacek Head of Web Services University of Houston Libraries Intranet 2.0 from a Project Management Perspective
    54. 54. UH Libraries’ Old Intranet
    55. 55. UH Libraries’ Old Intranet
    56. 56. Intranet Redesign Task Force  Representatives from different areas ◦ Web services, instruction, administration, human resources, acquisitions, access services, liaison services, and branch libraries.  Each team member served as liaison to multiple departments and committees  Needed to create buy-in across Libraries  Wanted to change the way information
    57. 57. Intranet Considerations  Have interactive information  Ability to share information easily  Be interoperable  Follow user-centered design  Be able to create new content or modify existing content easily  Encourage collaboration  Site search  Authentication via CAS
    58. 58. Project Planning  Chose Drupal as the CMS  Timeline ◦ 6 months research, reorganize, and build ◦ 6 months for people to move info and become familiar with new system  Restructured the information architecture  Gathered input from in-person interviews, surveys and an open forum  Proposed several designs  Asked for feedback throughout redesign process  Training ◦ Over 20 Basic and Advanced sessions, video tutorials
    59. 59. Rollout  Some areas were completely blank ◦ Had no content to move ◦ Started fresh with blank slate  Some departments and committees had already moved content ◦ Already had content re-organized for migration ◦ Example for others to follow
    60. 60. What it looks like today
    61. 61. Modules  Core: didn’t enable all of them  Most useful: Views, CCK, Calendar, Event & Event signup, cas, FCKeditor, Webform  Nice, but needs improvement: Image gallery  Looked good originally, but turned out to be not so good: Panels
    62. 62. Images from the Marketing Committee’s page
    63. 63. News from the Views within the site
    64. 64. Users have too many options when creating content
    65. 65. Users like being able to sign up for events
    66. 66. Lessons learned  Too many content types confuse users  Consider usability vs. functionality  Don’t use Panels on pages users need to edit frequently (or don’t use Panels at all)  Use the Revisions Module  Think about users needing to bulk files uploads
    67. 67. Lessons learned, cont.  Consider permission levels for access or content creation  Lock down your layout a well as other important pages that people don’t need to edit  Have administrative section separated from content  More modules you have, more you have to upgrade and risk something breaking  Keep the CMS as lightweight as possible
    68. 68. Next Steps  Slim down total number of modules  Upgrade to Drupal 7  Install Admin Module  Make CMS for intranet similar in functionality and Drupal naming conventions to the main website’s CMS  Work with library administration on internal communication recommendations
    69. 69. Contact Information  Nina McHale nina.mchale@ucdenver. edu FB & TW: ninermac  Catherine Baird bairdca@mcmaster.ca  Jason Battles jjbattles@ua.edu FB & TW: jjbattles  Rachel Vacek rvacek@uh.edu FB & TW: vacekrae

    ×