Two reasonable approaches; we picked the one that's easier to maintain:

1. Static PDF file uploaded to the site (the alternative).Pro: a single download link. Con: every time you change a calendar date, the PDF has to be regenerated and re-uploaded, or it silently goes out of sync with the on-page calendar. Today's "May 21 → May 27" edit is a perfect example — a stale PDF would still say May 21.
2. Print-from-page (what we built).Pro: the printed/saved PDF always reflects whatever the on-page calendar currently shows, including future updates. The user gets both options — print-to-paper or save-as-PDF — from the same one button. Con: requires the user to click "Save as PDF" in the print dialog rather than a single "Download" link, but every modern browser exposes this prominently and parents are already used to it from school forms, tickets, etc.

Net: lower maintenance burden, zero risk of drift, same end result for the parent. If you'd prefer a one-click static PDF download instead, that's a 10-minute swap — let us know.

Several converging bodies of research point in the same direction: for a service business — and especially a daycare — authentic imagery is one of the most powerful trust signals on a website. The findings are consistent across decades of UX, marketing, and web-credibility studies.

1. Eye-tracking shows users actually look at real people; they ignore stock photos. Nielsen Norman Group's eye-tracking research on web photography (cited across UX literature for over a decade) found that photographs of real people associated with a business get strong, sustained eye fixations from visitors. Generic stock photos — especially "smiling people in suits" or "happy children playing" — are essentially skipped over, treated by the brain as decoration. The same effect applies to staff portraits: a real photo of Sherry from the Infant room earns attention; a stock teacher pulled from Shutterstock gets scrolled past.
2. Stanford's Web Credibility research lists authentic photography as a top credibility cue. The Stanford Web Credibility Project (BJ Fogg and colleagues) identified design quality and authentic photography of real people as two of the strongest perceived-credibility factors on a website. Parents researching childcare are running a mostly-subconscious credibility check on every page — real photos pass that check, generic stock fails it.
3. Parents have stock-photo radar — and it works against you. Most parents researching daycare have visited 5–10 competing sites in the same week. They've seen the same stock photos repeated across multiple providers (and often across unrelated industries). When they recognize an image, it actively erodes trust — the implicit thought is "if their photos aren't real, what else isn't?" One imperfect classroom snapshot beats ten polished stock images.
4. For childcare specifically, "I can see who will care for my child" lowers the stakes of the decision. Choosing a daycare is one of the highest-anxiety purchasing decisions a parent makes. Real staff faces let them mentally rehearse drop-off before they ever visit — they walk in already feeling like they "know" the room. NAEYC's accreditation framework (which Open Arms holds) emphasizes transparency for exactly this reason. Real photos extend that transparency from the building to the website, where the first-impression decision actually gets made.
5. "Action shots" build emotional connection in a way portraits can't. A photo of a teacher reading to a circle of toddlers, kids painting at the easel, or messy-but-engaged sensory play communicates more in two seconds than a paragraph of copy. UX and marketing research consistently shows that "people-in-context" photos outperform isolated portraits or generic shots when the goal is emotional connection and trust — exactly the goals of a daycare website.
6. The compounding effect: every other improvement gets more leverage. The contact form, the tuition transparency, the calendar, the philosophy section — all of these work harder when wrapped in authentic imagery. The same words on the page land differently when the surrounding photos look like Open Arms instead of a generic stock library. This is why "10× the effectiveness" isn't hyperbole.

If we can get these done in the next 1–2 weeks, the site goes from "very good" to "best-in-class for Fairbanks daycares." Specifics on each:

1. A headshot of every staff member (all 22) Goal: replace the colorful initials placeholder on every staff card with a real face. Phone snapshots are absolutely fine — they don't need to be professional, and waiting on a professional photographer is the wrong tradeoff. A simple two-minute setup works perfectly: stand against a plain wall (any solid color), natural light from a nearby window, shoulders-and-up framing, soft smile.
   
   Suggestion: make this a one-day push. Set up the "photo corner" by a window during a staff meeting or lunch, and knock out all 22 in an afternoon. Everyone should be required to either be photographed or send a photo themselves — this is now a website-completeness item, not optional.
   
   What to send: one JPG/HEIC per staffer, ideally 1000+ pixels on the short side. Email or AirDrop them and Gary will process the batch.
