Search
Use search components when visitors need keyword or filtered search across site or list content.
From a visitor’s perspective, search means “tell us what you are looking for”, whether that is one field or many. Authors usually turn search on through a parent component or template (news list, program list, calendar, and so on), not one universal search bar on every page. Visual designers align field, button, and icon so search feels familiar even when the behind-the-scenes setup differs.
Behaviour
Three broad patterns appear on the site:
- Global site search in the header: an overlay with tabs for different targets (for example main site versus library). Opened from the navigation search control.
- Keyword rows on content pages: a text field and submit (often an icon button), used with news, programs, Thunderstone, calendar, and faceted sidebars.
- Structured forms for people or departments: several labelled fields rather than a single box, for directory and faculty experiences.
Authors add whichever parent exposes the pattern; there is no single generic Search component for every page.
Anatomy
Most keyword search rows include:
- Text field for the query.
- Submit control (icon or text).
- Optional section title or wrapper for placement in a sidebar or band.
Replace with a keyword row and, separately, a faceted sidebar example.
Content guidelines
- Placeholders help but must not be the only accessible name; pair with a visible label or an agreed accessible label for icon-only buttons.
- Keep short tab labels in global search so the choices stay scannable.
- Match placeholder and button language to the task (“Search events”, “Search by keyword”).
When to use
- Navigation site search when people need broad discovery.
- Parent list or template components when their docs describe a keyword bar.
- Directory or faculty components when the task needs structured fields.
When not to use
- Do not assume one bar fits all pages; pick the parent that owns the data.
- Do not recreate global site search outside the navigation shell; behaviour and accessibility are tied to that experience.
Best practices
Do
- Keep labels, placeholders, and accessible names aligned so everyone gets the same meaning.
- Reuse the same visual pattern for keyword rows where possible so the site feels cohesive.
- Test global search on each experience you maintain (for example main site and library) when navigation changes.
Don't
- Add a second global search on the same page without a strong reason.
- Strip focus styling from fields or buttons without replacing it.
Related
| Resource | |
|---|---|
| Navigation | Global header search overlay and tabs for site versus library targets. |
| Form controls | Labels, fields, and grouping for structured search forms. |
| Thunderstone search | Standalone Thunderstone keyword search where that product applies. |
| Thunderstone faceted search | Keyword row plus faceted filters on Thunderstone-backed lists. |
| Google search | Google Custom Search embed styling and behaviour when used. |
Multi-field directory and faculty UIs are different from a single keyword bar on purpose; see Person search, Department search, and faculty documentation for those patterns.
Search UIs lean on Bootstrap (input groups, form controls, primary buttons, tabs in site search). Faceted sidebars sometimes use a narrower text treatment than full input-group rows; that is intentional for layout but can look different if not reviewed side by side.
Alignment tips
- Prefer one canonical keyword row in specs: field plus primary submit with the shared search icon treatment, where product allows.
- Keep focus styles visible on fields and buttons.
- Constrain very wide standalone forms with a sensible max width so inputs do not stretch edge to edge on large monitors unless the template is full bleed.
Component-specific styles (program search, profile search, Thunderstone, and others) live in each feature’s stylesheets; see Code for locations.
Site search uses tab semantics and relationships between tabs and panels; the close control is a real button. Icon-only submit buttons need an accessible name (for example “Search” or “Search events”); decorative icons should be marked as such.
Multi-field forms (directory, faculty) should keep labels tied to fields with for and id. Keyboard users must reach every control in a logical order and activate buttons with Enter or Space. Where autocomplete runs, test with screen readers so suggestions do not surprise users. Preserve visible focus on inputs and buttons; do not rely on placeholder colour alone for focus.
Testing
Exercise open and close for site search, keyword search on major list types, keyboard use of icon submits, and multi-field directory and faculty forms after meaningful changes.
CRXDE Lite query
Use this query in CRXDE Lite to find instances of this component.
/jcr:root/content//*[@sling:resourceType = 'concordia/components/navigation/navigation.jsp']Implementation is distributed across navigation, search clientlibs, and individual list components.
| Area | Files to read |
|---|---|
| Site search markup | apps/concordia/components/navigation/navigation.jsp |
| Site search behaviour | etc/designs/concordia/clientlibs/header/js/mega-menu.js |
| Unified search | apps/concordia/components/search/unified-search/unified-search.jsp, _cq_htmlTag/.content.xml |
| Thunderstone | apps/concordia/components/search/thunderstone/thunderstone.jsp |
| Thunderstone faceted | apps/concordia/components/search/thunderstone-faceted-search/thunderstone-faceted-search.jsp |
| News grid bar | news-events/news-list/grid-scripts/searchbar.jsp |
| News faceted keyword | news-events/news-list/format_faceted_search.jsp |
| Calendar | news-events/calendar/calendar.jsp |
| Program list | program-list/program-list.jsp |
| Profile / student / CCE lists | individual-profile-list, student-group-list, cce/cce-offering-list |
| Offering search | cce/offering-search/offering-search.html |
| IT | it-services/service-search/service-search.html, it-services/service-list/service-list.html |
| Faculty | faculty/faculty-profile-search/faculty-profile-search.jsp |
| Directory | directory/person-search/person-search.html, directory/department-search/department-search.html |
| Shared search LESS | etc/designs/concordia/clientlibs/search/css.txt |
| Faceted shared | faceted-search/less/faceted-search.less |
Search bar and keyword instances
These are documented instances of a search bar or keyword field. Multi-step directory forms are listed separately.
Global and dedicated search components
| Pattern | Where | Key markup / hooks | Notes |
|---|---|---|---|
| Site search overlay | apps/concordia/components/navigation/navigation.jsp | .c-site-search, tabbed panes, form IDs | Tabs for targets (main site vs library, and similar). Opened via navbar search. Directories field may use autocomplete. |
| Unified search | apps/concordia/components/search/unified-search/unified-search.jsp | c-unified-search, #unified-search-term | Keyword field above tabbed result areas. |
| Thunderstone search | apps/concordia/components/search/thunderstone/thunderstone.jsp | c-thunderstone-search, #thunderstone-search-term | Empty state shows input group; results load when a query is present. |
| Thunderstone faceted search | apps/concordia/components/search/thunderstone-faceted-search/thunderstone-faceted-search.jsp | .c-tfs__search-form, .c-tfs__search-input | Keyword row for faceted Thunderstone experiences. |
News and events
| Pattern | Where | Key markup / hooks | Notes |
|---|---|---|---|
| News list (grid) search bar | news-events/news-list/grid-scripts/searchbar.jsp | .c-news-list-searchbar | Grid format; Thunderstone query param query. |
| News list (faceted) keyword | news-events/news-list/format_faceted_search.jsp | .c-news-list__faceted-filters, #search | Sidebar search bloc with filters. |
| Calendar | news-events/calendar/calendar.jsp | #searchTerm, input-group | Search events placeholder. |
Programmes, profiles, awards, CCE, IT
| Pattern | Where | Key markup / hooks | Notes |
|---|---|---|---|
| Program list | program-list/program-list.jsp | .program-search, #programFilter | Keyword filters program cards. |
| Individual profile list | individual-profile-list/individual-profile-list.html | .profile-list-search, #profileFilter | Keyword in faceted layout. |
| Student group list | student-group-list/student-group-list.html | #studentGroupFilter | Inside faceted search. |
| Research awards list | academics/research-awards-list/research-awards-list.jsp | #textFilter | Placeholder configurable. |
| CCE offering list | cce/cce-offering-list/cce-offering-list.html | #textFilter | Keyword in faceted list. |
| CCE offering search | cce/offering-search/offering-search.html | #offeringFilter | Standalone form. |
| IT service search | it-services/service-search/service-search.html | #service-search-form | Collapsible form. |
| IT service list (faceted) | it-services/service-list/service-list.html | #service-list-search | Sidebar keyword row. |
Faculty and directory
| Pattern | Where | Key markup / hooks | Notes |
|---|---|---|---|
| Faculty profile search | faculty/faculty-profile-search/faculty-profile-search.jsp | role="search", labelled fields | Multi-field; not a single bar. |
| Directory person search | directory/person-search/person-search.html | #person-search-form | First name, last name, optional advanced fields. |
| Directory department search | directory/department-search/department-search.html | #department-search-form | Radios and multi-select; different UX from keyword bar. |
Other
| Pattern | Where | Notes |
|---|---|---|
| Google Custom Search styling | etc/designs/concordia/clientlibs/search/less/google-search.less | Styles third-party embed when used. |
Markup notes
- Site search: outer wrapper with tabs and one form per tab; IDs follow
#c-site-search__…. - Keyword row: often
input-groupwithform-controland a primary segment for the submit control. - Thunderstone (empty): form with hidden page field, text field, and submit.
Authoring
There is no single Search bar dialog for all pages. Author the parent component or template that exposes search (Navigation is part of page structure; other components have their own dialogs).
Dependencies
- Bootstrap for tabs, input groups, buttons.
- jQuery and jQuery UI autocomplete for some site search targets.
- Thunderstone or other backends where those products apply.
- Clientlibs:
apps.concordia.header,apps.concordia.search, plus per-feature clientlibs.