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

Ability to add any number of links to a person's page #198

Open
symroe opened this Issue May 10, 2017 · 8 comments

Comments

Projects
None yet
3 participants
@symroe
Contributor

symroe commented May 10, 2017

It would be nice to have the ability to add n links to a person's profile.

This is because there is a low chance of us being able to predict the URLs that might be interesting to others about a person.

For example, this article is a great profile of a candidate, but there's no obvious place to link to it:

https://www.theguardian.com/politics/shortcuts/2017/mar/13/mayor-northern-powerhouse-womens-equality-party-tabitha-morton-liverpool

@symroe

This comment has been minimized.

Contributor

symroe commented May 10, 2017

A hack for this would be to add a new multi-line field that allows a URL per line. It's not ideal, but it would allow for recording the information on people.

@JoeMitchell

This comment has been minimized.

Contributor

JoeMitchell commented May 10, 2017

Niiice — this ties into my dream version of candidates*, which is that a person's page has any number of lines for dumping URLs into — by wombles (or in future, the Google-scraper/machine-learning thing) — and then the machines auto-sort them into 'Social, News, Bio, Homepage' etc, with womble help if not understood, in order to give some kind of structure...

I suppose this might just end up replicating Google...

*Not just mine; I think this has been discussed online somewhere, but not sure if there's an issue for it...

@chris48s

This comment has been minimized.

Member

chris48s commented May 10, 2017

I think there are probably a couple of intermediate steps between
"add ability to store an array of N arbitrary URLs against a candidate" and
"robots automatically discover and categorise candidate data" 🤖

@JoeMitchell

This comment has been minimized.

Contributor

JoeMitchell commented May 10, 2017

@symroe

This comment has been minimized.

Contributor

symroe commented Oct 3, 2018

Here's some more detail about what we're currently doing:

We currently store the following information for people. This information is stored on a mixture of the Person model or GenericForeignKeys to popolo.Link, popolo.Identifier, popolo.ContactDetail. All of these allow any value as a note, but in reality we only use a fixed list.

Fields in popolo.Link:

  • homepage
  • facebook personal
  • party candidate page
  • party PPC page
  • linkedin
  • facebook page
  • wikipedia

Fields in popolo.ContactDetail:

  • Twitter (screen name)

Fields in popolo.Identifier:

  • Twitter (internal identifier, used to track screen name changes)

Fields on Person directly:

  • [name, gender, biography, stuff that’s out of scope for this doc]
  • email

What to do next?

Statements I think are true:

  • We want to support any number of links about a person
  • We want to ‘enhance’ some types of links in some ways. For example, we want to update Twitter usernames from their internal ID, or pull extracts from wikipedia
  • We might want to use something like embed for URLs that support it, but we need to think a bit about moderation and how we display them

Data model:

I suggest we have a PersonLinks model with the following:

  • Person (FK)
  • url
  • site_identifier (for storing things like internal user ID – see Twitter)
  • link_type (a single tag for this site “twitter”, “linkedin”, “homepage”)
  • extract (for storing text from the site that’s useful for embedding. Twitter profiles, wikipedia summaries, Facebook bio)

Trying to define a ‘link’ as different to a ‘contact detail’ seems odd, when Twitter or Facebook are clearly both. Email is a special case that should be on the person model (ignoring the debate about what data to store on candidacies).

Consumers of the data (including WCIVF) can decide how best to display the data.

Our CRM does something that looks like this:

screenshot 2018-10-03 19 24 11

Are there any other nice patterns we should look at?

@symroe

This comment has been minimized.

Contributor

symroe commented Oct 3, 2018

Work here will also include something that addresses #238

@symroe

This comment has been minimized.

Contributor

symroe commented Oct 23, 2018

Some notes on how this might happen, in a rough order:

  • Move Person model to people app
  • Move Person CRUD forms to people app
  • Move tests to people app
  • Create new “PersonLinks” model
  • Model has:
    • [Timestampped model]
    • Type
    • Value
    • Identifier (unique together on (Person, Identifier))
  • Migrate data from various fields in to “PersonLinks”
  • Update Person CRUD forms to deal with PersonLinks, maybe a formset (no JS for now)
  • Think about merging, updating the existing version history
  • Think about front end design & progressively enhanced JS links form (auto classify by URL type, add more rows, etc)
  • Think about how/if to store n values per value type. Good case for "other". See comment thread

I see the top 3 as different but required prep work. I think I'll start there, and add more to this comment as I work through them and find more things.

@chris48s

This comment has been minimized.

Member

chris48s commented Nov 5, 2018

a few TODOs on the data entry side:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment