Streamlined name changes to components to limit confusion

[bstifle]

Summary

Names of certain components are confusing or inconsistent with the naming of other components

Measure of Success

have component names changed to be more accurate and less confusing

Name change proposals

Calcite-tab-nav -> calcite-tab-title-group

Reasoning: Matches other child / parent component nomenclature,

Prevents conflation with upcoming calcite-nav / calcite-nav-*

---

Calcite-drill-in (not yet built) (don’t use calcite-flow-whatever)

Reasoning: Drill in is a common UI term, and it can be used outside the scope of a flow or panel

---

Calcite-list, calcite-value-list, calcite-pick-list -> just-one-list-thing

Reasoning: If possible, make “value” and “pick” types of “the basic list component”.

---

Calcite-inline-editable -> calcite-….input-editable? Editable as prop?

Reasoning: Inline-editable doesn’t have a relationship to input. It’s also the only “adjective” component name.

If possible, make “editable” or “inline” or whatever a prop on input (and later textarea)

---

Rework Tabs, TabNav, Tab naming story

Reasoning: Tabs is the only one with a plural.

The 3 components to build a group of tabs is confusing. Consider renaming each to make it easier to understand the layers of functionality

---

radio button / radio button group / radio group

Reasoning: confusing name hopscotch.

Radio Button -> (no change)
Radio Button Group -> (no change)
Radio Group -> Radio Rectangle, Rectangle Radio, etc

[bstifle]

salesforce calls its version of radio group, "Listbox"

https://www.lightningdesignsystem.com/accessibility/patterns/listbox/

[julio8a]

Tabs

Clean up the amount of children

<calcite-tabs ...>
  <calcite-tab heading=title ...>content</calcite-tab>
  <calcite-tab heading=title ...>content</calcite-tab>
  <calcite-tab heading=title ...>content</calcite-tab>
</calcite-tabs>

Calcite-Flow

Rename to Calcite-drill-in, following standard naming for this component

Calcite-inline-editable

integrate with input and make a prop

Radio

Bring the radio group into the larger radio story
https://mdbootstrap.com/snippets/jquery/marta-szymanska/593151
https://ant.design/components/radio/#Radio/Radio.Button

[jcfranco]

I think we've narrowed down the list of changes. Moving this to the freezer until we get closer to the batch renaming beta release.

[jcfranco]

Via #1616, should we drop the -picker from calcite-input-<type>-picker?

From @eriklharper:

I prefer the name calcite-input-color over calcite-input-color-picker for the same reason I prefer calcite-input-time over calcite-input-time-picker. No need to have the -picker at the end when the last word is sufficient for communicating the type of input it is.

[julio8a]

For the input-based, I think it makes sense to use just color, time, date since you know what and where it will go into.

For general components, I'd like to keep picker and stay consistent with other frameworks:

Shopify:

Salesforce:

Vuetify:

[macandcheese]

Couple thoughts... Agree on most of the above. I think across the board the nomenclature could be standardized more... we use a lot of non-recognizable terms that folks not familiar with the system won't be looking for. We can obviously try to educate and promote but it seems like we just try to stick to more industry standard terms as a rule.

For tabs - I like the change to 'tab-title-group'. I don't particularly mind the plural 'tabs' - this is seen across most design system examples I can find. There is maybe something to clean up in the inconsistency with stepper (fwiw - a singular name on Carbon https://www.carbondesignsystem.com/components/progress-indicator/usage/), but that also is commonly seen across systems.

To me as a consumer, the number of "list" components is overwhelming. I know we are trying to prescribe behavior but trying to choose between them can be tough - even if comprehensive documentation is available it's still on the user to educate themselves. The child components are all very similar and a generic group component would be useful in all cases - short of combining the parent components, can they share a generic group and child item?

[geospatialem]

Closing in favor of the two above issues, 6152 and 6153 and with the refactor of tabs in #2721.

The remaining component name changes are no longer considered or valid since the original issue was opened.