Web Application Development and Hosting Consultation Guide

Required Information:

• URL: Full website address 
• Problem Description: What isn't working as expected? 
• Steps to Recreate: How can we reproduce the issue? 
• Impact: Who is affected and how urgently does this need resolution? 
• Access Information: Do you have admin access? What level? 

Primary Purpose: 

• What is the main goal of this website/application? 
• What specific problems does it solve? 
• What would success look like? 

Content and Functionality: 

• What type of content will be published? (Static pages, blogs, forms, databases, media, video) 
• Will visitors need to create accounts or log in for site functionality? 
• Will you collect any user data? What types? 
• Do you need e-commerce or payment processing? 
• Will you need integration with other UO systems? (SSO, Banner, Canvas, etc.) 

Audience and Scale: 

• Who is the primary audience? (Students, Faculty, Staff, Alumni, General Public) 
• How many users do you anticipate? (Daily/Monthly) 
• What types of users will access the service and approximately how many of each type? 
• Is this for a specific department, college, or university-wide? 

Complexity Assessment: 

• Is this primarily informational (brochure-ware) or interactive (applications, forms, databases)? 
• Do you need custom functionality or standard CMS features? 
• Will you need APIs or data integrations from other existing data sources? 
• Do you have specific technology requirements or preferences? 
• Will payment or e-commerce occur on the site? 

Performance and Availability: 

• Do you anticipate traffic spikes? (Registration periods, events, etc.) 
• What are your performance expectations? (Page load times, etc.) 
• Is this application mission critical to campus functionality?  What will be the effect if the application is unavailable for a period of time? 

Data Management: 

• What data will be collected by the service? 
• Does this involve sensitive data? (FERPA, PII, Health Information, etc.) 
• Any data retention requirements? How long does data need to be retained? 
• Who owns the data and content? 

Ongoing Management: 

• What UO Employment position will be the site steward?  
• This person will sign the web attestation acknowledging responsibility for ensuring the site meets legal, brand and ongoing maintenance requirements. 
• Who will maintain content? Do they have technical skills? 
• How frequently will content be updated? 
• Who will handle technical maintenance and updates? 
• Do you have staff allocated for this, or need training? 

Long-term Viability: 

• What is the expected lifespan of this site? (1 year, 5 years, indefinite) 
• Do you have an ongoing budget for hosting and maintenance? 
• What happens if the key staff leave? Is there a succession plan? 

Financial Planning: 

• What is your total project budget? 
• Have you allocated budget for: 
• Initial development 
• Annual hosting costs 
• Ongoing maintenance 
• Accessibility compliance 
• Security updates 
• Do you have a funding source identified? (Department, grant, auxiliary) 

Timeline: 

• When do you need this to launch? 
• Are there specific deadlines or event dates? 
• Is the timeline flexible or fixed? 

Content Management and Blogs: 

• UO Blogs (WordPress) - For blogs, simple sites, and departmental pages 
  • Self-service, UO branded, accessible templates 
  • SSO integrated, no cost to departments 
  • Best for: Simple sites, news, event listings, simple portfolios 
• UO Drupal Hosting - For complex departmental and college websites 
  • Professional web services support 
  • Custom functionality possible 
  • Best for: Multi-section sites, complex content types, integrations 
• SharePoint / Microsoft 365 - For internal collaboration and document management plus intranet sites 
  • Built-in SSO, file storage, team collaboration 
  • Best for: Internal departmental sites, project collaboration, document repositories 
• Pages - For simple, static informational pages 
  • Quick setup, minimal technical requirements 
  • Best for: Single-page sites, landing pages, quick info sharing 

Forms and Workflows: 

• TDX (TeamDynamix) - For ticketing, service requests, and workflow automation 
  • Form builder, approval workflows, reporting 
  • Best for: Service requests, IT support, process automation 
• OnBase - For document management and workflow 
  • Enterprise document management, records retention 
  • Best for: Official records, complex approval workflows 
• Microsoft Forms / Power Apps - For surveys and simple data collection 
  • SSO integrated, export to Excel/OneDrive 
  • Best for: Surveys, registration forms, simple data collection 
• Forms.uoregon.edu 
  • Approval process workflows 
  • Digital Signatures 
• Adobe Sign
  • Approval process workflows 
  • Digital Signatures 

Other Campus Services: 

• Information Services - Custom Web Application Development - For enterprise-level websites and applications 
  • Check with IS for existing APIs or data services 
  • Check with your college/division/department for existing web properties 
• Business Affairs for e-commerce and payment processing. 

Outcome: Refer to appropriate campus service 

• Provide contact information and setup instructions 
• Offer training resources if needed 
• Follow up to ensure successful implementation 

When to refer: 

• Site does not have specific grant funded branding requirements 
• Site purpose has a relation to existing web properties (go where the audience already is) 

Action: Connect with the existing web property site steward for consultation 

When to refer: 

• Need for custom workflows or online form development 
• Enterprise-level applications 
• Complex integrations with UO systems (Banner, Canvas, etc.) 
• Custom business process automation 
• Advanced data management and reporting needs 
• Campus solutions exist but don't meet complexity requirements 

Action: Connect with Information Services Web Application Development team for consultation 

When external vendors are appropriate: 

• Campus solutions cannot meet specific technical requirements 
• Need for specialized functionality not available on campus 
• Grant or external funding requires specific technology or branding requirements 
• Unique compliance or regulatory requirements 

Vendor must provide: 

• Current compliance documentation demonstrating recognized security standards: 
• ISO 27001, or 
• SOC 2 Type 2, or 
• HECVAT (Higher Education Community Vendor Assessment Tool, version 4.0 preferred) 

Vendor must agree to: 

