Flockingbird is about "managing your business network". We achieve this with basic, simple CRM functionality.
Basic example
Tags
As a member of an instance
When I discover another profile
Then I can tag that person with one or more tags
And I can determine the visibility (privacy) of those tags
And when I tag a person they become a contact
So that I can use tags to group and categorise profiles
Notes
As a member of an instance
When I discover another profile
Then I can add one or more notes to that profile
And I can determine the visibility (privacy) of those note
And when I add a note thy become a contact
So that I can use notes to add free-form context or details to a profile
Contact Details
As a member of an instance
When I discover another profile
Then I can add one or more contact details, only visible to me
And when I add that, they become a contact
So that I can use my contacts as address book.
We can add tags, notes or contact details, so that we have basic CRM functionality, turning our contact list into a basic addressbook and allowing us to enrich that.
The addressbook is "self updating" since when a person changes their attributes (such as contact details) they will be pushed to our copy and we get an up-to-date entry.
Notes allow free-form text and images to be added. Tags are a Limited List. Both notes and tags have visitbility settings so that the author (not the profile owner) can decide to share this detail with the world or with their community. So that the CRM becomes a community effort.
Public Tags and notes are always tracable to the author so that we give credit or place blame for a tag or note.
Added Contact Details are always private so that we never accidentally leak private information about a member without that member having influence about it.
Detailed design
We can add tags and use those tags to search,for- or filter profiles. Tags are a Limited List. If a tag allready exists on this profile and is visible to me, my name is added as "author" to that existing tag.
Clicking on a tag yields a list with all profiles visible to me, using that tag. This uses the search feature and is thus limited by the index.
Making a tag public means that anyone can see this tag, search by it, and can see that I (also) added this tag.
Making a tag private means that only I can search by this tag.
Adding a public tag notifies the tagged member of this event.
Adding a tag automatically adds that member to my contacts and makes me follow that contact.
We can add "free form" notes and read those notes on viewing the profile that they were placed on. TBD: should notes be indexed and if so, how? Clicking a note opens it for reading and/or deletion or editing.
Making a note public means that anyone can open this note for reading (TBD: see searching and indexing).
Making a note private means that only I can open this note for reading.
Only the author of a note can edit/delete it.
Adding a public note notifies the annotated member of this event.
Adding a note automatically adds that member to my contacts and makes me follow that contact.
Adding contact details allows me to enrich a public profile in my contact list with contact details that I know about that person.
Turning it from a common social media "these are the people you follow"-list into a full-blown alternative for an addressbook.
ContactDetails, Tags, LimitedLists, ResumeEntry and Affiliate models are to be described in more detail elsewhere.
Privacy model and setting of all these attributes is to be described elsewhere.
Markup and "free form" limiations are to be described in the specific models.
Drawbacks
Tagging and annotations can be abused to bully members. This can be mitigated or even solved entirely, with a proper blocking model. This is to be developed.
Indexing tags and notes puts a heavy burden on the indexes and the distribution of the data to be indexed.
Tagging and annotations can lead to my private details being exposed by other members, when they add e.g. an address or other private data to a public tag or note.
Notifying a member of a tag- or annotation event on their profile, can be abused to spam. E.g. a bot could add "buy viagra online dot com" tags to many users. This is somewhat worse than current spamming through usernames (Buy viagra online dot com now follows you) because the tags are published on my profile. And since notes can contain images or links, this becomes even more problematic.
High profile profiles (pun intended) are extra susceptible to this. Moderation and blocking is a requirement.
Alternatives
Making tags and notes always private. Downside is that this removes the "social" from social crm mostly. The benefit of leveraging work by my peers to enrich my contact list, is lost. Upside is that this allows data to remain entirely client-side even.
Additional CRM features such as todolists, tasks, alarms etc. Downside is the added complexity. Upside is that this makes for a full-featured CRM, good enough for more use-cases that the "simple" variant.
Not having any annotation or tagging features: leave the CRM for external tools and apps. This makes all other features (search, discovery, profiles) lean on the time and effort people spent on their own profile entirely. Whereas having this feature, can leverage the effort of a few highly active people.
Adoption strategy
Server admins must have good moderation features, e.g. blocklists or allow-lists of misbehaving instances or members.
Server admins must be able to lock profiles when they receive abuse and blocking or other moderation does not suffice.
These features must be filled with good defaults and be known to admins and be actively used by admins.
UX must make clear that I can add tags, notes and contact details on other peoples profiles. The effect of privacy settings must be clear.
I see notifications when others publicly tag or annotate me, so that I am made aware of this feature even when I don't visit other profiles.
How we teach this
Each profile has a clear and simple UX that shows the actions: add tags, add notes, to members. The interface to add a tag or a note is simple and recognisable, and limited in options. So that most members don't need manuals or training to use it.
Unresolved questions
TBD: indexing strategies.
TBD: see the TBD under details.
TBD: moderation features.
Summary
Flockingbird is about "managing your business network". We achieve this with basic, simple CRM functionality.
Basic example
Tags
As a member of an instance When I discover another profile Then I can tag that person with one or more tags And I can determine the visibility (privacy) of those tags And when I tag a person they become a contact So that I can use tags to group and categorise profiles
Notes
As a member of an instance When I discover another profile Then I can add one or more notes to that profile And I can determine the visibility (privacy) of those note And when I add a note thy become a contact So that I can use notes to add free-form context or details to a profile
Contact Details
As a member of an instance When I discover another profile Then I can add one or more contact details, only visible to me And when I add that, they become a contact So that I can use my contacts as address book.
See the figma scetches for more details
Motivation
We can add tags, notes or contact details, so that we have basic CRM functionality, turning our contact list into a basic addressbook and allowing us to enrich that.
The addressbook is "self updating" since when a person changes their attributes (such as contact details) they will be pushed to our copy and we get an up-to-date entry.
Notes allow free-form text and images to be added. Tags are a Limited List. Both notes and tags have visitbility settings so that the author (not the profile owner) can decide to share this detail with the world or with their community. So that the CRM becomes a community effort. Public Tags and notes are always tracable to the author so that we give credit or place blame for a tag or note.
Added Contact Details are always private so that we never accidentally leak private information about a member without that member having influence about it.
Detailed design
We can add tags and use those tags to search,for- or filter profiles. Tags are a Limited List. If a tag allready exists on this profile and is visible to me, my name is added as "author" to that existing tag. Clicking on a tag yields a list with all profiles visible to me, using that tag. This uses the search feature and is thus limited by the index. Making a tag public means that anyone can see this tag, search by it, and can see that I (also) added this tag. Making a tag private means that only I can search by this tag. Adding a public tag notifies the tagged member of this event. Adding a tag automatically adds that member to my contacts and makes me follow that contact.
We can add "free form" notes and read those notes on viewing the profile that they were placed on. TBD: should notes be indexed and if so, how? Clicking a note opens it for reading and/or deletion or editing. Making a note public means that anyone can open this note for reading (TBD: see searching and indexing). Making a note private means that only I can open this note for reading. Only the author of a note can edit/delete it. Adding a public note notifies the annotated member of this event. Adding a note automatically adds that member to my contacts and makes me follow that contact.
Adding contact details allows me to enrich a public profile in my contact list with contact details that I know about that person. Turning it from a common social media "these are the people you follow"-list into a full-blown alternative for an addressbook.
ContactDetails, Tags, LimitedLists, ResumeEntry and Affiliate models are to be described in more detail elsewhere. Privacy model and setting of all these attributes is to be described elsewhere. Markup and "free form" limiations are to be described in the specific models.
Drawbacks
Tagging and annotations can be abused to bully members. This can be mitigated or even solved entirely, with a proper blocking model. This is to be developed. Indexing tags and notes puts a heavy burden on the indexes and the distribution of the data to be indexed. Tagging and annotations can lead to my private details being exposed by other members, when they add e.g. an address or other private data to a public tag or note. Notifying a member of a tag- or annotation event on their profile, can be abused to spam. E.g. a bot could add "buy viagra online dot com" tags to many users. This is somewhat worse than current spamming through usernames (Buy viagra online dot com now follows you) because the tags are published on my profile. And since notes can contain images or links, this becomes even more problematic. High profile profiles (pun intended) are extra susceptible to this. Moderation and blocking is a requirement.
Alternatives
Adoption strategy
Server admins must have good moderation features, e.g. blocklists or allow-lists of misbehaving instances or members. Server admins must be able to lock profiles when they receive abuse and blocking or other moderation does not suffice. These features must be filled with good defaults and be known to admins and be actively used by admins. UX must make clear that I can add tags, notes and contact details on other peoples profiles. The effect of privacy settings must be clear. I see notifications when others publicly tag or annotate me, so that I am made aware of this feature even when I don't visit other profiles.
How we teach this
Each profile has a clear and simple UX that shows the actions: add tags, add notes, to members. The interface to add a tag or a note is simple and recognisable, and limited in options. So that most members don't need manuals or training to use it.
Unresolved questions
TBD: indexing strategies. TBD: see the TBD under details. TBD: moderation features.
Footnotes and references