> One way to enhance the usability of unique identifiers is by making them easily copyable.<p>No matter what your identifiers look like, if you want them to be easily copyable you should add `user-select: all` to the element containing them.<p>If you do this, all of the text will be selected automatically when you click on the element.<p><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/user-select" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/CSS/user-select</a>
> One way to enhance the usability of unique identifiers is by making them easily copyable. This can be achieved by removing the hyphens from the UUIDs,<p>No! That's throwing the baby out with the bathwater! Removing all separators means rare-but-important manual tasks of transcription or comparison become terrible, since there are no clear chunks.<p>Instead use a different character which doesn't have the same problem, one that most software considers part of the same "word"... such as the classic underscore.<p>For most people, double-clicking on this 123_456_789 will select all 9 important numbers. (And maybe a trailing space, but that's a separate problem.)
A couple other potentially desirable properties you could incorporate:<p>- K-sortable: ensures good locality when used as an id in a database (e.x. <a href="https://github.com/jetify-com/typeid">https://github.com/jetify-com/typeid</a> <a href="https://github.com/segmentio/ksuid">https://github.com/segmentio/ksuid</a> )<p>- checksum: primarily useful when an id might be conveyed verbally (e.x. customer support) or transcribed (e.x. Bitcoin wallet backup, BIP-39)
The author seems to be unaware of TypeID. You can use TypeID and ignore this article.<p><a href="https://github.com/jetify-com/typeid">https://github.com/jetify-com/typeid</a>
Related note: Amazon IAM credentials often look something like this (not real):<p><pre><code> aws_access_key_id = AKIA367COJQOEU3UOE
aws_secret_access_key = a7Ed0F80a0AF6606/MQG3+4o/o
</code></pre>
It's frustrating that you can select the access key by double clicking it but not the secret access key because of those / characters.
i keep a list of UUID reading and desirable properties here! <a href="https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20Notes/uuid%20list.md">https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...</a>
As someone who maintains a UUID library, this is definitely something that has been thought about, especially in the UUIDv6-v8 updates. But it was moved to be considered later as an extension after v6-v8 get approved fully.<p>But all these were talked about and considered before it was punted to a later time.
<a href="https://github.com/uuid6/uuid6-ietf-draft/issues/27">https://github.com/uuid6/uuid6-ietf-draft/issues/27</a>
<a href="https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft">https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d...</a>
<a href="https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/4">https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d...</a>
<a href="https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/2">https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d...</a><p>But there is always TypeID in the meantime which uses UUIDv7 under the hood: <a href="https://github.com/jetify-com/typeid">https://github.com/jetify-com/typeid</a><p>Either way, I am in favor of prefixing and using alternative encodings, but it will need some time to figure out the best route. In the mean time, there are so many alternatives. TypeID, NanoID, ULID, etc. I even made my own quick one just for giggles: <a href="https://github.com/daegalus/snowflakes">https://github.com/daegalus/snowflakes</a>
> In our MySQL database we use IDs mostly as primary key<p>Clustered index with random data stored as chars as the PK, what a great time! You will surely not regret this decision later.
Problem with using base58 is that it uses 24 letters (excl 'I') so you can end up with 4 letter words that the marketing/PR departments does not like.<p>Hexadecimal is safe.
> Try copying this UUID by double-clicking on it<p>Nobody does this. Normal users don't even know this is a thing. I worked on an app that did something like this for placeholders in generated text, and in all our extensive testing and high-touch rollouts, we never saw anyone use it.<p>It's nice that you took the time to think about it, but it's not that important.
Can use ULID to "fix" some issues<p><a href="https://github.com/ulid/spec">https://github.com/ulid/spec</a>
I built cybertoken [1] for API keys and passwords, not (only) IDs. It is basically the format that GitHub uses for their api keys. Underscores, a prefix, so we can get a better debugging experience and automated secret scanning. It also has a CRC32, so you can check offline if the token candidate is a cybertoken while doing secret scanning.<p>[1]: <a href="https://github.com/nikeee/cybertoken">https://github.com/nikeee/cybertoken</a>
I'd rather focus on optimizing the size of uuids than their text representation. Shipping uuids around as utf-8 text is silly. They're <i>at most</i> 128bits, so we shouldn't use more than that many.<p>In the case where it's necessary to have a text representation (e.g. in some user interface) I guess it's fine to choose whatever (stable) transformation you like, but the standard ways specified in RFC-4122 (hexadecimal, with or without hyphens) seem like the most foolproof. Regarding the logs search use case, the first "chunk" of a uuid is usually well more than enough for a unique match, IME.<p>Also, I've been burned before in cases where some clever transformation was used to make a uuid look different in text form, because in order to synthesize the actual binary uuid I first have to reverse engineer the transformation--e.g. to find the database record corresponding to some http request log message. That's just annoying, and the polar opposite of "user friendly" for the user story of an engineer trying to figure out what's wrong with the system.<p>So.. I guess my vote is to stick to the standard.
"Let’s not pretend like we are Google or AWS who have special needs around this. Any securely generated UUID with 128 bits is more than enough for us."<p>Thank you. This is overthought so much, including with partially-random things like uuid3, 5, 7.
An even better UUID UX would cycle through colors when you clicked one and then would overlay the assigned color when you see that same UUID elsewhere. Better to find a needle in a haystack if it's the only one with a pink background.
base58 is case sensitive which hinders readability. When devs work with uuids they typically remember the first few letters ("this is guid abc", "that one is guid 1ac"). Hard to do that in base58.<p>The coarsest encoding to have this property is Base32 where it remains easy to memorize first few letters without needing to memorize case.
> TLDR: Please don't do this: <a href="https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae561807fcaf" rel="nofollow">https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180...</a><p>But like... why? This article literally does not explain the benefits beyond copying, they are just assumed. I'm not immediately sold on shorter === better, especially when the updated UUIDs are only marginally shorter and you have now introduced the overhead of a translation layer for one of the most basic building blocks in your application.
Why would readability of a UUID matter? At most, users should by copy-pasting them, not reading them or trying to memorize them, so why should I and l and 1 looking similar matter?
Here is a thing I <i>wish</i> would Just Work, everywhere.<p>Given:<p><i>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</i><p>I'd like to, say, double click on <i>consectetur</i> to select it (which works), bt then, while holding Shift, I would like to double click on <i>elit</i> so that the selection of <i>consectetur</i> is preserved, and extended over <i>elit</i>, including <i>adipiscing</i>.<p>The behavior I typically see is that, while holding Shift, the first click will extend the selection to the exact character of <i>elit</i> that I'm pointing at. The second click will then cancel the selection and select all of <i>elit</i>.<p>Like it doesn't mean a damn thing that I'm holding down Shift!<p>Ironically, I can make multiple selections that way using Ctrl in Firefox; Ctrl does modify the semantics of the second click while there is a selection.
We need to separate the storage format (Postgres and MySQL both have a bigint serial for primary key and it should stay that way)<p>for display, you have various ways to encode that number into something easier for humans, what I prefer:<p>- short word
- no offensive words
- with a checksum (so we easily spot any copy paste mistake)
- not sequential
- can be put in a url without extra encoding<p>this is our implementation of that (base32 and luhn code)<p><a href="https://github.com/tttp/dxid">https://github.com/tttp/dxid</a>
> This can be achieved by removing the hyphens from the UUIDs, allowing users to simply double-click on the identifier to copy it.<p>Triple click can be used.
Q: What's special about the format of UUIDs compared to, say, an equivalent entropy 128-bit number? For many use cases, the hyphens appear to be utterly irrelevant.<p><a href="https://softwareengineering.stackexchange.com/questions/385524/what-is-the-minimum-length-for-a-uuid" rel="nofollow">https://softwareengineering.stackexchange.com/questions/3855...</a>
This is a great point. It's unfortunate that few engines and standard libraries implement base58 encoding/decoding. This is probably because it is a more complex format because it does not include certain ambiguous letters like l and O. Base64 is relatively straight forward to implement as it maps easily from a number to a character.
For user facing IDs I made base24 which limit the alphabet further to made it case insensitive.<p><a href="https://www.kuon.ch/post/2020-02-27-base24/" rel="nofollow">https://www.kuon.ch/post/2020-02-27-base24/</a>
TypeScript template literal types can be used to type-check IDs with prefixes: <a href="https://hw.leftium.com/#/item/39174998" rel="nofollow">https://hw.leftium.com/#/item/39174998</a>
If you expose UUIDs to the user, even if just as part of the URL, encode them as shortUUID: <a href="https://github.com/skorokithakis/shortuuid">https://github.com/skorokithakis/shortuuid</a>
I’ve always felt that Crockford Base 32 was very ergonomic. <a href="http://www.crockford.com/base32.html" rel="nofollow">http://www.crockford.com/base32.html</a>
Do they really have to be that long? And why can't they just be 4-4-4-4 (I'm sure someone knows). In hobby apps I often .split('-')[0] lol the first 8 is fine (so far)
Good points, wish they were specced into the original uuids so you don't need to postprocess (except for prefixes add those are more user-specific)
You also can't easily copy the word "double-click" by just double-clicking on it.<p>Maybe the browser (and other) UI is wrong about word boundaries.
The UX of UUIDs... should not exist. There are so many great ways to improve UX that don't involve overloading or mangling an internal primary identifier that otherwise follows a standard structure.<p>Use immutable human-readable identifiers like "slugs" and/or "natural keys" in addition to robust primary keys.<p>> TLDR Please don't do this: <a href="https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae561807fcaf" rel="nofollow">https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180...</a><p>That URL is fine, it should just be a 30X to <a href="https://company.com/stuff/cute-slug" rel="nofollow">https://company.com/stuff/cute-slug</a> and you should use the user-friendly URL where possible.
I at first misread "TLDR; Please don't do this:" as applying to the <i>entire</i> article. I read it expecting a kind of McSweeney's parody where it gives you terrible advice. Really confused because the advice was good and not funny.
Except that UUIDs by themselves don't do this at all:<p>> They provide a reliable way to ensure that each item, user, or piece of data has a unique identity.<p>It is the registration of a UUID in a database which prohibits reuse that does that. If you aren't do doing that, ensuring that each use of a UUID is not a reuse of an already assigned UUID, they are not UNIQUE.