docs: add design callouts in all the documentation when incompatibility with ODS #1614
Conversation
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
…e of the design callouts on Getting started Introduction page Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
✅ Deploy Preview for boosted ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
julien-deramond
added
feature
docs
This comment was marked as resolved.
This comment was marked as resolved.
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
julien-deramond
changed the title
There was a problem hiding this comment.
Here are some global comments, feel free to debate about these.
I'd rather use should not instead of can not almost everywhere in the callouts.
The way they are implemented yet make me feel that a callout is for the entire subpart.
Wondering if we should redirect to a usable Boosted variant on each callout ?
Maybe be more descriptive on some components.
Maybe we should on some examples explain why we shouldn't use this particular example but the concepts behind are still usable ?
We don't have specs for placeholders but is it fine to use them ?
Be brave for the migration guide change !
| @@ -253,6 +258,11 @@ Take that same HTML, but use `.nav-pills` instead: | |||
|
|
|||
| Force your `.nav`'s contents to extend the full available width one of two modifier classes. To proportionately fill all available space with your `.nav-item`s, use `.nav-fill`. Notice that all horizontal space is occupied, but not every nav item has the same width. | |||
|
|
|||
| <!-- Boosted mod : design callout --> | |||
| {{< ods-incompatibility-alert >}} | |||
There was a problem hiding this comment.
Feel like the concepts behind will be lost. Same below.
There was a problem hiding this comment.
Once again, the problem is not the technical part, but the look of the component used to illustrate this technical part...
There was a problem hiding this comment.
We should mention it or maybe change the examples look but I'm not sure this is possible...
There was a problem hiding this comment.
There was a problem hiding this comment.
Linked to my previous comment. If this is only a design reason but that the feature can be used it should be clearly explained.
There was a problem hiding this comment.
OK. From the info I have so far, the problem is the fact that the design should be buttons and not links.
TBH, it would be good to re-clarify the reasons of not using with the design.
Meanwhile, what about:
These link variants, which are just examples illustrating the use of the fill and justify utilities, should not be used because they do not respect the Orange Design System specifications. Indeed, they should be button components.
With more details, it might be useful to add a "refer to our Boosted ..." and/or "refer to the xx guidelines the ODS website"
There was a problem hiding this comment.
We use links on the whole page here even for https://deploy-preview-1614--boosted.netlify.app/docs/5.2/components/navs-tabs/#nested-tabs. Imo, it's not the main issue here since it's a design issue + no need to redirect to tabs light imo
There was a problem hiding this comment.
Let me try to clarify:
- Here, we have nav with links
<a>that have the look of buttons<button>. Here, it's not possible to have that. If we want to have components that have the look of buttons, then in the code they should be<button>html tags. - Now besides the combination "html tag/expected design", the only look that is ok for such components is the one of the tabs light.
Would this version be more satisfying ?
These link variants, which are just examples illustrating the use of the fill and justify utilities, should not be used because they do not respect the Orange Design System specifications. Indeed, nav tabs and html tags should not look like buttons.
Instead, please consider using our Boosted Tabs light variant. You can also refer to Navigation guidelines on the Orange Design System website.
There was a problem hiding this comment.
Here, we have a nav with links that have the look of buttons . Here, it's not possible to have that. If we want to have components that have the look of buttons, then in the code they should be html tags.
I strongly disagree with the fact that <a> shouldn't look like buttons. Since many call to action are presented as buttons but are truly links. I think it strongly depends on the context and the associated action. IMO, the actual behavior is fine.
Otherwise, many many and many designs will have to change as well.
IMO, if this is accepted by design:
instead of:
We might consider using .nav-underline instead of .nav-pill to present the remaining doc. We should keep a callout only if the design is against a specific feature. Any thoughts @julien-deramond ?
|
Some callouts are missing somehow. Haven't checked everything but the displayed cards are fine unless we warn about the usage of:
|
| @@ -285,6 +320,13 @@ Input groups include support for custom selects and custom file inputs. Browser | |||
|
|
|||
| ### Custom file input | |||
|
|
|||
| <!-- Boosted mod : design callout --> | |||
| {{< ods-incompatibility-alert >}} | |||
| These form variants can not be used because they do not respect the Orange Design System specifications. | |||
There was a problem hiding this comment.
yes, but if you can't glue the buttons together with the field you'll have something like this :
(example from va11ydette)
Is it better ?
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
|
Kudos, SonarCloud Quality Gate passed!
|
Co-authored-by: Louis-Maxime Piton <louismaxime.piton@orange.com>
Co-authored-by: Louis-Maxime Piton <louismaxime.piton@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
…ocs' into main-ic-add-design-callouts-in-docs Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
| @@ -253,6 +258,11 @@ Take that same HTML, but use `.nav-pills` instead: | |||
|
|
|||
| Force your `.nav`'s contents to extend the full available width one of two modifier classes. To proportionately fill all available space with your `.nav-item`s, use `.nav-fill`. Notice that all horizontal space is occupied, but not every nav item has the same width. | |||
|
|
|||
| <!-- Boosted mod : design callout --> | |||
| {{< ods-incompatibility-alert >}} | |||
There was a problem hiding this comment.
Here, we have a nav with links that have the look of buttons . Here, it's not possible to have that. If we want to have components that have the look of buttons, then in the code they should be html tags.
I strongly disagree with the fact that <a> shouldn't look like buttons. Since many call to action are presented as buttons but are truly links. I think it strongly depends on the context and the associated action. IMO, the actual behavior is fine.
Otherwise, many many and many designs will have to change as well.
IMO, if this is accepted by design:
instead of:
We might consider using .nav-underline instead of .nav-pill to present the remaining doc. We should keep a callout only if the design is against a specific feature. Any thoughts @julien-deramond ?
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
… >}} everywhere in the code Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
| @@ -25,6 +25,12 @@ Custom `<select>` menus need only a custom class, `.form-select` to trigger the | |||
|
|
|||
| You may also choose from small and large custom selects to match our similarly sized text inputs. | |||
|
|
|||
| {{< ods-incompatibility-alert >}} | |||
| These select sizes variants, with a **height different than 40px**, should not be used because they do not respect the Orange Design System specifications. | |||
There was a problem hiding this comment.
It's the second example of the artboard here: https://system.design.orange.com/0c1af118d/p/88ab5b-forms/b/599459
Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
…ng the dark mode now available on main branch Signed-off-by: Isabelle Chanclou <isabelle.chanclou@orange.com>
|
Kudos, SonarCloud Quality Gate passed!
|
There was a problem hiding this comment.
With the last changes, I'd rather set a global callout on badges to avoid hiding everything.
One .nav-underline.nav-justified render is broken.
Revert 4fcd51d if you don't like it.
louismaximepiton
force-pushed
the
main-ic-add-design-callouts-in-docs
branch
from
a0a8251
to
4fcd51d
Compare
Related issues
Closes #1199
Closes #1118
Closes #1117
Description
Everywhere needed in Boosted Docs, a callout message has been added.
Motivation & Context
Callout messages added to warn Boosted users that such component or component variant should not be used because incompatible with the orange design system specifications.
Types of change
Live previews
Checklist
npm run lint)