CUNY Academic Commons

The use case here is that we have someone teaching a class on the Commons using only a blog rather than a blog and a group.

Aside from the workarounds for this particular user, there are some workflow and usability issues for people teaching classes on the Commons:
1. do instructors understand the ramifications of not using a group and using a blog only for their courses? Since this course, from my understanding, intended to use Social Paper from the beginning, it should have been using a group
2. do users generally understand that they need to be in the same group with users they want to add or friends with users in order to add them to a paper?
3. do those two conditions (people have to to be in a group with or friends with a user before adding them to a paper) actually make sense from a usability perspective?

My answers to these questions are:
1. No. We need to be sure that the materials we produce to guide instructors are clear about this (Kelly -- FYI)
2. No. We need to address this is SP instructions and documentation (Scott, Boone)
3. No. We should consider whether it would be feasible to allow users to add any user from the network to share a paper. I imagine that would affect the usability of SP itself -- ie, that one would have to pre-load all member names to that javascript element, which (as we've seen with my account, since I have a lot of friends) could significantly slow page loads.
3a. This brings up another question -- are there ways of getting around this -- ie., a link/button someone could click that says "Add any member of the network" or something that would trigger a load of all member names on click so that it wouldn't have to be part of the automatic page loading of SP

I've cc'ed Luke, Kelly, Sam, Steve, and Scott. And obviously, I'm interested in Boone's thoughts.

If the inability to add users that are not friends/group-co-members is a showstopper, then we should just change it instead of introducing a bunch of documentation that describes workarounds.

ie, that one would have to pre-load all member names to that javascript element, which (as we've seen with my account, since I have a lot of friends) could significantly slow page loads.

The simplest alternative, given the technical hurdles, is to skip the preloading and do all Readers querying via AJAX. This will mean a sluggish but fully functional UX for Readers. If Erin and Matt deem this specific issue to be critical, then I will make the change, and we can worry about speed later on. (This issue strikes me as relatively minor, so I don't want to sink more hours into discovery than have already spent in order to find the "perfect" solution.)

Thanks, Boone and Matt. I like the usability questions this brought up as I was surprised myself to find that Cheryl Smith had created a course blog and not a course group. I agree with Matt that we can refine our instructions based on use cases like these.

I don't think the inability to add users that are not friends is a showstopper, but we should change the documentation if that is indeed the case. I also like Matt's idea outlined in 3a but if it takes tons of development time, perhaps it would be best to just change the documentation.