diff --git a/.gitignore b/.gitignore index 877e72c..fd3dbb5 100644 --- a/.gitignore +++ b/.gitignore @@ -34,5 +34,3 @@ yarn-error.log* # typescript *.tsbuildinfo next-env.d.ts - -plan/*.md \ No newline at end of file diff --git a/plan/content.md b/plan/content.md new file mode 100644 index 0000000..eae125e --- /dev/null +++ b/plan/content.md @@ -0,0 +1,87 @@ +# VanJS Website Content Enhancement Plan + +This plan outlines suggestions to enhance the website content, aiming to better reflect VanJS as a fun, active learning hub that showcases Vancouver's thriving developer community. + +## I. Overall Tone & Voice + +* **Action:** Adopt a more enthusiastic, welcoming, and community-focused tone throughout the website copy. +* **Keywords to weave in:** "vibrant", "connect", "share", "learn", "grow", "discover", "active", "fun", "community hub", "Vancouver's own". +* **Speak directly to the user:** Use "you", "your", "join us". + +## II. Section-Specific Content Suggestions + +### 1. Header +* **Current:** Functional, logo, navigation. +* **Suggestion:** While primarily navigational, ensure the overall site tone (set by other sections) makes even the header feel like part of a welcoming space. + +### 2. "Make Us LOL!" Section +* **Current:** "We love a good laugh! Submit your funniest joke and it might be featured at our upcoming event." +* **Goal:** Amplify the "fun" aspect and clarity. +* **Suggestions:** + * **Revised Intro:** "Got a killer dev joke? VanJS is where Vancouver's sharpest JavaScript minds unwind! Share your funniest (clean!) tech-related joke, and it might just steal the spotlight at our next meetup or on our social channels. Let's make our community LOL!" + * **Clarify Feature:** Be more specific about *where* jokes might be featured (e.g., "during meetup intros," "on our Twitter/LinkedIn"). + +### 3. Hero Section (`#hero`) +* **Current Tagline Area:** "VanJS" (H1) + Duck Image. +* **Current Description:** Focuses on what VanJS is, GitHub links. +* **Goal:** Create a more impactful first impression emphasizing learning, community, and activity. +* **Suggestions:** + * **Engaging H1/Sub-headline:** Consider adding a sub-headline below or near the "VanJS" H1: + * Example: "VanJS: Your Hub for JavaScript & Vancouver's Thriving Dev Community." + * Example: "VanJS: Learn, Connect, and Grow with Vancouver's Active JavaScript Scene." + * **Enrich Description:** Inject more dynamism: + * "Dive into Vancouver's most active monthly gathering for JavaScript enthusiasts! VanJS is your go-to for exploring the latest in JavaScript, front-end tech, and the open web. Whether you're a seasoned pro or just starting your coding journey, you'll find a welcoming space to learn from local experts, share your own insights (check out our Call for Speakers!), and connect with our vibrant developer community." + +### 4. Upcoming Events Section (`#upcoming`) +* **Current Intro:** "Check out our upcoming VanJS events in Vancouver." +* **Current Event Descriptions:** Often generic (e.g., "Join us for our monthly JavaScript meetup in Vancouver."). +* **Goal:** Make events sound unmissable, highlighting learning and networking. +* **Suggestions:** + * **Section Intro:** "Don't miss what's next! VanJS is always buzzing. Secure your spot for our upcoming events – get ready to learn something new, meet brilliant folks, and be part of Vancouver's passionate JS community." + * **Event Descriptions (Examples):** + * For Socials: "*VanJS March 2025 Social:* Kick back, chat, and connect! Join your fellow JavaScript devs at The Pint Public House for an evening of relaxed networking. Less code, more conversation – the perfect way to expand your Vancouver tech circle." + * For Talks: "*VanJS Easter Talks:* Spring into new ideas with VanJS! We're gathering at Northeastern University for an exciting lineup of talks from Vancouver's own JS innovators. Expect fresh perspectives, lively Q&A, and a great learning atmosphere." + * **Crucial:** If speaker names and talk titles are available, *always* include them. E.g., "Featuring [Speaker Name] on [Talk Topic]!" + +### 5. Past Events Section (`#past`) +* **Current Intro:** "Check out our past VanJS events in Vancouver." +* **Goal:** Showcase the history of valuable content and consistent activity. +* **Suggestions:** + * **Section Intro:** "Curious about what VanJS has been up to? We've hosted a fantastic range of talks and events! Browse our past meetups to see the diverse topics covered and the incredible insights shared by our community speakers." + * **Event Descriptions (if possible to augment briefly):** If recaps are detailed, hint at it. "*VanJS August 2024:* Explored AI dev tools, VFX-JS, and WebXR. View recap for highlights!" + * **Emphasize "View Recap":** Ensure this CTA is clear and links to genuinely informative content (Luma pages, slides, recordings if any). + +### 6. "Join Our Discord" Section (`#discord`) +* **Current Intro:** "Connect with our community on Discord to get real-time help, share ideas, and discuss projects!" +* **Goal:** Position Discord as an active, supportive extension of the meetup. +* **Suggestions:** + * **Section Intro:** "The VanJS conversation never stops! Our Discord server is a thriving 24/7 hub for Vancouver's JavaScript enthusiasts. Jump in to ask questions, get real-time coding help, share your latest projects, discover new tools, and stay connected with your local dev community between meetups. It's where the learning, sharing, and fun continue!" + +### 7. FAQ Section (`#faq`) +* **Current Intro:** "Some frequent questions from our community:" +* **Goal:** Reinforce welcoming nature and value proposition. +* **Suggestions:** + * **Review Answer Tone:** Ensure answers are friendly, clear, and helpful. + * **Consider Adding a Value-Focused FAQ:** + * Q: "Why should I attend VanJS? / What makes VanJS special?" + * A: "VanJS is your direct connection to Vancouver's vibrant JavaScript scene! It's a fantastic place to learn from local developers who are passionate about their craft, share your own knowledge (we love first-time speakers!), expand your professional network, and just have a great time with like-minded people. We're all about building a supportive and active community." + * **On Ticket Price:** The current explanation is good. Could end with: "...ensuring VanJS remains a valuable and sustainable resource for our amazing dev community." + +### 8. Footer (`#footer-contact`) +* **Current:** Logo, social/event links. +* **Goal:** A final friendly touch. +* **Suggestions:** + * Consider a small tagline if space and design allow: e.g., "VanJS: Connecting Vancouver's JavaScript Developers Since [Year]." or "Proudly part of Vancouver's tech community." + +## III. General Content Opportunities + +1. **Testimonials/Quotes:** + * **Suggestion:** If you can gather short, positive quotes from attendees or speakers about their VanJS experience (e.g., what they learned, who they met, why it's fun), incorporating a few on the homepage or a dedicated section could be very powerful social proof. + +2. **Highlighting Local Talent/Companies:** + * **Suggestion:** When mentioning past talks or if creating speaker profiles in the future, briefly mentioning the speaker's company (if they're representing it) helps showcase the breadth of Vancouver's tech ecosystem involved with VanJS. + +3. **Visual Storytelling:** + * **Suggestion:** Ensure images used (especially `hero.webp` and any future event photos) genuinely reflect the energy, diversity, and engagement of the meetups. Good photos are key to conveying "fun" and "active community." + +By refining the language and focusing on these themes, the VanJS website can more effectively communicate its value and the vibrancy of the community it serves. diff --git a/plan/design.md b/plan/design.md new file mode 100644 index 0000000..cdf57b6 --- /dev/null +++ b/plan/design.md @@ -0,0 +1,96 @@ +# Design Improvement Suggestions for VanJS Website + +This document outlines potential design and user experience (UX) improvements for the VanJS website, based on a review of its structure and content. + +## I. Header & Navigation + +1. **Mobile Navigation:** + * **Observation:** The main navigation links (`Home`, `Upcoming`, `Past`, etc.) are hidden on smaller screens, and no alternative (e.g., hamburger menu) is provided. Only the "VanJS" logo and "Attend" button are visible. + * **Suggestion:** Implement a mobile-friendly navigation pattern (e.g., hamburger icon that toggles a dropdown or off-canvas menu) to ensure all navigation links are accessible on all device sizes. This is critical for usability. + +2. **"Speakers" Nav Link:** + * **Observation:** The "Speakers" link in the header navigation (`#speakers`) points to a section that is currently commented out on the page. + * **Suggestion:** Either remove this link from the header until the "Speakers" section is implemented and live, or clearly mark it (e.g., "Speakers (Coming Soon!)") and have it link to a placeholder if appropriate. A dead link can be frustrating for users. + +3. **Visual Hierarchy of "Attend" Button:** + * **Observation:** The "Attend" button in the header uses `bg-secondary`. + * **Suggestion:** Ensure `bg-secondary` provides strong visual prominence if "Attend" is the primary call to action in the header. Its visual weight should align with its importance. The current yellow header (`bg-[#FEB92F]`) is very vibrant; ensure the "Attend" button stands out sufficiently or consider if it should have the primary brand color if it's the most important action. + +## II. Hero Section (`#hero`) + +1. **Clarity of Visual Elements:** + * **Observation:** The main `H1` "VanJS" is next to a rotated duck image. Below this is descriptive text and then a larger "hero" image (`hero.webp`). + * **Suggestion:** Ensure a clear visual flow. The primary headline should grab attention first. Consider the visual balance between the text block and the `hero.webp` image, especially on different screen sizes. Use spacing to clearly separate the introductory text/logo area from the main hero image if they are distinct concepts. + +2. **Alt Text for Hero Image:** + * **Observation:** Alt text is "VanJS event or community highlight image". + * **Suggestion:** While much better than "Hero", make it even more specific if the image depicts a recognizable scene, type of event, or specific group of people (while respecting privacy). E.g., "Attendees networking at a VanJS meetup" or "Speaker presenting at VanJS event at Northeastern University." + +## III. "Make Us LOL!" Section + +1. **Visual Integration:** + * **Observation:** This section appears above the main "Hero" section with the `H1` heading. This might feel a bit out of place as the first interactive content users see. + * **Suggestion:** Consider the placement of this section. If it's secondary content, it might fit better further down the page, or be visually styled to be less prominent than the main site introduction/hero. Alternatively, integrate its styling more closely with the overall page flow. + +2. **Call to Action (CTA) Feedback:** + * **Observation:** The "Submit Your Joke" button links to a Google Form. + * **Suggestion:** While the form itself will provide confirmation, consider adding a brief sentence near the button like, "Winners announced at the event!" or "Selected jokes shared on our social media!" to provide more context and incentive. + +## IV. Event Cards (Upcoming & Past) + +1. **Visual Consistency & Information Density:** + * **Observation:** Event cards display title, description, date, location, and an action button ("Attend" / "View Recap"). Some have sticker images. + * **Suggestion:** + * Ensure consistent sizing and alignment of elements within the cards, especially if description lengths vary significantly. + * For the sticker images on cards (e.g., `VanJS October 2024` image, `ref=s1e56`), ensure their placement and size feel intentional and don't overcrowd the card. If they are purely decorative, they could be more subtle. + * The date and location icons are good, ensure the text next to them is always clearly legible and well-aligned. + +2. **Clarity of "Sticker Images" in Event Cards:** + * **Observation:** Some event cards have an "VanJS October 2024" image (`ref=s1e56`) which seems to be a sticker. + * **Suggestion:** Ensure the purpose/meaning of these sticker images within the event cards is clear to the user or that they are primarily decorative. If they convey specific event themes, their visual style should support that. The current alt text for this sticker is its title, which is okay, but its visual role is worth considering. + +## V. Past Events - "Show More" Functionality + +1. **Visual Feedback for Hidden Content:** + * **Observation:** A "Show More" button loads more past events. + * **Suggestion:** Consider adding a visual cue that more events are available even before the button is clicked if it's not immediately obvious (e.g., a subtle fade-out at the bottom of the initially visible list). The current implementation (button appears if `pastEvents.length > 6`) is functional. + +## VI. "Join Our Discord" Section + +1. **CTA Prominence:** + * **Observation:** The Discord button is present with descriptive text. + * **Suggestion:** Ensure the Discord button is visually compelling and stands out as a clear call to action. The duck image placement is playful; ensure it doesn't distract from or awkwardly crowd the button on any screen size. + +## VII. FAQ Section + +1. **Readability of Accordion:** + * **Observation:** Uses a Radix-based accordion. + * **Suggestion:** Double-check the visual styling of the accordion (trigger and content areas). Ensure sufficient click target size for triggers, clear visual distinction between questions and answers, and that the open/close animation is smooth. The custom CSS for the accordion had some potential issues (e.g., `var(blue)` typo); ensure these are resolved for consistent styling. + +## VIII. Footer + +1. **Icon Clarity and Actionability:** + * **Observation:** The footer contains the VanJS logo and icons for Tickets, Meetup, and LinkedIn. + * **Suggestion:** Ensure the icons are clearly recognizable and that their clickable area is sufficient. If these are important links, give them enough visual space. Consider if text labels alongside or on hover could be beneficial, though the `title` attributes help. + +## IX. General Design & UX Considerations + +1. **Typography & Spacing:** + * **Suggestion:** Review overall typography (font sizes, line heights, font weights) for headings, paragraphs, and links to ensure a clear hierarchy and good readability. Pay attention to whitespace (margins, paddings) to avoid a cramped feel and to group related content effectively. + +2. **Color Palette & Contrast:** + * **Observation:** The primary brand color appears to be a vibrant yellow (`#FEB92F`). Other colors like `bg-muted`, `text-muted-foreground`, and black text are used. + * **Suggestion:** Ensure all text has sufficient contrast against its background, especially for `text-muted-foreground` on various backgrounds. The yellow, while vibrant, needs to be used carefully to ensure text on it is always legible. Use an online contrast checker tool. + +3. **Responsiveness & Consistency:** + * **Suggestion:** Thoroughly test the page across various screen sizes (mobile, tablet, desktop). Ensure: + * Layouts adapt gracefully. + * Text remains readable. + * Click targets are easy to hit. + * No content overflows or breaks. + * The visual experience is consistent and polished. + +4. **Visual Feedback on Interaction:** + * **Suggestion:** Ensure all interactive elements (links, buttons, accordion triggers) provide clear visual feedback on hover and focus states (e.g., underline, color change, outline). This is crucial for usability and accessibility. The `hover:underline` on nav links is good; ensure similar clear feedback everywhere. + +This list provides a starting point for design considerations. User testing with actual target audience members would be invaluable for identifying further UX improvements. \ No newline at end of file diff --git a/plan/dev.md b/plan/dev.md new file mode 100644 index 0000000..4805f35 --- /dev/null +++ b/plan/dev.md @@ -0,0 +1,114 @@ +# VanJS Development & CI Enhancement Plan + +This plan outlines suggestions for local development practices and Continuous Integration (CI) improvements to enhance code quality, developer experience, and site reliability for the VanJS website. + +## I. Local Development Environment Enhancements + +1. **Code Formatting with Prettier:** + * **Observation:** ESLint is configured (`next/core-web-vitals`), but a dedicated, opinionated formatter like Prettier is not explicitly integrated. + * **Suggestion:** Integrate Prettier for consistent code formatting across the project. This reduces cognitive load from style debates and makes diffs cleaner. + * **Action:** + * Install Prettier: `npm install --save-dev prettier eslint-config-prettier eslint-plugin-prettier` (or `yarn add --dev prettier eslint-config-prettier eslint-plugin-prettier`). + * Create a Prettier configuration file (e.g., `.prettierrc.json` or `.prettier.config.js`) with your preferred settings (or use defaults). + * Update `.eslintrc.json` to extend `eslint-config-prettier` (disables ESLint rules that conflict with Prettier). + * Optionally, add `eslint-plugin-prettier` to run Prettier as an ESLint rule. + * Encourage use of Prettier on save via editor integrations (e.g., VS Code Prettier extension). + +2. **Linting Staged Files with Husky & lint-staged:** + * **Suggestion:** Automate linting and formatting on pre-commit to catch issues early and ensure consistent code style before it enters the codebase. + * **Action:** + * Install Husky and lint-staged: `npm install --save-dev husky lint-staged` (or `yarn add --dev husky lint-staged`). + * Set up Husky hooks (e.g., `npx husky install`, then `npx husky add .husky/pre-commit "npx lint-staged"`). + * Configure `lint-staged` in `package.json` to run ESLint (with `--fix`) and Prettier (`--write`) on staged files. + ```json + // package.json (example lint-staged config) + "lint-staged": { + "*.{js,jsx,ts,tsx}": [ + "eslint --fix", + "prettier --write" + ], + "*.{json,md,css}": "prettier --write" + } + ``` + +3. **Type Checking (If/When Migrating to TypeScript):** + * **Observation:** Project is currently JavaScript. + * **Suggestion (Future):** If migrating to TypeScript, ensure `tsc --noEmit` is run as part of local checks (and CI) to catch type errors. + +4. **Dependency Management & Updates:** + * **Suggestion:** Regularly check for outdated dependencies to benefit from security patches, bug fixes, and new features. + * **Action:** + * Use `npm outdated` or `yarn outdated`. + * Consider tools like `npm-check-updates` for easier updating. + * Update dependencies systematically and test thoroughly after updates. + +5. **Environment Variables:** + * **Observation:** Currently, no obvious use of environment variables that require local setup (like API keys). + * **Suggestion:** If the site ever needs API keys or configurable settings, use a `.env.local` file (gitignored) for local development, and manage production/preview variables through your hosting provider (e.g., Vercel, Netlify, GitHub Pages secrets for Actions). + +## II. Testing Strategy + +1. **Component/Unit Tests:** + * **Observation:** No testing libraries currently in `package.json`. + * **Suggestion:** Introduce Jest and React Testing Library for testing individual components and utility functions. + * **Action:** + * Install: `npm install --save-dev jest @testing-library/react @testing-library/jest-dom jest-environment-jsdom` (or Yarn equivalent). + * Configure Jest (Next.js has built-in Jest configuration support, or you can create `jest.config.js`). + * Write tests for critical UI components (`EventCard`, `Header`, `AccordionFAQ`, etc.) to ensure they render correctly and handle props/state as expected. + +2. **End-to-End (E2E) Tests:** + * **Suggestion:** For ensuring key user flows work (e.g., navigation, form submissions if any, accordion interaction), consider E2E tests. + * **Action:** + * Choose a framework: Playwright (recommended by Microsoft, good Next.js support) or Cypress. + * Install and configure. + * Write tests for critical user paths (e.g., navigating to sections, opening/closing FAQ, checking links). + +3. **Visual Regression Testing (Optional but Beneficial):** + * **Suggestion:** For projects where visual consistency is paramount, visual regression testing can catch unintended UI changes. + * **Tools:** Percy, Chromatic (often integrates with Storybook). + +## III. Continuous Integration (CI) Enhancements + +* **Current CI:** A `.github/workflows` directory exists, but specific CI setup was not reviewed. +* **Assumptions:** Likely uses GitHub Actions for build/deployment (common for Next.js on GitHub Pages/Vercel). + +1. **Linting & Formatting Check:** + * **Action:** Add a CI step to run ESLint and Prettier (check-only mode, e.g., `prettier --check .`) on every push and pull request. Fail the build if issues are found. + * **Goal:** Enforce code style and catch lint errors automatically. + +2. **Run Tests (Unit & E2E):** + * **Action:** Add CI steps to execute all unit tests and E2E tests on every push to the main branch and on pull requests. + * **Goal:** Prevent regressions and ensure new code doesn't break existing functionality. + +3. **Build Check:** + * **Action:** Ensure the `next build` (and `next export` if applicable for static export) command runs successfully in CI. + * **Goal:** Catch build errors before deployment. + +4. **Dependency Vulnerability Scanning:** + * **Action:** Integrate a tool like `npm audit --audit-level=moderate` or GitHub's Dependabot alerts/scanning into CI. + * **Goal:** Get notified about security vulnerabilities in dependencies. + +5. **Lighthouse CI (Optional but Recommended for Performance/Accessibility):** + * **Action:** Use Lighthouse CI (e.g., `@lhci/cli` with GitHub Actions) to run Lighthouse audits automatically on pull requests or after deployments to a staging/preview environment. + * **Goal:** Track performance, accessibility, SEO, and best practice scores over time and prevent regressions in these areas. + * Set performance budgets to fail builds if metrics drop below thresholds. + +6. **Deployment Strategy:** + * **Suggestion:** Ensure a clear deployment strategy: + * **Preview Deployments:** For every PR, automatically deploy to a preview environment (Vercel and Netlify do this by default for Next.js apps). + * **Production Deployment:** Triggered by merges to the main branch after all checks pass. + +7. **Bundle Size Monitoring:** + * **Suggestion:** Use tools like `@next/bundle-analyzer` (can be run locally or in CI) or other bundle size checkers to monitor JavaScript bundle sizes. + * **Goal:** Prevent accidental inclusion of large libraries or code that negatively impacts load performance. + +## IV. Developer Experience (DX) + +1. **Storybook (For Component Development):** + * **Suggestion:** Consider using Storybook to develop UI components in isolation. This can improve development speed, testing, and visual documentation of components. + * **Action:** Install and configure Storybook for your Next.js project. + +2. **Clear README & Contribution Guidelines:** + * **Suggestion:** Enhance `README.md` with more project-specific setup instructions, contribution guidelines (if applicable for open source), and a brief overview of the project architecture. + +By implementing these development practices and CI checks, the VanJS project can achieve higher code quality, fewer bugs, better performance, and a more reliable and maintainable website. diff --git a/plan/github_issues_integration.md b/plan/github_issues_integration.md new file mode 100644 index 0000000..c66e9f7 --- /dev/null +++ b/plan/github_issues_integration.md @@ -0,0 +1,110 @@ +# VanJS Website: GitHub Issues Integration for Talk Proposals + +This plan outlines a system for leveraging GitHub Issues as a backend to manage talk proposals and allow potential speakers to sign up via the VanJS website. + +## I. Core Concept + +The goal is to create a transparent, developer-friendly workflow where: +1. Talk ideas and calls for speakers are managed as GitHub Issues. +2. These issues are dynamically displayed on the VanJS website. +3. Interested individuals can express their interest or "sign up" to speak on a topic via a form on the website. +4. This interaction (optionally) updates the corresponding GitHub Issue. + +## II. Workflow Details + +**1. GitHub Issue Management (The "Backend")** + +* **Repository:** Use a designated GitHub repository (e.g., `VanJS/meetup` or a new `VanJS/talk-proposals`). +* **Issue Template:** Implement a GitHub Issue Template to standardize proposal submissions. Key fields: + * `Title:` (Proposed Talk Title) + * `Speaker Name / GitHub Handle:` (e.g., @yourhandle) + * `Abstract/Summary:` (Brief overview of the talk) + * `Estimated Duration:` (e.g., 20 mins, 40 mins, Lightning Talk - 10 mins) + * `Target Audience Level:` (e.g., Beginner, Intermediate, Advanced, All) + * `Tags/Keywords:` (e.g., React, Performance, Accessibility, WebAssembly) + * `Notes for Organizers:` (Optional, internal notes) +* **Labels for Status Management:** Utilize GitHub labels extensively: + * `type:talk-proposal` (To identify all talk proposals) + * `status:new` (Newly submitted proposal) + * `status:needs-speaker` (A topic VanJS wants, but needs someone to present) + * `status:speaker-interested` (Someone expressed interest via the website) + * `status:under-review` (Organizers are reviewing the proposal/speaker match) + * `status:accepted` (Proposal accepted) + * `status:declined` (Proposal declined) + * `status:scheduled` (Talk is scheduled for an event) + * `event:[event-id/date]` (e.g., `event:2024-03-20` - if scheduled) + * Topic-specific tags (e.g., `topic:react`, `topic:testing`, `topic:ai`) + +**2. Displaying Talk Proposals on VanJS Website** + +* **Data Source:** GitHub API. +* **Fetching:** + * During the Next.js build (`getStaticProps` or ISR for a `/talks` or `/speak` page), fetch issues from the designated repository. + * Filter issues by relevant labels (e.g., `type:talk-proposal` AND (`status:new` OR `status:needs-speaker` OR `status:speaker-interested`)). + * Requires a GitHub API token (PAT or GitHub App token) stored securely as an environment variable (e.g., `GITHUB_TOKEN`). +* **Display:** + * List available talk topics/proposals. + * For each, show: Title, (partial) Abstract, relevant tags/labels (like topic and duration). + * If the issue has a `status:needs-speaker` or `status:new` (and is open for others to claim), display a prominent "Sign Up to Speak" or "I'm Interested!" button. + +**3. Website Form for Speaker Sign-up** + +* **Trigger:** User clicks the "Sign Up to Speak" button next to a specific talk proposal. +* **Form Fields:** + * Name + * Email Address + * GitHub Handle (Optional, but encouraged) + * A (potentially hidden) field carrying the GitHub Issue ID/Number they are interested in. + * Brief message (e.g., "Why you'd be great for this talk / your relevant experience"). +* **Form Submission Handling:** + * **Option A (Manual - Simplest Start):** + * The form uses a `mailto:` link that pre-fills an email to VanJS organizers with the talk details and speaker info. + * Organizers manually update the GitHub issue (assign speaker, change label to `status:speaker-interested` or `status:under-review`). + * **Option B (Third-Party Forms):** + * Submit to a service like Netlify Forms, Vercel Forms, Tally.so, or Google Forms. + * Organizers receive notifications and manually update the GitHub issue. + * **Option C (Automated GitHub Interaction - Advanced):** + * Form submits to a Next.js API Route (requires moving beyond pure static export for this interaction). + * The API route, using an authenticated GitHub client (GitHub App preferred): + 1. Receives form data. + 2. Comments on the specified GitHub Issue: e.g., "@speaker-handle has expressed interest in speaking on this topic via the VanJS website! Contact: [email]. Message: [message]." + 3. Changes the issue label (e.g., to `status:speaker-interested`). + 4. (Optional) Assigns the issue to the speaker if their GitHub handle was provided and validated. + 5. Sends a notification to organizers (e.g., email or Discord message). + +## III. Technical Implementation Steps (High-Level) + +1. **Setup GitHub Repository & Issue Process:** + * Define issue template. + * Define label set. + * Train organizers on the new workflow. +2. **Develop GitHub API Fetching Logic:** + * Securely store GitHub token (`GITHUB_TOKEN` environment variable). + * Write script/function (e.g., in `lib/github.js`) to fetch and parse issues using `node-fetch` or a GitHub client library (like Octokit). +3. **Create Talk Proposal Display Page/Section in Next.js:** + * Use `getStaticProps` or ISR to fetch data via the logic from step 2. + * Design UI components to display proposals and the "Sign Up" button. +4. **Implement Speaker Sign-Up Form:** + * Choose submission handling option (A, B, or C). + * Build the form component. + * If Option C, develop the Next.js API Route with GitHub API write capabilities. +5. **Styling & UX:** + * Ensure the process is clear and user-friendly for potential speakers. + * Provide clear feedback on form submission. + +## IV. Benefits + +* **Transparency:** Call for papers and available topics are public. +* **Developer-Friendly:** Uses a platform (GitHub) familiar to most developers. +* **Reduced Organizer Overhead (especially with Option C):** Automates parts of the speaker interest tracking. +* **Dynamic Content:** Website can showcase active calls for speakers. +* **Single Source of Truth:** GitHub issues remain the canonical source for talk proposal status. + +## V. Considerations & Future Enhancements + +* **Static Site Limitations:** Full automation (Option C) requires server-side logic, impacting the pure `output: "export"` model. Consider ISR for the talk list page if it needs to be more frequently updated than full rebuilds allow. +* **GitHub API Rate Limits:** Cache API responses during build or use conditional requests (ETags) if fetching frequently. +* **User Authentication (for speakers):** Not strictly necessary for initial sign-up, but a more advanced version could allow speakers to log in with GitHub to claim/manage their proposals directly (much more complex). +* **Filtering/Sorting:** Allow users to filter displayed talk proposals by tags on the website. + +This integration offers a robust way to manage talk proposals and engage the community in shaping the content of VanJS meetups. diff --git a/plan/integrations.md b/plan/integrations.md new file mode 100644 index 0000000..9ffd71a --- /dev/null +++ b/plan/integrations.md @@ -0,0 +1,85 @@ +# VanJS Website Integration Ideas + +This plan explores potential integrations the VanJS website could leverage to automate content, enhance user experience, and showcase community activity more dynamically. + +## I. Event Management & Automation (Luma Focus) + +* **Current System:** Event data is manually maintained in `src/data/events.js` with links to Luma for RSVP and details. + +1. **Automated Event Population from Luma API:** + * **Concept:** Instead of manually updating `events.js`, use the Luma API to fetch upcoming and past event data directly. + * **Feasibility & Action:** + * **Luma API Access:** Investigate if Luma provides a public API or an API suitable for this kind of data fetching. This is the primary prerequisite. + * **Data Fetching:** If an API is available, during the Next.js build process (`getStaticProps` or server-side generation if moving away from static export for this), fetch event data. + * **Data Mapping:** Map the API response fields to the structure your `EventCard` and `PastEvents` components expect (title, date, location, description, Luma link). + * **Benefits:** Ensures event listings are always up-to-date without manual intervention, reduces errors, saves organizer time. + * **Considerations:** API rate limits, error handling if the API is down, data transformation logic. + + Notes: + - Example: https://github.com/luma-team/basketball-club-example + - Get Events: https://docs.lu.ma/reference/get_public-v1-calendar-list-events + - Get Event: https://docs.lu.ma/reference/get_public-v1-event-get + +2. **Displaying RSVP Counts or Attendee Information (from Luma):** + * **Concept:** If the Luma API allows, fetch and display the number of RSVPs for upcoming events, or even a (privacy-respecting) list/avatar grid of attendees. + * **Benefit:** Can create a sense of buzz and encourage more sign-ups. + * **Considerations:** Privacy (only show public attendee info if Luma API supports this and users have consented), API capabilities. + +## II. Community Engagement & Social Proof + +1. **Displaying Event Feedback/Testimonials:** + * **Concept:** Showcase positive feedback or testimonials from past events directly on the website. + * **Sources & Actions:** + * **Post-Event Surveys:** If you send out feedback surveys (e.g., via Google Forms, Luma, or another tool), manually curate the best anonymous quotes and add them to a dedicated section or rotate them on the homepage. + * **Luma Comments/Reviews:** If Luma has a public review/comment system for events, investigate if its API (if available) could pull these in. Alternatively, manually curate. + * **Social Media Mentions:** Monitor social media (Twitter, LinkedIn) for positive mentions of VanJS. With permission, these could be embedded or quoted. + * **Benefit:** Powerful social proof that encourages new people to attend. + +2. **Joke Submissions & Display (from Google Forms):** + * **Current System:** Jokes are submitted via a Google Form. + * **Concept (Manual Curation):** Manually select the best/featured jokes from Google Form responses and display them on the site (e.g., a "Joke of the Month" section or rotating jokes). + * **Concept (Automation - Advanced):** + * Use Google Apps Script or a third-party tool (like Zapier/Integromat if suitable) to fetch new joke submissions from the Google Sheet linked to your form. + * Implement a simple review/approval system (could be as basic as a flag in the Sheet). + * Fetch approved jokes to display on the site (would likely require moving beyond a purely static export for this dynamic part, or a build-time fetch if jokes are updated infrequently). + * **Benefit:** Makes the "Make Us LOL!" section more dynamic and rewarding. + +3. **Discord Integration (Beyond a Link):** + * **Current System:** Link to Discord server. + * **Concept (Widget/Preview):** Embed a Discord widget (if one exists that meets your needs and privacy standards) to show server status (online members) or a preview of recent public channel activity. + * **Benefit:** Makes the Discord community feel more alive and accessible directly from the website. + * **Tools:** Check services like WidgetBot or look for official Discord embed options. + * **Considerations:** Privacy of messages, visual integration with the site design. + +## III. Content & Learning Resources + +1. **Speaker Profiles & Talk Archives:** + * **Concept:** If the "Speakers" section is developed, and with speaker permission: + * Create simple profiles for past/upcoming speakers (name, photo, bio, social links). + * Link to slides (GitHub, Speaker Deck) or video recordings (YouTube, Vimeo) of past talks. + * **Benefit:** Turns the website into a more valuable learning resource, showcases community talent, and gives speakers more visibility. + * **Action (Manual/Semi-Automated):** Collect this information from speakers. Can be stored in a structured data file (e.g., `speakers.js`) or fetched if an API source becomes available (e.g., from Luma if it supports speaker data associated with events). + +2. **Blog/Community Showcase:** + * **Concept (Future Growth):** Consider adding a simple blog or a section to showcase projects, articles, or open-source contributions from the VanJS community members. + * **Benefit:** Further positions VanJS as a hub for Vancouver's dev talent and provides more content for SEO and engagement. + * **Action:** This would be a larger undertaking, likely requiring a headless CMS or a system for community submissions and curation. + +## IV. Technical Integration Considerations + +* **Static Site vs. Dynamic Features:** Many advanced integrations (especially real-time data fetching or user-generated content display) might require moving parts of the site beyond a simple static export (`output: "export"`). This could involve: + * Using Next.js API routes for backend logic (e.g., fetching from external APIs, processing form data if not using a third-party service). + * Using Incremental Static Regeneration (ISR) or Server-Side Rendering (SSR) for pages that need to display frequently updated data from APIs. + * Using a headless CMS. +* **API Keys & Security:** If integrating with APIs that require authentication, ensure API keys are handled securely (e.g., using environment variables on the server-side or during build, never exposing them client-side). +* **Rate Limiting & Error Handling:** Be mindful of API rate limits and implement robust error handling for any external data fetching. + +**Starting Points:** + +* **Easiest Wins (Manual/Low-Tech):** + * Manually curating and adding testimonials/feedback. + * Manually selecting and displaying featured jokes. +* **High-Impact API Integration (If Luma API Exists & is Suitable):** + * Automating event listings from Luma. + +Investigating the Luma API capabilities should be a priority if event automation is a key goal. diff --git a/plan/plan.md b/plan/plan.md new file mode 100644 index 0000000..496e00a --- /dev/null +++ b/plan/plan.md @@ -0,0 +1,124 @@ +# Website Improvement Plan for VanJS + +This document outlines actionable steps to improve the VanJS website, based on a review of the codebase and live site functionality. + +## I. Performance & Optimization + +1. **Manual Image Optimization (High Priority):** + * **Context:** `next.config.mjs` has `images: { unoptimized: true }`. This means Next.js image optimization is disabled. + * **Action:** Manually optimize all raster images (`.png`, `.jpg`) in the `public/` directory. Use tools like Squoosh, TinyPNG, or ImageOptim. Focus on: + * `public/hero.jpg` (Likely LCP element) + * `public/ducky.png` + * `public/JasonLaughing.png` + * `public/JasonNerd.png` + * `public/VanJS.png` + * Event sticker images (e.g., `public/beerjs.png`, `public/santa.png`) + * **Goal:** Reduce file sizes to improve LCP and overall load times. + +2. **SVG Optimization:** + * **Action:** Minify SVG files in `public/` (e.g., `tickets.svg`, `meetup.svg`, `linkedin.svg`, `discord.svg` if used by `bg-discord-image`) using a tool like SVGO. + * **Goal:** Reduce file sizes of vector assets. + +3. **Review LCP (Largest Contentful Paint):** + * **Context:** Mobile LCP was 2.5s, which is on the edge of "good". + * **Action:** After image optimization, re-test LCP. If `public/hero.jpg` is the LCP, ensure it's preloaded if possible or not deferred. Since it's a static export, server-side preloading hints are limited, but ensuring the image tag is high in the DOM and not blocked by CSS/JS can help. + +## II. Accessibility (A11y) + +1. **Image Alt Text:** + * **`src/app/page.jsx`:** + * `hero.jpg`: Change `alt="Hero"` to be descriptive of the image content. + * `ducky.png`: Consider `alt="VanJS mascot duck"` for the first instance. For purely decorative uses (e.g., near "Discord" or "FAQs" headings if context is clear), `alt=""` might be acceptable if an A11y expert confirms. + * **`src/components/EventCard.jsx`:** + * Sticker Image: Replace hardcoded `alt="VanJS October 2024"` with dynamic alt text (e.g., `alt={\`Sticker for \${title}\`}`) or `alt=""` if purely decorative and event title provides context. Consider adding an `stickerAlt` field to event data. + * **`src/components/Footer.jsx`:** + * Social Icons (`tickets.svg`, `meetup.svg`, `linkedin.svg`): If the `title` attribute on the `Link` is considered sufficient, these could use `alt=""`. Otherwise, ensure current alt text is the best description. + +2. **Mobile Navigation (High Priority):** + * **`src/components/Header.jsx`:** + * **Action:** Implement a mobile-friendly navigation menu (e.g., hamburger menu) to provide access to all navigation links on smaller screens. + +3. **Link Attributes:** + * **Action:** Add `rel="noopener noreferrer"` to all `Link` components that use `target="_blank"`. + * `src/components/EventCard.jsx` (Attend/View Recap buttons) + * `src/components/Jokes.jsx` (Submit Your Joke button) + * `src/components/Header.jsx` (Attend button) + * `src/components/Footer.jsx` (Social links, if changed to `target="_blank"`) + +4. **Accordion CSS Reset:** + * **`src/components/ui/accordion/styles.css`:** + * **Action:** Re-evaluate the aggressive `all: unset;` on `button, h3`. Test for any negative impacts on focus indicators or default accessibility styling. Consider removing if Tailwind's preflight is sufficient. + +5. **Contrast Ratios:** + * **Action:** Use browser developer tools to check text contrast ratios, especially for: + * Text on `bg-[#FEB92F]` (VanJS yellow background). + * Text on `bg-muted`. + * Links with `className="text-black"` against their backgrounds in `src/app/page.jsx`. + * Paragraph text in `Jokes.jsx` with `bg-[#ffffff8c]` (semi-transparent white). + +## III. Code & Component Structure + +1. **Styling Consistency & Simplification:** + * **`src/components/ui/accordion/styles.css`:** + * Fix `background-color: var(blue);` typo in `:hover` state. + * Verify definition of `--violet-11` or replace. + * Migrate simple styles (padding, font-size, etc.) to Tailwind utility classes in `index.jsx` to reduce custom CSS. + * **Accordion Animations:** + * Consolidate accordion animations. The animations in `tailwind.config.js` should be sufficient if using Shadcn/UI components correctly. Remove redundant keyframes from `src/components/ui/accordion/styles.css`. + * **`src/components/Header.jsx` & `src/components/Footer.jsx` (Logo Image Style):** + * Remove redundant inline `style={{ height: "64px" }}` on the logo `Image` component if `height={64}` prop is used. Use Tailwind for sizing or ensure `width`/`height` props reflect true aspect ratio. + * **`src/components/Footer.jsx` (Icon Image Styles):** + * Review inline `objectFit` and `borderRadius` styles on SVG icons. Use Tailwind classes if possible. + * **`src/components/Jokes.jsx` (Shadow Style):** + * Clarify/simplify `shadow-[0_0_10px_#00000033] shadow-white` on the paragraph. + * **`src/components/PastEvents.jsx` (Button Style):** + * Consider using the standard `Button` component from `@/components/ui/button` for the "Show More/Less" button for visual consistency. + +2. **Data Structure Enhancements (`src/data/events.js`):** + * **Action (Recommended):** + * Add an `isoDate` field (ISO 8601 format) to event objects for better machine readability (SEO, sorting). + * Structure `location` into an object (e.g., `{ name: "Venue", address: "Details", mapLink: "..." }`) for richer data and Schema.org. + * **Goal:** Improve data robustness for SEO (Schema.org) and future display needs. + +3. **Component Logic & Cleanup:** + * **`src/components/Jokes.jsx`:** Remove the empty `` tag and the commented-out `
` tag. + * **`src/app/page.jsx`:** Remove empty comment ` {/* */}`. + * **`src/components/Header.jsx`:** Address the "Speakers" nav link which points to a non-existent section (remove or mark as upcoming). + * **`src/components/PastEvents.jsx` (Fade-in Animation):** + * If the `fade-in` effect is desired, define the CSS classes (`.fade-in`, `.show`) in global or component-specific CSS. + +4. **Dark Mode Strategy (`tailwind.config.js`):** + * **Action:** Decide if dark mode is a planned feature. If not, set `darkMode: false`. If yes, plan for implementation and testing. + +## IV. Potential Future Enhancements + +1. **Add Testing:** + * **Action:** Introduce testing libraries (e.g., Jest, React Testing Library for components; Playwright/Cypress for E2E). + * **Goal:** Improve code quality, prevent regressions. + +2. **Code Formatting with Prettier:** + * **Action:** Integrate Prettier with ESLint for consistent code formatting. + * **Goal:** Improve code readability and maintainability. + +3. **Structured Data (Schema.org):** + * **Action:** Implement Schema.org markup for Events (using the enhanced `isoDate` and structured `location` from `events.js`) to improve SEO and search result appearance. This can be done by outputting a `