You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes! I'm hoping it can both serve in the way you're saying as well as help with nuance, i.e., when someone wants to be called Bi+disabled and someone else wants to be referred to by pan+PwD.
Are you suggesting that we should avoid with longer terms, like disabled? Or something else that I'm missing?
Oh yes, that was definitely my intent. I want this to be as exhaustive as possible (while still allowing it to be useful in say, Twitter bios)... but I might not have made my hope very clear in my initial issue file. 🙈
Reacted by Kai Ase Siren, Joseph Thomas and Myles Lewando
The simplest form could be /search?q=propA+propB+propC. The order of the items in the querystring could determine the order of the results shown so that folks can decide which is most important to them. It's similar to linking to a search result that just filters down from all available items to the ones that match the comma-separated selectors. It would also be worth making it fuzzy enough that it gracefully handles typos and alternate spellings.
I really like the idea of letting the order of the query strings determine the order of elements on the page.
I am torn, though, on the use of /search for this case. It feels a bit too … maybe: technical for the use case of describing myself.
Maybe it could be something like www.selfdefined.me/?defines="[termA,termB,termC]". Where the query string is effectively the result of calling JSON.stringify on an array of the slugified terms.
We could also have a page like /define with a search input that lets users search and combine their personal combination.
Edit (19-10-21, 21:20): Realised that Tatiana has mentioned the domain selfdefined.me in the OP and updated links accordingly
Perhaps you could use selfdefined.me/is/<term>/(and|or|not|but)/<term>/(and|or|not|but)/<term>, so I could do:
selfdefined.me/is/heteronormative/and/bisexual/or/pansexual — I appreciate that this means long URLs, so I suggest that two things happen:
where possible replace terms with abbreviations/acronyms (e.g. selfdefined.me/is/heteronormative/and/bi/or/pan)
for short URLs, each term and joining word should be deterministic... I don't really have reasoning for this except that it feels like a good thing to d. It makes it impossible to track an individual between social accounts who re-use their short links by tracking the uniqueness?
make /is/ optional (or drop it altogether)
Additionally, the use of + to indicate "and" is problematic as it has URL encoded (%2B) or it will be treated as a space, making it difficult to include terms with a space in them.
Sure. In application we will want to be careful not to universally shorten words that have sensitivity around the acronym, such as the case with non-binary down to enby (Many non-binary individuals reject enby as they feel it's infantilising.)
Do you mind elaborating on this point a bit more? I'm not sure I understand fully
I agree. I think that the selfdefined.me/ prefix suffices for the amount of explanation you can get just from the URL. /is/ also doesn't make a ton of grammatical sense in this flow.
That's a good point about + signs turning the URL into less human-perceivable language. The intent is to have it be somewhat human perceivable to pique curiousity (as is the case with pronoun.is
I worry about it being confusing with all the forward slashes. Could underscores work? What are our options here? (Is it only non-encoded non-reserved/available characters?)
For ex: selfdefined.me/pan_queer
selfdefined/web-app#72 Would support storage of the % encoded link, so whatever you decide on as the linking structure as long as you encode it (and implement the service right) this should be handled.
Sure. In application we will want to be careful not to universally shorten words that have sensitivity around the acronym, such as the case with non-binary down to enby (Many non-binary individuals reject enby as they feel it's infantilising.)
It's also close to "NB" or "Non-Black", which makes it a kind of controversial term in many ways.
Sure. In application we will want to be careful not to universally shorten words that have sensitivity around the acronym, such as the case with non-binary down to enby (Many non-binary individuals reject enby as they feel it's infantilising.)
I think if we allow aliases, then it's up to the individual?
Do you mind elaborating on this point a bit more? I'm not sure I understand fully
I am concerned that if we generate unique short URLs — e.g. selfdefined.me/is/heteronormative/and/bisexual/or/pansexual becomes selfdefined.me/d345jd — then I can tell user Foo on Twitter is also user Bar on FetLife, a connection that the individual may not want to disclose, and which could be used to harm them (i.e. facilitates doxxing). Instead we should normalize the URLs such that different permutations of the same thing (e.g. /bi/or/pan is the same as /pan/or/bi) always yield the same string and then generate the same short URL.
Activity
coilysiren commentedon Oct 20, 2019
Wildcard consideration: I would ideally use this with acronyms, like
WoCTWoCQTPoCetc etc. So that I can have a URL like
selfdefined.me/qtpoctatianamac commentedon Oct 20, 2019
Yes! I'm hoping it can both serve in the way you're saying as well as help with nuance, i.e., when someone wants to be called
Bi+disabledand someone else wants to be referred to bypan+PwD.Are you suggesting that we should avoid with longer terms, like
disabled?Or something else that I'm missing?coilysiren commentedon Oct 20, 2019
I'm suggesting we use both, and allow people to mix and match them however they want! 👩🔬
tatianamac commentedon Oct 21, 2019
Oh yes, that was definitely my intent. I want this to be as exhaustive as possible (while still allowing it to be useful in say, Twitter bios)... but I might not have made my hope very clear in my initial issue file. 🙈
Primigenus commentedon Oct 21, 2019
The simplest form could be
/search?q=propA+propB+propC. The order of the items in the querystring could determine the order of the results shown so that folks can decide which is most important to them. It's similar to linking to a search result that just filters down from all available items to the ones that match the comma-separated selectors. It would also be worth making it fuzzy enough that it gracefully handles typos and alternate spellings.ovlb commentedon Oct 21, 2019
I really like the idea of letting the order of the query strings determine the order of elements on the page.
I am torn, though, on the use of
/searchfor this case. It feels a bit too … maybe: technical for the use case of describing myself.Maybe it could be something like
www.selfdefined.me/?defines="[termA,termB,termC]". Where the query string is effectively the result of callingJSON.stringifyon an array of the slugified terms.We could also have a page like
/definewith a search input that lets users search and combine their personal combination.Edit (19-10-21, 21:20): Realised that Tatiana has mentioned the domain
selfdefined.mein the OP and updated links accordinglydshafik commentedon Nov 18, 2019
Perhaps you could use
selfdefined.me/is/<term>/(and|or|not|but)/<term>/(and|or|not|but)/<term>, so I could do:selfdefined.me/is/heteronormative/and/bisexual/or/pansexual— I appreciate that this means long URLs, so I suggest that two things happen:selfdefined.me/is/heteronormative/and/bi/or/pan)/is/optional (or drop it altogether)Additionally, the use of
+to indicate "and" is problematic as it has URL encoded (%2B) or it will be treated as a space, making it difficult to include terms with a space in them.tatianamac commentedon Nov 19, 2019
@dshafik Thanks for this insight!
non-binarydown toenby(Many non-binary individuals rejectenbyas they feel it's infantilising.)selfdefined.me/prefix suffices for the amount of explanation you can get just from the URL./is/also doesn't make a ton of grammatical sense in this flow.That's a good point about
+signs turning the URL into less human-perceivable language. The intent is to have it be somewhat human perceivable to pique curiousity (as is the case with pronoun.isI worry about it being confusing with all the forward slashes. Could underscores work? What are our options here? (Is it only non-encoded non-reserved/available characters?)
For ex:
selfdefined.me/pan_queerhibaymj commentedon Feb 14, 2020
selfdefined/web-app#72 Would support storage of the % encoded link, so whatever you decide on as the linking structure as long as you encode it (and implement the service right) this should be handled.
lorarjohns commentedon Jul 10, 2020
It's also close to "NB" or "Non-Black", which makes it a kind of controversial term in many ways.
dshafik commentedon Jul 10, 2020
I think if we allow aliases, then it's up to the individual?
I am concerned that if we generate unique short URLs — e.g.
selfdefined.me/is/heteronormative/and/bisexual/or/pansexualbecomesselfdefined.me/d345jd— then I can tell user Foo on Twitter is also user Bar on FetLife, a connection that the individual may not want to disclose, and which could be used to harm them (i.e. facilitates doxxing). Instead we should normalize the URLs such that different permutations of the same thing (e.g./bi/or/panis the same as/pan/or/bi) always yield the same string and then generate the same short URL.