Open bradgessler opened 3 years ago
Not sure if if this is the best place to put it, but a use case I had was around quantity.
For example it would be good to have an easy interface to store a quantity of an item - e.g Toilet Rolls - Quantity 10. Then an easy mechanism to "Take 1" which decrements the counter by 1. This will make it very easy from the user interface to quickly open storage take one or more of that item, and keep thingybase updated - rather than doing an edit and text update.
Custom fields in general is a great but as you mentioned they could spin off into separate features. For me a custom field allows to user to create a simple field on any item, they create a field name and add the value. Thats it. If they want that same field on all items they will need to create it manually on every item they want it on.
I think the above types you mentioned should be their own features in their own right.
For me - based on my usage so far I would be interested in Size, Quantity, Colour, Is Empty flag.
The field would also need a type, in addition to a name and value.
For example, if you wanted an "expiration date" field, you'd want it to be a date field so you can ensure only dates are in that field, have a date picker, etc.
That would also make it possible to search & filter more intelligently since it could reason more from a date (as opposed to just a text field that happens to be a date).
This is why I think templates will be important. For example, people won't want to create an item and add an expiration date each time, so instead they could create a "Perishable" template that would require less setup time each time they want to make a bunch of those.
For the toilet paper example, I'd imagine a template called a "bin" or something (not s great name). It would have the name and a numeric field called "quantity" and by a "quantity" type. The quantity type would give you URLs, APIs, controls, UIs, etc to handle incrementing and decrementing in a sane way.
Custom fields could be really complicated and get messed up if not done properly, so I want to make sure I do it right. Expect this to marinate for a while as I mull over it and get feedback from others for what they'd want to do with custom fields. What's more likely to happen is each use case for custom fields will get broken out into its own feature, because "custom X" is usually code for "I want X, but I don't quite understand it". For example, it's easy to think an expiration date is a custom field, but then you probably want to get an email if something is about to expire, which would make that its own feature.
Here's a few types of custom fields to consider:
The question is, what would you want to do with that data once it's stored? That question is what will lead to something more interesting.