Hello Jakub,
Thanks for kicking this off. the initial fields you’ve suggested (Title, Summary, HTML Content, Store URL, and Featured Image) provide a solid foundation. I see from #general message that you went further in right direction. I’d like to propose a few additional fields to support better categorization, filtering, and reusability of content across the frontend:
Additional Case Study Fields
- Business Name – The merchant’s brand name for clear attribution.
- Business Logo – It would be good to have it, so that this logo can be used on different visual blocks throughout website.
- Platform – Select box with values like Magento Open Source, Mage-OS, etc.
- Industry Vertical – Select box with predefined choices (e.g., Fashion, Automotive, Electronics). This enables us to build industry-specific landing pages.
- Business Model – A text area describing how the business operates inspired by examples like the Hajduk Split FC case study on Hyvä.
- Focus Country / Region – Select box, Useful for regional relevance and localization.
- Business Type Classification – Select box (e.g., B2B, B2C, B2G).
- Extension Vendor Tracking – Multi-select field referencing vendors or specific extensions used.
- Key Results – Up to 5 short input fields to highlight measurable outcomes. This encourages concise and impactful storytelling, and allows for consistent frontend presentation.
- Agency – I suggest that only Magento Association Mambers can post case studies, this field should be a relation to an agency/member
Testimonials
I’d suggest we either:
Treat testimonials as a dedicated entity, allowing multiple testimonials per case study (e.g., from the client, agency, or developers), OR
Handle them as structured CMS blocks if simplicity is preferred.
If we go with a dedicated entity, I propose these fields:
- Testimonial Author Name – e.g., Client’s representative
- Testimonial Author Link (optional) – LinkedIn, website, etc.
- Testimonial Content
- Testimonial Avatar Image – Square, 512x512
This structure allows testimonials to be reused in other contexts, such as filtered showcases (e.g., B2B client testimonials), or pulled dynamically into relevant landing pages.
Open Graph tags
It would be good to have separate open graph tags for:
- og:title
- og:image
- og:description
Just in case moderator wants to share og tags differently. However, in case they are empty, default previously entered data should be used.
Hello Jakub,
Thanks for kicking this off. the initial fields you’ve suggested (Title, Summary, HTML Content, Store URL, and Featured Image) provide a solid foundation. I see from #general message that you went further in right direction. I’d like to propose a few additional fields to support better categorization, filtering, and reusability of content across the frontend:
Additional Case Study Fields
Testimonials
I’d suggest we either:
Treat testimonials as a dedicated entity, allowing multiple testimonials per case study (e.g., from the client, agency, or developers), OR
Handle them as structured CMS blocks if simplicity is preferred.
If we go with a dedicated entity, I propose these fields:
This structure allows testimonials to be reused in other contexts, such as filtered showcases (e.g., B2B client testimonials), or pulled dynamically into relevant landing pages.
Open Graph tags
It would be good to have separate open graph tags for:
Just in case moderator wants to share og tags differently. However, in case they are empty, default previously entered data should be used.