[DG: Teaching & Learning] Using Google Docs

[Matthew Jones]

Some more comments:

Even if the university was a "Google Apps for Education Member" the ideas of
google groups and Sakai groups are completely separate. Currently with the
rSmart implementation, if someone new clicks on a document that they don't
yet have access to, they're prompted to request access from the owner if the
document is private.  These Access Controls can be adjusted through the
gdata-api but Sakai would need either to know everyone's Google OpenId's in
the system (or at least the class/group), or the local ID's would have to be
Google ID's under Google Apps. Then the system could potentially either add
these members to the site on document access with either read or read/write
depending on some setting defined by the document owner.

On Sun, Mar 20, 2011 at 8:04 PM, John Johnston <johnpj at umich.edu> wrote:
>
> • Read access to Google Docs for site participants. Resources created of
> the type “Link to Google Doc” will automatically allow sakai site
> participants to read the content of the Doc regardless of the permissions
> settings for that document in Google Docs.
>

I didn't see this to be the case. On the documents I tried they all said I
need permission to access this item. I don't see anything in the code that
manipulates access control list of the documents, though this is a feature
of the GData API. However,

[image: need permission.png]


> • Document editing within Google Docs (for those with granted access
> through Google Docs)
>
>
The document owner has to grant access for each user individually with
either read or read/write when someone requests it. It seems like you'd need
something in Sakai to set these defaults and set it for it to work
otherwise.

Ideally there might be something that created a google group that matched up
with the Sakai group, then it can just manipulate this. However as of today
there is no groups API (
http://code.google.com/p/gdata-issues/issues/detail?id=27) so the only
solution is to add everyone individually. This seems would be quite a bit of
work still to work out all the details of this.

Shortcomings:
> • Google Mail, Calendar, Photos, and Sites are not integrated
>

API's for Google Mail, Picasa, Calendar and Sites all exist. However these
would obviously require someone to write up a requirements for what they'd
do, come up with the design (fund) and implement them. I'd consider it an
obvious shortcoming since only google documents link was advertised.


> • The directory of Google Docs does not provide any metadata (date
> Modified, file type, size); This limits the user’s ability to identify the
> correct file
>

I agree that not being able to easily tell form the UI that it is a Google
document is something that should be improved for sure. I don't know what
metadata the document feed provides or if it would be representable in the
same interface, but I agree it would be nice to have.


> • Editing permissions from the Resource tool are not passed through to
> Google Docs to site participants with “edit any resource” permission
> (empowered users can edit properties, but not the file contents in Google
> Docs).
>

Correct, I don't *see* any access controls (ACLs) being set on the remote
documents. I think you'd really need a to set up separate permissions for
this anyway as they are external resources and currently seem more similar
to a web link than the document in the site.

I think the other questions this brings up, along with other tools (like LTI
ones) is what happens to these resources when the site is duplicated? It's
easy to handle internal content but exporting or copying sites with external
links seems like a really tough problem all as far as standards, coding and
actual behavior. And if anyone attaches items from google docs you also have
a question of ownership, which some institutions may not want to deal with.

Overall though, I think that the work done on this is nice and a great start
toward future projects. Especially with schools that choose to go all-in
with Google's "Google Apps" and potential for build off of.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20110320/43761cbb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 25141 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20110320/43761cbb/attachment-0001.png