Discussion initially started here: #710

README: fix broken link to contribution guidelines

Note: this only happens when clicking from github. https://atlantis.getjobber.com/ works fine.
Clicking README hyperlink to contribution guidelines results in 404 not found.

Expected URL: https://github.com/GetJobber/atlantis/blob/master/docs/CONTRIBUTING.md
Actual URL (404): https://github.com/GetJobber/atlantis/blob/master/CONTRIBUTING.md

Fix

~~add docs/ to the link on line 164~~
~~from: [contribution guidelines](/CONTRIBUTING.md) to learn how.~~
~~to: [contribution guidelines](/docs/CONTRIBUTING.md) to learn how.~~
edit - on second thought, doing this might break the site link.

GitHub supports relative links in README files.
As long as Gatsby markdown parser is able to remove the . this would still work on the docs site and GitHub.

add ./ to the link on line 164
from: /CONTRIBUTING.md
to: ./CONTRIBUTING.md

Foundation Design Bug: Anchor tag styling not applied

I noticed that anchor tag styling (<a>) isn't defined in our foundations or isn't getting applied. (screenshots to be added)

Add CI Integration

At the very least we should make sure CI fails for

tests
linting rules

Menu: Section headers should be read out by screen readers

Section headers are not read out to assistive technologies.

RadioGroup is missing `role` and `aria-labelledby` attributes

The RadioGroup has a div that wraps all of the RadioOptions within. This div has a role of radiogroup so that assistive technology can better identify it

The RadioGroup should have an aria-label, aria-labelledby relationship, or a label, so that the group makes sense.

Add a component overview page

Developers unfamiliar with Atlantis can have a hard time finding components that suit their needs, and the search bar only provides limited information. Could we implement a component overview page so that small previews of components could be seen?

An example of this can be seen on Ant Design

Implement component to display placeholder for content (skeleton/placeholder)

It would be nice to have a component to be used to display placeholder content when API/HTTP or asynchronous actions are taking place.

Examples:

Related to #649

Chore: Add automation for commit messages

While contributing to the code, I discovered that husky runs linting and pre-checks but post that, the developer has to write the commit message on his/her own.

Moreover, it is when raising a PR that someone comes to know about we follow conventional commits 😄. S/he then needs to read the scope and pattern and then frame a message.

Proposal:

I have used an interesting npm package that helps automate the commit message creation process at the terminal. Its called cz-conventional-changelog

This runs post husky checks and gives an interactive user interface to the developer to frame his/her commit message in a very similar fashion as we tell in the PR description guidelines.

I tried it below in this repo as well with the defaults and it seems to work well 😃.

Value add:

Will automate commit message creation
Will bring in consistency among all commit messages in the repo 🙂

Let me know, if this sounds like something to be explored or if something hidden might be present which I am not aware of. I Will be more than happy to discuss 😃. Thanks!!

Update DescriptionList details text colour

Related Components:

https://atlantis.getjobber.com/components/description-list

The colour of the text in the details (right hand) column should be --color-greyBlue--dark instead of --color-greyBlue.

Create a contributing.md file

To ensure all contributors are held to the same high standard and make it easy to contribute we should add a CONTRIBUTING.md file.

Some Resources:

Make Tabs Accessible

Related Components:

https://atlantis.getjobber.com/components/tabs

Tabs have no focus states or defined hierarchy. Content within tabs cant be accessed until going through all tabs. They should use different navigation (arrows vs tabs).

Elements with the role tab must either be a child of an element with the tablist role, or have their id part of the aria-owns property of a tablist.

