Knowledge Base Page Sidebar

Users currently lack a way to easily browse and navigate between topics within the knowledge base. Without a sidebar, they must return to a main index or scroll through long pages, leading to a frustrating experience and reduced content discoverability. When do they experience this issue? Anytime users are reading an article and want to move to another related topic or section without starting over. 💡 Proposed Solution How are we solving this problem? Implement a sticky sidebar on all knowledge base article pages that lists key categories and articles. This sidebar will allow users to browse related content without leaving the page. Alternatives considered - Top navigation tabs were considered but found to be less intuitive on mobile and harder to scale with growing content. What is the general shape of this solution? The sidebar will be positioned to the left (or collapsible on mobile), listing categories and expandable items under each category to show related articles. Mockups, prototypes, or comparisons [Insert link or image of wireframes or design mockups for the sidebar] How will we know if this is successful? Increased article views per session, reduced time-to-resolution for common questions, and reduced support ticket volume. Performance considerations Sidebar should be lightweight and cached efficiently to avoid slowing down page load times, especially on mobile. 📅 Development Plan What are we building? A collapsible, responsive sidebar for the knowledge base that dynamically loads article categories and links. How will it work? - On page load, the sidebar will fetch the latest category/article structure. - Articles will be nested under categories, and clicking will navigate directly to that article without leaving the knowledge base. - The sidebar will remain visible (or collapsible) as users scroll. How will we ensure it works? We will test across screen sizes, ensure accessibility (keyboard nav + screen reader support), and test integration with the content management system. When will it be ready? MVP ready for internal testing in 2 weeks; public rollout within 3–4 weeks. 🏁 Launch Checklist 1. Internal Alignment - [ ] Can we clearly explain what this change is? - [ ] Have we shared the details of this change with relevant teams (support, product, engineering)? 2. External Messaging - [ ] Will users be aware of this new sidebar feature? - [ ] Does any help documentation need to be updated? 3. Quality Assurance - [ ] Has the feature been tested across browsers and devices? - [ ] Is the sidebar accessible and responsive? 4. Metrics & Measurement - [ ] Do we know what success looks like and how to track it? - [ ] Are dashboards or alerts configured? 5. Launch Plan - [ ] Stakeholders aligned? - [ ] Content in sidebar final and accurate? - [ ] CMS and sidebar integration tested? 🛠 Additional Notes or Requirements - Dependencies: Content team to finalize and structure article categories. - Risks: Potential for outdated links if articles are moved or renamed; mitigate with real-time syncing to CMS.

Content Row Pagination

Currently, our website displays three recent article cards in a static row. This approach becomes inefficient when there are more articles, as users cannot easily browse or navigate through older content. It creates a poor user experience, especially for those interested in exploring more than just the three most recent articles. Who is affected by this problem?   End-users browsing the website for recent articles, especially those interested in older content. When do they experience this issue?   This problem arises when users scroll through the articles section and cannot access older articles beyond the three most recent. Why is this important or urgent?   Solving this will improve the user experience by allowing visitors to engage with more content, increasing the time spent on the site and reducing bounce rates. 💡 Proposed Solution How are we solving this problem?   Introduce pagination to the article section, allowing users to view more articles by clicking through pages or using infinite scrolling. Alternatives considered   - Infinite scrolling was considered, but we opted for traditional pagination for simplicity and better performance on mobile devices. What is the general shape of this solution?   The article section will display a fixed number of articles per page, and users can navigate through pages using "Next" and "Previous" buttons. Mockups, prototypes, or comparisons   📅 Development Plan What are we building?   We will develop a pagination feature that allows users to navigate through multiple pages of article cards in the recent articles section. How will it work?   The page will load a set number of articles (e.g., 3 or 5), with navigation buttons to move between pages. How will we ensure it works?   We will conduct thorough testing across browsers and devices, ensuring that pagination functions correctly across different screen sizes and that performance remains optimal. When will it be ready?   The feature is expected to be ready for internal testing within 1 week, with a public launch within 2 weeks. 🛠 Additional Notes or Requirements   - Dependencies: None identified at the moment.   - Risks: Potential for slower page load times with larger content volumes; mitigated by pagination's performance focus.

Update DMARC record

Authenticatie van E-maildomein voor Mailchimp We willen ons e-maildomein authenticeren voor Mailchimp, maar ontvangen een foutmelding dat er al een DMARC-record bestaat. Mailchimp vraagt ons dit record te verwijderen. Urgentie De authenticatie van ons e-maildomein is cruciaal voor Mailchimp en onze e-mailcampagnes. Huidige Situatie E-maildomein: factordelta.nl Huidige DMARC-instelling: Er is een DMARC-record, maar we hebben geen inzicht in de configuratie. Vragen Is het huidige DMARC-record voor Postmark? DMARC Records zijn over het algemeen niet verbonden aan een enkele dienst maar worden gebruikt om alle e-mailverkeer te beschermen. Het huidige DMARC-record kan dus voor meerdere diensten worden gebruikt, inclusief Postmark. Het is alleen belangrijk dat er geen dubbele / conflicterende regels in staan. Gevolgen van het verwijderen van het oude DMARC-record Het verwijderen van het oude DMARC-record zou geen probleem moeten zijn. Postmark heeft geen expliciete vereisten voor het gebruik van p=quarantine, ze accepteren zowel 'none' als 'quarantine' Oplossing Overbodige regel "v=DMARC1; p=quarantine;" verwijderen Momenteel zijn er twee DMARC-records voor het domein. De p=quarantine-regel, ingesteld tijdens de PostMark-configuratie, kan worden verwijderd. We kunnen p=none gebruiken in plaats daarvan.