Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🔗 Determine URL/query approach #4

Open
tatianamac opened this issue Oct 20, 2019 · 11 comments
Open

🔗 Determine URL/query approach #4

tatianamac opened this issue Oct 20, 2019 · 11 comments

Comments

@tatianamac
Copy link
Collaborator

Goal: Create a linking strategy where selfdefined.me/AsianAmerican+pan will render a page with a definition for Asian American and pan.

Impact: Users can self-identify via social bios, email signatures, etc.

Considerations:

  • Strings should be human-readable, to some degree (similar to pronoun.is/they), to pique curiousity.
  • Some cap will have to be set on number of identifiers.
  • Endless possibilities of combinations technically exist.
  • Solution should not rely solely on JS so that it's more accessible.
  • Some sort of generator will need to exist, where a user can pick terms to generate their own string.
  • The way each definition is stored will need to be future-proofed for the API, Slack/Twitter bots, etc.
@coilysiren
Copy link

coilysiren commented Oct 20, 2019

Wildcard consideration: I would ideally use this with acronyms, like

  • WoC
  • TWoC
  • QTPoC

etc etc. So that I can have a URL like selfdefined.me/qtpoc

@tatianamac
Copy link
Collaborator Author

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?

@coilysiren
Copy link

I'm suggesting we use both, and allow people to mix and match them however they want! 👩‍🔬

@tatianamac
Copy link
Collaborator Author

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
Copy link

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
Copy link
Collaborator

ovlb commented 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 /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

@dshafik
Copy link

dshafik commented 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:

  1. where possible replace terms with abbreviations/acronyms (e.g. selfdefined.me/is/heteronormative/and/bi/or/pan)
  2. 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?
  3. 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.

@tatianamac
Copy link
Collaborator Author

@dshafik Thanks for this insight!

  1. 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.)
  2. Do you mind elaborating on this point a bit more? I'm not sure I understand fully
  3. 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

@hibaymj
Copy link

hibaymj commented 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
Copy link

@dshafik Thanks for this insight!

  1. 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.

@dshafik
Copy link

dshafik commented Jul 10, 2020

@tatianamac

  1. 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?

  1. 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.

@tatianamac tatianamac transferred this issue from selfdefined/web-app Aug 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants