Handwritten label codes

[bradgessler]

Not everybody is going to buy a thermal label printer. Even though they're awesome, they cost at least $100, which is a barrier for people who want to get a feel for Thingybase before they commit to spending that.

The code should be short, just a few digits, so that it can be written on a box or piece of paper with a Sharpie.

Later, to find the box, the person looking for the item would punch the code into their account, which would effectively search for the items.

Concerns

The nice thing about labels now is they're globally unique. They're just URLs. If you're not logged in and you scan the label, it will ask you to login and get to where you're trying to get. A code wouldn't be globally unique, so it would be more difficult to get the person to the right place.

Complicating that, unlike the labels, a handwritten code wouldn't have any instructions or context around it on a box. The person who is organizing would have to set that up, which could limit the utility of the handwritten codes and make it more difficult for collaboration.

[ab623]

Does a code have to be globally unique? For this code I was thinking as long as it is unique to the user that should be enough, as you'd have to be logged in to search for this code anyway, unlike QR codes which will link you to the page even if you are logged out.

A 4 char a-z0-9 code will give 36^4 = 1.68 million unique codes. More than enough for each item, even though for me personally, my use case would mainly be writing this code on boxes to "see inside them" when searching with the code via the website.

[bradgessler]

The codes wouldn't have to be globally unique. Would you be OK if the codes were like this?

LHSa

I think I'd have to make the case insensitive so that LHSa, lhsa, and LHSA would all work.

Where would one enter the code? I could have www.thingybase.com/code the place where the codes are entered.

[ab623]

That makes sense to me. I think the case insensitivity makes sense too. In regards to searching,

For search - I suggest using the existing search box. In the search results, if the code was matched, the result could be highlighted at the top. Then all other standard results could be listed below in a new section.

[bradgessler]

Good deal on the search box.

Technical note: the ID in the URL is actually a shortened UUID. I might have to display a few digits of the UUID for the label, which should be fine. The advantage to this is I no longer have to worry about case since its a hex-base system.

[bradgessler]

I got the search wired up to look for the first 6 (or more) digits of the label UUID. I still need to make it more obvious that there's a "handwritten code" that can be put on a box, but if you want to start handwriting codes on the box now you can do so.

In the example label below, the UUID is 34eb811d-d91f-4903-b39e-6fbe6e6baac3, so you could write 34eb81 on a box and find the item in the search in the top left. You could enter more chars too like 34eb811d-d9 or the whole thing like 34eb811d-d91f-4903-b39e-6fbe6e6baac3.

I think there's some more informative UI that could be put into place that makes this much better and instructing people the they can write the code on the box or item and find it later. That will come next.

[bradgessler]

I've got a working UI for viewing handwritten codes that can be written on items or boxes for finding later. Here's what it looks like:

This has been deployed and will receive further tweaks. Now is a good time to give feedback about this feature.

[ab623]

That looks good. I used it and it works rather well! Nice job.

My only slight issue with the label mechanism, is if I ever delete the label I cant regenerate the same label, it will create a fresh UUID. Not a big deal, but something I was going to point out. Seems like once an item is created the the label ID should remain static.

[bradgessler]

That confirms a suspicion I have that the architecture of labels is overly complicated.

Hold off creating a bunch of codes until I get a chance to simplify the way codes work so they're associated more directly with the item. It should take about a day for me to make this fix.

I'll chime in on here when it's OK to start labeling a bunch of stuff with the codes.

[bradgessler]

Alrighty, I made the changes so that the code refers to the item instead of the label. This addresses the feedback from @ab623 (thanks so much! 🙇) and eliminates the code embargo from the message above.

Now you can write 6 digit labels over items, etc. and not worry about them breaking 🤠.

Next steps...

The label code indirection was caused by some over-optimized architectural decisions made over a year ago to solve for the following two problems that turned out not to be problems:

1. What if somebody wants multiple labels to point at the same item and
2. What if people want to create an label and attach it to an item later

@ab623 confirmed my suspicions that these were edge cases and create more confusion than its worth. That means I get to clean things and greatly simplify some internals in the application in addition to making the UI less cluttered.

Impact

This won't impact codes or labels unless you are relying on item URLs (not label URLs or codes). I estimate this will impact 0 people.

The only reason you would rely on item URLs or UUIDs is if you hacked on an internal Thingybase API or bookmarked an item or container. If you bookmarked an item or container and it ends up being a 404 down the road, you'll just have to search for it again and re-bookmark. Chime in if that's a big problem for you and a slightly more complicated migration could be chosen.

[bradgessler]

Did a bunch of backend work the resulted in the removal of the "Delete" button for people who are watching here.

Technical note: I removed the database-backed ActiveRecord "Label" record and replaced it with an ActiveModel object that heavily delegates to items schema. The labels schema is still around, but will be deleted within the next few days if I don't hear back on any issues.