mirror of
https://github.com/naturalcrit/homebrewery.git
synced 2026-03-30 03:18:14 +00:00
Created Folders: Collected Clippings (markdown)
ericscheid
589
Folders:-Collected-Clippings.md
Normal file
589
Folders:-Collected-Clippings.md
Normal file
@@ -0,0 +1,589 @@
|
|||||||
|
This is a file of collected clippings of conversations from gitter, discord, reddit, github, etc.
|
||||||
|
|
||||||
|
It's a chaotic mess. Don't try cleaning it up. Do copy/steal interesting stuff into the main wiki topic page for folders.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
|
||||||
|
Initially you'll be able to filter by tags on the user page, but as we
|
||||||
|
get user settings set up I plan on adding smart folders to the list
|
||||||
|
that key off of tags
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
DUMB FOLDERS
|
||||||
|
|
||||||
|
Dumb folders are just smart folders with a specific structure of
|
||||||
|
nested tags, unless you're planning on having them correspond to real
|
||||||
|
disk folders instead of just simulating that with metadata.
|
||||||
|
|
||||||
|
> /{route}/{route}/{resource} vs /{tag} and /{tag}
|
||||||
|
|
||||||
|
Hmm .. no .. folders will be a mechanism to view a curated collection
|
||||||
|
of brews. Each of those brews will have a resource uri of just
|
||||||
|
`/user/name/:brewid` — the folder path will not be exposed (for a
|
||||||
|
couple of reasons).
|
||||||
|
|
||||||
|
Or maybe not. [RESOLVE]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
If we have "folders" which act as views of curated collections of
|
||||||
|
brews, and have urls like `/user/name/foldername` or
|
||||||
|
`/user/name/foldername/nestedfoldername` .. and requesting that url
|
||||||
|
reveals the folder contents .. the brews listed there wouldn't include
|
||||||
|
the folder path in their respect URIs, right?
|
||||||
|
|
||||||
|
They'd be things like `/share/brewid` or `/edit/brewid`. Right?
|
||||||
|
|
||||||
|
Given the brewids are becoming perma-identifiers, while folder names
|
||||||
|
could come and go and mutate, and possibly even a brew could be placed
|
||||||
|
into multiple folders of one user, and certainly a multi-author brew
|
||||||
|
could be placed into multiple author folders (since folders are owned
|
||||||
|
and managed as a user thing, not a brew thing) .. it would be making a
|
||||||
|
lot of hard work for us to try supporting `/share/foldername/nestedfoldername/brewid`
|
||||||
|
(especially since the route could be parsed by totally discarding the
|
||||||
|
folder-path middle).
|
||||||
|
|
||||||
|
|
||||||
|
Dumb folders could be inferred from an array of strings in a code
|
||||||
|
fence in each brew - unless we want to make it easy for users to
|
||||||
|
rename/move folders (likely), and use a picker UI instead of “type the
|
||||||
|
path string” UI (also likely). Would also support creating empty
|
||||||
|
folders.
|
||||||
|
|
||||||
|
[RESOLVED: separate mongo entity, folder object contains array of brewids ]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
SMART FOLDERS
|
||||||
|
|
||||||
|
What smart folders are is a folder that instead of having a static set
|
||||||
|
of items that only changes when items are added/removed is a query
|
||||||
|
that calls for documents that meet criteria.
|
||||||
|
|
||||||
|
On smart folders, would we want criteria other than just tags?
|
||||||
|
Probably not for v0.1 of course, but eventually .. things like smart
|
||||||
|
folders for "edited recently", "viewed recently", or "most popular
|
||||||
|
brews"?
|
||||||
|
|
||||||
|
FWIW the idea of smart folders based off tags was going to be
|
||||||
|
implemented after we got user settings set up -- that way you'd only
|
||||||
|
see folders you created
|
||||||
|
|
||||||
|
We still need dumb folders before/contemporaneous with tags, to avoid
|
||||||
|
tag-misused-as-folder behaviour. (Assuming tags will become public
|
||||||
|
facing in various ways).
|
||||||
|
|
||||||
|
I think that overall smart folders would likely not be able to do more
|
||||||
|
than a query URL but it would give a nice UI. The only advantage it
|
||||||
|
might have is being able to nest it. So a dumb folder that holds smart
|
||||||
|
folders, etc. Its just a UI to hold queries in the end though.
|
||||||
|
|
||||||
|
I think the easiest way to make them useful would be to allow them to
|
||||||
|
hold folders in addition to a query. So you could put static items in
|
||||||
|
a smart folder so long as they were inside a dumb folder.
|
||||||
|
|
||||||
|
My personal desire for smart folders is the ability to group homebrews
|
||||||
|
simply. Having a folder for "forest" and a folder for "monsters" and
|
||||||
|
making a dryad statblock and it automatically goes into each when
|
||||||
|
given those tags. Or for instance making homebrew and tagging it with
|
||||||
|
everything relevant but also "campaign X" and having it go to the
|
||||||
|
campaign folder that the players have access to, even though it was
|
||||||
|
created in a different folder originally.
|
||||||
|
|
||||||
|
|
||||||
|
Smart folders could simply be dumb-folders with non-blank
|
||||||
|
smart-criteria. That way not only can the smart folder be placed
|
||||||
|
inside another folder (dumb or smart), but could also have other items
|
||||||
|
(brews, folders) placed within it.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
WHAT COMPLEXITY OF QUERY?
|
||||||
|
|
||||||
|
> (tag1 AND tag2) OR (tag3 AND tag1 AND tag4) NOT (tag5 OR tag6)
|
||||||
|
|
||||||
|
We could likely get away with a simple structure of an array of
|
||||||
|
queries, each query being executed in order and compiled into one
|
||||||
|
collection. The simplest version would be
|
||||||
|
|
||||||
|
[
|
||||||
|
[tag1, tag2, tag3],
|
||||||
|
[tag6, tag7]
|
||||||
|
]
|
||||||
|
|
||||||
|
.. but lets look ahead a little bit and make that more explicit, like this..
|
||||||
|
|
||||||
|
[
|
||||||
|
{ "and": [tag1, tag2, tag3] },
|
||||||
|
{ "and": [tag6, tag7] }
|
||||||
|
]
|
||||||
|
|
||||||
|
.. so we could later extend that to this..
|
||||||
|
|
||||||
|
[
|
||||||
|
{ "and": [tag1, tag2, tag3], "not": [tag4, tag5]}, // or ..
|
||||||
|
{ "and": [tag6, tag7] }, // or ..
|
||||||
|
{ "and": [tag8]}, //
|
||||||
|
{ "omit": [tag9, tag10] }, //
|
||||||
|
{ "omit": [tag11] }
|
||||||
|
]
|
||||||
|
|
||||||
|
But that is getting way ahead of what would be needed. Probably ever.
|
||||||
|
|
||||||
|
And also doesn't even support non-tag criteria. /sigh.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
FOLDER HIERARCHY
|
||||||
|
|
||||||
|
Folders will have a `parent-folder-id` property. That way a simple
|
||||||
|
nesting hierarchy can be established, and we don't have to worry about
|
||||||
|
loops. A blank `parent-folder-id` just means it is in the root (i.e.
|
||||||
|
userpage).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
USER FACING URLS?
|
||||||
|
|
||||||
|
> Ah and at that point we'd need Folders to exist as a whole separate
|
||||||
|
Mongo object that has relations back to brews, so we can use object
|
||||||
|
ids as urls instead of folder names
|
||||||
|
|
||||||
|
Object ids instead of folder names as user-facing UI ? hrmm
|
||||||
|
|
||||||
|
Would be useful internally to avoid breaking links when things get
|
||||||
|
renamed
|
||||||
|
|
||||||
|
But I do like being able to rattle off “/users/erics/friday-game” in a
|
||||||
|
socmed chat to a new player.
|
||||||
|
|
||||||
|
That's also fair -- and for that we could get into published folders
|
||||||
|
vs unpublished ones if we wanted
|
||||||
|
|
||||||
|
URLs being object ids would also allow you to share them more
|
||||||
|
privately so people don't just url spam until they find a valid folder
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
PASSWORD PROTECTED FOLDERS
|
||||||
|
|
||||||
|
> object ids would also allow you to share them more privately so
|
||||||
|
> people don't just url spam until they find a valid folder
|
||||||
|
|
||||||
|
This is a difficult problem. We want users to share a folder, but only
|
||||||
|
to a limited audience, most/many of which won’t present any
|
||||||
|
credentials on request. An obfuscated mumble-token does work for that,
|
||||||
|
but does require sharing that mumble-token instead of the friendly
|
||||||
|
name.
|
||||||
|
|
||||||
|
Another method might be basic auth on the folder .. share the friendly
|
||||||
|
url and the password and your anon buddies can view. Others guessing
|
||||||
|
the friendly url hit the gate, do not pass go.
|
||||||
|
|
||||||
|
|
||||||
|
Maybe do something like Google sharing URLs!? Generate a "token" that
|
||||||
|
is passed as a query parameter and lasts until it is revoked -- if the
|
||||||
|
token isn't present and valid then you can't access the folder
|
||||||
|
|
||||||
|
Hmm .. sociologically I like the having the "token" be named a
|
||||||
|
"password". Not only has it the tech features, it also communicates
|
||||||
|
“this is a private space”.
|
||||||
|
|
||||||
|
|
||||||
|
Was almost about to suggest three states: folders anyone can view with
|
||||||
|
the url, password required, and folders only I can view. Yeah nah,
|
||||||
|
this can be done with just a password field: no password, password
|
||||||
|
shared, password not shared. Problem solved.
|
||||||
|
|
||||||
|
Side note: an author should not be prompted for the password of a
|
||||||
|
password protected folder if it is a folder they created.
|
||||||
|
|
||||||
|
|
||||||
|
Minor issue of leakage of existence tho (password prompt vs 404).
|
||||||
|
People will know you have a folder named "My Naughty Brews", there
|
||||||
|
would be no plausible deniability. We could always force the password
|
||||||
|
to be on a query param instead of in the browser window.
|
||||||
|
|
||||||
|
So `/../folder` → 404, but `/../folder?p=secret` → access?
|
||||||
|
And `/../folder?p=wrong_secret` would also be 404
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
TAGS UI:
|
||||||
|
|
||||||
|
> I assume only the OG author can add and remove authors?
|
||||||
|
|
||||||
|
> I assume only the OG author can add and remove tags?
|
||||||
|
|
||||||
|
So that's the thing -- we don't actually have a way to distinguish the
|
||||||
|
original author vs added authors. So while this is obviously a huge
|
||||||
|
improvement, it could still be a problem if someone malicious was
|
||||||
|
given edit access
|
||||||
|
|
||||||
|
Secondarily, only letting `author[0]` edit authors would be nice but
|
||||||
|
at least preventing removal of `author[0]` would be ideal.
|
||||||
|
|
||||||
|
Hmm. Well I would like to at least see `author[0]` never being able to
|
||||||
|
be removed if nothing else. It would be dumb if someone could remove
|
||||||
|
your perms after you shared it…
|
||||||
|
|
||||||
|
Eventually, this might be managed via a `owningAuthor` field on the brew.
|
||||||
|
|
||||||
|
The existence of an `originalAuthor` field, more properly known as
|
||||||
|
`owningAuthor` field, would imply the existence of a `transfer
|
||||||
|
ownership` UI.
|
||||||
|
|
||||||
|
And raises questions about what happens with google-drive brews when
|
||||||
|
the owner changes.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
DO TAGS *AFTER* FOLDERS
|
||||||
|
|
||||||
|
Hmm .. we’re gonna have to hold off on brew tags until we also get
|
||||||
|
user folders implemented .. because users *will() use tags as
|
||||||
|
folder-proxies, and I don’t want to see a folder magically appear
|
||||||
|
named “dumb shit I’ll get to later” (because of an added author adding
|
||||||
|
a tag). Especially if I have that brew marked as Published.
|
||||||
|
|
||||||
|
FWIW the idea of smart folders based off tags was going to be
|
||||||
|
implemented after we got user settings set up -- that way you'd only
|
||||||
|
see folders you created.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
TAGS BY INCREMENTS
|
||||||
|
|
||||||
|
I think the best plan for tags to start is just an incremental release
|
||||||
|
where we release the ability to add tags, they show up, and you can
|
||||||
|
filter by them
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
FOLDERS AS SPECIAL CASE OF TAGS?
|
||||||
|
|
||||||
|
> Those are just two separate tagging mechanisms. You could have a url
|
||||||
|
route strategy which displays them differently, but I'm not sure why
|
||||||
|
they'd have to be implemented as entirely different systems. It seems
|
||||||
|
redundant. What I'm saying is that you can implement folders using
|
||||||
|
whatever framework you come up with for tagging files. They don't have
|
||||||
|
to internally be two systems.
|
||||||
|
|
||||||
|
Now, in theory, both types of folders (dumb, smart) could be done with
|
||||||
|
tags. A dumb folder would be "show all documents with the tag (read:
|
||||||
|
folder ID) 'folder:j12h3j2ebjy'", and a smart folder would be "show
|
||||||
|
all documents that are tagged as a monster and made by jeddai". Adding
|
||||||
|
a document to a dumb folder would add the folder tag. Showing the tags
|
||||||
|
that dumb folders use would be a suboptimal user experience because I
|
||||||
|
imagine that a folder ID would be a UUID or something similar, but
|
||||||
|
that is a way that could do both.
|
||||||
|
|
||||||
|
|
||||||
|
On the other hand, it would be more convenient to store a list of
|
||||||
|
brewids into a folder object, instead of folderid (or list of
|
||||||
|
folderids) into a brew object. A) If a folder is deleted, it would
|
||||||
|
entail deleting one folder object (vs updating multiple brew objects
|
||||||
|
to suit), and B) things get messy when different users can and will
|
||||||
|
put the one brew into each of their own folders (folders are user
|
||||||
|
centric objects).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
PUBLIC VS PRIVATE TAGS
|
||||||
|
|
||||||
|
> All public tags are actually "public:{tag}" and the tag search only
|
||||||
|
looks for ones that match 'public:{tag}'. Or maybe the reverse of
|
||||||
|
that, it ignores tags that have 'private:{tag}'
|
||||||
|
|
||||||
|
However, “private:{tag}” clashes with an idea of tag categories. Like
|
||||||
|
“system:PF2” and “genre:Fantasy”. Look at GMB high-level categories of
|
||||||
|
tags for practical examples.
|
||||||
|
|
||||||
|
That said, perhaps an attribute could be added to tags, like
|
||||||
|
"genre:erotic-punk{private}".
|
||||||
|
|
||||||
|
This is all orthogonal to whether a brew is published or not. This is
|
||||||
|
about whether a published brew would have all the author tags made
|
||||||
|
visible on that brew.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
SMART FOLDERS VS SERVER PERFORMANCE
|
||||||
|
|
||||||
|
> Bogging down the server with complex and large queries is not exactly
|
||||||
|
optimal so I imagined you guys would find some reasonable limit that
|
||||||
|
gave it minor flexibility without punishing your usage
|
||||||
|
|
||||||
|
The full list of a user's brews would be retrieved in one call on the
|
||||||
|
back end, and then they are processed and displayed on the front end
|
||||||
|
via react. So, at worst, it only slows down the client not the server.
|
||||||
|
All the same, I'd prefer simpler too.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> Hmm .. if a brew is put into a dumb folder, we'd remove it from the
|
||||||
|
top level view. But what happens to brews that appear in smart
|
||||||
|
folders [according to smart criteria]?
|
||||||
|
|
||||||
|
Smart folders would likely be "illegal locations" to store a brew,
|
||||||
|
they merely query them from other locations. So it would just be
|
||||||
|
wherever it was created, root or dumb folder, but also the smart
|
||||||
|
folder.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Wait .. if someone was thinking they'd use smart folders to tidy up
|
||||||
|
their userpage, then they'd be disappointed. They'd have to manually
|
||||||
|
shunt all the brews they want not visible on the base userpage into a
|
||||||
|
dumb folder.
|
||||||
|
|
||||||
|
Would smart folders scan all brews, including brews that have been
|
||||||
|
shunted into either sub-folders or even into sibling folders? For
|
||||||
|
example, I create a dumb folder for "My Traveller™ game", and toss all
|
||||||
|
those brews in there. If I then have a smart folder inside that folder
|
||||||
|
for tag=monster, I probably wouldn't want monsters from "My Pokemon™
|
||||||
|
game" to appear there, right?
|
||||||
|
|
||||||
|
Maybe that could be a filter? Or even just a checkmark? Like, "search
|
||||||
|
sub folders" and "search sibling folders" would be options? because I
|
||||||
|
can definitely imagine having a single monster in multiple folders. I
|
||||||
|
can't imagine why a smart folder would be a valid location for a brew
|
||||||
|
to live permanently though, because part of the reason to have a smart
|
||||||
|
folder would be to keep the same brew in multiple locations without
|
||||||
|
having to duplicate it. And it makes no sense to have a folder with no
|
||||||
|
static values to be where a brew "lives" if it can also be seen in
|
||||||
|
other locations?
|
||||||
|
|
||||||
|
Agree, smart folders are lenses, not locations.
|
||||||
|
|
||||||
|
Rename "folders" as being lenses? Does a nested hierarchy of lenses
|
||||||
|
make sense? (Isn't that a microscope?)
|
||||||
|
|
||||||
|
|
||||||
|
I know that from a database perspective what I am talking about is
|
||||||
|
more like a view. But I think for the average person that "smart
|
||||||
|
folder" will more clearly express what it is than lense or view. I
|
||||||
|
guess "filter" is fairly ubiquitous if we are looking for a new name.
|
||||||
|
|
||||||
|
We're using "filter" to refer to the free-form filtering widget at the
|
||||||
|
top of the userpage. Hmm, no wait, we're also using "search" for that.
|
||||||
|
I think "filter" as a term is only used in the backend or in a css
|
||||||
|
class. Time for a tiny refactor to tidy up nomenclature.
|
||||||
|
|
||||||
|
People filter their emails and excel sheets.
|
||||||
|
|
||||||
|
True, "search" as a UI is usually thought of as a
|
||||||
|
command-and-response, while "filter" is more a live and dynamic update
|
||||||
|
of the view.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
A BREW IN EVERY PORT
|
||||||
|
|
||||||
|
We're planning on allowing a specific brew to be placed into multiple
|
||||||
|
dumb folders. Think of them as symlinks.
|
||||||
|
|
||||||
|
So just a desktop shortcut but for brews? xD
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
VERY EARLY TAG DISCUSSIONS:
|
||||||
|
|
||||||
|
|
||||||
|
It would be cool to be able to share a whole Folder at a time, rather
|
||||||
|
than individual brews, too.
|
||||||
|
|
||||||
|
It made me think it might be possible to use a Route like
|
||||||
|
/user/:id/:folder_name to access another user's brews that are both
|
||||||
|
Published and tagged with 'folder:{folder_name}'. Of course, that
|
||||||
|
needs both tagging brews and brew filtering by tags to be in place and
|
||||||
|
functional first, which at this point is are likely extensions to
|
||||||
|
follow on from the current brew sorting work.
|
||||||
|
|
||||||
|
So the end user would only need to navigate to
|
||||||
|
homebrewery.naturalcrit.com/user/Gazook89/my_homebrew_campaign to see
|
||||||
|
all of that published material.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
If we have "folders" which act as views of curated collections of
|
||||||
|
brews, and have urls like `/user/name/foldername` or
|
||||||
|
`/user/name/foldername/nestedfoldername` .. and requesting that url
|
||||||
|
reveals the folder contents .. the brews listed there wouldn't include
|
||||||
|
the folder path in their respect URIs, right?
|
||||||
|
|
||||||
|
They'd be things like `/share/brewid` or `/edit/brewid`. Right?
|
||||||
|
|
||||||
|
Given the brewids are becoming perma-identifiers, while folder names
|
||||||
|
could come and go and mutate, and possibly even a brew could be placed
|
||||||
|
into multiple folders of one user, and certainly a multi-author brew
|
||||||
|
could be placed into multiple author folders (since folders are owned
|
||||||
|
and managed as a user thing, not a brew thing) .. it would be making a
|
||||||
|
lot of hard work for us to try supporting
|
||||||
|
/share/foldername/nestedfoldername/brewid (especially since the route
|
||||||
|
could be parsed by totally discarding the folder-path middle).
|
||||||
|
|
||||||
|
|
||||||
|
Yah. Punt the question of what do we do if
|
||||||
|
`/user/name/foldername/oops-this-was-renamed/brewid` is clicked. Will
|
||||||
|
that be `404 NOT FOUND`, or `300 MULTIPLE CHOICES` (because it could
|
||||||
|
be in multiple folders) or `301 MOVED PERMANENTLY` or `302 FOUND` or
|
||||||
|
`418 I'M A TEAPOT`?
|
||||||
|
|
||||||
|
It should likely be `400 BAD REQUEST` (because we simply don't support
|
||||||
|
routes-to-brews).
|
||||||
|
|
||||||
|
Also, is this a URI to a brew, or to a strangely named folder:
|
||||||
|
`/user/name/folder/nested/Z2yOC6xNMpKc`. (The latter, of course, and
|
||||||
|
we shouldn't be asking the server to guess).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
On the folder subject, my thinking was less folder hierarchy and more
|
||||||
|
groups. Actually "group" might be a better term, as it doesn't imply a
|
||||||
|
multi-layer parent-child hierarchy in the way that "folder" does. So
|
||||||
|
the hypothetical functionality is that user's Brews can be filtered to
|
||||||
|
a group of brews defined by the tag "group:group_name", perhaps
|
||||||
|
accessible via a Route (e.g. /user/:id/:group_name). This should be a
|
||||||
|
fairly natural extension to filtering Brews by title.
|
||||||
|
|
||||||
|
So my progression plan for this project is roughly [x] Sorting => [ ]
|
||||||
|
Filtering by Title => [ ] Filtering by System => [ ] Filtering by Tag
|
||||||
|
=> [ ] Custom User tags
|
||||||
|
|
||||||
|
You know, in between and around the other stuff I'm already doing and
|
||||||
|
need to get back to first.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
On filtering: there are two different features to be considered
|
||||||
|
|
||||||
|
a shareable permalink that shows only the matching brews a UI widget
|
||||||
|
that facilitates live filtering of the account page I have a
|
||||||
|
javascript-injection stub that works for #2, although it can also be
|
||||||
|
done via react.
|
||||||
|
|
||||||
|
On (1), a wrinkle might be not allowing escalation exposure. That is,
|
||||||
|
if I give you /user/erics/fridaygame, you certainly could escape to
|
||||||
|
/user/erics (of course), but I might wantsundaygame and fridaygame to
|
||||||
|
not be visible from there (while still exposing lore).
|
||||||
|
|
||||||
|
|
||||||
|
I think groups could have a similar "published" status that hides them
|
||||||
|
if you are not logged in.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
In my thinking, group is a special tag. One brew can have multiple
|
||||||
|
group tags, but the filter term 'group:A' will only find brews tagged
|
||||||
|
with 'group:A'. Custom user tags can use [A-Za-z0-9], all symbols
|
||||||
|
reserved for future use, so a tag containing a colon (e.g.
|
||||||
|
'group:erics') can only be applied through the UI. The structure
|
||||||
|
itself is still flat, so in this thought experiment, ALL brews are
|
||||||
|
still visible at /user/erics (to the user, and if published, the
|
||||||
|
public) but are automatically filtered to just the group:fridaygame at
|
||||||
|
/user/erics/fridaygame.
|
||||||
|
|
||||||
|
It's not impossible to imagine a publish_in_group:true tag that makes
|
||||||
|
it visible to the public (like PUBLISHED) but only when viewed via the
|
||||||
|
group.
|
||||||
|
|
||||||
|
A better version being publish_in_group:fridaygame, to specify which
|
||||||
|
group to publish it in, rather than just publishing it in all groups
|
||||||
|
it's attached to.
|
||||||
|
|
||||||
|
If I put a brew in a group, I would want it to be visible when that
|
||||||
|
group is shared. I can't think of a situation for putting a brew in a
|
||||||
|
group but the brew wouldn't be published. (Unless it's an unpublished
|
||||||
|
brew?)
|
||||||
|
|
||||||
|
So it comes down to whether the tag/group/ui (e.g. fridaygame) is
|
||||||
|
exposed on the home page. Someone could be given
|
||||||
|
/user/erics/fridaygame, escalate to /user/erics, see some interesting
|
||||||
|
tags there of published brews, and thus also visit /user/erics/lore to
|
||||||
|
see a list of brews with that tag (because I've not hidden that tag).
|
||||||
|
|
||||||
|
The published/unpublished status of a brew should still be respected
|
||||||
|
though. I might have a "Halloween Rules" brew I put into :fridaygame
|
||||||
|
and :sundaygame and :mondaygame ahead of time, and only push to
|
||||||
|
publish mid October. Similarly, if I un-publish "House Rules" then I'd
|
||||||
|
want that to not be listed in any group, even if still tagged.
|
||||||
|
|
||||||
|
Yes, unpublished brews will never be visible to users who are not
|
||||||
|
listed as an author.
|
||||||
|
|
||||||
|
Not visible in a listing. They can still be shared and visited.
|
||||||
|
|
||||||
|
On syntax of tags .. I think I wrote something on that at some point,
|
||||||
|
something like <grouping>:<value>, where <grouping> could be preloaded
|
||||||
|
with {meta, type, system, version} and associated tags (e.g.
|
||||||
|
system:D&D, version:2e, type:lore; or system:Pathfinder,
|
||||||
|
type:adventure; etc). Hmm .. maybe not separate system and version.
|
||||||
|
We'd still want to allow multiple tags of the same grouping, such as
|
||||||
|
[meta:lore, meta:feats, meta:monster] or even [system:d&d5e,
|
||||||
|
system:pathfinder2e]. There would be some nonsense or unlikely
|
||||||
|
combinations, but we shouldn't preclude those possibilities
|
||||||
|
|
||||||
|
People are bound to have Brews that encompass Lore, Feats, Classes,
|
||||||
|
etc. It's not hard to envisage a brew for a Homebrew race of
|
||||||
|
unpleasant-goose-humanoids, for example, that has custom Racial Feats
|
||||||
|
(Fly, Honk) and adds homebrew twists to existing Classes (Barbarian of
|
||||||
|
the Golden Bell, White Feather Rogue) or creates new ones entirely.
|
||||||
|
|
||||||
|
Also possible someone might author a brew tagged [system:d&d2e,
|
||||||
|
meta:feats] or even [system:d&d5e, meta:nwp].
|
||||||
|
|
||||||
|
|
||||||
|
And of course just because we pre-define meta, system (or game), and
|
||||||
|
type, that doesn't mean a user couldn't mint their own grouping terms
|
||||||
|
and tags (e.g. tone:silly).
|
||||||
|
|
||||||
|
Ugh .. does this mean we might also want to filter by grouping? "Show
|
||||||
|
me all brews tagged with tone:".
|
||||||
|
|
||||||
|
Also, on the system vs version question
|
||||||
|
.. sub-tags that qualify the group:tag?
|
||||||
|
e.g. `system:d&d:2e``, `tone:silly:very``.
|
||||||
|
|
||||||
|
(the Library Sciences part of my backstory is emerging)
|
||||||
|
|
||||||
|
Getting ahead of ourselves here though. We should perhaps reserve `:`
|
||||||
|
as a special character in tag names.
|
||||||
|
|
||||||
|
It certainly should be possible for a user to enter an ungrouped tag:
|
||||||
|
`fridaygame``, `session_zero``, `storytime`.
|
||||||
|
|
||||||
|
My thinking is that only tags that follow the form `group:name` qualify
|
||||||
|
as groupings and would be accessible via ``/user/:id/:group` However it
|
||||||
|
should still be possible to filter by custom tags like tone-silly
|
||||||
|
|
||||||
|
[NB. the idea of implementing folders via tags i.e. `group:` was later
|
||||||
|
abandoned. There are useful and helpful things we can do if folders
|
||||||
|
are maintained as separate objects.]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user