Brand Playbook Web App -- 2
Budget: $250 – $750 USD
Design System, Brand Kit, & Brand Guidelines AIO
Placeholder and incomplete bids will be rejected on-face without additional communication! Please use the clarification board if there is a gap blocking a real bid proposal. Ideally your bid proposal can be immediately awarded without further negotiation. Please read the following proposal requirements as well as the complete project requirements before bidding. These strict requirements seem unfortunate, but after receiving tons of seeming automatic and fake bids, this will help focus efforts on only the legitimate bid proposals.
*Proposal Requirements*
This project is small enough there will be only one payment and it will be made immediately upon verification of project completion and specification. The proposal accepts a 5% total bid penalty for each day the project is late to help incentive priority and a timeline that can be counted upon. This requirement may not be compatible with freelancers who have not done similar projects before.
Along with the fixed price and time, bid proposals need to have:
- A github or gitlab link to a similar static site generation project you have done using Gatsby, Astro, NextJS, Remix, or Fresh. Alternatively, if you are taking on this project to learn Astro and SSG, please provide a URL to a git MR/PR that shows off your development skills (preferably a web app using FP style Typescript) and to a design project in Figma or Penpot.
- A list of the “Optional Functionally” items with each marked as included in the proposals pierce, included for additional time and price, or not included at all. Included items need to be accomplished by a description of how it will be implemented.
Project delivery will be a git repo of the software with a README.md that describes how to configure, build, test, and publish the web app as well as the CICD tasks and flows if the CICD option is implemented.
*Project Summary*
A whitelabel Astro documentation web app tailored for the specific Brand Playbook purpose of a design system, brand kit, and brand guidelines all-in-one with git-style asset management, git powered CMS, and tight Storybook integration.
The quality and end user experience should meet or exceed that found in the Project Inspiration References (PIR).
*Project Inspiration References*
https://seeds.sproutsocial.com
https://atlassian.design/
*Required Functionality*
Elegantly presents and facilitates collaboration on the Design System, Brand Kit, and Brand Guidelines that is on par with the PIR.
Brand components include all of those found at PIR. Brand components include elements such as values, logo variation, imagery style. Not every instance of the Brand Playbook will include every component.
Just as UI components are tokenized, the Brand components should be tokenized. UI competent tokens are defined by the UI component library used in the Playbook and do not need to be separately defined. The context of the brand component tokenization is three fold:
- Implementers should be able to have a fully functional web app by just configuring the brand tokens and theme tokens - not unlike creating a Material Design theme.
- It is expected that we will need machine readable markup and schema for integration into future projects.
- UI Component libraries that use tokens are more robust and easier to adopt and we expect the same advantages for Brand components. A UI example can be viewed at https://m3.material.io/foundations/design-tokens/ and https://carbondesignsystem.com/guidelines/color/tokens/
Playbook content entries are made in MDX and MD, with decap CMS integration.
Seamlessly embed a composed Storybook into the app. This embedded Storybook will only be used to compose other Storybooks in order to display the UI components alongside the rest of the Brand Playbook and does not need to support testing or development workflows - those activities would be accomplished at the source Storybooks. For this project delivery, compose these three Storybooks into the embedded Storybook:
- Remote Carbon Design Web Components
- Local marketing only components
- Local custom UI components
The project git repo has two Storybooks apps alongside the Playbook app where marking only components such as landing pages and custom UI components are developed and tested.
Auto configured for analytics and RUM via Grafana Faro.
Instances of the web app can be easily updated when there are new features or fixes from upstream. Preferably via semver node modules.
Optional Functionality
- Internationalization via astro-i18next
- Brand components could be rendered with a JSON-LD Schema
- Changelog - mini blog with RSS Feed
- Requiring authorizations for private content
- CICD: devcontainer.json, GitHub Workflows, Review Apps, BunJS, moonrepo or buck2, and hosting on GCS, Firebase or Fly, etc.
*Technical Implementation*
Astro, shipping minimal JavaScript. No JS, including Faro on the homepage is feasible. Other pages do have JS for the embedded Storybook, perhaps, search, and for comments if implemented. In these other cases, the JS should be dynamically loaded.
Extending @astrojs/starlight [1] for a brand playbook is a quite attractive direction, but is not required.
Strict TypeScript without null or any. Emphasize the functional programming paradigm and avoid OPP. An FP library is not required but fp-ts is welcomed more concerned with using JS built-ins such as a map rather than a switch, no nested branches, reduce, no try/catch/throw, pure functions, use of eslint-plugin-functional, etc.
The two Storybooks and the Playbook app do not need to use a monorepo task runner unless the CICD option is implemented, but PNPM should be used rather than npm, yarn, or others.
Example of Astro and Decap integration [2]. Use of Cloudinary’s DAM is welcome.
TailwindCSS, prefer htmlx for interactivity.
HATEOS is preferred but if JS state is really needed, interested in using nanostores.
Pagefind or similar for search. Astro with Pagefind example [3].
The usual suspects such as: astro-auto-import, astro-seo, astro-compress, @astrojs/sitemap, @astrojs/rss, astro-icon, @astrojs/tailwindcss, swiper, @tailwindcss/forms, @tailwindcss/typograph, @astrojs/mdx, astro-imagetools, astro-robots-txt
The three referenced Astro projects should be quite informative to this implementation:
- [1] https://starlight.astro.build/
- [2] https://github.com/zankhq/astros
- [3] https://github.com/chrismwilliams/astro-theme-cactus
Thank you, I look forward to hearing from you and I hope this project will be meaningful to you.
Placeholder and incomplete bids will be rejected on-face without additional communication! Please use the clarification board if there is a gap blocking a real bid proposal. Ideally your bid proposal can be immediately awarded without further negotiation. Please read the following proposal requirements as well as the complete project requirements before bidding. These strict requirements seem unfortunate, but after receiving tons of seeming automatic and fake bids, this will help focus efforts on only the legitimate bid proposals.
*Proposal Requirements*
This project is small enough there will be only one payment and it will be made immediately upon verification of project completion and specification. The proposal accepts a 5% total bid penalty for each day the project is late to help incentive priority and a timeline that can be counted upon. This requirement may not be compatible with freelancers who have not done similar projects before.
Along with the fixed price and time, bid proposals need to have:
- A github or gitlab link to a similar static site generation project you have done using Gatsby, Astro, NextJS, Remix, or Fresh. Alternatively, if you are taking on this project to learn Astro and SSG, please provide a URL to a git MR/PR that shows off your development skills (preferably a web app using FP style Typescript) and to a design project in Figma or Penpot.
- A list of the “Optional Functionally” items with each marked as included in the proposals pierce, included for additional time and price, or not included at all. Included items need to be accomplished by a description of how it will be implemented.
Project delivery will be a git repo of the software with a README.md that describes how to configure, build, test, and publish the web app as well as the CICD tasks and flows if the CICD option is implemented.
*Project Summary*
A whitelabel Astro documentation web app tailored for the specific Brand Playbook purpose of a design system, brand kit, and brand guidelines all-in-one with git-style asset management, git powered CMS, and tight Storybook integration.
The quality and end user experience should meet or exceed that found in the Project Inspiration References (PIR).
*Project Inspiration References*
https://seeds.sproutsocial.com
https://atlassian.design/
*Required Functionality*
Elegantly presents and facilitates collaboration on the Design System, Brand Kit, and Brand Guidelines that is on par with the PIR.
Brand components include all of those found at PIR. Brand components include elements such as values, logo variation, imagery style. Not every instance of the Brand Playbook will include every component.
Just as UI components are tokenized, the Brand components should be tokenized. UI competent tokens are defined by the UI component library used in the Playbook and do not need to be separately defined. The context of the brand component tokenization is three fold:
- Implementers should be able to have a fully functional web app by just configuring the brand tokens and theme tokens - not unlike creating a Material Design theme.
- It is expected that we will need machine readable markup and schema for integration into future projects.
- UI Component libraries that use tokens are more robust and easier to adopt and we expect the same advantages for Brand components. A UI example can be viewed at https://m3.material.io/foundations/design-tokens/ and https://carbondesignsystem.com/guidelines/color/tokens/
Playbook content entries are made in MDX and MD, with decap CMS integration.
Seamlessly embed a composed Storybook into the app. This embedded Storybook will only be used to compose other Storybooks in order to display the UI components alongside the rest of the Brand Playbook and does not need to support testing or development workflows - those activities would be accomplished at the source Storybooks. For this project delivery, compose these three Storybooks into the embedded Storybook:
- Remote Carbon Design Web Components
- Local marketing only components
- Local custom UI components
The project git repo has two Storybooks apps alongside the Playbook app where marking only components such as landing pages and custom UI components are developed and tested.
Auto configured for analytics and RUM via Grafana Faro.
Instances of the web app can be easily updated when there are new features or fixes from upstream. Preferably via semver node modules.
Optional Functionality
- Internationalization via astro-i18next
- Brand components could be rendered with a JSON-LD Schema
- Changelog - mini blog with RSS Feed
- Requiring authorizations for private content
- CICD: devcontainer.json, GitHub Workflows, Review Apps, BunJS, moonrepo or buck2, and hosting on GCS, Firebase or Fly, etc.
*Technical Implementation*
Astro, shipping minimal JavaScript. No JS, including Faro on the homepage is feasible. Other pages do have JS for the embedded Storybook, perhaps, search, and for comments if implemented. In these other cases, the JS should be dynamically loaded.
Extending @astrojs/starlight [1] for a brand playbook is a quite attractive direction, but is not required.
Strict TypeScript without null or any. Emphasize the functional programming paradigm and avoid OPP. An FP library is not required but fp-ts is welcomed more concerned with using JS built-ins such as a map rather than a switch, no nested branches, reduce, no try/catch/throw, pure functions, use of eslint-plugin-functional, etc.
The two Storybooks and the Playbook app do not need to use a monorepo task runner unless the CICD option is implemented, but PNPM should be used rather than npm, yarn, or others.
Example of Astro and Decap integration [2]. Use of Cloudinary’s DAM is welcome.
TailwindCSS, prefer htmlx for interactivity.
HATEOS is preferred but if JS state is really needed, interested in using nanostores.
Pagefind or similar for search. Astro with Pagefind example [3].
The usual suspects such as: astro-auto-import, astro-seo, astro-compress, @astrojs/sitemap, @astrojs/rss, astro-icon, @astrojs/tailwindcss, swiper, @tailwindcss/forms, @tailwindcss/typograph, @astrojs/mdx, astro-imagetools, astro-robots-txt
The three referenced Astro projects should be quite informative to this implementation:
- [1] https://starlight.astro.build/
- [2] https://github.com/zankhq/astros
- [3] https://github.com/chrismwilliams/astro-theme-cactus
Thank you, I look forward to hearing from you and I hope this project will be meaningful to you.
Related categories:
Website Design
User Interface / IA
Brand Management
Next.js
Progressive Web Apps