Naming the cards

Update: accommodated devs’ comments’

This ticket describes work that should be done in the Hub.

To-do to close this ticket:

• add id, card-name, and route as properties that exist on all cards
• assigns the id to the route, as a stopgap
• make card name user-editable (does not matter if this is unique)
• provide a default value for card name
• make sure that the id is server-side generated, unique, and not editable
• open a ticket that describes what you think should be done next, including UI
• use the card name in the card header (i.e. in Schema mode, the bright blue card header should say “My Card Name” not “My-Card-Name”

General card properties

All cards should have the following properties:

• id
• card-name
• route

id

• id is generated by the system
• it has to be unique
• id cannot be changed
• id is internal and is not shown to the user

card-name

This is the name that users give to the card (the instance of the card) they create - whether it’s a regular instance of a card or a template. The name that users give to the card becomes the type for all cards that adopt this card.

• card-name doesn’t have to be unique
• card-name is required
• card-name can be changed

route

• it has to be unique
• by default, it would be a combination of dasherized card-name and (optional) some modifier to make it unique - populated as soon as user enters card name (or even in sync with it). E.g. if user enters “invoice template” into the card name field, and there is already a card with route “invoice-template”, we will suggest modified route “invoice-template-284” that user can still edit
• it can be changed by users provided it maintains uniqueness

The exact method of ensuring route uniqueness is TBD.
As user types the route we shall validate its uniqueness (whether as user types, with debounce, or on blur) and, if validation failed, suggest a modified version that is unique. For users’ convenience, we will label this field “Card URL” since non-developers might not be familiar with routing concept.

aliases/vanity URLs

In the future, we might create vanity URLs for cards, but that doesn’t change the card route.

• vanity URL has to be unique (same requirement as for route)

Designs

Regular

Route validation failed

Error state and message styling are in draft. Error state design will be addressed in a separate ticket.

XD file: https://drive.google.com/open?id=1QSAC1931gocLR_sgbHqPQIAiQ9oegQ5C

[bagby]

I agree with everything @habdelra said, and would go a step further and say ID’s should never be created by a user (and they should never be modified once created).

[habdelra]

Also we need to consider how we enforce the uniqueness constraint on ID’s and routes (aka slugs) for cards. If a user is creating a card’s ID then we need to make sure it doesn’t collide with an existing ID. same for a route, a user cannot set a route for a card to be the same as another card is using.

We could decide that ID’s are auto generated UUID’s (or something similar) and that alleviates the need for a user to worry about specifying duplicate ID’s.