• University of Oregon Standard Terms and Conditions for Goods and Services 
• Section 27: FERPA compliance (if applicable) 
• Sections 9 and 12: Confidential data management expectations 

During contracting, ISO will request: 

• Types of data the service will collect 
• Types and approximate number of users 
• Integration requirements with existing UO systems 
• Security documentation (HECVAT, SOC 2 Type 2, or ISO 27001) 

Contacts: 

• Leland VanBrunt (ISO) 
• Andy Preising (ISO) 

Preferred: Entra ID (Microsoft Azure Active Directory) 

• Benefits: Cloud-based resilience, broad support, access control integration 
• Protocols: SAML or OAuth 2.0/OpenID Connect 

Also Supported: Shibboleth SSO 

• Protocols: SAML 2.0 or CAS 
• Note: UO is transitioning away from Shibboleth 

Vendor Requirements:

Vendors must specify which authentication protocols they support: 

1. SAML 2.0 or CAS only → University supports via Shibboleth IdP 
2. SAML or OAuth 2.0/OpenID Connect → University supports via Entra ID IdP (preferred) 
3. Both protocols supported → Entra ID preferred 

Vendors should propose the authentication method they most commonly support for optimal implementation and sustainability. 

Contact: 

• Single Sign On Consultation

Legal Requirement: All university web properties must comply with: 

• WCAG 2.1 Level AA (Web Content Accessibility Guidelines) 
• Section 508 of the Rehabilitation Act 
• ADA Title II (Americans with Disabilities Act) 

Vendor must provide: 

• Accessibility compliance documentation 
• VPAT (Voluntary Product Accessibility Template) if available 
• Commitment to maintain accessibility through updates 
• Support for accessibility testing and remediation 

Required in contract: 

• Explicit accessibility compliance terms 
• Vendor responsibility for accessible code/platform 
• Client ability to create accessible content 
• Remediation process for accessibility issues 
• Regular accessibility audits 

Resources: 

• WebApp - Web Accessibility (Confluence, SDDS space) 

Contact:

• Digital Accessibility (ictaccess@uoregon.edu) 

Hosting and Infrastructure: 

• Uptime guarantees (typically 99.9% or higher) 
• Backup frequency and retention policy 
• Disaster recovery procedures 
• Server/platform maintenance windows 

Software Updates: 

• Security patch timelines 
• Platform/CMS version updates 
• Plugin/module maintenance 
• Third-party integration updates 

Support Terms: 

• Support hours and response times 
• Contact methods (phone, email, ticket system) 
• Escalation procedures 
• Service Level Agreements (SLAs) 

Content Ownership: 

• UO retains ownership of all content and data 
• Data export capabilities and formats 
• Migration support if contract ends 
• Content backup and archival procedures 

Recommended Terms: 

• Initial contract period (typically one to three years) 
• Renewal options and terms 
• Price lock or escalation limits 
• Termination clauses and notice periods 
• Data return/deletion procedures upon termination 

Ensure clarity on: 

• Initial setup/development costs 
• Recurring hosting/maintenance fees (monthly/annual) 
• Per-user or tiered pricing structure 
• Costs for additional features or modules 
• Bandwidth/storage limits and overage costs 
• Support costs (included vs. additional) 
• Training costs 
• Price increases and escalation caps 

Any site served from a uoregon.edu domain has to abide by brand standards. If the site has branding in grant requirements then it needs to use UO Minimal Branding standards *TBD

• Brand Guide (University Communications)  
• Web Standards (University Communications Brand Guide) 
  • Potential to have an At the University of Oregon branding.  
  • If only UO involvement, then it has to follow UO Brand.  
  • If there is a collaboration between UO and other institutions, then it doesn't have to follow UO Brand. Cannot have a uoregon.edu sub-domain.
• Must follow grant branding (if grant has it).

Log all consultations to: 

• Understand demand patterns 
• Identify gaps in campus services 
• Inform future platform investments 
• Demonstrate value of consultation service 
• Track outcomes and success rates 

Track: 

• Request date and requester 
• Department/division 
• Problem type 
• Solution recommended 
• Campus service vs. external vendor 
• Budget range 
• Outcome status

Additional Resources 

Campus Contacts: 

• Web Community of Practice: Tony Herrig 
• University Communications: Jason Huebsch 
• Information Security Office (ISO): Leland VanBrunt, Andy Preising 
• SSO/Identity Management: Chris Bernard 
• Procurement and Contracting Services (PCS): Tina Davidson 
• IS Web Application Development: Jesse Sedwick 
• API Gateway and Access: Keith Folsom 
• Accessibility: Grey Pierce 

Documentation: 

• WebApp - Web Accessibility (Confluence, SDDS space) 
• Purchasing and Contracting Service Procurement Portal 
• University Terms & Conditions (Purchasing and Contracting Services) 

Start with Why? - understand the underlying need, not just the requested solution 

• Look for existing campus solutions first - they're often more sustainable 
• Consider Information Services for custom enterprise solutions before recommending external vendors 
• Evaluate if custom workflows, online forms, or complex integrations indicate need for Information Services 
• Consider total cost of ownership, not just initial costs 
• Assess long-term sustainability - who will maintain this in two to three years? 
• Ensure compliance is addressed upfront, not as an afterthought 
• Document decisions and rationale for future reference 

• No identified budget or funding source 
• No staff assigned for ongoing maintenance 
• Unclear purpose or success criteria 
• Duplicates existing campus functionality 
• Unrealistic timeline expectations 
• Doesn't consider accessibility or security requirements

• Check in 30 days after recommendation 
• Track implementation success 
• Gather feedback for process improvement 
• Update documentation based on lessons learned