Proposal: Organization Profiles

[undergroundwebdesigns]

Proposed Idea

Let JoatU support "Organization Profiles", where the profile represents an organization with a physical presence in a given community. Organizations frequently have access to larger resources (buildings, specialized equipment) that they may be able to make available to the larger community to a greater or lesser extent.

Details

• Organization Profiles could be run/managed by multiple user accounts.
• Some level of verification by JoatU admins may be required to start a new Organization profile, confirming that the organization exists and you are acting on their behalf.
• Organizations may be a great resource for organizing community benefit events in their community through JoatU.
• Organization profiles may cost money to maintain (possibly just for for-profit orgs?). Possible income stream for JoatU!

[joatu]

Definitely of interest. Multiple JoatU users being able to be attached to one Organizational Account would be useful. Especially as opposed to a unique login for the organization. Comparable to the way Facebook Pages utilize admin abilities.

The ability for Organizations to create Community Requests.

The ability for Organizations to be manage CAPS to pay out their Community Requests.

[undergroundwebdesigns]

So this isn't a priority, obviously, at all. I think if/when we did add this concept of "organizations" though, we would want to apply to to hubs. Basically I'd see a hub as an organization that is specially affiliated with and sort of "sponsors" the local pod. In that case what we'd be building would be the possibility for other organizations to also have a presence, without being tied to a specific pod. Could be a great fit for non-profits as well.

In another issue we were talking about city-level offers... I think this feature falls under that same "level" of features. We don't need to implement these features till JoatU has grown a bit more.

[joatu]

At the same time, having JoatU as an admin organization that can create other organizations, add users to said organizations, allocate points to said organizations...And then allow those organizations the capabilities to both create events freely (without oversight) and distribute points (without oversight). That would be powerful.

[undergroundwebdesigns]

I've been thinking a lot about Organizations today, what they should do, how people should use them, and how they relate to requests & offers, and also community offers, events, caps, etc. I've been taking into account the discussion over in #102 as well. Here's some thoughts & ideas I've come up with so far, for further discussion:

