zesty-io / design-system Goto Github PK

Is your feature request related to a problem? Please describe.
Currently our color usage is inconsistent. Usage is an ad-hoc decision made by a developer with no established guidance.

Describe the solution you'd like
These are all in the context of the manager-ui because it provides us the most product surface which to consider this across.

Green = Save

An action which will persist data to the API.

Orange = Publish

An action which will make data available on an instances production domain. Significant. This makes a change "live".

Red = Delete

An action which will remove data from the API. Significant. Often combined with a double confirmation dialog.

Grey = Cancel

An action which backs out of the current experience. Typically used with modals & dialogs.

Blue = Make resource OR Link

An action which starts the creation of a new resource. Usually requires link a user to a new view.

An internal or external link which is not a button.

Dark Blue(Default) = Action

An action which changes the state of the application or triggers an external event.

Describe alternatives you've considered

Additional context

We primarily design this system in the context of the https://github.com/zesty-io/manager-ui which as a CMS has the REST API actions of Create, Read, Update, Delete, Publish (CRUD + P)

These actions map to the colors described here as;

• Create = Blue
• Read = N/A
• Update = Green
• Delete = Red
• Publish = Orange

Is your feature request related to a problem? Please describe.
We should have a component which allows rendering of radio type inputs. This would work really well in the manager-ui for the "Dropdown" field type were currently we use a FieldTypeDropdown to render.

Describe the solution you'd like

<fieldset>
    <legend>Field Label</legend>

    <input type="radio" id="option.one.name" name="option.one.name">
    <label for="option.one.name">option.one.value</label><br/>

    <input type="radio" id="option.two.name" name="option.two.name">
    <label for="option.two.name">option.one.value</label><br/>

</fieldset>

As shown on the https://developer.mozilla.org/en-US/docs/Web/HTML/Element/legend page

• Only one option can be selected at a time
• User can implement "none" option if needed

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

As the product grows there will be more sections that a user may navigate with in the app. A design system tabs component would add value to the product. We have numerous links taking the user to the same place causing users extra cognitive load. By adding tabs we can reduce the cognitive load for navigating and allowing for improved navigation through the products.

Describe the solution you'd like
Build out a Tabs component and implement where it may be useful fo navigation

Describe alternatives you've considered
https://material.io/components/tabs

Additional context
Material -ui : Tabs organize content across different screens, data sets, and other interactions.
We are now mimicking this style for the new Content Composer tabs

CC: @shrunyan

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

We should explore using the dialog tag to provide better semantics on our Modal, Notice, ConfirmDialog and anything else that is a temporary visual which can be dismissed.

• Naming of DropdownFieldType is inconsistent, should be DropDownFieldType or DropdownFieldType, currently usage is mixed

• Field Types should take callback to return values

• All Field Types need to take a label, required option, and initial value

• Quill field type is HUGE and maybe shouldnt be included if it cannot get smaller

• May need a checkbox component

• Search component cannot use the 'form' html element as it can be placed in a form while in dropdown and this causes an error

• BinaryFieldType styles pollute global

• Currency css positioning will not work

Wraps button size small, has grey colors with orange accent icon of the book icon. It will open a link to zesty.org in target blank using the search query

<docs subject="content models">

Is your feature request related to a problem? Please describe.
Often it can be easier to locate a specific option when they are sort by alphanumeric. Because if you know the text value of the option you are looking for scanning to find it becomes easier. e.g. Lists of months, states, etc.

Describe the solution you'd like
Display an A-Z sort icon on the top of a select dropdown. When clicked would toggle between ascending and descending alpah numeric sort.

• Like the search field would this only be displayed on lists greater than 50?
• Once clicked if it then toggles between asc/dsc how could someone return to the default order? Third click?

Describe alternatives you've considered

Additional context

• Would need to fit visually with other elements.
• Should not be visually dominating.

TODOS:

• Titles should be collapsable.
• The content property ZUID should be path. The component needs to be able to handle none ZUID based navigation as well. It's up to the consumer to build out the paths that get rendered.

Describe the bug
At the moment this specific component is failing to be parsed React during the runtime.

To Reproduce
Steps to reproduce the behavior:

1. Go to http://8-f48cf3a682-7fthvk.manager.dev.zesty.io:9000/content/6-556370-8sh47g/7-b939a4-457q19
2. Open console
3. See error

Expected behavior
View should render without throwing a React Error and crashing the application.

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu
• Browser chrome

Is your feature request related to a problem? Please describe.
Working towards more semantic, accessible and functional solutions

Describe the solution you'd like
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist
https://gsong.dev/articles/datalist-autosuggest

I feel like there's got to be a great use case for us in our design system for this element!

Describe alternatives you've considered

Additional context

Describe the bug
When reverting back to a previous version of a content item, content in a wysiwyg field remains the same

To Reproduce
Steps to reproduce the behavior:

1. Go to an instance with a wysiwyg field.
2. Make an edit and hit save to create a version.
3. Revert back to the previous version.
4. See the edits have not reverted.

Expected behavior
Expect for previously versioned content to display based on the version selected.

Screenshots
https://www.loom.com/share/867b3c1532584147b82da64e5ef9d589

Describe the bug
Depth 5+ nav nodes have border-left: 0px and border-left: 2px on hover causing a layout shift on hover

To Reproduce
Steps to reproduce the behavior:

1. Go to http://8-f48cf3a682-7fthvk.manager.dev.zesty.io:8080/content/
2. Hover over depth 5 or higher nav item
3. see item shift by 2px

Expected behavior
border-left: 2px at all times

Screenshots

Describe the bug
The FieldTypeImage component has a hard coded url path which is specific to the zesty.io media service causing this component to not be flexible and allow for alternate media sources.

In addition this component is explicitly dependent on the RiotJS media app. It has a button which when clicked opens the media app. Ideally this would be an action described by the consumer and provided to this component.

Expectations

1. The component consumer provides the complete image url to be shown
2. The component consumer provides a handler to manage the image selection experience.

Describe the bug
The FieldTypeEditor component allows for switching between wysiwyg, inline, markdown and html editor modes. When inserting an image in the wysiwyg or inline editors it render a lower right handle to resize the image. The width/height values set when resizing are lost when swithcing to the markdown or html editor modes.

To Reproduce
Steps to reproduce the behavior:

1. Go to content item with article_writer field
2. Insert image into article writer
3. Resize image
4. Switch to markdown mode
5. Switch back to inline mode
6. See image is no longer resized

Expected behavior
When switching between modes image width/height should be translated to each modes syntax for denoting those values.

With markdown this may require using an html <img> tag and width/height attributes. As markdown syntax does not allow for specifying image dimensions. https://stackoverflow.com/a/21972032

The html mode should just the wysiwyg markup as authored. Need to investigate on why this doesn't already happen.

Screenshots

Additional context