# Temple Solel experience blueprint

This is a proposed direction for the next draft, not a claim that integrations already work. It follows the public-site inventory and eight-site benchmark review. The current review demonstrates visual direction, calendar browsing, navigation, visit-guide disclosures and email layouts.

## The core journeys

| Visitor goal | Design response | What needs verification |
| --- | --- | --- |
| Visit for the first time | New Here page, service rhythm, first-Friday itinerary, contact and access information | Visitor/check-in policy, parking, accessibility, holiday exceptions and response owner |
| Find a service or event | Next-service utility, list-first calendar, month view, category filters and complete event details | Authoritative calendar source, feed/API access, timezone, recurring exceptions and cancellations |
| Register or renew | Clear event/program handoff to the existing ShulCloud flow | Form ownership, member/nonmember eligibility, capacity, required fields and confirmation behavior |
| Find the right school | Distinct preschool, religious school and teen pathways, age guidance and tour/inquiry action | Current program details, correct school site, fees, dates and inquiry recipient |
| Get help with a life transition | Visible care/lifecycle route with compassionate language and clear contact options | Correct emergency number, after-hours policy, pastoral boundaries and staff review |
| Participate in social action | Opportunities by activity, duration and age, with a concrete next step | Partner details, schedule, physical demands, capacity and volunteering requirements |
| Give | Explain purpose and fund choices, then connect to the existing donation service | Current funds, restricted gifts, acknowledgements and payment-provider flow |
| Use member services | Consistent Member login link, directory and renewal destinations | Actual permissions and authentication boundaries; keep private data out of the public site |
| Learn or listen later | Searchable teaching/music library with topics, transcripts, captions and original-source attribution | Publishing permission, existing archives, sustainable editorial capacity and transcript quality |

## Information architecture

Primary navigation: **New here / Shabbat & holidays / Learn & connect / Calendar / Give**. A utility layer holds **Member login / Livestream / Contact**. Search should help with programs, events and practical questions once the content set justifies it.

The next draft should cover home, visit, worship, calendar and event detail, learning overview, preschool, religious school, teens, adult learning, community and action, lifecycle/care, clergy and staff, giving, contact, and a reusable seasonal holiday hub. Reuse templates where the task is shared; do not force pastoral care and event promotion into the same sales layout.

Visitors can arrive by audience or activity. Avoid an invasive personalization quiz. A simple interest filter can offer Families, Teens, Adults, New Here, and Online, but only if program metadata makes these choices accurate. Plain-language Hebrew explanations belong near the relevant term, without flattening the congregation’s voice.

## A reliable event system

One event should have: title, concise description, start/end, America/Phoenix timezone, series/exception relationship, location or online format, audience, category, registration URL and state, cost where applicable, access information, contact, image/alt text, and publishing/expiration dates. A cancellation is a state on the existing record, not a disappearing page.

States to design after direction selection: open registration, no registration required, members only, sold out, waitlist, registration closed, cancelled, online, and hybrid. The current calendar only demonstrates browsing with sample records; it does not simulate real capacity or registration success.

Agenda is the default on small screens. Month is an overview with readable event details available alongside it. Add-to-calendar and series subscriptions are useful next steps; they must preserve timezone and recurring exceptions. Holiday dates should come from an approved authoritative calendar, not handwritten approximations. Do not expose sensitive meeting locations or private attendee lists.

Start by reconciling the current Google Calendar, WordPress event surface and ShulCloud records with staff. Use a supported feed/API if available and authorized; otherwise keep a deliberately small editorial record that links to the existing registration page. Do not promise bidirectional sync before testing real access and sample data.

## Communication system

Use event data to produce human-reviewed website cards, eNUZ modules and social copy. A practical template set includes weekly digest, welcome, reminder, registration confirmation, cancellation/change, holiday invitation, membership renewal and giving appeal. Only the weekly digest, welcome and event reminder have editable HTML samples in this review.

Social art should use exact export dimensions: feed portrait 1080×1350, story 1080×1920, square 1080×1080, and a flexible landscape web/email header. Keep important copy away from platform overlays and preserve readable date/action text. The generated campaign board establishes composition and style; it is not an export-ready template library. Build live text over reusable art so staff can update details without regenerating pictures.

Preference options can separate weekly news, families, learning and special notices. Respect the current provider’s consent/unsubscribe workflow. Avoid a separate signup database. No emails or social posts were sent during this work.

## Visual and editorial system

- Keep the existing logo file for the first draft. Optional small-size refinements should preserve the recognizable silhouette, sun, mountains and path; generated approximations are not finished logo files.
- Use blue as an anchor. Yellow and orange are accents, with dark readable text rather than pale yellow small type.
- Pair one expressive heading family with one readable body family. Test actual font licensing, Hebrew coverage and performance before final selection; the prototypes use system Georgia and Arial.
- Commission/select real photographs of worship, learning, friendships, intergenerational life, music and service. The temple’s existing photographs are source material; approval and consent need review before a new public use. Generated illustrations should remain illustrations, not fabricated documentary photographs.
- Define repeatable spacing, button styles, form fields, error/success states, cards, date blocks, navigation, banners and email modules. Let typography and hierarchy do most of the work.
- Use calm, optional motion, visible focus, real headings, descriptive links, sufficient contrast, captions, transcripts and text alternatives. Aim for WCAG 2.2 AA; the current checks are not a conformance certification.

## Staff workflow and maintenance

Agree who owns the calendar, home-page curation, pastoral information, program pages and photography. Provide a short publish/preview flow with required event fields and scheduled expiration. A cancellation should update every affected channel through its own approved workflow. Keep a revision trail and accessible preview; do not make staff edit CSS or regenerate art to change a date.

Before launch, reconcile stale PDFs and duplicate destinations, build a redirect map, preserve useful page URLs where possible, and make meaningful HTML content the default rather than image flyers. Add page metadata and structured event information only from verified records. Check indexing, error pages, search behavior and mobile performance with real content.

## What success would mean

Use task tests rather than vague aesthetic approval: can a newcomer find the next service and contact; can a member reach renewal; can a parent find the right school; can a visitor register for the correct event; can a person seeking care find the right contact? Observe these tasks on phones with both members and newcomers, including people with access needs.

Potential measures: first-visit inquiries, completed program/registration handoffs, failed searches, event-detail usefulness, successful member navigation, publishing time and date discrepancies. Establish a baseline and agree privacy-conscious measurement before claiming improvement. Avoid treating page views alone as community engagement.

Defer a custom app, replacement CRM, community message board, automated pastoral advice, and a general AI concierge until real needs and staffing support them. These add maintenance and trust costs without proving the basic website better.

## Evidence and boundaries

Sources: [Temple Solel](https://templesolel.org/), [membership forms](https://templesolel.org/membership/forms/), [services](https://templesolel.org/services/), [ShulCloud public site](https://templesolelaz.shulcloud.com/), [W3C WCAG 2.2](https://www.w3.org/TR/WCAG22/), [WAI forms guidance](https://www.w3.org/WAI/tutorials/forms/), and the eight official benchmark sites linked in the research brief.

No private-system access, staff interview, analytics review, member testing, live integration or production migration was performed. Proposed benefits and priorities are design judgments to validate with the congregation.