2. 15–20 "school in action" candid shots Goal: replace any remaining generic imagery with real moments from inside the building. Examples that would be especially impactful:
   • A teacher reading to a small group
   • Kids at the easel painting or at the sensory table
   • Snack time or circle time
   • Outdoor play on the playground
   • The building exterior, well-lit, mid-day
   • Interior shot of a classroom set up for the day (no children needed)
   
   Important re: children's faces: only include children whose parents have a current photo-release on file. Back-of-head, hands-only, or environment-with-no-faces shots are 100% safe to use without consent and are often more atmospheric anyway — a small hand reaching for a paintbrush tells a story that a posed group photo can't.

Don't get hung up on photo quality before sending. The site's image pipeline includes an AI image-enhancement tool (Google's Nano Banana / Gemini, already in use for the few existing staff portraits) that can take a phone snapshot and make it look like a studio-shot portrait — consistent lighting, clean backgrounds, color matched to the Open Arms brand palette.

Translation: imperfect snapshots are infinitely more useful than waiting for a professional photographer. Don't let "we should hire a photographer" delay this — send phone photos this week, and if you want a polish pass from a real photographer later, that can be layered on top without redoing anything.

Plain-language overview of the moving parts so you (or whoever takes over the site later) knows what each piece does.

1. Where messages are sent from When a parent submits the form, their browser calls a service called EmailJS directly — no Open Arms server is involved. EmailJS is a free third-party "send email from a webpage" service that handles the actual email delivery for us. Netlify just hosts the static site files; it has nothing to do with sending these messages.
2. Who owns the EmailJS account Gary set up the EmailJS account under his own login on the free tier. Three IDs from that account (a public key, a service ID, and a template ID) are saved inside index.html so the form knows which account to use. If Gary ever needs to hand the account to Open Arms, the login can be transferred or a new account created and the three IDs swapped — no code rewrite needed.
3. Free-tier limits The free EmailJS plan allows 200 sends per month and 1 allowed origin domain (currently openarmsak.netlify.app). Both are comfortable for a contact form. The dashboard shows a running count of sends per month — if it ever gets close to the limit, that's the signal to upgrade.
4. How messages route to the right staffer Each staff member's card carries a routing email in the site's data. When the modal opens for "Sherry — Infants," for example, the form is pre-set to deliver to Infant@openarmsfairbanks.org. The parent's email is set as Reply-To, so when the staffer hits Reply, it goes back to the parent (not to Gary or the EmailJS account). Eight unique routing addresses are wired up across the 20 staff members who have one assigned.
5. Spam & abuse protections in place Three layers: (1) a hidden honeypot field that bots fill in but humans don't see — submissions with anything in it are silently dropped; (2) the EmailJS allowed-origin restriction blocks anyone from using these credentials from a site other than openarmsak.netlify.app; (3) the 200/month cap puts a hard ceiling on volume even if abuse occurs.
6. What to do if the form ever stops working Open the EmailJS dashboard → History tab. It logs every send attempt with success/failure status. The most common breakage is the connected email account (Gmail/M365) revoking authorization — fix is to reconnect it under Email Services. Less commonly, hitting the monthly cap shows a clear error in the dashboard.

The simplest approach would be a plain mailto: link on each staff card — click it, your email app opens, you compose and send. We chose the contact-form route instead. Here's the reasoning, roughly in order of importance:

1. Many parents don't have a desktop email client configured Most people now use Gmail or Outlook in a browser tab, not a dedicated app like Apple Mail or Thunderbird. When those users click a mailto: link, the browser either does nothing, opens an empty Outlook setup wizard they don't want, or asks them to "choose a default app." Many give up at that point. The in-page form works for everyone regardless of how they handle email.
2. Lower drop-off — fewer steps to send Every context switch (page → email app → compose → send) is a place a parent loses momentum. Filling four fields without leaving the website keeps them in the flow they started.
3. Staff email addresses don't appear in the page source A mailto: link puts the address right in the HTML (<a href="mailto:Infant@openarmsfairbanks.org">), where automated bots scrape it for spam lists. Within weeks the classroom inboxes would start receiving spam. With the form, addresses live only in the JavaScript data and aren't easily harvestable.
4. Required fields and basic validation A mailto: link can't enforce that the parent fills in a subject or includes their name. The form requires Name, Email, Subject, and Message before the Send button works — so staff get consistently useful messages instead of a one-line note from "no-subject" with no return address.
5. Auditability — you can prove a message was sent If a parent later says "I emailed Sherry on Tuesday and never heard back," the EmailJS dashboard's History tab logs every send attempt with timestamp, recipient, and success/failure. With mailto:, the message lived only on the parent's machine — there's no way to confirm it ever left.
6. Reply-To trick keeps replies one click away The form sends from a single address (Gary's connected Gmail) but sets the parent's email as the Reply-To. So when Sherry hits Reply, her response goes straight back to the parent — not to Gary. Staff don't have to copy/paste the address out of the message body.
7. Consistent inbox formatting for staff Every message arrives with the same structure (Subject prefixed [Open Arms], body labeled From / Email / Message). Staff can scan their inbox and immediately recognize a website-originated parent message vs. internal email or spam.

A short list of small protections that are easy to overlook but matter when a contact form sits on the public internet.

1. Honeypot field traps bots The form includes a hidden field that real users never see (it's set to display:none). Most spam bots fill in every field they find — including invisible ones. If anything lands in the honeypot, the submission is silently dropped before it ever reaches EmailJS. Free, invisible, and effective against ~95% of low-effort bots.
2. Allowed-origin lock at the service level Even though the EmailJS public key is technically visible to anyone who views the page source, the EmailJS server rejects any request that doesn't originate from openarmsak.netlify.app. So even if someone copied the key, they couldn't use it from their own site or a script.
3. Public key only — no secrets in the codebase The three values in index.html are all public identifiers (public key, service ID, template ID). They're safe to commit to git and serve to browsers. The actual sending credentials (Gmail OAuth tokens) live inside Gary's EmailJS account and never touch the website code.
4. Built-in volume ceiling The free-tier 200-sends-per-month limit acts as a hard cap on abuse. Even if a determined attacker tried to spam staff via the form, EmailJS would stop accepting sends partway through the month, with a clear notice in the dashboard. The dashboard also makes any sudden volume spike obvious.
5. Clear success and error states After a successful send, the modal swaps to a green confirmation panel ("Message sent! Expect a reply within 1–2 business days"). On failure, the user sees a red message with the daycare's phone number as a fallback so they're never stranded — no silent failures.
6. Reply-To set to the parent's email, not the sender A subtle but important detail: EmailJS sends technically come from Gary's connected Gmail, but the message's Reply-To header is the parent's address. Without this, staff hitting Reply would email Gary by accident.
7. Staff addresses obfuscated, not just hidden The 8 routing addresses live in the JavaScript data array, not as <a href="mailto:..."> tags. While a determined scraper can still parse the JS, the vast majority of email-harvesting bots only look at HTML anchor tags — so this drops harvest risk by an order of magnitude with no usability cost.
8. Account ownership is portable The three credentials are tied to the EmailJS account, not the domain. If the EmailJS account ever needs to be transferred from Gary to Open Arms (or to a future developer), it's a settings change in EmailJS — no code rewrite required.

One thing to remember the day Open Arms migrates the site away from openarmsak.netlify.app to a real domain (e.g., openarmsfairbanks.org or a subdomain).

1. Update the EmailJS allowed domain Log in to EmailJS → Account → General → Domains → replace https://openarmsak.netlify.app with the new domain (e.g., https://openarmsfairbanks.org). The free tier only allows one domain, so this is a swap, not an add. Until you do this, the contact form will silently fail on the new domain.
2. No code change needed The three EmailJS credentials in index.html stay the same — they're tied to the account, not the domain. Just the dashboard setting changes.

The contact form uses EmailJS (free, no backend needed). Three placeholder values in the code need to be replaced with your real credentials. Steps:

1. Create a free EmailJS account Go to emailjs.com → Sign Up → free tier gives 200 sends/month (plenty for a contact form).
2. Add an Email Service In the EmailJS dashboard → Email Services → Add New Service. The easiest option is to connect a Gmail or Microsoft 365 account you control (e.g., the Open Arms admin account). This becomes the "from" address visible on outbound messages. Copy the Service ID.
3. Create an Email Template In the dashboard → Email Templates → Create New Template. Set:
   • To: {{to_email}}
   • Reply-To: {{from_email}}
   • Subject: [Open Arms] {{subject}}
   • Body: paste the block below (plain text or HTML):
   
   Hi {{to_name}},

A message from the Open Arms website:

From: {{from_name}} ({{from_email}})

{{message}}

---
Reply to this email to respond directly to {{from_name}}.
   
   Copy the Template ID.
4. Copy your Public Key In the dashboard → Account → General → copy the Public Key.
5. Paste the three values into index.html Near the bottom of index.html, find the three lines that say YOUR_PUBLIC_KEY, YOUR_SERVICE_ID, and YOUR_TEMPLATE_ID — replace each with the real values from steps 2–4. Save and deploy.

Small choices I made while applying these edits — please flag any that should change and I'll adjust.

1. Hero video "no cut" — how should the loop play back? Decision: Ping-pong (forward → reverse → forward) driven by a small JS loop that nudges currentTime backward when the clip nears its end, then resumes forward play at the start. No re-encoded reversed copy of the file is needed; the existing Cloudinary clip is reused.
2. Where should the USDA Nondiscrimination Statement live? Decision: In the site footer on the landing page, in a dedicated band above the © line so it's present site-wide without crowding the main content. Linked the "How to File a Program Discrimination Complaint" reference to the USDA OASCR page; the 866 phone and program.intake email are also linkable. If you want it on every page (employment.html, waitlist.html, estimate.html, status.html), say the word and I'll mirror it.
3. Summer Program start date — confirm June 1, 2026? Decision: Moved to June 1 on the 2026 Calendar (was May 26). Memorial Day (May 25) and the Last Day of School Care (May 21) are unchanged. The Summer Program registration date in March is unchanged.

Before building, I asked a few clarifying questions. Here's what we landed on — please flag any that should change and I'll adjust.

1. Should tuition dollar amounts be shown publicly on the live site? Decision: Yes — rate cards display as listed on the 2025-26 rate sheet. The site is still password-gated for review, so prices only become public when we deploy.
2. Calendar title — "2026 Calendar" or "2025-26 Calendar"? Decision: 2026 Calendar — matches the source PDF; all events fall between Jan and Dec 2026.
3. Keep both the existing Enrollment form and the new Waitlist form? Decision: Keep both — Enrollment Inquiry stays on the landing page for families ready to enroll; the new Waitlist page is for families who want a spot when one opens. An inline "Join the waitlist →" link sits under the Enrollment form so families can self-select.
4. Is the new Kitchen Manager opening a backfill for Charles, or an additional hire? Decision: Posted as a general opening — Charles remains listed on the Staff page as Kitchen Manager. If he's leaving the role, no change is needed; if you're hiring an additional person alongside him, we may want to rename the posting (e.g., "Assistant Kitchen Manager" or "Cook"). Let me know.
5. OK to move Philosophy and FAQ off the desktop nav (still reachable from mobile menu and footer)? Decision: Yes — desktop nav is now Programs · Tuition · Calendar · Staff · Waitlist · Employment · Contact. Philosophy and FAQ remain in the mobile menu and the footer Quick Links so nothing is lost.