Really loving Kinopio. I’ve switched my team over to Kinopio from Notion, but one difficult thing in doing so is dealing with all the individual invite links.
I thought it would be smart to create a single board with invite links to each of our boards but that seems to break Kinopio. Are there any plans for teams?
A fellow user here – the way I use it with my team is inviting them as collaborators on all our shared boards. As far as I know, they do need to go initially to the Invite Url while signed in (or sign in after they go). After that the boards will show up in their space browser.
re sharing invite links on a space, that should actually be a short-term-reliable way to do it. For security reasons, the invite code is valid until a collaborator is removed (whether they get kicked out, or they leaves a space.)
@aiden Can you elaborate by what you mean by the links ‘break[ing] kinopio’?
As a short-term band-aid for this issue, I could add a feature that lets you email individual space invites to people. The invite email field could support multiple recipients so if you want to invite ‘Susan’ and ‘Cheryl’ to all projects you could input
susan@company.com, cheryl@company.com
and that’d kick off an email with an invite code for each of them.
The downsides of this:
is that if you wanted to invite your team to a bunch of spaces at once, that’d be a lot of emails for them to receive (1per space)
Also the invite links would be the same as the app once, so if you sent an invite to someone and they joined and then left the space then the invite links for that space sent to everyone else would become invalid. It’s maybe kind of an edge case, but could happen.
That said, would y’all find a feature like this useful?
So I just retested making the invite link a card and it worked! Last night the link would send me to an empty new board and there would be an error in the bottom left corner.
Definitely not holding you to this timeline… but as a follow-up, I’m interested in whether or not there’s an update on this – is it on the roadmap? has there been a shift in thoughts about the role of teams in the product? I am now onboarding a couple of people to a project and I’d like each to have a Kinopio account alongside the other tools I’ve set up (GitHub, Notion, Figma, Slack etc.) but managing a bunch of individual accounts will be a little painful.
That said, this is not a blocker to us using Kinopio so we’ll still be using it even if there’s no expectations of teams being delivered (short or long term), mostly just looking for an update so I know what to expect in terms of how I manage Kinopio accounts and access to shared spaces
No real updates on this yet, it’s on the roadmap space but it’s not slotted into a specific place yet.
has there been a shift in thoughts about the role of teams in the product?
It’s use cases like that I’ve been waiting to learn a lot more about. My gut sense is that I don’t want to build a teams feature prematurely because it’s something only a narrow slice of users will use, but the development time is long. Additionally, teams is weighed against other requested features that all/more users can use.
I was planning on waiting till it felt obvious like ‘uh oh I should have this already’ before starting (so probably hearing from ~5-10 ppl asking for it, and learning about their desired use cases/capabilities)
I am now onboarding a couple of people to a project and I’d like each to have a Kinopio account alongside the other tools I’ve set up (GitHub, Notion, Figma, Slack etc.) but managing a bunch of individual accounts will be a little painful.
What does teammate onboarding look like with those tools? Do you send them a special url to sign up under a team, or do you ask them to sign up as individuals and then join your existing team?
In the meantime, there might be pseudo teams like tools that can be built using the kinopio api Kinopio API.
e.g.
you can get all your spaces, the ones you make and collaborate on with GET /user
If you namespace/emoji your team spaces like [team] cool project then you can filter out just team ones
on the spaces you created, you could remove a specific collaborator with DELETE /space/collaborator
Def not the ideal solution of course, just a teams bandaid for now
Each tool is different but the general themes are:
I create a team / organisation / space
I invite people to the team, which could mean they independently create a new account by logging in with their Google Workspace account (e.g: Slack) or I invite them manually by providing their username to an invite form (e.g: GitHub) or I create a generic invite URL which is listed in my onboarding instructions (e.g: 1Password)
I am billed per user that is part of the team
I can remove people from the team
Notion and Slack are nice because users can log in with their Google Workspace account and are immediately granted access through domain whitelisting, vs. GitHub where I must manually invite a user (makes onboarding a little more time consuming).
Most important to me is that my users do not have to think about their account, they should just be told that we use Kinopio and I carry the burden of dealing with access management and billing. I believe @bentsai previously talked about how disruptive it was when one of their team members ran into account limits during a meeting.
I think my dream implementation within Kinopio would be: I can create teams, I manage who is in the team, I pay for each member in the team, spaces can be created within the team, a team member can view a list of all “open” and “closed” spaces in the team (but not “private”).
The specifics of the invite mechanism are less important to me because even GitHub’s hands-on invite flow isn’t unpleasant, but I think the most flexible is 1Password’s reusable invite link, most secure/enterprisey is domain-level whitelisting with oauth (but this necessitates the 1 account per team model) and most common for one-account-many-team platforms (e.g: GitHub) is “hey new team member, what’s your username so I can invite you to tool?”.
Actually it might be helpful if I just provide some examples from my new teams onboarding instructions.
I can create teams, I manage who is in the team, I pay for each member in the team, spaces can be created within the team,
This is very much inline with what I’m picturing
a team member can view a list of all “open” and “closed” spaces in the team (but not “private”).
Do you mean that team members can’t view spaces that are private? Here’s how I think this could play out: every member of the team can see all spaces – but when you make a space, you have to explicitly add it to your team (like github). This prevents accidental internal sharing, without confusing internal private sharing.
some examples from my new teams onboarding instructions
I guess in the case of github it’s likely that the dev you hired already has a github account and you want to add them to your team. In the case of the others the new hire has a seperate account for your team.
In the case of kinopio, I could see someone having an account already and wanting to maybe join your team github style. The problem for kinopio with white listing @example.com is that I ask users to verify their email after sign-up, but I don’t require it.
Most important to me is that my users do not have to think about their account, they should just be told that we use Kinopio and I carry the burden of dealing with access management and billing
What if a team member could provide a url that would guide a new user through signing up with a specified @example.com kinopio account and automatically join them to the team? If the user already has an account that they wanted to use, then they could just join the team with that.
of course I voted yes on the twitter poll, but my instinct comported with the above, and I initially came to make that comment to temper my “yes”. teams feels like a more enterprise-y feature that only a small number of users would use.
but then I thought would be useful for any group of folks who are wanting to collaborate on a project or build some community. one use case/analogy that came to mind is: a lot of communities have discord/slack instances with different channels focused on various topics.
similarly, having a layer above a kinopio space to tie together a group of spaces could be useful here. you can invite people to this “team”, and that gives them access to all the spaces that are being worked on.
Yeah, I’m definitely onboard with the gut feeling that this might not be important to the wider audience. I think the challenge is in identifying whether the lack of team features is prohibiting more team based uptake, or if the product is inherently a collaborative tool for individuals rather than a tool for formal teams.
There’s probably also some degree of risk around revenue being made up of a small number of large teams, and their expectations around ongoing product evolution to better support their use-cases. Explicitly deciding not to support teams could be a conscious choice to position the product away from enterprise-y use-cases in order to protect from their influence and burden – but I do like @bentsai’s discord-esque community angle, maybe there’s a middle-ground
teams feels like a more enterprise-y feature that only a small number of users would use
might not be important to the wider audience
agreed. because of that it’s priority is a little lower. The main benefit of a teams feature - assuming minimal overhead/maintainance burden - is to be able to charge for it, see if more people use kinopio as a result of being invited in by work
quoting myself:
What if a team member could provide a url that would guide a new user through signing up with a specified @example.com kinopio account and automatically join them to the team?
The problem with @example.com accounts is what do you do if a user signs up for a kinopio account through work but uses it for personal stuff too. Then they quit and their account is removed. They’d also lose their personal stuff too… sounds like a nightmare of a potential support issue
Just my two cents as someone who has no use for teams: when someone quits, the team owner should be able to remove them from the team so they lose access to the team spaces and paid features. They should still be able to login with their work e-mail (assuming they own the password), view their personal spaces, and change their e-mail from here. Assuming they’d be over the card limit with personal spaces, I’d let them view their spaces, but not edit until they upgrade. If you wanted to remove their spaces, maybe give 90 days for the user to take action and delete the spaces at that point if no action is taken.
i agree with the principle but I still trying to work through this scenario:
I can do this if I don’t have the feature where if you have an @example.com email you can join a team’s spaces.
I would probably need to build an email change ui too (which I should do anyways)
So in this scenario if pirijan@example.com leaves a company, the team administrator can remove me from the team.
I now can’t access any of that team’s spaces.
I can still login into my account though with the email/password, so I can access all my personal stuff just fine
If I want, I can change my email address
This seems the least destructive option,
more friction on team inviting (no blanket domain based inviting, have to invite people manually, github style)
but prevents users from getting locked out of their accounts and losing access to anything personal (which does happened with trello, which works similarly to slack/notion)