getjobber / atlantis Goto Github PK
View Code? Open in Web Editor NEWπ± Atlantis
Home Page: https://atlantis.getjobber.com
License: MIT License
π± Atlantis
Home Page: https://atlantis.getjobber.com
License: MIT License
Discussion initially started here: #710
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
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
I noticed that anchor tag styling (<a>
) isn't defined in our foundations or isn't getting applied. (screenshots to be added)
At the very least we should make sure CI fails for
Section headers are not read out to assistive technologies.
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.
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
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
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.
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 π.
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!!
Related Components:
The colour of the text in the details (right hand) column should be --color-greyBlue--dark
instead of --color-greyBlue
.
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:
Related Components:
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.
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.
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.
[META]
I think we should submit thereadme
as a PR instead of discussing it as an issue
[COMPONENT]
Should we have aisCollapsed
property to decide if this starts off as collapsed or not.
[COMPONENT]
I don't likeCollapse
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
The Collapse
component will collapse content to a specified maximum height; when interacted with that content will expand to its full dimensions.
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
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>
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 |
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.
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.
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.
The Confirmation Modal's keyboard shortcuts can be improved.
Expected Behaviour
escape
, should close the confirmation modal and trigger onCancel
and onRequestClose
enter
, if not focused on any elements, should trigger onConfirm
and onRequestClose
Initially suggested in #646, but added this issue to have discussions around requirements here instead.
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:
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?
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.
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
.
Some other considerations that we would want to resolve (thanks @joelwarrington-jobber!) are:
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?
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
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?)
Related Components:
The message
prop should accept markdown.
This can be done using the Markdown
component.
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
.
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?
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?
Related Components:
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.
Padding changes to 16px when icon is introduced
Padding changes to 16px when an icon is introduced
INCLUDE IMAGE
The first menu item does not receive focus when opened (user must tab to the first menu item).
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.
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.
This will allow us to maintain maximum backwards compatibility with existing systems as we build out Atlantis
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
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"
Related Components:
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.
Related Components:
If there are no options in a section hide the section header.
Example:
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?
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.
The Card component is aesthetically similar to the Modal component, however it does not have the ability to provide actions.
Related Components:
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.
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!
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.
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
It would be nice to be able to close a popover when the Escape keyboard key was pressed
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.
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.