-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add a placeholder overview page to Storybook (#732)
- Loading branch information
Showing
1 changed file
with
103 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,103 @@ | ||
Building a design system for a Bible translation app requires a deep understanding of our values, mission, and the people who will be using the system. Below is a comprehensive plan for the design system, tailored to communicate our core values and help users interact with the app effectively. | ||
|
||
### Introduction | ||
|
||
Welcome to the Bible Platform Design System. This system serves as the cornerstone for crafting seamless, intuitive, and inclusive Bible translation apps. We've rooted our design philosophy in these core: expansive and extensible, open, cooperative, and opportunity-focused. The design choices, from shapes to colors, reflect these principles. | ||
|
||
This Design System is created and maintained by the Paratext UX Team. It is an early draft not ready to be distributed or used as a reference. In case of questions or comments you may contact us through the [UX channel](https://discord.com/channels/1064938364597436416/1082713526780575845) on the Platform.Bible Discord server. | ||
|
||
### Design Principles | ||
|
||
1. **Foundationally Strong**: The app's interfaces should feel reliable and secure to convey stability, supporting the foundational value. | ||
|
||
2. **Expansively Inclusive**: The design system should be flexible to accommodate the diverse linguistic and cultural backgrounds of the vast user base. | ||
|
||
3. **Openness**: Interfaces should promote transparency and foster an environment of collaboration and sharing. | ||
|
||
4. **Cooperative Engagement**: The design should encourage cooperation among users, allowing them to interact, share insights, and work together on language projects. | ||
|
||
5. **Opportunity Creation**: Finally, the app should highlight growth, learning, and the discovery of new possibilities within the context of language and spirituality. | ||
|
||
### Design Tokens | ||
|
||
The design tokens represent the visual atoms of the design system. Here are some examples: | ||
|
||
- **Color Palette**: A range of colors inspired by the sky, from dawn to dusk, communicates openness and opportunity. | ||
- **Typography**: A legible typeface that resonates with trust, and suggests a foundation. | ||
- **Spacing Scale**: Harmonized spacing that allows for content to breathe, signifying openness. | ||
- **Iconography**: Symbols with roundness and unclosed elements to represent expansion and extensibility. | ||
- **Borders and Radii**: Smooth, rounded corners on elements to emphasize friendliness and collaboration. | ||
|
||
### Foundations | ||
|
||
This section would detail the core elements like Grid, Typography, Colors, Icons, and Imagery—a complete reference to ensure consistency in the design. | ||
|
||
### Getting Started Guide | ||
|
||
This guide would provide developers with step-by-step instructions on how to implement the design system. It would include essential information on how to configure their environment, and where to find components and resources. | ||
|
||
### Voice and Tone | ||
|
||
- **Voice**: Welcoming, respectful, and warm. It should feel like a companion that supports the user in their exploration and understanding of the Bible. | ||
- **Tone**: Adaptable to context. Should be more formal and reverent when dealing with scripture content, and more casual and encouraging in teaching and guidance sections. | ||
|
||
### MDX, TypeScript, and CSF Examples | ||
|
||
Our Bible translation app design system would use MDX for documentation, TypeScript for type-safe components, and CSF to showcase components in Storybook. Here's a snippet: | ||
|
||
```mdx | ||
// Button.mdx | ||
import { Meta, Story, Props } from '@storybook/addon-docs/blocks'; | ||
import { Button } from './Button'; | ||
|
||
<Meta title="Components/Button" component={Button} /> | ||
|
||
# Button | ||
|
||
The button component is used to trigger an action or event. | ||
|
||
## Usage | ||
|
||
<Props of={Button} /> | ||
|
||
<Story name="Basic"> | ||
<Button label="Translate" onClick={() => console.log('Translated!')} /> | ||
</Story> | ||
``` | ||
|
||
```tsx | ||
// Button.tsx | ||
import React from 'react'; | ||
|
||
interface ButtonProps { | ||
label: string; | ||
onClick: () => void; | ||
} | ||
|
||
const Button: React.FC<ButtonProps> = ({ label, onClick }) => ( | ||
<button onClick={onClick}>{label}</button> | ||
); | ||
|
||
export default Button; | ||
``` | ||
|
||
```tsx | ||
// Button.stories.tsx | ||
import React from 'react'; | ||
import Button from './Button'; | ||
import { Story, Meta } from '@storybook/react/types-6-0'; | ||
|
||
export default { | ||
title: 'Components/Button', | ||
component: Button, | ||
} as Meta; | ||
|
||
const Template: Story<ButtonProps> = (args) => <Button {...args} />; | ||
|
||
export const Primary = Template.bind({}); | ||
Primary.args = { | ||
label: 'Translate', | ||
}; | ||
``` | ||
|
||
This snippet illustrates the foundational structure you'd see in the design system documentation and components. The documentation in MDX provides context and guidelines, TypeScript ensures robustness and type safety for the components, and CSF within Storybook offers a playground for interactive component visualization and testing. |