• Firstly, I think we should re-visit how we conceptualize offers & requests. Right now they either belong to a specific pod, or they're global. That's not a very flexible distinction, and with the new requirement that organizations be able to both create offers & requests and also have offers and requests that are specific only to them, it's clear we need a new understanding of offers & requests. I think we should move towards giving offers & requests some sort of location info of their own (probably be just a postal code). Once we know (roughly) where the offer / request is located in physical space we can then do things like show all offers within a pod, all offers within X km of a given location (radius search), etc. This location data would still be optional, to support offers that are truly global in scope (e.g. remote web development work ;) ). In addition to that, I think we should enhance the "visibility" options. Rather than "global" or "pod" being the only options, I envision it being "global" or "private to:". Selecting the second option would then display a list of the user's pod(s) and organizations, and they can check off which ones they'd like to make the offer / request visible too. This setup allows any user to create offers & requests that are visible only to members of a specific organization, or only to a few organizations, or only to a specific pod, or global.
• Organizations will have "members", users who are associated with the organization in some way. Exactly what this membership means will depend on the organization itself. If the organization represents an interest group, then members might just be anyone in the group. If the organization represents a business or not-for-profit, the members might include the employees or volunteers. In the case of the Coop Sur Genereux, I imagine the members would probably be the residents. In the case of organizations that are also Hubs, membership in the Hub and membership in the Hub's Pod are not considered the same: membership in the Pod is defined by home address and the pod's geographic area, membership in the Hub Org is defined by the Org admins. Some members of an Org may be designated as organization "admins", granting them extra abilities in order to administer the organization (e.g. editing it's name & description). For initial release, only "JoatU admins (Jamie and Alex) will be able to designate someone an Org admin.
• As discussed elsewhere, it should be possible for an offer or request that is created by an organization admin to be created on behalf of the organization. We would still internally track specifically which user created it, but for display purposes we would use the organization's name as the creator, and we'd probably highlight it with a different colour or style. The interface for creating these would also be slightly different: visibility options should probably just be "global" or "private to this organization's members", for example.
• A "hub" will remain simply an organization that is linked to a "pod", though in this case when creating an organization offer or request, the visibility options would be "global", "private to this organization", and "private to the pod".
• Organizations may have a physical address but this isn't required, in order to allow for global interest groups.
• Organization admins can invite existing JoatU users to join their organization, or can set the organization as public so that any JoatU user can join (this would depend on us having some sort of organization search page, and might not be build right away). Organization admins might also be allowed to invite totally new users into JoatU (to join their org), but that could cause our userbase to grow very quickly. Are we ready for that?
• I think we also need to reconsider the home-page people see when they log in. Right now this is their pod page, but we seem to be moving away from the pod as the "prime focus" of the app, especially if new users can be invited by an organization admin. Already there are a lot of users who don't have a pod, and in that case having the pod page as their homepage makes no sense. A better solution might be a kind of "dashboard" page that shows a few new events, a few new offers / requests, and other "new happenings" of relevance to them. This page would link to their home Pod's page (if they're in a pod) and would include a list of any organizations they're a member of, for easy access. This page would also be an ideal place for a map of the wider area around the user, highlighting local hubs, pods, and organizations.

I think those ideas sum up most of the functionality described in #102, while also providing a better background context of how all the parts fit together with the existing app, and how people might use these features. @joatu what do you think?

[joatu]

• People can only be a part of one pod at any given time (a change from thoughts in the past)
• People can change their pod to a different one (assuming they begin spending more time in a different pod than the one that they are in) when they put in a new postal code. That new postal code changes the postal code data on the person's offers/requests?

If we do it like you spoke, about the offers/requests having a postal code (or the option to put it in), does that mean people can put different postal codes for different offers (I think that makes sense)? I think it would be necessary that the postal codes are auto-inserted into the offers/requests and can be changed if the person wants to.

• If someone changes their main postal code, it creates a notification that tells the person that their postal code in their offers/requests do not match
• We would have to create the feature for people to change their postal codes
• Offers/Requests with postal code data would allow for proximity searches (and to simply display distances on the search results pages)
• Users should be able to 'check/uncheck' their organisations that they want to include in their searches. This feature should auto-save for the next time they come back.
• The idea of being specific pod/global was always meant to be temporary so I'm fine with moving beyond it.
• Search results pertaining to a certain geographic distance away from X Pod should be an either/or thing. Either you select your specific organisations to search within, OR you select X km around your Pod. Show results by "Closest/Furthest" should also be an included feature in that.
• In regards to the last point, I imagined organisations that wouldn't be fixed points per say, but a geographic region. For example, Montreal. That would allow people to make offers available to everyone within the city if they so choose without creating specific km-based limitations. This would also allow someone living outside of Montreal to join the Montreal organization and to search within it despite living somewhere else (perhaps Laval, which is just North of Montreal). (I hope this paragraph is clear)
• I agree with the 'global' or 'private to' bit (if that wasn't clear by what I've already written).
• I agree with everything you wrote in the second paragraph. Tiered memberships for organisations (admin/members). Different types of organisations as well (note my thoughts on the capacity for cities (maybe even countries? the world?) to be organisations). Hub/Org membership is not the same as Pod membership. The possibility for being admin of multiple hubs/orgs. A "create an organisation" option somewhere in JoatU at some point.
• Yes to the third paragraph. When someone responds to a hub/org community request, it should open itself like a group chat to be visible to all admins. Future admins should have access to these past conversations. Admins should be able to turn-off notifications (mute) for specific conversations as well as the capacity to do that for all emails (if for example, that job is designated to specific admins that handle X). Or perhaps within orgs there are admins and super-admins? The super-admins can administer 'jobs' within the org. I.E. Respond to normal requests (Person A gets those). Respond to community offers (Person B gets those). Person C+D are in charge of allocating CAPS.
• Yes to hub paragraph. Except I think organizations should be able to be a part of other organisations (like the 'montreal' org)...At least in terms of geographic organisations and/or distance from Pod. I think for this case, allowing Hub Requests/Offers to be displayed not necessarily globally, but within 100KM could be ok...UNLESS you think that's unnecessary because of people searching will limit their search results, so this kind of thing won't pop up? At the same time, it's going to clog the system if we have offers to lend out a hammer from Malaysia right next to your offer to do remote programming work. Now I'm confusing myself though, if I select 100KM and someone else selects globally, that means they'll be able to see my offer, correct because they're theoretically willing to travel the world to get what I'm offering? Or am I only broadcasting to people within 100KM of my Pod? For privacy's sake, the broadcasting of 100KM makes a bit more sense to me. Thoughts?
• Yes to your thoughts on organisation admins. And yes to their ability to invite new users. I think that's a major part of what's holding us back to be honest. I'm selectively inviting people and at this point and that needs to change. There's a group (one of the organisations, Echangeoir Verdun) that I want to have the ability to start inviting people and there's another org/community space called The Plant that have an amazing entourage that should be allowed to do the same. I don't think we have to worry too much about the userbase growing too quickly if I'm still only inviting one organisation at a time. (Side-note/bug: Some people aren't receiving the invite emails and I'm not sure why)
• Yes to your thoughts on the home-page. I'm not sure what should be the 'ideal' things to be showing at this point in time, but once there are organisations creating events and inviting users, I think it will become more apparent 'how' people are using the site. I'd love to have some admin feature analytics showing how many messages are sent weekly for example. Not sure what other analytics we could use.
• There are also a bunch of users I invited that never accepted the invite...I'm not sure if some of them just never received the invite or if they just let it slip by...It could be one or the other, but something that's on my mind.

Great discussion! I'm really excited to see where we go and I look forward to reading your next thoughts.

[joatu]

I'm going to be attending a festival mid-June and was imagining people signing up, creating quick offers/requests within the "festival/organisation" that would then ping (at this point, email) the other people in the festival. I think as a eventual app, that could be a really useful capability. "Need people on second floor to help place chairs" and it pings everyone with the app.

[undergroundwebdesigns]

Ok, here's some follow up comments, as I'm planning on working on this today and over the weekend:

Re: postal codes and offers/requests. You bring up a good point about "what if someone moves, or changes pods". One way we could handle that is that new offers & requests default to your "home" location (home postal code... which is the same one that determines your pod), but there's an option to use a different postal code instead (or none at all, for non-location based offers). If you later change your home postal code, we could ask if you also want to update the postal code of any open offers/requests that are associated with your "home" address (maybe on an individual basis?)

Why should "search by distance" and "search by pod / org" be exclusive? Maybe I want to search for offers and requests from my neighbourhood (pod), or any of my organizations, but don't want to travel more than 50k?

So far as the question of privacy / clutter due to too many global options goes, here's my thoughts: As the person creating the offer or request you choose privacy settings, which are based on hub, organization, or pod membership. So you can say "only members of my home pod, and org X can see this offer". You can also make something public to anyone. In either case, geographic distance is not a factor, just membership in the org / pod. When searching for an offer or request, you have the option of limiting results to only those explicitly made a available to some pod / org / hub(s) and/or limiting the distance you are willing to travel. The distance filter would probably be enabled by default, set to some relatively large distance (100km?), then people can adjust as necessary. Having a default addresses your concern about finding people lending hammers in Asia in search results for Montreal. Basically, I'm operating under the assumption that if traveling is required, it is the person seeking to fulfill the offer / request (the searcher) that will be doing the traveling. So I can say I'm lending out a hammer from Vancouver, and make that public, and someone from Toronto might search globally, find that, and decide to take me up on that... but probably wouldn't. To assist with that, we could also allow people to change the "centre point" of distance search... so if I'm from Toronto but temporarily visiting Vancouver, I can centre the search on my hostel (current location), and then search for a hammer within 50km or whatever.

I disagree with allowing organizations to cover geographic areas (e.g. a "city" org). We could create something like this in the future, but I question how useful it actually is. Usually it's much better to depend on a distance-filtered search than to try and do a search for "just things in Montreal". Really it's the same problem as doing searches just for offers to a specific pod.... what if I'm at the edge of the city? Or just outside it? Also, who would "run" a city-sized organization? Also, anything getting into a hierarchy of orgs/pods adds quite a bit of complexity.

Re: people who haven't accepted the invitation... probably that's just a reality of life. Most people won't, for whatever reason, statistically speaking.

[joatu]

If I understand what you wrote the same way you are thinking it, it makes good sense to me. I'm looking forward to see how it turns out!

[undergroundwebdesigns]

Some more notes after discussion with Jamie:

• Offers / Requests are either public, or made to one specific Organization.
• As a regular user making an Offer to an organization, I can make it just to the Org itself (visible only to admins) or visible to both the Org and all it's members.
• Orgs can be public or private. Private is "secret", and will only be visible anywhere to people who already are members.
• Orgs marked "private" can appear in a list / search page, and once found non-members an view the Org page, seeing the org description and Offers / Requests made by the Org. Non-members can not see the member list or offers / requests made to the org by other members.
• Non-members may request to join a public organization, but must be approved by an Org admin before they can see protected content.

[joatu]

Paging @undergroundwebdesigns