Add role="tablist" aria-label="Tab group name"` to the Tabs element.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tab_Role

There should also be a role of tabpanel to go with the role of tab that is on the buttons. A labelledby attribute should also point out which tab is associated with what tabbed content.

InputValidation: Add space below error messages

Related Components:

While working with input groups with validation, there's little space below errors. Would be good to increase the space below error messages.

Component to visually truncate content

The goal of this issue is to discuss the proposal process and discuss the proposed component. Please start your comments with [META] or [COMPONENT] depending on what you're commenting on. Keep each comment on that particular topic.

A few example comments.

Good

[META]
I think we should submit the readme as a PR instead of discussing it as an issue

Good

[COMPONENT]
Should we have a isCollapsed property to decide if this starts off as collapsed or not.

Bad

[COMPONENT]
I don't like Collapse as the name of the component. Also do we need a Props Table section?

(It comments on both the component and process)

Proposed component documentation:

.../collapse/README.md

Collapse

The Collapse component will collapse content to a specified maximum height; when interacted with that content will expand to its full dimensions.

Design Patterns

The goal of the Collapse component is to hide away secondary or supporting information that is not immediately necessary for the current action or goal. It allows the user to easily expand that content when and if it becomes relevant.

It should only be used to hide away context if there's a good reason to believe it will not be relevant in the majority of cases

Usage

Section to be replaced with an interactive playground when compiled/served.

<Collapse collapsedHeight="2 em">
  <ul class="list">
    <!-- ... Content of the list that will be collapsed -->
  </ul>
</Collapse>

Props Table

name	type	default	description
`collapsedHeight`	`string`	'0em'	The height of the component when it is collapsed
`children`	`node`	`null`	The node that will be collapsed

Playground examples take up too much vertical space

As a consumer of Atlantis docs, I want to be able to focus on the right content in examples so that I can absorb the right information.

Pain point

Currently our Playground takes up a ton of vertical space with the code sandbox. This is fine when the intent is to highlight technical patterns, but for design usage examples we end up with more visual space allocated to code examples than the guidelines and visual examples themselves. It makes documentation for relatively simple components like Avatar and Emphasis seem overwhelming.

Potential solution

Add a prop to Playground that defaults to closed/minimized, with an option for the user to expand. Allow for code-specific Playgrounds to be set to "open" by default if needed.

Examples

Implement keyboard shortcuts to close and confirm for ConfirmationModal

The Confirmation Modal's keyboard shortcuts can be improved.

https://atlantis.getjobber.com/components/confirmation-modal

Expected Behaviour

on escape, should close the confirmation modal and trigger onCancel and onRequestClose
enter, if not focused on any elements, should trigger onConfirm and onRequestClose

Implement component to act as countdown, with consistent formatting options

Initially suggested in #646, but added this issue to have discussions around requirements here instead.

Implement navigation/side drawer component

There are many cases where we'd need to display a drawer like component similar to ones present in Atlantis:

Could we implement something like this:

Prop	Type	Required
activator (Similar to menu component)	React Component	true
direction	"left", "right", "top", "bottom"	true
children	React Children	true
open	boolean	false
onDismissRequest	(): void	false
onOpenRequest	(): void	false

const [isOpen, setIsOpen] = useState(false);

return (
  <SideDrawer activator={<Button />} direction="left" open={isOpen} onOpenRequest={handleOpen} onDismissRequest={handleDismiss}>
    <h1>I am content inside the drawer</h1>
  <SideDrawer />
)

function handleOpen() {
  setIsOpen(true);
}

function handleDismiss() {
  setIsOpen(false);
}

on dismiss request would trigger when:

dismiss button clicked
drawer swiped away
clicked on area outside of dismiss button
escape key is pressed

The drawer would overlap content and be placed on-top and would slide in based on the direction.

Also would be good to have accessibility considered.

When on a mobile like/sized device, the drawer could take the entire page?

Add linting rules

Documentation: placeholder link instead of Slack channel

On this page - https://developer.getjobber.com/docs - there's a reference to "Jobber's public Slack channel," but the link goes to example.com. That should probably be fixed or removed.

Define pattern for breadcrumbs/history in `Page`

A few one-off instances of "back button" breadcrumbs have been used alongside Page - a good indicator that it's time to incorporate this mechanism into the component itself, so end users can just use the pattern without having to solve it themselves.

An initial idea explored in a since-closed exploratory PR was to add a single small tertiary button that would simply jump the user up one level in the hierarchy of the application. For example, if you were looking at something like...

settings/notifications

the Back button would return you to

settings.

Outstanding Questions

Some other considerations that we would want to resolve (thanks @joelwarrington-jobber!) are:

Multi-level breadcrumbs

If multi-level breadcrumbs were to be a possibility, we could make it so that the breadcrumb type is an array, if the length is 1, use the button style and then some other type of style for multiple?

Additional properties

For added flexibility, would we be able to have 2 additional properties of a breadcrumb?

interface breadcrumb {
  label: string;
  /* Default = "../" */
  url?: string;
  onClick?(): void;
}

If the onClick property is passed, the url is ignored

History vs hierarchy

Do we need to account for the user's X recently-visited views in the breadcrumbs, rather than the application hierarchy? Is that the responsibility of a breadcrumb? E.g. in the above use case of being on a specific settings view...

History could look something like:

home / schedule / invoices ➡️ Notifications Settings (maybe there's a prompt on that view to adjust your invoicing notifications)

Hierarchy would look like:

settings ➡️ Notifications Settings

Does this need to be something that Page is even responsible for? (Could/should end-users configure Page to their needs?)

Add ability to use markdown for ConfirmationModal

Related Components:

The message prop should accept markdown.

This can be done using the Markdown component.

The dismiss button on a Modal should us a Button

Related Components:

The dismiss (𝖷) button in the header of a Modal should use a tertiary button.

An example of this can be seen in the Toast component.

Requiring <tbody> tag in <Table> ?

A great mention of accessibility when dealing with <Table> component in #763

I was wondering if we should update the schematics of the <Table> component to make <Body> as a required children?

Figure out sustainable way to support password managers with password input

Easy autofill (how does this working in practice with username and password inputs?)
Password fill button that gets populated in the input (make sure it doesn't overlap)

Investigate usage of optional title for Drawer and other related components (Modal)

See #709

There's been separate design discussion around how we might treat...

a Modal without a header

a dismissible Card

and this title question with Drawer really speaks to the same questions, so a larger issue might be whether we should use an internal component to handle all of these items consistently?

Adjust padding on buttons with icons relative to size

Related Components:

https://atlantis.getjobber.com/components/button

Currently our buttons have different padding based on what size prop is being used. (Small 8px, Base 12px, Large 16px).

However, one an icon prop is introduced, the padding defaults to 16px regardless of size. The padding should stay the same according to its size.

Small button with 8px padding

Padding changes to 16px when icon is introduced

Base button with 12px padding

Padding changes to 16px when an icon is introduced
INCLUDE IMAGE

Menu: First item should receive focus when opened

The first menu item does not receive focus when opened (user must tab to the first menu item).

Add vertical option to the Divider component

The divider component can only be used to divide content in a traditional page flow (top down), but has no option to divide content which is in a left to right page flow.

<Tabs> Component to allow props for default opened tab

Component in question:
https://atlantis.getjobber.com/components/tabs

Proposing enhancement(s):
Allowing a props (eg: selectedTab) to be used for selected the default opened Tab

<Tabs selectedTab={1}>
  <Tab label="Eggs"></Tab>
  <Tab label="Cheese"></Tab> {*/ This will be the opened tab by default */}
</Tabs>

Use Case and Reasoning:
If we want to restore the state for the <Tabs> component, right now we couldn't preselect a <Tab> and bring the user back to the correct context.

More specifically, let's say we use <Tabs> inside of a <Modal> component and if the user comes back to either continue their workflow, or edit some information, we would like to bring them back to the exact view with pre-populated information, allowing them to resume their workflows.

Create build script to generate CSS backfill

This will allow us to maintain maximum backwards compatibility with existing systems as we build out Atlantis

Card: Add ability to specify `external` similarly to button on card

Card has the ability to specify a URL but it doesn't give you the option to open it in a new tab if it's an external URL such as the button

Banner: Close button should have a more distinct `aria-label`

Close button on the Banner should be more distinct aria-label (ex. "Close notification") so its clear what it relates to rather than just "close"

Update Tooltip to use React Popper

Related Components:

https://atlantis.getjobber.com/components/tooltip

The Tooltip currently uses a non-react version of popper.js and is a bit messy as a result. We should update it to use React Popper. This will also resolve some positioning edge cases.

Autocomplete should not show empty section headers

Related Components:

https://atlantis.getjobber.com/components/autocomplete#section-headings

If there are no options in a section hide the section header.

Example:

Make it easier to cycle through props

Most of our components have fairly limited props, where it's not that hard to edit data in the Playground and see the results.

For components like Icon, however, there are so many possible values for name that must be matched exactly for the prop to work, that the end user of the docs has to scroll through the entire page to search for the right icon.

In addition, cycling through color options is tedious.

And finally, for less-technical users like designers and PMs, it may be daunting to work in the Playground's editor.

Is there a solution to make it easier for consumers of our docs to explore the the visual effects of typed properties on a component?

Tabs: Make tabs navigable by arrow keys and remove tab navigation

The Tab component's accessibility can be improved to use expected keyboard behaviour.

Unlike a same-page link, a tab does not move the user to the associated section/panel of content. It just reveals the content visually. This is advantageous to sighted users (including sighted screen reader users) who wish to flit between different sections without having to wade back up the page each time they want to choose a new one.

This comes with an unfortunate side effect: If the user wishes to move to a section by keyboard and interact with its internal content, they have to step through any tabs to the right of the current tab, which are in focus order.

This problem is solved by delegating tab selection to arrow keys. The user is able to select and activate tabs using the arrow keys, while the Tab key is preserved for focusing contents within and below the active tab panel. To put it another way: Tab is not for tabs, which I concede is a bit confusing. I wish the key and the control had different names, but alas.

It's equally important that pressing Shift + Tab returns the user to the selected tab. This is all possible by giving each tab but the selected tab tabindex="-1", which removes the inactive tabs from focus order but allows focus via a script. In the following example, the second tab is the selected tab, as denoted by the aria-selected state being set to true.

https://inclusive-components.design/tabbed-interfaces/

Expected Behaviour

While focused on the tab selector, arrow keys which navigate between the sections:
While focused on the tab selector, tabbing will focus on the content of the tab
While focused on the content of a tab, tabbing will focus on the tab selector

Add actions to Card component

The Card component is aesthetically similar to the Modal component, however it does not have the ability to provide actions.

Add ability to specify actions
- primary action
- secondary action
- tertiary action

Modal should receive focus when opened

Related Components:

https://atlantis.getjobber.com/components/modal

When a modal is opened, you still have to tab through all the content of the page to get to it. Tab and Shift + Tab should not focus outside of the modal. When a dialog opens, focus moves to an element inside the dialog.

https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=111%2C122%2C131%2C132%2C133%2C141%2C143%2C144%2C146%2C148%2C1410%2C1411%2C1412%2C1413%2C211%2C212%2C223%2C224%2C225%2C226%2C241%2C242%2C243#focus-order

Expose library as NPM package

React Markdown needs to be updated to latest version as its falling behind significantly

There are a bunch of things which need to be updated due to breaking changes.

Initially started in #765 but don't have the capacity to continue the update. Hoping someone else can pick this up!

Add password strength component to display the strength of a users password

Have implemented a hook to determine the strength of a password, but a component would be great to have which displays this information in a user friendly way.

Should have a way to add this to a password input easily (displaying below the input)
Should have a way to validate the password input using the password strength from the hook and providing options to enable/disable or set minimum validations (like it needs to be a score > 100 for example)

Can't install `@jobber/hooks` without also using `@apollo/client`

If you don't use @apollo/client you aren't able to use any hooks even if not using the ones to provide utility functions for Apollo.

I think this should be fixed or we should call it out as a required dependency

Popover: close on Escape

It would be nice to be able to close a popover when the Escape keyboard key was pressed

Gallery: Add a gallery component to swipe through images and photos like a lightbox

https://www.figma.com/file/b7LY6hVMwFOj5maidxPTMB/Design-System-Contribution-%5B-Gallery-%5D?node-id=402%3A0

Menu: Esc key should close the menu

The Esc key does not work as advertised (VoiceOver, for example, understands that Menu is a menu and reads “press the Esc key to close”, but we do not offer this functionality). This means that to close the menu, the user must ensure they have tabbed to the button and then hit return/space to close.

Update package scripts to be platform/OS agnostic

Remove the -f and change semi colons to &&

OR

use this: https://github.com/shelljs/shx

Investigate drawer accessibility

I noticed that the drawer component is only visually hidden when not open, is this intended, should there also be something hiding it with an aria attribute?

Noticed this when working on #709

Bug: Any component which uses `--color-border` within Card has the color overriden to be transparent

I noticed that using a <Divider /> within a Card causes it to lose it's color as the --color-border value is overriden in the Card component.

Card should use it's own internal CSS variable instead of overriding it, especially when it has children components.

getjobber / atlantis Goto Github PK

atlantis's People

Contributors

Stargazers

Watchers

Forkers

atlantis's Issues

Fix

Proposal:

Value add:

Good

Good

Bad

Collapse

Design Patterns

Usage

Props Table

Pain point

Potential solution

Examples

Outstanding Questions

Multi-level breadcrumbs

Additional properties

History vs hierarchy

Expected Behaviour

Recommend Projects

Recommend Topics

Recommend Org