You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Scott Wilson (Commented) (JIRA)" <ji...@apache.org> on 2012/03/17 16:37:38 UTC
[jira] [Commented] (RAVE-103) Support shared spaces
[ https://issues.apache.org/jira/browse/RAVE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231993#comment-13231993 ]
Scott Wilson commented on RAVE-103:
-----------------------------------
I think there are two models we can look at:
1. Page Sharing
In this model, a user creates a new page, and from the tab context menu selects "Share this page...". A dialog opens, and the user can add people (e.g. using a search/filter view), or select an existing group (e.g. friends, family, co-workers...). The user chooses OK, and each user is notified when they log into Rave of the invitation to add the shared Page. The user who created the Page is the Owner; each user they share with is by default a Viewer (read-only). However, it should be possible for the Owner to grant other users a "Can Edit" role allowing them to add, remove and move widgets.
2. Workspace Sharing
In this model, there is a higher-level entity comprising a collection of multiple pages managed by a group. New shared pages can be added as sub-pages of the top-level workspace. I'm a bit less clear on the workflow for this one, whether its the same as (1) but with sub-pages, or something conceptually quite different
====
Paul and I are really interested in seeing if we can develop something along the lines of model (1) in a sprint next week as it would be a good fit for a project we're working on. This wouldn't include the OpenSocial Spaces extension (I'm sure someone else could implement it later) but would include the basic functionality of sharing pages, selecting users, and extending the relevant PermissionEvaluator classes for non-Owner roles.
> Support shared spaces
> ---------------------
>
> Key: RAVE-103
> URL: https://issues.apache.org/jira/browse/RAVE-103
> Project: Rave
> Issue Type: Epic
> Reporter: Matt Franklin
>
> Support shared, or common, spaces with group managed pages, widgets, and security
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Scott Wilson <sc...@gmail.com>.
On 19 Mar 2012, at 09:37, Evgeny Bogdanov wrote:
> Hi Scott,
>
> within space proposal there is a discussion about
> splitting up group (named collection of people) from role (named set of rights)
> or merge them in a sense that every group has fixed set of rights.
>
> https://groups.google.com/forum/?fromgroups#!searchin/opensocial-and-gadgets-spec/space$20role$20group/opensocial-and-gadgets-spec/nnuc9qadBfM/xTu-hMIdi3kJ
>
> What is the vision for RAVE?
I was thinking more along the Google Docs sharing line - so owners assigning a collection of permissions (e..g "Can Edit") per-member per-page. I think in this context groups are more a convenience mechanism for adding multiple members at a time.
> Best
> Evgeny
>
> On 17.03.12 16:37, Scott Wilson (Commented) (JIRA) wrote:
>> [ https://issues.apache.org/jira/browse/RAVE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>
>> Scott Wilson commented on RAVE-103:
>> -----------------------------------
>>
>> I think there are two models we can look at:
>>
>> 1. Page Sharing
>>
>> In this model, a user creates a new page, and from the tab context menu selects "Share this page...". A dialog opens, and the user can add people (e.g. using a search/filter view), or select an existing group (e.g. friends, family, co-workers...). The user chooses OK, and each user is notified when they log into Rave of the invitation to add the shared Page. The user who created the Page is the Owner; each user they share with is by default a Viewer (read-only). However, it should be possible for the Owner to grant other users a "Can Edit" role allowing them to add, remove and move widgets.
>>
>> 2. Workspace Sharing
>>
>> In this model, there is a higher-level entity comprising a collection of multiple pages managed by a group. New shared pages can be added as sub-pages of the top-level workspace. I'm a bit less clear on the workflow for this one, whether its the same as (1) but with sub-pages, or something conceptually quite different
>>
>> ====
>>
>> Paul and I are really interested in seeing if we can develop something along the lines of model (1) in a sprint next week as it would be a good fit for a project we're working on. This wouldn't include the OpenSocial Spaces extension (I'm sure someone else could implement it later) but would include the basic functionality of sharing pages, selecting users, and extending the relevant PermissionEvaluator classes for non-Owner roles.
>>
>>> Support shared spaces
>>> ---------------------
>>>
>>> Key: RAVE-103
>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>> Project: Rave
>>> Issue Type: Epic
>>> Reporter: Matt Franklin
>>>
>>> Support shared, or common, spaces with group managed pages, widgets, and security
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>> .
>>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Evgeny Bogdanov <ev...@epfl.ch>.
Hi Scott,
within space proposal there is a discussion about
splitting up group (named collection of people) from role (named set of
rights)
or merge them in a sense that every group has fixed set of rights.
https://groups.google.com/forum/?fromgroups#!searchin/opensocial-and-gadgets-spec/space$20role$20group/opensocial-and-gadgets-spec/nnuc9qadBfM/xTu-hMIdi3kJ
What is the vision for RAVE?
Best
Evgeny
On 17.03.12 16:37, Scott Wilson (Commented) (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RAVE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231993#comment-13231993 ]
>
> Scott Wilson commented on RAVE-103:
> -----------------------------------
>
> I think there are two models we can look at:
>
> 1. Page Sharing
>
> In this model, a user creates a new page, and from the tab context menu selects "Share this page...". A dialog opens, and the user can add people (e.g. using a search/filter view), or select an existing group (e.g. friends, family, co-workers...). The user chooses OK, and each user is notified when they log into Rave of the invitation to add the shared Page. The user who created the Page is the Owner; each user they share with is by default a Viewer (read-only). However, it should be possible for the Owner to grant other users a "Can Edit" role allowing them to add, remove and move widgets.
>
> 2. Workspace Sharing
>
> In this model, there is a higher-level entity comprising a collection of multiple pages managed by a group. New shared pages can be added as sub-pages of the top-level workspace. I'm a bit less clear on the workflow for this one, whether its the same as (1) but with sub-pages, or something conceptually quite different
>
> ====
>
> Paul and I are really interested in seeing if we can develop something along the lines of model (1) in a sprint next week as it would be a good fit for a project we're working on. This wouldn't include the OpenSocial Spaces extension (I'm sure someone else could implement it later) but would include the basic functionality of sharing pages, selecting users, and extending the relevant PermissionEvaluator classes for non-Owner roles.
>
>> Support shared spaces
>> ---------------------
>>
>> Key: RAVE-103
>> URL: https://issues.apache.org/jira/browse/RAVE-103
>> Project: Rave
>> Issue Type: Epic
>> Reporter: Matt Franklin
>>
>> Support shared, or common, spaces with group managed pages, widgets, and security
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
> .
>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Ate Douma <at...@douma.nu>.
On 03/23/2012 07:59 PM, Cooper, Sean D. wrote:
>
>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Monday, March 19, 2012 9:52 AM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>>
>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>
>>> [ https://issues.apache.org/jira/browse/RAVE-
>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>
>>> Scott Wilson commented on RAVE-103:
>>> -----------------------------------
>>>
>>> I think there are two models we can look at:
>>>
>>> 1. Page Sharing
>>>
>>> In this model, a user creates a new page, and from the tab context menu
>> selects "Share this page...". A dialog opens, and the user can add people (e.g.
>> using a search/filter view), or select an existing group (e.g. friends, family, co-
>> workers...). The user chooses OK, and each user is notified when they log into
>> Rave of the invitation to add the shared Page. The user who created the Page is
>> the Owner; each user they share with is by default a Viewer (read-only).
>> However, it should be possible for the Owner to grant other users a "Can Edit"
>> role allowing them to add, remove and move widgets.
>>>
>>> 2. Workspace Sharing
>>>
>>> In this model, there is a higher-level entity comprising a collection of multiple
>> pages managed by a group. New shared pages can be added as sub-pages of the
>> top-level workspace. I'm a bit less clear on the workflow for this one, whether its
>> the same as (1) but with sub-pages, or something conceptually quite different
>>>
>> IMO we should (eventually) strive to merge both these models into one logical
>> model from Rave perspective.
>> For one, we already have a 'shared' page right now: the profile page. With sub
>> pages...
>>
>> IMO the current separate/special handling of the profile page should technically
>> or model wise not be special at all. What difference is there between sharing
>> 'a' page to the public with sharing 'the' profile page(s) to the public?
>> To me this seems like just a matter of security configuration, with the profile
>> page 'just' representing a common default 'share'.
>>
>> Interestingly, the current profile page also now has 'sub' pages, which in a
>> minimalistic sense maybe could be regarded as a shared 'workspace' already
>> (with
>> a single owner).
>>
>> I'm interested in how adding a shared page to the users view of pages will work
>> out.
>>
>> Right now we do not have yet a navigational representation of pages.
>> Will sharing the canonical 'Main' page with john.doe result in two 'Main' pages
>> to be shown? As the name of a page (currently) is only stored in the page
>> itself, to prevent 'namespace' clashes, you either need to:
>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>> /person/canonical/pages/Main), or
>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2, Main3),
>> or
>> - introduce a mounting or shortcut like feature where the viewer can structure
>> its own 'site' and 'inject' shared pages at any desired location, or
>> - ...?
>>
>> Note: in the above options I'm not referring to page IDs anymore. While each
>> page can/should still be addressable by ID (too), if you're going to share pages
>> you'll need *also* a logical naming representation to be able for the viewer to
>> navigate its own 'site' or even more so a public/anonymous view of 'the' site.
>> Meaning: we'll need to come up with a navigational structure for pages which
>> can
>> be rendered through menu's, site maps, etc. These IMO should be accessible
>> and
>> represented as REST resources like the web itself. Thus hierarchically structured.
>>
>> Once we get there, I think the workspace vs page discussion becomes easier and
>> more 'structured'. A workspace then can simply represent a parent (or root)
>> page
>> resource with optional children which happens to be shared, somehow.
>>
>> Important this IMO is a discussion on ownership of a shared page or workspace,
>> something which was also discussed, but IMO not concluded, recently on the
>> OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>
>> I think each page/space/workspace or whatever (Rave) 'social' web resource
>> should have a canonical owner. Meaning only one. And if you want to 'share'
>> ownership, then a separate and standalone entity like Group should be used.
>> Because that will then allow providing both a canonical location (url).
>> Consider for instance searching (public web or from within the portal) and
>> finding an entry matching a page or workspace: what or who's canonical url
>> should be linked to if you would have multiple owners?
>>
>
>
> -1
Right :)
IMO you're a bit too quick to throw in a -1.
Typically it is better to first express your concern, like as you do below, and
discuss the matter a bit more to see if there really are conflicting goals and
if so how we can resolve them in a way satisfactory for all.
And I this case, if I understand your concerns below correctly, I think its more
likely we have a misunderstanding than conflicting goals.
> I have a use case where I don't want a canonical user to own the workspace.
> If I create a workspace page which should live on for 4+ years I cannot
> guarantee that the individual who first created it will still be responsible
> for the workspace or even an employee for the life of that workspace.
That make sense, and I agree it should be possible for a workspace to 'survive'
its original creator/owner if so needed.
> I would like the ability to create workspace pages in a non-owner/group way,
> e.g. /portal/app/workspace/## where ## is the id of the workspace that you
> are working with.
Here I think or POVs are deviating :)
> Permissions should be attached to the page and updatable by an admin in case the
> original set of people change work focuses and or positions in the company.
OK, so lets see if this can be solved in a way which hopefully fits your
use-case as well.
In my proposal there should always only be one canonical 'owner' of a page or
space. That is: at a certain time. However, that doesn't (have to) mean this
ownership isn't transferable. So, if for instance an 'employee' owner leaves the
company, this ownership could very well be transferred to someone else, by an
admin, or at least 'control' be taken over by an admin (becoming the new owner).
Alternatively, the ownership could be assigned to a specific group (which is
*not* an OpenSocial group in the current model for sure), and individuals can be
added/removed from this group as desired (by the group itself or an admin).
Such a group is 'owned' by the organization (controlled by an admin) and
probably functionally related to this page/workspace. If people change work
focuses and/or position should not affect the 'role' of this group IMO. And if
it does, it always remains possible to 'reassign' the ownership to another group
or even another individual.
IMO none of the above should conflict with your requirements but it does allow
maintaining a single canonical 'owner' at any time. And that is IMO critical
because otherwise it is impossible to maintain a single point of responsibility.
And from application and end-user perspective, it means every page/space will
have a single/canonical address space (URL if you want).
Also note that I only gave an example of an url namespace which for convenience
and simplicity references a Rave user, that doesn't imply any restriction or
limitation to use a completely different url naming scheme for your custom
portal. So a /portal/app/workspace/## can very well be 'owned' by an admin, a
group or a specific user, however you'd like to configure that. And if you only
want an admin to be able to maintain such workspaces, simply make the admin the
owner or better yet: define a separate 'admin' group for that purpose.
If the above doesn't satisfy your requirements, then please explain where it
doesn't fit.
Our goal here is to provide a solution generic enough for all practical
use-cases so if it doesn't yet cover that we'll need to figure out a way to make
that possible.
Regards, Ate
>
>
>> There are many different ways to represent a site structure and also many
>> different ways to logically blend or merge/share/overlay logical structures on
>> top of it, but I think it would be useful to start with something which as a
>> minimum provides a canonical representation of the Rave site, and leverage
>> that
>> as a start for sharing purposes, without any need to 'OK' a shared page before
>> it becomes 'visible'.
>>
>> So for example canonical could have the following 'pages':
>>
>> /portal/app/my/profile
>> /portal/app/my/profile/about
>> /portal/app/my/profile/activities
>> /portal/app/my/pages/main
>> /portal/app/my/pages/social
>>
>> and have its /profile, /profile/about and /pages/social pages shared with
>> john.doe.
>>
>> Then, john.doe might be able to see (and have menu/links) to:
>>
>> /portal/app/my/profile
>> /portal/app/my/profile/about
>> /portal/app/my/profile/activities
>> /portal/app/my/pages/main
>> /portal/app/my/pages/social
>> /portal/app/person/canonical/profile
>> /portal/app/person/canonical/profile/about
>> /portal/app/person/canonical/pages/social
>>
>> Of course the above url structure is just an example.
>>
>> As soon as I have a bit more time I can try to better explain it, but hopefully
>> it makes sense somewhat.
>>
>> Ate
>>
>>
>>> ====
>>>
>>> Paul and I are really interested in seeing if we can develop something along
>> the lines of model (1) in a sprint next week as it would be a good fit for a project
>> we're working on. This wouldn't include the OpenSocial Spaces extension (I'm
>> sure someone else could implement it later) but would include the basic
>> functionality of sharing pages, selecting users, and extending the relevant
>> PermissionEvaluator classes for non-Owner roles.
>>>
>>>> Support shared spaces
>>>> ---------------------
>>>>
>>>> Key: RAVE-103
>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>> Project: Rave
>>>> Issue Type: Epic
>>>> Reporter: Matt Franklin
>>>>
>>>> Support shared, or common, spaces with group managed pages, widgets, and
>> security
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>>
>>>
>
RE: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by "Cooper, Sean D." <se...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Monday, March 19, 2012 9:52 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>
>On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>
>> [ https://issues.apache.org/jira/browse/RAVE-
>103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>
>> Scott Wilson commented on RAVE-103:
>> -----------------------------------
>>
>> I think there are two models we can look at:
>>
>> 1. Page Sharing
>>
>> In this model, a user creates a new page, and from the tab context menu
>selects "Share this page...". A dialog opens, and the user can add people (e.g.
>using a search/filter view), or select an existing group (e.g. friends, family, co-
>workers...). The user chooses OK, and each user is notified when they log into
>Rave of the invitation to add the shared Page. The user who created the Page is
>the Owner; each user they share with is by default a Viewer (read-only).
>However, it should be possible for the Owner to grant other users a "Can Edit"
>role allowing them to add, remove and move widgets.
>>
>> 2. Workspace Sharing
>>
>> In this model, there is a higher-level entity comprising a collection of multiple
>pages managed by a group. New shared pages can be added as sub-pages of the
>top-level workspace. I'm a bit less clear on the workflow for this one, whether its
>the same as (1) but with sub-pages, or something conceptually quite different
>>
>IMO we should (eventually) strive to merge both these models into one logical
>model from Rave perspective.
>For one, we already have a 'shared' page right now: the profile page. With sub
>pages...
>
>IMO the current separate/special handling of the profile page should technically
>or model wise not be special at all. What difference is there between sharing
>'a' page to the public with sharing 'the' profile page(s) to the public?
>To me this seems like just a matter of security configuration, with the profile
>page 'just' representing a common default 'share'.
>
>Interestingly, the current profile page also now has 'sub' pages, which in a
>minimalistic sense maybe could be regarded as a shared 'workspace' already
>(with
>a single owner).
>
>I'm interested in how adding a shared page to the users view of pages will work
>out.
>
>Right now we do not have yet a navigational representation of pages.
>Will sharing the canonical 'Main' page with john.doe result in two 'Main' pages
>to be shown? As the name of a page (currently) is only stored in the page
>itself, to prevent 'namespace' clashes, you either need to:
>- 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>/person/canonical/pages/Main), or
>- allow the viewer to *locally* rename that page (ugh: Main1, Main2, Main3),
>or
>- introduce a mounting or shortcut like feature where the viewer can structure
>its own 'site' and 'inject' shared pages at any desired location, or
>- ...?
>
>Note: in the above options I'm not referring to page IDs anymore. While each
>page can/should still be addressable by ID (too), if you're going to share pages
>you'll need *also* a logical naming representation to be able for the viewer to
>navigate its own 'site' or even more so a public/anonymous view of 'the' site.
>Meaning: we'll need to come up with a navigational structure for pages which
>can
>be rendered through menu's, site maps, etc. These IMO should be accessible
>and
>represented as REST resources like the web itself. Thus hierarchically structured.
>
>Once we get there, I think the workspace vs page discussion becomes easier and
>more 'structured'. A workspace then can simply represent a parent (or root)
>page
>resource with optional children which happens to be shared, somehow.
>
>Important this IMO is a discussion on ownership of a shared page or workspace,
>something which was also discussed, but IMO not concluded, recently on the
>OpenSocial 3.0 kickoff concerning the Spaces proposal.
>
>I think each page/space/workspace or whatever (Rave) 'social' web resource
>should have a canonical owner. Meaning only one. And if you want to 'share'
>ownership, then a separate and standalone entity like Group should be used.
>Because that will then allow providing both a canonical location (url).
>Consider for instance searching (public web or from within the portal) and
>finding an entry matching a page or workspace: what or who's canonical url
>should be linked to if you would have multiple owners?
>
-1
I have a use case where I don't want a canonical user to own the workspace. If I create a workspace page which should live on for 4+ years I cannot guarantee that the individual who first created it will still be responsible for the workspace or even an employee for the life of that workspace. I would like the ability to create workspace pages in a non-owner/group way, e.g. /portal/app/workspace/## where ## is the id of the workspace that you are working with. Permissions should be attached to the page and updatable by an admin in case the original set of people change work focuses and or positions in the company.
>There are many different ways to represent a site structure and also many
>different ways to logically blend or merge/share/overlay logical structures on
>top of it, but I think it would be useful to start with something which as a
>minimum provides a canonical representation of the Rave site, and leverage
>that
>as a start for sharing purposes, without any need to 'OK' a shared page before
>it becomes 'visible'.
>
>So for example canonical could have the following 'pages':
>
> /portal/app/my/profile
> /portal/app/my/profile/about
> /portal/app/my/profile/activities
> /portal/app/my/pages/main
> /portal/app/my/pages/social
>
>and have its /profile, /profile/about and /pages/social pages shared with
>john.doe.
>
>Then, john.doe might be able to see (and have menu/links) to:
>
> /portal/app/my/profile
> /portal/app/my/profile/about
> /portal/app/my/profile/activities
> /portal/app/my/pages/main
> /portal/app/my/pages/social
> /portal/app/person/canonical/profile
> /portal/app/person/canonical/profile/about
> /portal/app/person/canonical/pages/social
>
>Of course the above url structure is just an example.
>
>As soon as I have a bit more time I can try to better explain it, but hopefully
>it makes sense somewhat.
>
>Ate
>
>
>> ====
>>
>> Paul and I are really interested in seeing if we can develop something along
>the lines of model (1) in a sprint next week as it would be a good fit for a project
>we're working on. This wouldn't include the OpenSocial Spaces extension (I'm
>sure someone else could implement it later) but would include the basic
>functionality of sharing pages, selecting users, and extending the relevant
>PermissionEvaluator classes for non-Owner roles.
>>
>>> Support shared spaces
>>> ---------------------
>>>
>>> Key: RAVE-103
>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>> Project: Rave
>>> Issue Type: Epic
>>> Reporter: Matt Franklin
>>>
>>> Support shared, or common, spaces with group managed pages, widgets, and
>security
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
New to Rave !
Posted by Viknes B <vi...@msn.com>.
Hi Guys,
I am new to Rave. It would be of great help if u guys can tell me where i
can get some examples implemented with the help of Rave.
Thanks
Viknes
RE: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>Sent: Monday, March 19, 2012 5:36 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>
>On 19 Mar 2012, at 13:51, Ate Douma wrote:
>
>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>
>>> [ https://issues.apache.org/jira/browse/RAVE-
>103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>
>>> Scott Wilson commented on RAVE-103:
>>> -----------------------------------
>>>
>>> I think there are two models we can look at:
>>>
>>> 1. Page Sharing
>>>
>>> In this model, a user creates a new page, and from the tab context menu
>selects "Share this page...". A dialog opens, and the user can add people (e.g.
>using a search/filter view), or select an existing group (e.g. friends, family, co-
>workers...). The user chooses OK, and each user is notified when they log into
>Rave of the invitation to add the shared Page. The user who created the Page
>is the Owner; each user they share with is by default a Viewer (read-only).
>However, it should be possible for the Owner to grant other users a "Can Edit"
>role allowing them to add, remove and move widgets.
>>>
>>> 2. Workspace Sharing
>>>
>>> In this model, there is a higher-level entity comprising a collection of
>multiple pages managed by a group. New shared pages can be added as sub-
>pages of the top-level workspace. I'm a bit less clear on the workflow for this
>one, whether its the same as (1) but with sub-pages, or something
>conceptually quite different
>>>
>> IMO we should (eventually) strive to merge both these models into one
>logical model from Rave perspective.
>> For one, we already have a 'shared' page right now: the profile page. With
>sub pages...
>>
>> IMO the current separate/special handling of the profile page should
>technically or model wise not be special at all. What difference is there
>between sharing 'a' page to the public with sharing 'the' profile page(s) to the
>public?
>> To me this seems like just a matter of security configuration, with the profile
>page 'just' representing a common default 'share'.
>
>Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
>Anyone that you could add as a member of your page, or some user-less
>permissions attached to the page.
+1 for modeling them the same. We just have to make sure that we have the right information available when the page is created to apply the right permission scheme; but this could be accomplished by re-working the Page Template to include a default permission set. There is one small OpenSocial concern we need to make sure we have a strategy for supporting: The default view name for profile isn't HOME, it's PROFILE.
>>
>> Interestingly, the current profile page also now has 'sub' pages, which in a
>minimalistic sense maybe could be regarded as a shared 'workspace' already
>(with a single owner).
>
>Indeed - every page is sort of a workspace in that regard, though that isn't
>currently exposed through the UI.
I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it. The workspace would represent the context and could come in the form of a portal, profile, team site, peer-to-peer shared workspace, and any other scenario. The changes in context would allow us to create implementations that have different "UI" for each workspace. This way, each workspace can lay out the entire web page however works best for their use case. We can then create a new construct of "Workspace Template" that is responsible for the overall look, feel & layout of the web page and use the PageTemplates to manage the regions and corresponding widgets.
>>
>> I'm interested in how adding a shared page to the users view of pages will
>work out.
>
>That looks to be the bigger challenge - making the model make sense to users.
IMO, we need to have a smooth navigation in the header to move between various workspaces.
>
>>
>> Right now we do not have yet a navigational representation of pages.
>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>pages to be shown? As the name of a page (currently) is only stored in the
>page itself, to prevent 'namespace' clashes, you either need to:
>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>/person/canonical/pages/Main), or
>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>Main3), or
>> - introduce a mounting or shortcut like feature where the viewer can
>structure its own 'site' and 'inject' shared pages at any desired location, or
>> - ...?
>
>Perhaps the "mounted" pages look in some way different to the normal tabs
>stylistically (e.g. aligned to the right and a different colour, with a tooltip along
>the lines of "Shared with you by Bob"). Or maybe you have to have a separate
>page navigation UI to organise pages - "My pages", "Pages shared with me",
>"Public pages" (etc)
I think what approach we take depends on what is sharable. Assuming we go with the "Workspace" concept, would your users want to share entire workspaces or just individual groups of regions that we now call pages, or both?
>
>>
>> Note: in the above options I'm not referring to page IDs anymore. While
>each page can/should still be addressable by ID (too), if you're going to share
>pages you'll need *also* a logical naming representation to be able for the
>viewer to navigate its own 'site' or even more so a public/anonymous view of
>'the' site. Meaning: we'll need to come up with a navigational structure for
>pages which can be rendered through menu's, site maps, etc. These IMO
>should be accessible and represented as REST resources like the web itself.
>Thus hierarchically structured.
>>
>> Once we get there, I think the workspace vs page discussion becomes easier
>and more 'structured'. A workspace then can simply represent a parent (or
>root) page resource with optional children which happens to be shared,
>somehow.
>>
>> Important this IMO is a discussion on ownership of a shared page or
>workspace, something which was also discussed, but IMO not concluded,
>recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>
>> I think each page/space/workspace or whatever (Rave) 'social' web
>resource should have a canonical owner. Meaning only one. And if you want
>to 'share' ownership, then a separate and standalone entity like Group should
>be used. Because that will then allow providing both a canonical location (url).
>
>+1 I like the idea of a single owner of any page, even if that owner is a Group:
This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>
>/portal/app/group/trekkies/profile
>/portal/app/group/trekkies/spock
>
>> Consider for instance searching (public web or from within the portal) and
>finding an entry matching a page or workspace: what or who's canonical url
>should be linked to if you would have multiple owners?
>>
>> There are many different ways to represent a site structure and also many
>different ways to logically blend or merge/share/overlay logical structures on
>top of it, but I think it would be useful to start with something which as a
>minimum provides a canonical representation of the Rave site, and leverage
>that as a start for sharing purposes, without any need to 'OK' a shared page
>before it becomes 'visible'.
>
>Agreed - a predictable and user-readable URL scheme will help with
>understanding how the pages fit together.
>
>At the moment, if you try and access a page without permission, you just get
>an error message - this could instead have a dialog to send a message to the
>owner that you'd like to be added or otherwise start a flow that could lead to
>being added as a page member.
>
>>
>> So for example canonical could have the following 'pages':
>>
>> /portal/app/my/profile
>> /portal/app/my/profile/about
>> /portal/app/my/profile/activities
>> /portal/app/my/pages/main
>> /portal/app/my/pages/social
I am all for intuitive URL structure and think addressable sub-components could make sense. For at least one of our use cases, we would want /portal/app/my/profile/about and /portal/app/my/profile have the same overall structure with user image etc at the top of the page. Maybe in /about the about tab could be active?
>>
>> and have its /profile, /profile/about and /pages/social pages shared with
>john.doe
>>
>> Then, john.doe might be able to see (and have menu/links) to:
>>
>> /portal/app/my/profile
>> /portal/app/my/profile/about
>> /portal/app/my/profile/activities
>> /portal/app/my/pages/main
>> /portal/app/my/pages/social
>> /portal/app/person/canonical/profile
>> /portal/app/person/canonical/profile/about
>> /portal/app/person/canonical/pages/social
>>
>> Of course the above url structure is just an example.
>
>
>>
>> As soon as I have a bit more time I can try to better explain it, but hopefully
>it makes sense somewhat.
>
>I did some hacking on the model, controller, and permission evaluator code
>today to get the backend of page sharing working, and have passed the baton
>to Paul as I don't think I'm going to get any coding time for the next two days.
>So we should (I hope) have some working page-sharing to play with by the
>end of the week.
>
>>
>> Ate
>>
>>
>>> ====
>>>
>>> Paul and I are really interested in seeing if we can develop something along
>the lines of model (1) in a sprint next week as it would be a good fit for a
>project we're working on. This wouldn't include the OpenSocial Spaces
>extension (I'm sure someone else could implement it later) but would include
>the basic functionality of sharing pages, selecting users, and extending the
>relevant PermissionEvaluator classes for non-Owner roles.
>>>
>>>> Support shared spaces
>>>> ---------------------
>>>>
>>>> Key: RAVE-103
>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>> Project: Rave
>>>> Issue Type: Epic
>>>> Reporter: Matt Franklin
>>>>
>>>> Support shared, or common, spaces with group managed pages, widgets,
>and security
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>> For more information on JIRA, see:
>http://www.atlassian.com/software/jira
>>>
>>>
>>
RE: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>Sent: Thursday, March 22, 2012 10:54 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>
>
>On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
>
>> Some input from the UX perspective:
>>
>> Navigation does depend on the architecture of the application (in essence,
>the user learns about the architecture from the navigation structure).
>>
>> You want the possibility of inheritance, but having too many levels makes it
>hard/impossible to navigate/visualize the structure.
>>
>> I'd suggest coming up with a basic skeleton first, and then working
>backwards to implementation. For example:
>>
>> Environment
>> - one (or more) workspaces
>> - zero (or more) sub-workspaces (or sub-spaces - useful if the workspace
>gets too large... however, I'd end inheritance there)
>> - one (or more) pages
>> - zero (or more) widgets
>
>I think I'd be happier with one less level:
>
>one or more workspaces (context and header)
>... has one or more pages (tab)
> ... has one or more regions (area on page)
> ... has zero or more widgets
>
>Though reading down I think we may mean the same thing :-)
>
>
>> In my way of thinking, the workspace defines the context (+1 for context-
>sensitive implementation!). The user may or may not need/want to navigate
>to other workspaces. As Matt stated, traditionally the header is used to show
>the current context - and to allow the user to navigate to a different context.
>
>For moving between pages within a workspace, there is the existing tabbed
>navigation model. I think adding a context-switching navigation for moving
>between workspaces would fit well; and associating this navigation with the
>header also makes sense.
>
>(I find the Liferay model for handling the workspace/pages concept really
>confusing, so simpler would be better...)
+1. We want the least confusing model possible
>
>>
>> A workspace will have one or more owners* who get to decide who can:
>> - edit the workspace (i.e., join the ranks of administrators)
>> - access the workspace (i.e., join the ranks of users)
>> ---
>> * (from implementation perspective, that could equal "one owner - who can
>be a group")
>>
>> The concept of ownership is key. Who owns the content that you create in a
>workspace? In just about every collaboration-support system I've seen, the
>author retains ownership. However, that creates problems - when the user
>leaves the workspace (or the environment), what happens to the content? I'd
>like to explore the concept of content being owned by the workspace... and if
>the user is not comfortable with that, they have their own (personal)
>workspace to work with.
>>
>> Stan Drozdetski
>> MITRE
>>
>> -----Original Message-----
>> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>> Sent: Tuesday, March 20, 2012 10:42 AM
>> To: rave-dev@incubator.apache.org
>> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>>
>>> -----Original Message-----
>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>>> Sent: Monday, March 19, 2012 5:36 PM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>>>
>>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
>>>
>>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>>>
>>>>> [ https://issues.apache.org/jira/browse/RAVE-
>>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>>>
>>>>> Scott Wilson commented on RAVE-103:
>>>>> -----------------------------------
>>>>>
>>>>> I think there are two models we can look at:
>>>>>
>>>>> 1. Page Sharing
>>>>>
>>>>> In this model, a user creates a new page, and from the tab context
>menu
>>> selects "Share this page...". A dialog opens, and the user can add people
>(e.g.
>>> using a search/filter view), or select an existing group (e.g. friends, family,
>co-
>>> workers...). The user chooses OK, and each user is notified when they log
>into
>>> Rave of the invitation to add the shared Page. The user who created the
>Page
>>> is the Owner; each user they share with is by default a Viewer (read-only).
>>> However, it should be possible for the Owner to grant other users a "Can
>Edit"
>>> role allowing them to add, remove and move widgets.
>>>>>
>>>>> 2. Workspace Sharing
>>>>>
>>>>> In this model, there is a higher-level entity comprising a collection of
>>> multiple pages managed by a group. New shared pages can be added as
>sub-
>>> pages of the top-level workspace. I'm a bit less clear on the workflow for
>this
>>> one, whether its the same as (1) but with sub-pages, or something
>>> conceptually quite different
>>>>>
>>>> IMO we should (eventually) strive to merge both these models into one
>>> logical model from Rave perspective.
>>>> For one, we already have a 'shared' page right now: the profile page. With
>>> sub pages...
>>>>
>>>> IMO the current separate/special handling of the profile page should
>>> technically or model wise not be special at all. What difference is there
>>> between sharing 'a' page to the public with sharing 'the' profile page(s) to
>the
>>> public?
>>>> To me this seems like just a matter of security configuration, with the
>profile
>>> page 'just' representing a common default 'share'.
>>>
>>> Right - that could be handled by "magic" Users like AnyAuthenticatedUser
>and
>>> Anyone that you could add as a member of your page, or some user-less
>>> permissions attached to the page.
>>
>> +1 for modeling them the same. We just have to make sure that we have
>the right information available when the page is created to apply the right
>permission scheme; but this could be accomplished by re-working the Page
>Template to include a default permission set. There is one small OpenSocial
>concern we need to make sure we have a strategy for supporting: The
>default view name for profile isn't HOME, it's PROFILE.
>>
>>>>
>>>> Interestingly, the current profile page also now has 'sub' pages, which in a
>>> minimalistic sense maybe could be regarded as a shared 'workspace'
>already
>>> (with a single owner).
>>>
>>> Indeed - every page is sort of a workspace in that regard, though that isn't
>>> currently exposed through the UI.
>>
>> I could definitely see a scenario where we have the concept of a workspace
>with "pages" attached to it. The workspace would represent the context and
>could come in the form of a portal, profile, team site, peer-to-peer shared
>workspace, and any other scenario. The changes in context would allow us to
>create implementations that have different "UI" for each workspace. This
>way, each workspace can lay out the entire web page however works best for
>their use case. We can then create a new construct of "Workspace Template"
>that is responsible for the overall look, feel & layout of the web page and use
>the PageTemplates to manage the regions and corresponding widgets.
>>
>>>>
>>>> I'm interested in how adding a shared page to the users view of pages will
>>> work out.
>>>
>>> That looks to be the bigger challenge - making the model make sense to
>users.
>>
>> IMO, we need to have a smooth navigation in the header to move between
>various workspaces.
>>
>>>
>>>>
>>>> Right now we do not have yet a navigational representation of pages.
>>>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>>> pages to be shown? As the name of a page (currently) is only stored in the
>>> page itself, to prevent 'namespace' clashes, you either need to:
>>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>>> /person/canonical/pages/Main), or
>>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>>> Main3), or
>>>> - introduce a mounting or shortcut like feature where the viewer can
>>> structure its own 'site' and 'inject' shared pages at any desired location, or
>>>> - ...?
>>>
>>> Perhaps the "mounted" pages look in some way different to the normal
>tabs
>>> stylistically (e.g. aligned to the right and a different colour, with a tooltip
>along
>>> the lines of "Shared with you by Bob"). Or maybe you have to have a
>separate
>>> page navigation UI to organise pages - "My pages", "Pages shared with
>me",
>>> "Public pages" (etc)
>>
>> I think what approach we take depends on what is sharable. Assuming we
>go with the "Workspace" concept, would your users want to share entire
>workspaces or just individual groups of regions that we now call pages, or
>both?
>>
>>>
>>>>
>>>> Note: in the above options I'm not referring to page IDs anymore. While
>>> each page can/should still be addressable by ID (too), if you're going to
>share
>>> pages you'll need *also* a logical naming representation to be able for the
>>> viewer to navigate its own 'site' or even more so a public/anonymous view
>of
>>> 'the' site. Meaning: we'll need to come up with a navigational structure for
>>> pages which can be rendered through menu's, site maps, etc. These IMO
>>> should be accessible and represented as REST resources like the web itself.
>>> Thus hierarchically structured.
>>>>
>>>> Once we get there, I think the workspace vs page discussion becomes
>easier
>>> and more 'structured'. A workspace then can simply represent a parent (or
>>> root) page resource with optional children which happens to be shared,
>>> somehow.
>>>>
>>>> Important this IMO is a discussion on ownership of a shared page or
>>> workspace, something which was also discussed, but IMO not concluded,
>>> recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>>>
>>>> I think each page/space/workspace or whatever (Rave) 'social' web
>>> resource should have a canonical owner. Meaning only one. And if you
>want
>>> to 'share' ownership, then a separate and standalone entity like Group
>should
>>> be used. Because that will then allow providing both a canonical location
>(url).
>>>
>>> +1 I like the idea of a single owner of any page, even if that owner is a
>Group:
>>
>> This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>>
>>>
>>> /portal/app/group/trekkies/profile
>>> /portal/app/group/trekkies/spock
>>>
>>>> Consider for instance searching (public web or from within the portal) and
>>> finding an entry matching a page or workspace: what or who's canonical url
>>> should be linked to if you would have multiple owners?
>>>>
>>>> There are many different ways to represent a site structure and also
>many
>>> different ways to logically blend or merge/share/overlay logical structures
>on
>>> top of it, but I think it would be useful to start with something which as a
>>> minimum provides a canonical representation of the Rave site, and
>leverage
>>> that as a start for sharing purposes, without any need to 'OK' a shared page
>>> before it becomes 'visible'.
>>>
>>> Agreed - a predictable and user-readable URL scheme will help with
>>> understanding how the pages fit together.
>>>
>>> At the moment, if you try and access a page without permission, you just
>get
>>> an error message - this could instead have a dialog to send a message to
>the
>>> owner that you'd like to be added or otherwise start a flow that could lead
>to
>>> being added as a page member.
>>>
>>>>
>>>> So for example canonical could have the following 'pages':
>>>>
>>>> /portal/app/my/profile
>>>> /portal/app/my/profile/about
>>>> /portal/app/my/profile/activities
>>>> /portal/app/my/pages/main
>>>> /portal/app/my/pages/social
>>
>> I am all for intuitive URL structure and think addressable sub-components
>could make sense. For at least one of our use cases, we would want
>/portal/app/my/profile/about and /portal/app/my/profile have the same
>overall structure with user image etc at the top of the page. Maybe in /about
>the about tab could be active?
>>
>>>>
>>>> and have its /profile, /profile/about and /pages/social pages shared with
>>> john.doe
>>>>
>>>> Then, john.doe might be able to see (and have menu/links) to:
>>>>
>>>> /portal/app/my/profile
>>>> /portal/app/my/profile/about
>>>> /portal/app/my/profile/activities
>>>> /portal/app/my/pages/main
>>>> /portal/app/my/pages/social
>>>> /portal/app/person/canonical/profile
>>>> /portal/app/person/canonical/profile/about
>>>> /portal/app/person/canonical/pages/social
>>>>
>>>> Of course the above url structure is just an example.
>>>
>>>
>>>>
>>>> As soon as I have a bit more time I can try to better explain it, but
>hopefully
>>> it makes sense somewhat.
>>>
>>> I did some hacking on the model, controller, and permission evaluator code
>>> today to get the backend of page sharing working, and have passed the
>baton
>>> to Paul as I don't think I'm going to get any coding time for the next two
>days.
>>> So we should (I hope) have some working page-sharing to play with by the
>>> end of the week.
>>>
>>>>
>>>> Ate
>>>>
>>>>
>>>>> ====
>>>>>
>>>>> Paul and I are really interested in seeing if we can develop something
>along
>>> the lines of model (1) in a sprint next week as it would be a good fit for a
>>> project we're working on. This wouldn't include the OpenSocial Spaces
>>> extension (I'm sure someone else could implement it later) but would
>include
>>> the basic functionality of sharing pages, selecting users, and extending the
>>> relevant PermissionEvaluator classes for non-Owner roles.
>>>>>
>>>>>> Support shared spaces
>>>>>> ---------------------
>>>>>>
>>>>>> Key: RAVE-103
>>>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>>>> Project: Rave
>>>>>> Issue Type: Epic
>>>>>> Reporter: Matt Franklin
>>>>>>
>>>>>> Support shared, or common, spaces with group managed pages,
>widgets,
>>> and security
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> If you think it was sent incorrectly, please contact your JIRA
>administrators:
>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>>> For more information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>>>>
>>>>>
>>>>
>>
>>
RE: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Thursday, March 22, 2012 2:13 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>
>On Mar 22, 2012 6:49 PM, "Scott Wilson" <sc...@gmail.com>
>wrote:
>>
>>
>> On 22 Mar 2012, at 15:40, Ate Douma wrote:
>>
>> > On 03/22/2012 03:54 PM, Scott Wilson wrote:
>> >>
>> >> On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
>> >>
>> >>> Some input from the UX perspective:
>> >>>
>> >>> Navigation does depend on the architecture of the application (in
>essence, the user learns about the architecture from the navigation
>structure).
>> >>>
>> >>> You want the possibility of inheritance, but having too many levels
>makes it hard/impossible to navigate/visualize the structure.
>> >>>
>> >>> I'd suggest coming up with a basic skeleton first, and then working
>backwards to implementation. For example:
>> >>>
>> >>> Environment
>> >>> - one (or more) workspaces
>> >>> - zero (or more) sub-workspaces (or sub-spaces - useful if the
>workspace gets too large... however, I'd end inheritance there)
>> >>> - one (or more) pages
>> >>> - zero (or more) widgets
>> >>
>> >> I think I'd be happier with one less level:
>> >>
>> >> one or more workspaces (context and header)
>> >> ... has one or more pages (tab)
>> >> ... has one or more regions (area on page)
>> >> ... has zero or more widgets
>> >>
>> >> Though reading down I think we may mean the same thing :-)
>> >
>> > To me either of the above, for *now*, is fine.
>> >
>> > However, a less strict separation between workspaces and pages IMO
>should be kept in mind and will pay off better in the end.
>> >
>> > As I said before, in my view a workspace can be just a page with
>(possible) child pages and some extra security and other *configurations*.
>> > If for instance a theme should only be configurable on root page or
>workspace level IMO is a choice to be made by a concrete Rave
>implementation, not forced into the model...
>> > Likewise, rendering and representation choices concerning
>workspace/root-page context and switching, also should be an (custom)
>implementation choice.
>> > Same goes for showing sibling pages or child pages as tabs.
>> > Or usage of # hashbang for sub url navigation (which IMO is
>fundamentally broken and wrong to be honest).
>>
>> I think we're in agreement here. The model just has a hierarchy of pages
>and sub-pages, but for the concrete implementation in the current portal we
>can present this as "workspaces" with "tabs". It could just as easily be
>represented using a side-nav tree or heading/subheading structure.
>
>+1
+1
>
>>
>> >
>> > I'd be in favor of specifying a 'workspace' as a set of 'rules' which
>we then leverage in the demo Rave portal as:
>> > - a root navigational page
>> > - defines an inheritable theming for child pages
>> > - defines administrative ownership for this page and its children
>> > - defines access/view privileges for this page and its children
>> >
>> > But being (just) a page in itself, the above 'rules' would just be an
>implementation detail, e.g. (custom) portal specific.
>> >
>> > If in another context nested/child page would be allowed to override
>the theming, or define additional security constraints, or context
>switching on child pages, that should also be possible.
>> > For our (Hippo) use-cases we definitely will be needing that level of
>flexibility...
>> >
>> > What I like to stress is that while building a good and out-of-the-box
>usable Rave portal *demo* implementation, we need keep an open mind for
>other use-cases :)
>> > Definitely not by making it more complex than needed, but also not more
>restricted than possible or single use-case driven either.
>> >
>> >>
>> >>
>> >>> In my way of thinking, the workspace defines the context (+1 for
>context-sensitive implementation!). The user may or may not need/want to
>navigate to other workspaces. As Matt stated, traditionally the header is
>used to show the current context - and to allow the user to navigate to a
>different context.
>> >>
>> >> For moving between pages within a workspace, there is the existing
>tabbed navigation model. I think adding a context-switching navigation for
>moving between workspaces would fit well; and associating this navigation
>with the header also makes sense.
>> >>
>> >> (I find the Liferay model for handling the workspace/pages concept
>really confusing, so simpler would be better...)
>> >
>> > Can you explain a bit how the Liferay model works?
>> > Its been a long time since I used or even looked at Liferay.
>> > Good examples of what you *don't* want are IMO extremely useful!
>>
>>
>> LifeRay typically has a drop-down menu with "Home" and "My Places"; the
>latter of which has the sub-list of "workspaces"; each of these is then
>broken down into "Private Pages" and "Public Pages" (all in a sort of
>cascading menu). There are also tabs and breadcrumbs.
>>
>> One of the big usability issues with a lot of sites is its not obvious
>how these things are really structured as there are lots of "aliases" that
>mean you can end up somewhere completely different to where you thought
>you
>were going (and not know where you "are" so to speak).
>Thanks for explaining. I remember it now. Quite confusing interaction
>indeed, and I never really liked it.
>>
>> So for Rave I'd like the structure to be simple and obvious in the
>default implementation, with as little possibility to feel "lost" as
>possible.
>
>+1
+1
>>
>> >
>> > Ate
>> >>
>> >>>
>> >>> A workspace will have one or more owners* who get to decide who
>can:
>> >>> - edit the workspace (i.e., join the ranks of administrators)
>> >>> - access the workspace (i.e., join the ranks of users)
>> >>> ---
>> >>> * (from implementation perspective, that could equal "one owner -
>who
>can be a group")
>> >>>
>> >>> The concept of ownership is key. Who owns the content that you
>create
>in a workspace? In just about every collaboration-support system I've seen,
>the author retains ownership. However, that creates problems - when the
>user leaves the workspace (or the environment), what happens to the
>content? I'd like to explore the concept of content being owned by the
>workspace... and if the user is not comfortable with that, they have their
>own (personal) workspace to work with.
>> >>>
>> >>> Stan Drozdetski
>> >>> MITRE
>> >>>
>> >>> -----Original Message-----
>> >>> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>> >>> Sent: Tuesday, March 20, 2012 10:42 AM
>> >>> To: rave-dev@incubator.apache.org
>> >>> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>> >>>> Sent: Monday, March 19, 2012 5:36 PM
>> >>>> To: rave-dev@incubator.apache.org
>> >>>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>> >>>>
>> >>>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
>> >>>>
>> >>>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>> >>>>>>
>> >>>>>> [ https://issues.apache.org/jira/browse/RAVE-
>> >>>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> >>>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>> >>>>>>
>> >>>>>> Scott Wilson commented on RAVE-103:
>> >>>>>> -----------------------------------
>> >>>>>>
>> >>>>>> I think there are two models we can look at:
>> >>>>>>
>> >>>>>> 1. Page Sharing
>> >>>>>>
>> >>>>>> In this model, a user creates a new page, and from the tab context
>menu
>> >>>> selects "Share this page...". A dialog opens, and the user can add
>people (e.g.
>> >>>> using a search/filter view), or select an existing group (e.g.
>friends, family, co-
>> >>>> workers...). The user chooses OK, and each user is notified when
>they log into
>> >>>> Rave of the invitation to add the shared Page. The user who created
>the Page
>> >>>> is the Owner; each user they share with is by default a Viewer
>(read-only).
>> >>>> However, it should be possible for the Owner to grant other users a
>"Can Edit"
>> >>>> role allowing them to add, remove and move widgets.
>> >>>>>>
>> >>>>>> 2. Workspace Sharing
>> >>>>>>
>> >>>>>> In this model, there is a higher-level entity comprising a
>collection of
>> >>>> multiple pages managed by a group. New shared pages can be added
>as
>sub-
>> >>>> pages of the top-level workspace. I'm a bit less clear on the
>workflow for this
>> >>>> one, whether its the same as (1) but with sub-pages, or something
>> >>>> conceptually quite different
>> >>>>>>
>> >>>>> IMO we should (eventually) strive to merge both these models into
>one
>> >>>> logical model from Rave perspective.
>> >>>>> For one, we already have a 'shared' page right now: the profile
>page. With
>> >>>> sub pages...
>> >>>>>
>> >>>>> IMO the current separate/special handling of the profile page should
>> >>>> technically or model wise not be special at all. What difference is
>there
>> >>>> between sharing 'a' page to the public with sharing 'the' profile
>page(s) to the
>> >>>> public?
>> >>>>> To me this seems like just a matter of security configuration, with
>the profile
>> >>>> page 'just' representing a common default 'share'.
>> >>>>
>> >>>> Right - that could be handled by "magic" Users like
>AnyAuthenticatedUser and
>> >>>> Anyone that you could add as a member of your page, or some user-
>less
>> >>>> permissions attached to the page.
>> >>>
>> >>> +1 for modeling them the same. We just have to make sure that we
>have the right information available when the page is created to apply the
>right permission scheme; but this could be accomplished by re-working the
>Page Template to include a default permission set. There is one small
>OpenSocial concern we need to make sure we have a strategy for supporting:
> The default view name for profile isn't HOME, it's PROFILE.
>> >>>
>> >>>>>
>> >>>>> Interestingly, the current profile page also now has 'sub' pages,
>which in a
>> >>>> minimalistic sense maybe could be regarded as a shared 'workspace'
>already
>> >>>> (with a single owner).
>> >>>>
>> >>>> Indeed - every page is sort of a workspace in that regard, though
>that isn't
>> >>>> currently exposed through the UI.
>> >>>
>> >>> I could definitely see a scenario where we have the concept of a
>workspace with "pages" attached to it. The workspace would represent the
>context and could come in the form of a portal, profile, team site,
>peer-to-peer shared workspace, and any other scenario. The changes in
>context would allow us to create implementations that have different "UI"
>for each workspace. This way, each workspace can lay out the entire web
>page however works best for their use case. We can then create a new
>construct of "Workspace Template" that is responsible for the overall look,
>feel& layout of the web page and use the PageTemplates to manage the
>regions and corresponding widgets.
>> >>>
>> >>>>>
>> >>>>> I'm interested in how adding a shared page to the users view of
>pages will
>> >>>> work out.
>> >>>>
>> >>>> That looks to be the bigger challenge - making the model make sense
>to users.
>> >>>
>> >>> IMO, we need to have a smooth navigation in the header to move
>between various workspaces.
>> >>>
>> >>>>
>> >>>>>
>> >>>>> Right now we do not have yet a navigational representation of pages.
>> >>>>> Will sharing the canonical 'Main' page with john.doe result in two
>'Main'
>> >>>> pages to be shown? As the name of a page (currently) is only stored
>in the
>> >>>> page itself, to prevent 'namespace' clashes, you either need to:
>> >>>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something
>like:
>> >>>> /person/canonical/pages/Main), or
>> >>>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>> >>>> Main3), or
>> >>>>> - introduce a mounting or shortcut like feature where the viewer can
>> >>>> structure its own 'site' and 'inject' shared pages at any desired
>location, or
>> >>>>> - ...?
>> >>>>
>> >>>> Perhaps the "mounted" pages look in some way different to the
>normal
>tabs
>> >>>> stylistically (e.g. aligned to the right and a different colour,
>with a tooltip along
>> >>>> the lines of "Shared with you by Bob"). Or maybe you have to have a
>separate
>> >>>> page navigation UI to organise pages - "My pages", "Pages shared
>with me",
>> >>>> "Public pages" (etc)
>> >>>
>> >>> I think what approach we take depends on what is sharable. Assuming
>we go with the "Workspace" concept, would your users want to share entire
>workspaces or just individual groups of regions that we now call pages, or
>both?
>> >>>
>> >>>>
>> >>>>>
>> >>>>> Note: in the above options I'm not referring to page IDs anymore.
>While
>> >>>> each page can/should still be addressable by ID (too), if you're
>going to share
>> >>>> pages you'll need *also* a logical naming representation to be able
>for the
>> >>>> viewer to navigate its own 'site' or even more so a public/anonymous
>view of
>> >>>> 'the' site. Meaning: we'll need to come up with a navigational
>structure for
>> >>>> pages which can be rendered through menu's, site maps, etc. These
>IMO
>> >>>> should be accessible and represented as REST resources like the web
>itself.
>> >>>> Thus hierarchically structured.
>> >>>>>
>> >>>>> Once we get there, I think the workspace vs page discussion
>becomes
>easier
>> >>>> and more 'structured'. A workspace then can simply represent a
>parent (or
>> >>>> root) page resource with optional children which happens to be
>shared,
>> >>>> somehow.
>> >>>>>
>> >>>>> Important this IMO is a discussion on ownership of a shared page or
>> >>>> workspace, something which was also discussed, but IMO not
>concluded,
>> >>>> recently on the OpenSocial 3.0 kickoff concerning the Spaces
>proposal.
>> >>>>>
>> >>>>> I think each page/space/workspace or whatever (Rave) 'social' web
>> >>>> resource should have a canonical owner. Meaning only one. And if you
>want
>> >>>> to 'share' ownership, then a separate and standalone entity like
>Group should
>> >>>> be used. Because that will then allow providing both a canonical
>location (url).
>> >>>>
>> >>>> +1 I like the idea of a single owner of any page, even if that owner
>is a Group:
>> >>>
>> >>> This is in alignment with the discussions from the OpenSocial 3.0
>kickoff.
>> >>>
>> >>>>
>> >>>> /portal/app/group/trekkies/profile
>> >>>> /portal/app/group/trekkies/spock
>> >>>>
>> >>>>> Consider for instance searching (public web or from within the
>portal) and
>> >>>> finding an entry matching a page or workspace: what or who's
>canonical url
>> >>>> should be linked to if you would have multiple owners?
>> >>>>>
>> >>>>> There are many different ways to represent a site structure and
>also many
>> >>>> different ways to logically blend or merge/share/overlay logical
>structures on
>> >>>> top of it, but I think it would be useful to start with something
>which as a
>> >>>> minimum provides a canonical representation of the Rave site, and
>leverage
>> >>>> that as a start for sharing purposes, without any need to 'OK' a
>shared page
>> >>>> before it becomes 'visible'.
>> >>>>
>> >>>> Agreed - a predictable and user-readable URL scheme will help with
>> >>>> understanding how the pages fit together.
>> >>>>
>> >>>> At the moment, if you try and access a page without permission, you
>just get
>> >>>> an error message - this could instead have a dialog to send a
>message to the
>> >>>> owner that you'd like to be added or otherwise start a flow that
>could lead to
>> >>>> being added as a page member.
>> >>>>
>> >>>>>
>> >>>>> So for example canonical could have the following 'pages':
>> >>>>>
>> >>>>> /portal/app/my/profile
>> >>>>> /portal/app/my/profile/about
>> >>>>> /portal/app/my/profile/activities
>> >>>>> /portal/app/my/pages/main
>> >>>>> /portal/app/my/pages/social
>> >>>
>> >>> I am all for intuitive URL structure and think addressable
>sub-components could make sense. For at least one of our use cases, we
>would want /portal/app/my/profile/about and /portal/app/my/profile have
>the
>same overall structure with user image etc at the top of the page. Maybe in
>/about the about tab could be active?
>> >>>
>> >>>>>
>> >>>>> and have its /profile, /profile/about and /pages/social pages
>shared with
>> >>>> john.doe
>> >>>>>
>> >>>>> Then, john.doe might be able to see (and have menu/links) to:
>> >>>>>
>> >>>>> /portal/app/my/profile
>> >>>>> /portal/app/my/profile/about
>> >>>>> /portal/app/my/profile/activities
>> >>>>> /portal/app/my/pages/main
>> >>>>> /portal/app/my/pages/social
>> >>>>> /portal/app/person/canonical/profile
>> >>>>> /portal/app/person/canonical/profile/about
>> >>>>> /portal/app/person/canonical/pages/social
>> >>>>>
>> >>>>> Of course the above url structure is just an example.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> As soon as I have a bit more time I can try to better explain it,
>but hopefully
>> >>>> it makes sense somewhat.
>> >>>>
>> >>>> I did some hacking on the model, controller, and permission
>evaluator code
>> >>>> today to get the backend of page sharing working, and have passed
>the baton
>> >>>> to Paul as I don't think I'm going to get any coding time for the
>next two days.
>> >>>> So we should (I hope) have some working page-sharing to play with by
>the
>> >>>> end of the week.
>> >>>>
>> >>>>>
>> >>>>> Ate
>> >>>>>
>> >>>>>
>> >>>>>> ====
>> >>>>>>
>> >>>>>> Paul and I are really interested in seeing if we can develop
>something along
>> >>>> the lines of model (1) in a sprint next week as it would be a good
>fit for a
>> >>>> project we're working on. This wouldn't include the OpenSocial
>Spaces
>> >>>> extension (I'm sure someone else could implement it later) but would
>include
>> >>>> the basic functionality of sharing pages, selecting users, and
>extending the
>> >>>> relevant PermissionEvaluator classes for non-Owner roles.
>> >>>>>>
>> >>>>>>> Support shared spaces
>> >>>>>>> ---------------------
>> >>>>>>>
>> >>>>>>> Key: RAVE-103
>> >>>>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>> >>>>>>> Project: Rave
>> >>>>>>> Issue Type: Epic
>> >>>>>>> Reporter: Matt Franklin
>> >>>>>>>
>> >>>>>>> Support shared, or common, spaces with group managed pages,
>widgets,
>> >>>> and security
>> >>>>>>
>> >>>>>> --
>> >>>>>> This message is automatically generated by JIRA.
>> >>>>>> If you think it was sent incorrectly, please contact your JIRA
>administrators:
>> >>>>
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> >>>>>> For more information on JIRA, see:
>> >>>> http://www.atlassian.com/software/jira
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>
>> >>>
>> >>
>> >
>>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Ate Douma <at...@douma.nu>.
On Mar 22, 2012 6:49 PM, "Scott Wilson" <sc...@gmail.com>
wrote:
>
>
> On 22 Mar 2012, at 15:40, Ate Douma wrote:
>
> > On 03/22/2012 03:54 PM, Scott Wilson wrote:
> >>
> >> On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
> >>
> >>> Some input from the UX perspective:
> >>>
> >>> Navigation does depend on the architecture of the application (in
essence, the user learns about the architecture from the navigation
structure).
> >>>
> >>> You want the possibility of inheritance, but having too many levels
makes it hard/impossible to navigate/visualize the structure.
> >>>
> >>> I'd suggest coming up with a basic skeleton first, and then working
backwards to implementation. For example:
> >>>
> >>> Environment
> >>> - one (or more) workspaces
> >>> - zero (or more) sub-workspaces (or sub-spaces - useful if the
workspace gets too large... however, I'd end inheritance there)
> >>> - one (or more) pages
> >>> - zero (or more) widgets
> >>
> >> I think I'd be happier with one less level:
> >>
> >> one or more workspaces (context and header)
> >> ... has one or more pages (tab)
> >> ... has one or more regions (area on page)
> >> ... has zero or more widgets
> >>
> >> Though reading down I think we may mean the same thing :-)
> >
> > To me either of the above, for *now*, is fine.
> >
> > However, a less strict separation between workspaces and pages IMO
should be kept in mind and will pay off better in the end.
> >
> > As I said before, in my view a workspace can be just a page with
(possible) child pages and some extra security and other *configurations*.
> > If for instance a theme should only be configurable on root page or
workspace level IMO is a choice to be made by a concrete Rave
implementation, not forced into the model...
> > Likewise, rendering and representation choices concerning
workspace/root-page context and switching, also should be an (custom)
implementation choice.
> > Same goes for showing sibling pages or child pages as tabs.
> > Or usage of # hashbang for sub url navigation (which IMO is
fundamentally broken and wrong to be honest).
>
> I think we're in agreement here. The model just has a hierarchy of pages
and sub-pages, but for the concrete implementation in the current portal we
can present this as "workspaces" with "tabs". It could just as easily be
represented using a side-nav tree or heading/subheading structure.
+1
>
> >
> > I'd be in favor of specifying a 'workspace' as a set of 'rules' which
we then leverage in the demo Rave portal as:
> > - a root navigational page
> > - defines an inheritable theming for child pages
> > - defines administrative ownership for this page and its children
> > - defines access/view privileges for this page and its children
> >
> > But being (just) a page in itself, the above 'rules' would just be an
implementation detail, e.g. (custom) portal specific.
> >
> > If in another context nested/child page would be allowed to override
the theming, or define additional security constraints, or context
switching on child pages, that should also be possible.
> > For our (Hippo) use-cases we definitely will be needing that level of
flexibility...
> >
> > What I like to stress is that while building a good and out-of-the-box
usable Rave portal *demo* implementation, we need keep an open mind for
other use-cases :)
> > Definitely not by making it more complex than needed, but also not more
restricted than possible or single use-case driven either.
> >
> >>
> >>
> >>> In my way of thinking, the workspace defines the context (+1 for
context-sensitive implementation!). The user may or may not need/want to
navigate to other workspaces. As Matt stated, traditionally the header is
used to show the current context - and to allow the user to navigate to a
different context.
> >>
> >> For moving between pages within a workspace, there is the existing
tabbed navigation model. I think adding a context-switching navigation for
moving between workspaces would fit well; and associating this navigation
with the header also makes sense.
> >>
> >> (I find the Liferay model for handling the workspace/pages concept
really confusing, so simpler would be better...)
> >
> > Can you explain a bit how the Liferay model works?
> > Its been a long time since I used or even looked at Liferay.
> > Good examples of what you *don't* want are IMO extremely useful!
>
>
> LifeRay typically has a drop-down menu with "Home" and "My Places"; the
latter of which has the sub-list of "workspaces"; each of these is then
broken down into "Private Pages" and "Public Pages" (all in a sort of
cascading menu). There are also tabs and breadcrumbs.
>
> One of the big usability issues with a lot of sites is its not obvious
how these things are really structured as there are lots of "aliases" that
mean you can end up somewhere completely different to where you thought you
were going (and not know where you "are" so to speak).
Thanks for explaining. I remember it now. Quite confusing interaction
indeed, and I never really liked it.
>
> So for Rave I'd like the structure to be simple and obvious in the
default implementation, with as little possibility to feel "lost" as
possible.
+1
>
> >
> > Ate
> >>
> >>>
> >>> A workspace will have one or more owners* who get to decide who can:
> >>> - edit the workspace (i.e., join the ranks of administrators)
> >>> - access the workspace (i.e., join the ranks of users)
> >>> ---
> >>> * (from implementation perspective, that could equal "one owner - who
can be a group")
> >>>
> >>> The concept of ownership is key. Who owns the content that you create
in a workspace? In just about every collaboration-support system I've seen,
the author retains ownership. However, that creates problems - when the
user leaves the workspace (or the environment), what happens to the
content? I'd like to explore the concept of content being owned by the
workspace... and if the user is not comfortable with that, they have their
own (personal) workspace to work with.
> >>>
> >>> Stan Drozdetski
> >>> MITRE
> >>>
> >>> -----Original Message-----
> >>> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
> >>> Sent: Tuesday, March 20, 2012 10:42 AM
> >>> To: rave-dev@incubator.apache.org
> >>> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
> >>>
> >>>> -----Original Message-----
> >>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> >>>> Sent: Monday, March 19, 2012 5:36 PM
> >>>> To: rave-dev@incubator.apache.org
> >>>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
> >>>>
> >>>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
> >>>>
> >>>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
> >>>>>>
> >>>>>> [ https://issues.apache.org/jira/browse/RAVE-
> >>>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> >>>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
> >>>>>>
> >>>>>> Scott Wilson commented on RAVE-103:
> >>>>>> -----------------------------------
> >>>>>>
> >>>>>> I think there are two models we can look at:
> >>>>>>
> >>>>>> 1. Page Sharing
> >>>>>>
> >>>>>> In this model, a user creates a new page, and from the tab context
menu
> >>>> selects "Share this page...". A dialog opens, and the user can add
people (e.g.
> >>>> using a search/filter view), or select an existing group (e.g.
friends, family, co-
> >>>> workers...). The user chooses OK, and each user is notified when
they log into
> >>>> Rave of the invitation to add the shared Page. The user who created
the Page
> >>>> is the Owner; each user they share with is by default a Viewer
(read-only).
> >>>> However, it should be possible for the Owner to grant other users a
"Can Edit"
> >>>> role allowing them to add, remove and move widgets.
> >>>>>>
> >>>>>> 2. Workspace Sharing
> >>>>>>
> >>>>>> In this model, there is a higher-level entity comprising a
collection of
> >>>> multiple pages managed by a group. New shared pages can be added as
sub-
> >>>> pages of the top-level workspace. I'm a bit less clear on the
workflow for this
> >>>> one, whether its the same as (1) but with sub-pages, or something
> >>>> conceptually quite different
> >>>>>>
> >>>>> IMO we should (eventually) strive to merge both these models into
one
> >>>> logical model from Rave perspective.
> >>>>> For one, we already have a 'shared' page right now: the profile
page. With
> >>>> sub pages...
> >>>>>
> >>>>> IMO the current separate/special handling of the profile page should
> >>>> technically or model wise not be special at all. What difference is
there
> >>>> between sharing 'a' page to the public with sharing 'the' profile
page(s) to the
> >>>> public?
> >>>>> To me this seems like just a matter of security configuration, with
the profile
> >>>> page 'just' representing a common default 'share'.
> >>>>
> >>>> Right - that could be handled by "magic" Users like
AnyAuthenticatedUser and
> >>>> Anyone that you could add as a member of your page, or some user-less
> >>>> permissions attached to the page.
> >>>
> >>> +1 for modeling them the same. We just have to make sure that we
have the right information available when the page is created to apply the
right permission scheme; but this could be accomplished by re-working the
Page Template to include a default permission set. There is one small
OpenSocial concern we need to make sure we have a strategy for supporting:
The default view name for profile isn't HOME, it's PROFILE.
> >>>
> >>>>>
> >>>>> Interestingly, the current profile page also now has 'sub' pages,
which in a
> >>>> minimalistic sense maybe could be regarded as a shared 'workspace'
already
> >>>> (with a single owner).
> >>>>
> >>>> Indeed - every page is sort of a workspace in that regard, though
that isn't
> >>>> currently exposed through the UI.
> >>>
> >>> I could definitely see a scenario where we have the concept of a
workspace with "pages" attached to it. The workspace would represent the
context and could come in the form of a portal, profile, team site,
peer-to-peer shared workspace, and any other scenario. The changes in
context would allow us to create implementations that have different "UI"
for each workspace. This way, each workspace can lay out the entire web
page however works best for their use case. We can then create a new
construct of "Workspace Template" that is responsible for the overall look,
feel& layout of the web page and use the PageTemplates to manage the
regions and corresponding widgets.
> >>>
> >>>>>
> >>>>> I'm interested in how adding a shared page to the users view of
pages will
> >>>> work out.
> >>>>
> >>>> That looks to be the bigger challenge - making the model make sense
to users.
> >>>
> >>> IMO, we need to have a smooth navigation in the header to move
between various workspaces.
> >>>
> >>>>
> >>>>>
> >>>>> Right now we do not have yet a navigational representation of pages.
> >>>>> Will sharing the canonical 'Main' page with john.doe result in two
'Main'
> >>>> pages to be shown? As the name of a page (currently) is only stored
in the
> >>>> page itself, to prevent 'namespace' clashes, you either need to:
> >>>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something
like:
> >>>> /person/canonical/pages/Main), or
> >>>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
> >>>> Main3), or
> >>>>> - introduce a mounting or shortcut like feature where the viewer can
> >>>> structure its own 'site' and 'inject' shared pages at any desired
location, or
> >>>>> - ...?
> >>>>
> >>>> Perhaps the "mounted" pages look in some way different to the normal
tabs
> >>>> stylistically (e.g. aligned to the right and a different colour,
with a tooltip along
> >>>> the lines of "Shared with you by Bob"). Or maybe you have to have a
separate
> >>>> page navigation UI to organise pages - "My pages", "Pages shared
with me",
> >>>> "Public pages" (etc)
> >>>
> >>> I think what approach we take depends on what is sharable. Assuming
we go with the "Workspace" concept, would your users want to share entire
workspaces or just individual groups of regions that we now call pages, or
both?
> >>>
> >>>>
> >>>>>
> >>>>> Note: in the above options I'm not referring to page IDs anymore.
While
> >>>> each page can/should still be addressable by ID (too), if you're
going to share
> >>>> pages you'll need *also* a logical naming representation to be able
for the
> >>>> viewer to navigate its own 'site' or even more so a public/anonymous
view of
> >>>> 'the' site. Meaning: we'll need to come up with a navigational
structure for
> >>>> pages which can be rendered through menu's, site maps, etc. These IMO
> >>>> should be accessible and represented as REST resources like the web
itself.
> >>>> Thus hierarchically structured.
> >>>>>
> >>>>> Once we get there, I think the workspace vs page discussion becomes
easier
> >>>> and more 'structured'. A workspace then can simply represent a
parent (or
> >>>> root) page resource with optional children which happens to be
shared,
> >>>> somehow.
> >>>>>
> >>>>> Important this IMO is a discussion on ownership of a shared page or
> >>>> workspace, something which was also discussed, but IMO not concluded,
> >>>> recently on the OpenSocial 3.0 kickoff concerning the Spaces
proposal.
> >>>>>
> >>>>> I think each page/space/workspace or whatever (Rave) 'social' web
> >>>> resource should have a canonical owner. Meaning only one. And if you
want
> >>>> to 'share' ownership, then a separate and standalone entity like
Group should
> >>>> be used. Because that will then allow providing both a canonical
location (url).
> >>>>
> >>>> +1 I like the idea of a single owner of any page, even if that owner
is a Group:
> >>>
> >>> This is in alignment with the discussions from the OpenSocial 3.0
kickoff.
> >>>
> >>>>
> >>>> /portal/app/group/trekkies/profile
> >>>> /portal/app/group/trekkies/spock
> >>>>
> >>>>> Consider for instance searching (public web or from within the
portal) and
> >>>> finding an entry matching a page or workspace: what or who's
canonical url
> >>>> should be linked to if you would have multiple owners?
> >>>>>
> >>>>> There are many different ways to represent a site structure and
also many
> >>>> different ways to logically blend or merge/share/overlay logical
structures on
> >>>> top of it, but I think it would be useful to start with something
which as a
> >>>> minimum provides a canonical representation of the Rave site, and
leverage
> >>>> that as a start for sharing purposes, without any need to 'OK' a
shared page
> >>>> before it becomes 'visible'.
> >>>>
> >>>> Agreed - a predictable and user-readable URL scheme will help with
> >>>> understanding how the pages fit together.
> >>>>
> >>>> At the moment, if you try and access a page without permission, you
just get
> >>>> an error message - this could instead have a dialog to send a
message to the
> >>>> owner that you'd like to be added or otherwise start a flow that
could lead to
> >>>> being added as a page member.
> >>>>
> >>>>>
> >>>>> So for example canonical could have the following 'pages':
> >>>>>
> >>>>> /portal/app/my/profile
> >>>>> /portal/app/my/profile/about
> >>>>> /portal/app/my/profile/activities
> >>>>> /portal/app/my/pages/main
> >>>>> /portal/app/my/pages/social
> >>>
> >>> I am all for intuitive URL structure and think addressable
sub-components could make sense. For at least one of our use cases, we
would want /portal/app/my/profile/about and /portal/app/my/profile have the
same overall structure with user image etc at the top of the page. Maybe in
/about the about tab could be active?
> >>>
> >>>>>
> >>>>> and have its /profile, /profile/about and /pages/social pages
shared with
> >>>> john.doe
> >>>>>
> >>>>> Then, john.doe might be able to see (and have menu/links) to:
> >>>>>
> >>>>> /portal/app/my/profile
> >>>>> /portal/app/my/profile/about
> >>>>> /portal/app/my/profile/activities
> >>>>> /portal/app/my/pages/main
> >>>>> /portal/app/my/pages/social
> >>>>> /portal/app/person/canonical/profile
> >>>>> /portal/app/person/canonical/profile/about
> >>>>> /portal/app/person/canonical/pages/social
> >>>>>
> >>>>> Of course the above url structure is just an example.
> >>>>
> >>>>
> >>>>>
> >>>>> As soon as I have a bit more time I can try to better explain it,
but hopefully
> >>>> it makes sense somewhat.
> >>>>
> >>>> I did some hacking on the model, controller, and permission
evaluator code
> >>>> today to get the backend of page sharing working, and have passed
the baton
> >>>> to Paul as I don't think I'm going to get any coding time for the
next two days.
> >>>> So we should (I hope) have some working page-sharing to play with by
the
> >>>> end of the week.
> >>>>
> >>>>>
> >>>>> Ate
> >>>>>
> >>>>>
> >>>>>> ====
> >>>>>>
> >>>>>> Paul and I are really interested in seeing if we can develop
something along
> >>>> the lines of model (1) in a sprint next week as it would be a good
fit for a
> >>>> project we're working on. This wouldn't include the OpenSocial
Spaces
> >>>> extension (I'm sure someone else could implement it later) but would
include
> >>>> the basic functionality of sharing pages, selecting users, and
extending the
> >>>> relevant PermissionEvaluator classes for non-Owner roles.
> >>>>>>
> >>>>>>> Support shared spaces
> >>>>>>> ---------------------
> >>>>>>>
> >>>>>>> Key: RAVE-103
> >>>>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
> >>>>>>> Project: Rave
> >>>>>>> Issue Type: Epic
> >>>>>>> Reporter: Matt Franklin
> >>>>>>>
> >>>>>>> Support shared, or common, spaces with group managed pages,
widgets,
> >>>> and security
> >>>>>>
> >>>>>> --
> >>>>>> This message is automatically generated by JIRA.
> >>>>>> If you think it was sent incorrectly, please contact your JIRA
administrators:
> >>>>
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> >>>>>> For more information on JIRA, see:
> >>>> http://www.atlassian.com/software/jira
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
> >
>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Erik Isaksson <er...@kth.se>.
On Thu, Mar 22, 2012 at 6:48 PM, Scott Wilson
<sc...@gmail.com> wrote:
>
> On 22 Mar 2012, at 15:40, Ate Douma wrote:
>
>> On 03/22/2012 03:54 PM, Scott Wilson wrote:
>>>
>>> On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
>>>
>>>> Some input from the UX perspective:
>>>>
>>>> Navigation does depend on the architecture of the application (in essence, the user learns about the architecture from the navigation structure).
>>>>
>>>> You want the possibility of inheritance, but having too many levels makes it hard/impossible to navigate/visualize the structure.
>>>>
>>>> I'd suggest coming up with a basic skeleton first, and then working backwards to implementation. For example:
>>>>
>>>> Environment
>>>> - one (or more) workspaces
>>>> Â - zero (or more) sub-workspaces (or sub-spaces - useful if the workspace gets too large... however, I'd end inheritance there)
>>>> Â Â - one (or more) pages
>>>> Â Â Â - zero (or more) widgets
>>>
>>> I think I'd be happier with one less level:
>>>
>>> one or more workspaces (context and header)
>>> ... has one or more pages  (tab)
>>> Â ... has one or more regions (area on page)
>>> Â Â ... has zero or more widgets
>>>
>>> Though reading down I think we may mean the same thing :-)
>>
>> To me either of the above, for *now*, is fine.
>>
>> However, a less strict separation between workspaces and pages IMO should be kept in mind and will pay off better in the end.
>>
>> As I said before, in my view a workspace can be just a page with (possible) child pages and some extra security and other *configurations*.
>> If for instance a theme should only be configurable on root page or workspace level IMO is a choice to be made by a concrete Rave implementation, not forced into the model...
>> Likewise, rendering and representation choices concerning workspace/root-page context and switching, also should be an (custom) implementation choice.
>> Same goes for showing sibling pages or child pages as tabs.
>> Or usage of # hashbang for sub url navigation (which IMO is fundamentally broken and wrong to be honest).
>
> I think we're in agreement here. The model just has a hierarchy of pages and sub-pages, but for the concrete implementation in the current portal we can present this as "workspaces" with "tabs". It could just as easily be represented using a side-nav tree or heading/subheading structure.
I think the model that you've described is the same as what I've used
for the space environment in ROLE, except rather than "workspaces"
they're just called "spaces", and the tabs/pages are called
"activities" (which work the same way as pages, and are shown as tabs
in the UI).
An example: http://role.ull.uu.se/spaces/cool
You can create your own space at: http://role.ull.uu.se/
In the UI, we also always show the user's personal space (same as what
would be shown to a user after he logs on to RAVE). We don't have any
UI for navigating between shared spaces (yet). Instead, we rely on
users knowing (and sharing among each other) the space's URL.
Only the owners of a space can add pages and widgets (while all
members of a space can store data in the context of a space, somewhat
similar to app data in OpenSocial). We intend to improve on that by
allowing any user to add pages and widgets that are visible to only
that user (while only the owner can add pages and widgets that become
visible to everyone). Those pages and widgets should also be sharable
among users somehow, so that a user can add a page/widget that was
shared by another user.
It might be worth thinking about where widget user preferences are to
be stored. In our case, the owner sets user prefs that become the
default for the space, which other users are then able to override.
Best regards,
Erik
>
>>
>> I'd be in favor of specifying a 'workspace' as a set of 'rules' which we then leverage in the demo Rave portal as:
>> - a root navigational page
>> - defines an inheritable theming for child pages
>> - defines administrative ownership for this page and its children
>> - defines access/view privileges for this page and its children
>>
>> But being (just) a page in itself, the above 'rules' would just be an implementation detail, e.g. (custom) portal specific.
>>
>> If in another context nested/child page would be allowed to override the theming, or define additional security constraints, or context switching on child pages, that should also be possible.
>> For our (Hippo) use-cases we definitely will be needing that level of flexibility...
>>
>> What I like to stress is that while building a good and out-of-the-box usable Rave portal *demo* implementation, we need keep an open mind for other use-cases :)
>> Definitely not by making it more complex than needed, but also not more restricted than possible or single use-case driven either.
>>
>>>
>>>
>>>> In my way of thinking, the workspace defines the context (+1 for context-sensitive implementation!). The user may or may not need/want to navigate to other workspaces. As Matt stated, traditionally the header is used to show the current context - and to allow the user to navigate to a different context.
>>>
>>> For moving between pages within a workspace, there is the existing tabbed navigation model. I think adding a context-switching navigation for moving between workspaces would fit well; and associating this navigation with the header also makes sense.
>>>
>>> (I find the Liferay model for handling the workspace/pages concept really confusing, so simpler would be better...)
>>
>> Can you explain a bit how the Liferay model works?
>> Its been a long time since I used or even looked at Liferay.
>> Good examples of what you *don't* want are IMO extremely useful!
>
>
> LifeRay typically has a drop-down menu with "Home" and "My Places"; the latter of which has the sub-list of "workspaces"; each of these is then broken down into "Private Pages" and "Public Pages" Â (all in a sort of cascading menu). There are also tabs and breadcrumbs.
>
> One of the big usability issues with a lot of sites is its not obvious how these things are really structured as there are lots of "aliases" that mean you can end up somewhere completely different to where you thought you were going (and not know where you "are" so to speak).
>
> So for Rave I'd like the structure to be simple and obvious in the default implementation, with as little possibility to feel "lost" as possible.
>
>>
>> Ate
>>>
>>>>
>>>> A workspace will have one or more owners* who get to decide who can:
>>>> - edit the workspace (i.e., join the ranks of administrators)
>>>> - access the workspace (i.e., join the ranks of users)
>>>> ---
>>>> * (from implementation perspective, that could equal "one owner - who can be a group")
>>>>
>>>> The concept of ownership is key. Who owns the content that you create in a workspace? In just about every collaboration-support system I've seen, the author retains ownership. However, that creates problems - when the user leaves the workspace (or the environment), what happens to the content? I'd like to explore the concept of content being owned by the workspace... and if the user is not comfortable with that, they have their own (personal) workspace to work with.
>>>>
>>>> Stan Drozdetski
>>>> MITRE
>>>>
>>>> -----Original Message-----
>>>> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>>>> Sent: Tuesday, March 20, 2012 10:42 AM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>>>>
>>>>> -----Original Message-----
>>>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>>>>> Sent: Monday, March 19, 2012 5:36 PM
>>>>> To: rave-dev@incubator.apache.org
>>>>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>>>>>
>>>>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
>>>>>
>>>>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>>>>>
>>>>>>> Â Â [ https://issues.apache.org/jira/browse/RAVE-
>>>>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>>>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>>>>>
>>>>>>> Scott Wilson commented on RAVE-103:
>>>>>>> -----------------------------------
>>>>>>>
>>>>>>> I think there are two models we can look at:
>>>>>>>
>>>>>>> 1. Page Sharing
>>>>>>>
>>>>>>> In this model, a user creates a new page, and from the tab context menu
>>>>> selects "Share this page...". A dialog opens, and the user can add people (e.g.
>>>>> using a search/filter view), or select an existing group (e.g. friends, family, co-
>>>>> workers...). The user chooses OK, and each user is notified when they log into
>>>>> Rave of the invitation to add the shared Page. The user who created the Page
>>>>> is the Owner; each user they share with is by default a Viewer (read-only).
>>>>> However, it should be possible for the Owner to grant other users a "Can Edit"
>>>>> role allowing them to add, remove and move widgets.
>>>>>>>
>>>>>>> 2. Workspace Sharing
>>>>>>>
>>>>>>> In this model, there is a higher-level entity comprising a collection of
>>>>> multiple pages managed by a group. New shared pages can be added as sub-
>>>>> pages of the top-level workspace. I'm a bit less clear on the workflow for this
>>>>> one, whether its the same as (1) but with sub-pages, or something
>>>>> conceptually quite different
>>>>>>>
>>>>>> IMO we should (eventually) strive to merge both these models into one
>>>>> logical model from Rave perspective.
>>>>>> For one, we already have a 'shared' page right now: the profile page. With
>>>>> sub pages...
>>>>>>
>>>>>> IMO the current separate/special handling of the profile page should
>>>>> technically or model wise not be special at all. What difference is there
>>>>> between sharing 'a' page to the public with sharing 'the' profile page(s) to the
>>>>> public?
>>>>>> To me this seems like just a matter of security configuration, with the profile
>>>>> page 'just' representing a common default 'share'.
>>>>>
>>>>> Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
>>>>> Anyone that you could add as a member of your page, or some user-less
>>>>> permissions attached to the page.
>>>>
>>>> +1 for modeling them the same. Â We just have to make sure that we have the right information available when the page is created to apply the right permission scheme; but this could be accomplished by re-working the Page Template to include a default permission set. Â There is one small OpenSocial concern we need to make sure we have a strategy for supporting: Â The default view name for profile isn't HOME, it's PROFILE.
>>>>
>>>>>>
>>>>>> Interestingly, the current profile page also now has 'sub' pages, which in a
>>>>> minimalistic sense maybe could be regarded as a shared 'workspace' already
>>>>> (with a single owner).
>>>>>
>>>>> Indeed - every page is sort of a workspace in that regard, though that isn't
>>>>> currently exposed through the UI.
>>>>
>>>> I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it. Â The workspace would represent the context and could come in the form of a portal, profile, team site, peer-to-peer shared workspace, and any other scenario. Â The changes in context would allow us to create implementations that have different "UI" for each workspace. Â This way, each workspace can lay out the entire web page however works best for their use case. Â We can then create a new construct of "Workspace Template" that is responsible for the overall look, feel& Â layout of the web page and use the PageTemplates to manage the regions and corresponding widgets.
>>>>
>>>>>>
>>>>>> I'm interested in how adding a shared page to the users view of pages will
>>>>> work out.
>>>>>
>>>>> That looks to be the bigger challenge - making the model make sense to users.
>>>>
>>>> IMO, we need to have a smooth navigation in the header to move between various workspaces.
>>>>
>>>>>
>>>>>>
>>>>>> Right now we do not have yet a navigational representation of pages.
>>>>>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>>>>> pages to be shown? As the name of a page (currently) is only stored in the
>>>>> page itself, to prevent 'namespace' clashes, you either need to:
>>>>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>>>>> /person/canonical/pages/Main), or
>>>>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>>>>> Main3), or
>>>>>> - introduce a mounting or shortcut like feature where the viewer can
>>>>> structure its own 'site' and 'inject' shared pages at any desired location, or
>>>>>> - ...?
>>>>>
>>>>> Perhaps the "mounted" pages look in some way different to the normal tabs
>>>>> stylistically (e.g. aligned to the right and a different colour, with a tooltip along
>>>>> the lines of "Shared with you by Bob"). Or maybe you have to have a separate
>>>>> page navigation UI to organise pages - "My pages", "Pages shared with me",
>>>>> "Public pages" (etc)
>>>>
>>>> I think what approach we take depends on what is sharable. Â Assuming we go with the "Workspace" concept, would your users want to share entire workspaces or just individual groups of regions that we now call pages, or both?
>>>>
>>>>>
>>>>>>
>>>>>> Note: in the above options I'm not referring to page IDs anymore. While
>>>>> each page can/should still be addressable by ID (too), if you're going to share
>>>>> pages you'll need *also* a logical naming representation to be able for the
>>>>> viewer to navigate its own 'site' or even more so a public/anonymous view of
>>>>> 'the' site. Meaning: we'll need to come up with a navigational structure for
>>>>> pages which can be rendered through menu's, site maps, etc. These IMO
>>>>> should be accessible and represented as REST resources like the web itself.
>>>>> Thus hierarchically structured.
>>>>>>
>>>>>> Once we get there, I think the workspace vs page discussion becomes easier
>>>>> and more 'structured'. A workspace then can simply represent a parent (or
>>>>> root) page resource with optional children which happens to be shared,
>>>>> somehow.
>>>>>>
>>>>>> Important this IMO is a discussion on ownership of a shared page or
>>>>> workspace, something which was also discussed, but IMO not concluded,
>>>>> recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>>>>>
>>>>>> I think each page/space/workspace or whatever (Rave) 'social' web
>>>>> resource should have a canonical owner. Meaning only one. And if you want
>>>>> to 'share' ownership, then a separate and standalone entity like Group should
>>>>> be used. Because that will then allow providing both a canonical location (url).
>>>>>
>>>>> +1 I like the idea of a single owner of any page, even if that owner is a Group:
>>>>
>>>> This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>>>>
>>>>>
>>>>> /portal/app/group/trekkies/profile
>>>>> /portal/app/group/trekkies/spock
>>>>>
>>>>>> Consider for instance searching (public web or from within the portal) and
>>>>> finding an entry matching a page or workspace: what or who's canonical url
>>>>> should be linked to if you would have multiple owners?
>>>>>>
>>>>>> There are many different ways to represent a site structure and also many
>>>>> different ways to logically blend or merge/share/overlay logical structures on
>>>>> top of it, but I think it would be useful to start with something which as a
>>>>> minimum provides a canonical representation of the Rave site, and leverage
>>>>> that as a start for sharing purposes, without any need to 'OK' a shared page
>>>>> before it becomes 'visible'.
>>>>>
>>>>> Agreed - a predictable and user-readable URL scheme will help with
>>>>> understanding how the pages fit together.
>>>>>
>>>>> At the moment, if you try and access a page without permission, you just get
>>>>> an error message - this could instead have a dialog to send a message to the
>>>>> owner that you'd like to be added or otherwise start a flow that could lead to
>>>>> being added as a page member.
>>>>>
>>>>>>
>>>>>> So for example canonical could have the following 'pages':
>>>>>>
>>>>>> /portal/app/my/profile
>>>>>> /portal/app/my/profile/about
>>>>>> /portal/app/my/profile/activities
>>>>>> /portal/app/my/pages/main
>>>>>> /portal/app/my/pages/social
>>>>
>>>> I am all for intuitive URL structure and think addressable sub-components could make sense. Â For at least one of our use cases, we would want /portal/app/my/profile/about and /portal/app/my/profile have the same overall structure with user image etc at the top of the page. Maybe in /about the about tab could be active?
>>>>
>>>>>>
>>>>>> and have its /profile, /profile/about and /pages/social pages shared with
>>>>> john.doe
>>>>>>
>>>>>> Then, john.doe might be able to see (and have menu/links) to:
>>>>>>
>>>>>> /portal/app/my/profile
>>>>>> /portal/app/my/profile/about
>>>>>> /portal/app/my/profile/activities
>>>>>> /portal/app/my/pages/main
>>>>>> /portal/app/my/pages/social
>>>>>> /portal/app/person/canonical/profile
>>>>>> /portal/app/person/canonical/profile/about
>>>>>> /portal/app/person/canonical/pages/social
>>>>>>
>>>>>> Of course the above url structure is just an example.
>>>>>
>>>>>
>>>>>>
>>>>>> As soon as I have a bit more time I can try to better explain it, but hopefully
>>>>> it makes sense somewhat.
>>>>>
>>>>> I did some hacking on the model, controller, and permission evaluator code
>>>>> today to get the backend of page sharing working, and have passed the baton
>>>>> to Paul as I don't think I'm going to get any coding time for the next two days.
>>>>> So we should (I hope) have some working page-sharing to play with by the
>>>>> end of the week.
>>>>>
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>
>>>>>>> ====
>>>>>>>
>>>>>>> Paul and I are really interested in seeing if we can develop something along
>>>>> the lines of model (1) in a sprint next week as it would be a good fit for a
>>>>> project we're working on. Â This wouldn't include the OpenSocial Spaces
>>>>> extension (I'm sure someone else could implement it later) but would include
>>>>> the basic functionality of sharing pages, selecting users, and extending the
>>>>> relevant PermissionEvaluator classes for non-Owner roles.
>>>>>>>
>>>>>>>> Support shared spaces
>>>>>>>> ---------------------
>>>>>>>>
>>>>>>>> Â Â Â Â Â Â Â Â Key: RAVE-103
>>>>>>>> Â Â Â Â Â Â Â Â URL: https://issues.apache.org/jira/browse/RAVE-103
>>>>>>>> Â Â Â Â Â Â Project: Rave
>>>>>>>> Â Â Â Â Issue Type: Epic
>>>>>>>> Â Â Â Â Â Reporter: Matt Franklin
>>>>>>>>
>>>>>>>> Support shared, or common, spaces with group managed pages, widgets,
>>>>> and security
>>>>>>>
>>>>>>> --
>>>>>>> This message is automatically generated by JIRA.
>>>>>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>>>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Scott Wilson <sc...@gmail.com>.
On 22 Mar 2012, at 15:40, Ate Douma wrote:
> On 03/22/2012 03:54 PM, Scott Wilson wrote:
>>
>> On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
>>
>>> Some input from the UX perspective:
>>>
>>> Navigation does depend on the architecture of the application (in essence, the user learns about the architecture from the navigation structure).
>>>
>>> You want the possibility of inheritance, but having too many levels makes it hard/impossible to navigate/visualize the structure.
>>>
>>> I'd suggest coming up with a basic skeleton first, and then working backwards to implementation. For example:
>>>
>>> Environment
>>> - one (or more) workspaces
>>> - zero (or more) sub-workspaces (or sub-spaces - useful if the workspace gets too large... however, I'd end inheritance there)
>>> - one (or more) pages
>>> - zero (or more) widgets
>>
>> I think I'd be happier with one less level:
>>
>> one or more workspaces (context and header)
>> ... has one or more pages (tab)
>> ... has one or more regions (area on page)
>> ... has zero or more widgets
>>
>> Though reading down I think we may mean the same thing :-)
>
> To me either of the above, for *now*, is fine.
>
> However, a less strict separation between workspaces and pages IMO should be kept in mind and will pay off better in the end.
>
> As I said before, in my view a workspace can be just a page with (possible) child pages and some extra security and other *configurations*.
> If for instance a theme should only be configurable on root page or workspace level IMO is a choice to be made by a concrete Rave implementation, not forced into the model...
> Likewise, rendering and representation choices concerning workspace/root-page context and switching, also should be an (custom) implementation choice.
> Same goes for showing sibling pages or child pages as tabs.
> Or usage of # hashbang for sub url navigation (which IMO is fundamentally broken and wrong to be honest).
I think we're in agreement here. The model just has a hierarchy of pages and sub-pages, but for the concrete implementation in the current portal we can present this as "workspaces" with "tabs". It could just as easily be represented using a side-nav tree or heading/subheading structure.
>
> I'd be in favor of specifying a 'workspace' as a set of 'rules' which we then leverage in the demo Rave portal as:
> - a root navigational page
> - defines an inheritable theming for child pages
> - defines administrative ownership for this page and its children
> - defines access/view privileges for this page and its children
>
> But being (just) a page in itself, the above 'rules' would just be an implementation detail, e.g. (custom) portal specific.
>
> If in another context nested/child page would be allowed to override the theming, or define additional security constraints, or context switching on child pages, that should also be possible.
> For our (Hippo) use-cases we definitely will be needing that level of flexibility...
>
> What I like to stress is that while building a good and out-of-the-box usable Rave portal *demo* implementation, we need keep an open mind for other use-cases :)
> Definitely not by making it more complex than needed, but also not more restricted than possible or single use-case driven either.
>
>>
>>
>>> In my way of thinking, the workspace defines the context (+1 for context-sensitive implementation!). The user may or may not need/want to navigate to other workspaces. As Matt stated, traditionally the header is used to show the current context - and to allow the user to navigate to a different context.
>>
>> For moving between pages within a workspace, there is the existing tabbed navigation model. I think adding a context-switching navigation for moving between workspaces would fit well; and associating this navigation with the header also makes sense.
>>
>> (I find the Liferay model for handling the workspace/pages concept really confusing, so simpler would be better...)
>
> Can you explain a bit how the Liferay model works?
> Its been a long time since I used or even looked at Liferay.
> Good examples of what you *don't* want are IMO extremely useful!
LifeRay typically has a drop-down menu with "Home" and "My Places"; the latter of which has the sub-list of "workspaces"; each of these is then broken down into "Private Pages" and "Public Pages" (all in a sort of cascading menu). There are also tabs and breadcrumbs.
One of the big usability issues with a lot of sites is its not obvious how these things are really structured as there are lots of "aliases" that mean you can end up somewhere completely different to where you thought you were going (and not know where you "are" so to speak).
So for Rave I'd like the structure to be simple and obvious in the default implementation, with as little possibility to feel "lost" as possible.
>
> Ate
>>
>>>
>>> A workspace will have one or more owners* who get to decide who can:
>>> - edit the workspace (i.e., join the ranks of administrators)
>>> - access the workspace (i.e., join the ranks of users)
>>> ---
>>> * (from implementation perspective, that could equal "one owner - who can be a group")
>>>
>>> The concept of ownership is key. Who owns the content that you create in a workspace? In just about every collaboration-support system I've seen, the author retains ownership. However, that creates problems - when the user leaves the workspace (or the environment), what happens to the content? I'd like to explore the concept of content being owned by the workspace... and if the user is not comfortable with that, they have their own (personal) workspace to work with.
>>>
>>> Stan Drozdetski
>>> MITRE
>>>
>>> -----Original Message-----
>>> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>>> Sent: Tuesday, March 20, 2012 10:42 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>>>
>>>> -----Original Message-----
>>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>>>> Sent: Monday, March 19, 2012 5:36 PM
>>>> To: rave-dev@incubator.apache.org
>>>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>>>>
>>>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
>>>>
>>>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>>>>
>>>>>> [ https://issues.apache.org/jira/browse/RAVE-
>>>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>>>>
>>>>>> Scott Wilson commented on RAVE-103:
>>>>>> -----------------------------------
>>>>>>
>>>>>> I think there are two models we can look at:
>>>>>>
>>>>>> 1. Page Sharing
>>>>>>
>>>>>> In this model, a user creates a new page, and from the tab context menu
>>>> selects "Share this page...". A dialog opens, and the user can add people (e.g.
>>>> using a search/filter view), or select an existing group (e.g. friends, family, co-
>>>> workers...). The user chooses OK, and each user is notified when they log into
>>>> Rave of the invitation to add the shared Page. The user who created the Page
>>>> is the Owner; each user they share with is by default a Viewer (read-only).
>>>> However, it should be possible for the Owner to grant other users a "Can Edit"
>>>> role allowing them to add, remove and move widgets.
>>>>>>
>>>>>> 2. Workspace Sharing
>>>>>>
>>>>>> In this model, there is a higher-level entity comprising a collection of
>>>> multiple pages managed by a group. New shared pages can be added as sub-
>>>> pages of the top-level workspace. I'm a bit less clear on the workflow for this
>>>> one, whether its the same as (1) but with sub-pages, or something
>>>> conceptually quite different
>>>>>>
>>>>> IMO we should (eventually) strive to merge both these models into one
>>>> logical model from Rave perspective.
>>>>> For one, we already have a 'shared' page right now: the profile page. With
>>>> sub pages...
>>>>>
>>>>> IMO the current separate/special handling of the profile page should
>>>> technically or model wise not be special at all. What difference is there
>>>> between sharing 'a' page to the public with sharing 'the' profile page(s) to the
>>>> public?
>>>>> To me this seems like just a matter of security configuration, with the profile
>>>> page 'just' representing a common default 'share'.
>>>>
>>>> Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
>>>> Anyone that you could add as a member of your page, or some user-less
>>>> permissions attached to the page.
>>>
>>> +1 for modeling them the same. We just have to make sure that we have the right information available when the page is created to apply the right permission scheme; but this could be accomplished by re-working the Page Template to include a default permission set. There is one small OpenSocial concern we need to make sure we have a strategy for supporting: The default view name for profile isn't HOME, it's PROFILE.
>>>
>>>>>
>>>>> Interestingly, the current profile page also now has 'sub' pages, which in a
>>>> minimalistic sense maybe could be regarded as a shared 'workspace' already
>>>> (with a single owner).
>>>>
>>>> Indeed - every page is sort of a workspace in that regard, though that isn't
>>>> currently exposed through the UI.
>>>
>>> I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it. The workspace would represent the context and could come in the form of a portal, profile, team site, peer-to-peer shared workspace, and any other scenario. The changes in context would allow us to create implementations that have different "UI" for each workspace. This way, each workspace can lay out the entire web page however works best for their use case. We can then create a new construct of "Workspace Template" that is responsible for the overall look, feel& layout of the web page and use the PageTemplates to manage the regions and corresponding widgets.
>>>
>>>>>
>>>>> I'm interested in how adding a shared page to the users view of pages will
>>>> work out.
>>>>
>>>> That looks to be the bigger challenge - making the model make sense to users.
>>>
>>> IMO, we need to have a smooth navigation in the header to move between various workspaces.
>>>
>>>>
>>>>>
>>>>> Right now we do not have yet a navigational representation of pages.
>>>>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>>>> pages to be shown? As the name of a page (currently) is only stored in the
>>>> page itself, to prevent 'namespace' clashes, you either need to:
>>>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>>>> /person/canonical/pages/Main), or
>>>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>>>> Main3), or
>>>>> - introduce a mounting or shortcut like feature where the viewer can
>>>> structure its own 'site' and 'inject' shared pages at any desired location, or
>>>>> - ...?
>>>>
>>>> Perhaps the "mounted" pages look in some way different to the normal tabs
>>>> stylistically (e.g. aligned to the right and a different colour, with a tooltip along
>>>> the lines of "Shared with you by Bob"). Or maybe you have to have a separate
>>>> page navigation UI to organise pages - "My pages", "Pages shared with me",
>>>> "Public pages" (etc)
>>>
>>> I think what approach we take depends on what is sharable. Assuming we go with the "Workspace" concept, would your users want to share entire workspaces or just individual groups of regions that we now call pages, or both?
>>>
>>>>
>>>>>
>>>>> Note: in the above options I'm not referring to page IDs anymore. While
>>>> each page can/should still be addressable by ID (too), if you're going to share
>>>> pages you'll need *also* a logical naming representation to be able for the
>>>> viewer to navigate its own 'site' or even more so a public/anonymous view of
>>>> 'the' site. Meaning: we'll need to come up with a navigational structure for
>>>> pages which can be rendered through menu's, site maps, etc. These IMO
>>>> should be accessible and represented as REST resources like the web itself.
>>>> Thus hierarchically structured.
>>>>>
>>>>> Once we get there, I think the workspace vs page discussion becomes easier
>>>> and more 'structured'. A workspace then can simply represent a parent (or
>>>> root) page resource with optional children which happens to be shared,
>>>> somehow.
>>>>>
>>>>> Important this IMO is a discussion on ownership of a shared page or
>>>> workspace, something which was also discussed, but IMO not concluded,
>>>> recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>>>>
>>>>> I think each page/space/workspace or whatever (Rave) 'social' web
>>>> resource should have a canonical owner. Meaning only one. And if you want
>>>> to 'share' ownership, then a separate and standalone entity like Group should
>>>> be used. Because that will then allow providing both a canonical location (url).
>>>>
>>>> +1 I like the idea of a single owner of any page, even if that owner is a Group:
>>>
>>> This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>>>
>>>>
>>>> /portal/app/group/trekkies/profile
>>>> /portal/app/group/trekkies/spock
>>>>
>>>>> Consider for instance searching (public web or from within the portal) and
>>>> finding an entry matching a page or workspace: what or who's canonical url
>>>> should be linked to if you would have multiple owners?
>>>>>
>>>>> There are many different ways to represent a site structure and also many
>>>> different ways to logically blend or merge/share/overlay logical structures on
>>>> top of it, but I think it would be useful to start with something which as a
>>>> minimum provides a canonical representation of the Rave site, and leverage
>>>> that as a start for sharing purposes, without any need to 'OK' a shared page
>>>> before it becomes 'visible'.
>>>>
>>>> Agreed - a predictable and user-readable URL scheme will help with
>>>> understanding how the pages fit together.
>>>>
>>>> At the moment, if you try and access a page without permission, you just get
>>>> an error message - this could instead have a dialog to send a message to the
>>>> owner that you'd like to be added or otherwise start a flow that could lead to
>>>> being added as a page member.
>>>>
>>>>>
>>>>> So for example canonical could have the following 'pages':
>>>>>
>>>>> /portal/app/my/profile
>>>>> /portal/app/my/profile/about
>>>>> /portal/app/my/profile/activities
>>>>> /portal/app/my/pages/main
>>>>> /portal/app/my/pages/social
>>>
>>> I am all for intuitive URL structure and think addressable sub-components could make sense. For at least one of our use cases, we would want /portal/app/my/profile/about and /portal/app/my/profile have the same overall structure with user image etc at the top of the page. Maybe in /about the about tab could be active?
>>>
>>>>>
>>>>> and have its /profile, /profile/about and /pages/social pages shared with
>>>> john.doe
>>>>>
>>>>> Then, john.doe might be able to see (and have menu/links) to:
>>>>>
>>>>> /portal/app/my/profile
>>>>> /portal/app/my/profile/about
>>>>> /portal/app/my/profile/activities
>>>>> /portal/app/my/pages/main
>>>>> /portal/app/my/pages/social
>>>>> /portal/app/person/canonical/profile
>>>>> /portal/app/person/canonical/profile/about
>>>>> /portal/app/person/canonical/pages/social
>>>>>
>>>>> Of course the above url structure is just an example.
>>>>
>>>>
>>>>>
>>>>> As soon as I have a bit more time I can try to better explain it, but hopefully
>>>> it makes sense somewhat.
>>>>
>>>> I did some hacking on the model, controller, and permission evaluator code
>>>> today to get the backend of page sharing working, and have passed the baton
>>>> to Paul as I don't think I'm going to get any coding time for the next two days.
>>>> So we should (I hope) have some working page-sharing to play with by the
>>>> end of the week.
>>>>
>>>>>
>>>>> Ate
>>>>>
>>>>>
>>>>>> ====
>>>>>>
>>>>>> Paul and I are really interested in seeing if we can develop something along
>>>> the lines of model (1) in a sprint next week as it would be a good fit for a
>>>> project we're working on. This wouldn't include the OpenSocial Spaces
>>>> extension (I'm sure someone else could implement it later) but would include
>>>> the basic functionality of sharing pages, selecting users, and extending the
>>>> relevant PermissionEvaluator classes for non-Owner roles.
>>>>>>
>>>>>>> Support shared spaces
>>>>>>> ---------------------
>>>>>>>
>>>>>>> Key: RAVE-103
>>>>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>>>>> Project: Rave
>>>>>>> Issue Type: Epic
>>>>>>> Reporter: Matt Franklin
>>>>>>>
>>>>>>> Support shared, or common, spaces with group managed pages, widgets,
>>>> and security
>>>>>>
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Ate Douma <at...@douma.nu>.
On 03/22/2012 03:54 PM, Scott Wilson wrote:
>
> On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
>
>> Some input from the UX perspective:
>>
>> Navigation does depend on the architecture of the application (in essence, the user learns about the architecture from the navigation structure).
>>
>> You want the possibility of inheritance, but having too many levels makes it hard/impossible to navigate/visualize the structure.
>>
>> I'd suggest coming up with a basic skeleton first, and then working backwards to implementation. For example:
>>
>> Environment
>> - one (or more) workspaces
>> - zero (or more) sub-workspaces (or sub-spaces - useful if the workspace gets too large... however, I'd end inheritance there)
>> - one (or more) pages
>> - zero (or more) widgets
>
> I think I'd be happier with one less level:
>
> one or more workspaces (context and header)
> ... has one or more pages (tab)
> ... has one or more regions (area on page)
> ... has zero or more widgets
>
> Though reading down I think we may mean the same thing :-)
To me either of the above, for *now*, is fine.
However, a less strict separation between workspaces and pages IMO should be
kept in mind and will pay off better in the end.
As I said before, in my view a workspace can be just a page with (possible)
child pages and some extra security and other *configurations*.
If for instance a theme should only be configurable on root page or workspace
level IMO is a choice to be made by a concrete Rave implementation, not forced
into the model...
Likewise, rendering and representation choices concerning workspace/root-page
context and switching, also should be an (custom) implementation choice.
Same goes for showing sibling pages or child pages as tabs.
Or usage of # hashbang for sub url navigation (which IMO is fundamentally broken
and wrong to be honest).
I'd be in favor of specifying a 'workspace' as a set of 'rules' which we then
leverage in the demo Rave portal as:
- a root navigational page
- defines an inheritable theming for child pages
- defines administrative ownership for this page and its children
- defines access/view privileges for this page and its children
But being (just) a page in itself, the above 'rules' would just be an
implementation detail, e.g. (custom) portal specific.
If in another context nested/child page would be allowed to override the
theming, or define additional security constraints, or context switching on
child pages, that should also be possible.
For our (Hippo) use-cases we definitely will be needing that level of
flexibility...
What I like to stress is that while building a good and out-of-the-box usable
Rave portal *demo* implementation, we need keep an open mind for other use-cases :)
Definitely not by making it more complex than needed, but also not more
restricted than possible or single use-case driven either.
>
>
>> In my way of thinking, the workspace defines the context (+1 for context-sensitive implementation!). The user may or may not need/want to navigate to other workspaces. As Matt stated, traditionally the header is used to show the current context - and to allow the user to navigate to a different context.
>
> For moving between pages within a workspace, there is the existing tabbed navigation model. I think adding a context-switching navigation for moving between workspaces would fit well; and associating this navigation with the header also makes sense.
>
> (I find the Liferay model for handling the workspace/pages concept really confusing, so simpler would be better...)
Can you explain a bit how the Liferay model works?
Its been a long time since I used or even looked at Liferay.
Good examples of what you *don't* want are IMO extremely useful!
Ate
>
>>
>> A workspace will have one or more owners* who get to decide who can:
>> - edit the workspace (i.e., join the ranks of administrators)
>> - access the workspace (i.e., join the ranks of users)
>> ---
>> * (from implementation perspective, that could equal "one owner - who can be a group")
>>
>> The concept of ownership is key. Who owns the content that you create in a workspace? In just about every collaboration-support system I've seen, the author retains ownership. However, that creates problems - when the user leaves the workspace (or the environment), what happens to the content? I'd like to explore the concept of content being owned by the workspace... and if the user is not comfortable with that, they have their own (personal) workspace to work with.
>>
>> Stan Drozdetski
>> MITRE
>>
>> -----Original Message-----
>> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>> Sent: Tuesday, March 20, 2012 10:42 AM
>> To: rave-dev@incubator.apache.org
>> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>>
>>> -----Original Message-----
>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>>> Sent: Monday, March 19, 2012 5:36 PM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>>>
>>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
>>>
>>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>>>
>>>>> [ https://issues.apache.org/jira/browse/RAVE-
>>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>>>
>>>>> Scott Wilson commented on RAVE-103:
>>>>> -----------------------------------
>>>>>
>>>>> I think there are two models we can look at:
>>>>>
>>>>> 1. Page Sharing
>>>>>
>>>>> In this model, a user creates a new page, and from the tab context menu
>>> selects "Share this page...". A dialog opens, and the user can add people (e.g.
>>> using a search/filter view), or select an existing group (e.g. friends, family, co-
>>> workers...). The user chooses OK, and each user is notified when they log into
>>> Rave of the invitation to add the shared Page. The user who created the Page
>>> is the Owner; each user they share with is by default a Viewer (read-only).
>>> However, it should be possible for the Owner to grant other users a "Can Edit"
>>> role allowing them to add, remove and move widgets.
>>>>>
>>>>> 2. Workspace Sharing
>>>>>
>>>>> In this model, there is a higher-level entity comprising a collection of
>>> multiple pages managed by a group. New shared pages can be added as sub-
>>> pages of the top-level workspace. I'm a bit less clear on the workflow for this
>>> one, whether its the same as (1) but with sub-pages, or something
>>> conceptually quite different
>>>>>
>>>> IMO we should (eventually) strive to merge both these models into one
>>> logical model from Rave perspective.
>>>> For one, we already have a 'shared' page right now: the profile page. With
>>> sub pages...
>>>>
>>>> IMO the current separate/special handling of the profile page should
>>> technically or model wise not be special at all. What difference is there
>>> between sharing 'a' page to the public with sharing 'the' profile page(s) to the
>>> public?
>>>> To me this seems like just a matter of security configuration, with the profile
>>> page 'just' representing a common default 'share'.
>>>
>>> Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
>>> Anyone that you could add as a member of your page, or some user-less
>>> permissions attached to the page.
>>
>> +1 for modeling them the same. We just have to make sure that we have the right information available when the page is created to apply the right permission scheme; but this could be accomplished by re-working the Page Template to include a default permission set. There is one small OpenSocial concern we need to make sure we have a strategy for supporting: The default view name for profile isn't HOME, it's PROFILE.
>>
>>>>
>>>> Interestingly, the current profile page also now has 'sub' pages, which in a
>>> minimalistic sense maybe could be regarded as a shared 'workspace' already
>>> (with a single owner).
>>>
>>> Indeed - every page is sort of a workspace in that regard, though that isn't
>>> currently exposed through the UI.
>>
>> I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it. The workspace would represent the context and could come in the form of a portal, profile, team site, peer-to-peer shared workspace, and any other scenario. The changes in context would allow us to create implementations that have different "UI" for each workspace. This way, each workspace can lay out the entire web page however works best for their use case. We can then create a new construct of "Workspace Template" that is responsible for the overall look, feel& layout of the web page and use the PageTemplates to manage the regions and corresponding widgets.
>>
>>>>
>>>> I'm interested in how adding a shared page to the users view of pages will
>>> work out.
>>>
>>> That looks to be the bigger challenge - making the model make sense to users.
>>
>> IMO, we need to have a smooth navigation in the header to move between various workspaces.
>>
>>>
>>>>
>>>> Right now we do not have yet a navigational representation of pages.
>>>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>>> pages to be shown? As the name of a page (currently) is only stored in the
>>> page itself, to prevent 'namespace' clashes, you either need to:
>>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>>> /person/canonical/pages/Main), or
>>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>>> Main3), or
>>>> - introduce a mounting or shortcut like feature where the viewer can
>>> structure its own 'site' and 'inject' shared pages at any desired location, or
>>>> - ...?
>>>
>>> Perhaps the "mounted" pages look in some way different to the normal tabs
>>> stylistically (e.g. aligned to the right and a different colour, with a tooltip along
>>> the lines of "Shared with you by Bob"). Or maybe you have to have a separate
>>> page navigation UI to organise pages - "My pages", "Pages shared with me",
>>> "Public pages" (etc)
>>
>> I think what approach we take depends on what is sharable. Assuming we go with the "Workspace" concept, would your users want to share entire workspaces or just individual groups of regions that we now call pages, or both?
>>
>>>
>>>>
>>>> Note: in the above options I'm not referring to page IDs anymore. While
>>> each page can/should still be addressable by ID (too), if you're going to share
>>> pages you'll need *also* a logical naming representation to be able for the
>>> viewer to navigate its own 'site' or even more so a public/anonymous view of
>>> 'the' site. Meaning: we'll need to come up with a navigational structure for
>>> pages which can be rendered through menu's, site maps, etc. These IMO
>>> should be accessible and represented as REST resources like the web itself.
>>> Thus hierarchically structured.
>>>>
>>>> Once we get there, I think the workspace vs page discussion becomes easier
>>> and more 'structured'. A workspace then can simply represent a parent (or
>>> root) page resource with optional children which happens to be shared,
>>> somehow.
>>>>
>>>> Important this IMO is a discussion on ownership of a shared page or
>>> workspace, something which was also discussed, but IMO not concluded,
>>> recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>>>
>>>> I think each page/space/workspace or whatever (Rave) 'social' web
>>> resource should have a canonical owner. Meaning only one. And if you want
>>> to 'share' ownership, then a separate and standalone entity like Group should
>>> be used. Because that will then allow providing both a canonical location (url).
>>>
>>> +1 I like the idea of a single owner of any page, even if that owner is a Group:
>>
>> This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>>
>>>
>>> /portal/app/group/trekkies/profile
>>> /portal/app/group/trekkies/spock
>>>
>>>> Consider for instance searching (public web or from within the portal) and
>>> finding an entry matching a page or workspace: what or who's canonical url
>>> should be linked to if you would have multiple owners?
>>>>
>>>> There are many different ways to represent a site structure and also many
>>> different ways to logically blend or merge/share/overlay logical structures on
>>> top of it, but I think it would be useful to start with something which as a
>>> minimum provides a canonical representation of the Rave site, and leverage
>>> that as a start for sharing purposes, without any need to 'OK' a shared page
>>> before it becomes 'visible'.
>>>
>>> Agreed - a predictable and user-readable URL scheme will help with
>>> understanding how the pages fit together.
>>>
>>> At the moment, if you try and access a page without permission, you just get
>>> an error message - this could instead have a dialog to send a message to the
>>> owner that you'd like to be added or otherwise start a flow that could lead to
>>> being added as a page member.
>>>
>>>>
>>>> So for example canonical could have the following 'pages':
>>>>
>>>> /portal/app/my/profile
>>>> /portal/app/my/profile/about
>>>> /portal/app/my/profile/activities
>>>> /portal/app/my/pages/main
>>>> /portal/app/my/pages/social
>>
>> I am all for intuitive URL structure and think addressable sub-components could make sense. For at least one of our use cases, we would want /portal/app/my/profile/about and /portal/app/my/profile have the same overall structure with user image etc at the top of the page. Maybe in /about the about tab could be active?
>>
>>>>
>>>> and have its /profile, /profile/about and /pages/social pages shared with
>>> john.doe
>>>>
>>>> Then, john.doe might be able to see (and have menu/links) to:
>>>>
>>>> /portal/app/my/profile
>>>> /portal/app/my/profile/about
>>>> /portal/app/my/profile/activities
>>>> /portal/app/my/pages/main
>>>> /portal/app/my/pages/social
>>>> /portal/app/person/canonical/profile
>>>> /portal/app/person/canonical/profile/about
>>>> /portal/app/person/canonical/pages/social
>>>>
>>>> Of course the above url structure is just an example.
>>>
>>>
>>>>
>>>> As soon as I have a bit more time I can try to better explain it, but hopefully
>>> it makes sense somewhat.
>>>
>>> I did some hacking on the model, controller, and permission evaluator code
>>> today to get the backend of page sharing working, and have passed the baton
>>> to Paul as I don't think I'm going to get any coding time for the next two days.
>>> So we should (I hope) have some working page-sharing to play with by the
>>> end of the week.
>>>
>>>>
>>>> Ate
>>>>
>>>>
>>>>> ====
>>>>>
>>>>> Paul and I are really interested in seeing if we can develop something along
>>> the lines of model (1) in a sprint next week as it would be a good fit for a
>>> project we're working on. This wouldn't include the OpenSocial Spaces
>>> extension (I'm sure someone else could implement it later) but would include
>>> the basic functionality of sharing pages, selecting users, and extending the
>>> relevant PermissionEvaluator classes for non-Owner roles.
>>>>>
>>>>>> Support shared spaces
>>>>>> ---------------------
>>>>>>
>>>>>> Key: RAVE-103
>>>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>>>> Project: Rave
>>>>>> Issue Type: Epic
>>>>>> Reporter: Matt Franklin
>>>>>>
>>>>>> Support shared, or common, spaces with group managed pages, widgets,
>>> and security
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>>> For more information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>>>>
>>>>>
>>>>
>>
>>
>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Scott Wilson <sc...@gmail.com>.
On 20 Mar 2012, at 17:53, Drozdetski, Stan A. wrote:
> Some input from the UX perspective:
>
> Navigation does depend on the architecture of the application (in essence, the user learns about the architecture from the navigation structure).
>
> You want the possibility of inheritance, but having too many levels makes it hard/impossible to navigate/visualize the structure.
>
> I'd suggest coming up with a basic skeleton first, and then working backwards to implementation. For example:
>
> Environment
> - one (or more) workspaces
> - zero (or more) sub-workspaces (or sub-spaces - useful if the workspace gets too large... however, I'd end inheritance there)
> - one (or more) pages
> - zero (or more) widgets
I think I'd be happier with one less level:
one or more workspaces (context and header)
... has one or more pages (tab)
... has one or more regions (area on page)
... has zero or more widgets
Though reading down I think we may mean the same thing :-)
> In my way of thinking, the workspace defines the context (+1 for context-sensitive implementation!). The user may or may not need/want to navigate to other workspaces. As Matt stated, traditionally the header is used to show the current context - and to allow the user to navigate to a different context.
For moving between pages within a workspace, there is the existing tabbed navigation model. I think adding a context-switching navigation for moving between workspaces would fit well; and associating this navigation with the header also makes sense.
(I find the Liferay model for handling the workspace/pages concept really confusing, so simpler would be better...)
>
> A workspace will have one or more owners* who get to decide who can:
> - edit the workspace (i.e., join the ranks of administrators)
> - access the workspace (i.e., join the ranks of users)
> ---
> * (from implementation perspective, that could equal "one owner - who can be a group")
>
> The concept of ownership is key. Who owns the content that you create in a workspace? In just about every collaboration-support system I've seen, the author retains ownership. However, that creates problems - when the user leaves the workspace (or the environment), what happens to the content? I'd like to explore the concept of content being owned by the workspace... and if the user is not comfortable with that, they have their own (personal) workspace to work with.
>
> Stan Drozdetski
> MITRE
>
> -----Original Message-----
> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
> Sent: Tuesday, March 20, 2012 10:42 AM
> To: rave-dev@incubator.apache.org
> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>
>> -----Original Message-----
>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>> Sent: Monday, March 19, 2012 5:36 PM
>> To: rave-dev@incubator.apache.org
>> Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>>
>> On 19 Mar 2012, at 13:51, Ate Douma wrote:
>>
>>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>>
>>>> [ https://issues.apache.org/jira/browse/RAVE-
>> 103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>>
>>>> Scott Wilson commented on RAVE-103:
>>>> -----------------------------------
>>>>
>>>> I think there are two models we can look at:
>>>>
>>>> 1. Page Sharing
>>>>
>>>> In this model, a user creates a new page, and from the tab context menu
>> selects "Share this page...". A dialog opens, and the user can add people (e.g.
>> using a search/filter view), or select an existing group (e.g. friends, family, co-
>> workers...). The user chooses OK, and each user is notified when they log into
>> Rave of the invitation to add the shared Page. The user who created the Page
>> is the Owner; each user they share with is by default a Viewer (read-only).
>> However, it should be possible for the Owner to grant other users a "Can Edit"
>> role allowing them to add, remove and move widgets.
>>>>
>>>> 2. Workspace Sharing
>>>>
>>>> In this model, there is a higher-level entity comprising a collection of
>> multiple pages managed by a group. New shared pages can be added as sub-
>> pages of the top-level workspace. I'm a bit less clear on the workflow for this
>> one, whether its the same as (1) but with sub-pages, or something
>> conceptually quite different
>>>>
>>> IMO we should (eventually) strive to merge both these models into one
>> logical model from Rave perspective.
>>> For one, we already have a 'shared' page right now: the profile page. With
>> sub pages...
>>>
>>> IMO the current separate/special handling of the profile page should
>> technically or model wise not be special at all. What difference is there
>> between sharing 'a' page to the public with sharing 'the' profile page(s) to the
>> public?
>>> To me this seems like just a matter of security configuration, with the profile
>> page 'just' representing a common default 'share'.
>>
>> Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
>> Anyone that you could add as a member of your page, or some user-less
>> permissions attached to the page.
>
> +1 for modeling them the same. We just have to make sure that we have the right information available when the page is created to apply the right permission scheme; but this could be accomplished by re-working the Page Template to include a default permission set. There is one small OpenSocial concern we need to make sure we have a strategy for supporting: The default view name for profile isn't HOME, it's PROFILE.
>
>>>
>>> Interestingly, the current profile page also now has 'sub' pages, which in a
>> minimalistic sense maybe could be regarded as a shared 'workspace' already
>> (with a single owner).
>>
>> Indeed - every page is sort of a workspace in that regard, though that isn't
>> currently exposed through the UI.
>
> I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it. The workspace would represent the context and could come in the form of a portal, profile, team site, peer-to-peer shared workspace, and any other scenario. The changes in context would allow us to create implementations that have different "UI" for each workspace. This way, each workspace can lay out the entire web page however works best for their use case. We can then create a new construct of "Workspace Template" that is responsible for the overall look, feel & layout of the web page and use the PageTemplates to manage the regions and corresponding widgets.
>
>>>
>>> I'm interested in how adding a shared page to the users view of pages will
>> work out.
>>
>> That looks to be the bigger challenge - making the model make sense to users.
>
> IMO, we need to have a smooth navigation in the header to move between various workspaces.
>
>>
>>>
>>> Right now we do not have yet a navigational representation of pages.
>>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>> pages to be shown? As the name of a page (currently) is only stored in the
>> page itself, to prevent 'namespace' clashes, you either need to:
>>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>> /person/canonical/pages/Main), or
>>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>> Main3), or
>>> - introduce a mounting or shortcut like feature where the viewer can
>> structure its own 'site' and 'inject' shared pages at any desired location, or
>>> - ...?
>>
>> Perhaps the "mounted" pages look in some way different to the normal tabs
>> stylistically (e.g. aligned to the right and a different colour, with a tooltip along
>> the lines of "Shared with you by Bob"). Or maybe you have to have a separate
>> page navigation UI to organise pages - "My pages", "Pages shared with me",
>> "Public pages" (etc)
>
> I think what approach we take depends on what is sharable. Assuming we go with the "Workspace" concept, would your users want to share entire workspaces or just individual groups of regions that we now call pages, or both?
>
>>
>>>
>>> Note: in the above options I'm not referring to page IDs anymore. While
>> each page can/should still be addressable by ID (too), if you're going to share
>> pages you'll need *also* a logical naming representation to be able for the
>> viewer to navigate its own 'site' or even more so a public/anonymous view of
>> 'the' site. Meaning: we'll need to come up with a navigational structure for
>> pages which can be rendered through menu's, site maps, etc. These IMO
>> should be accessible and represented as REST resources like the web itself.
>> Thus hierarchically structured.
>>>
>>> Once we get there, I think the workspace vs page discussion becomes easier
>> and more 'structured'. A workspace then can simply represent a parent (or
>> root) page resource with optional children which happens to be shared,
>> somehow.
>>>
>>> Important this IMO is a discussion on ownership of a shared page or
>> workspace, something which was also discussed, but IMO not concluded,
>> recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>>
>>> I think each page/space/workspace or whatever (Rave) 'social' web
>> resource should have a canonical owner. Meaning only one. And if you want
>> to 'share' ownership, then a separate and standalone entity like Group should
>> be used. Because that will then allow providing both a canonical location (url).
>>
>> +1 I like the idea of a single owner of any page, even if that owner is a Group:
>
> This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>
>>
>> /portal/app/group/trekkies/profile
>> /portal/app/group/trekkies/spock
>>
>>> Consider for instance searching (public web or from within the portal) and
>> finding an entry matching a page or workspace: what or who's canonical url
>> should be linked to if you would have multiple owners?
>>>
>>> There are many different ways to represent a site structure and also many
>> different ways to logically blend or merge/share/overlay logical structures on
>> top of it, but I think it would be useful to start with something which as a
>> minimum provides a canonical representation of the Rave site, and leverage
>> that as a start for sharing purposes, without any need to 'OK' a shared page
>> before it becomes 'visible'.
>>
>> Agreed - a predictable and user-readable URL scheme will help with
>> understanding how the pages fit together.
>>
>> At the moment, if you try and access a page without permission, you just get
>> an error message - this could instead have a dialog to send a message to the
>> owner that you'd like to be added or otherwise start a flow that could lead to
>> being added as a page member.
>>
>>>
>>> So for example canonical could have the following 'pages':
>>>
>>> /portal/app/my/profile
>>> /portal/app/my/profile/about
>>> /portal/app/my/profile/activities
>>> /portal/app/my/pages/main
>>> /portal/app/my/pages/social
>
> I am all for intuitive URL structure and think addressable sub-components could make sense. For at least one of our use cases, we would want /portal/app/my/profile/about and /portal/app/my/profile have the same overall structure with user image etc at the top of the page. Maybe in /about the about tab could be active?
>
>>>
>>> and have its /profile, /profile/about and /pages/social pages shared with
>> john.doe
>>>
>>> Then, john.doe might be able to see (and have menu/links) to:
>>>
>>> /portal/app/my/profile
>>> /portal/app/my/profile/about
>>> /portal/app/my/profile/activities
>>> /portal/app/my/pages/main
>>> /portal/app/my/pages/social
>>> /portal/app/person/canonical/profile
>>> /portal/app/person/canonical/profile/about
>>> /portal/app/person/canonical/pages/social
>>>
>>> Of course the above url structure is just an example.
>>
>>
>>>
>>> As soon as I have a bit more time I can try to better explain it, but hopefully
>> it makes sense somewhat.
>>
>> I did some hacking on the model, controller, and permission evaluator code
>> today to get the backend of page sharing working, and have passed the baton
>> to Paul as I don't think I'm going to get any coding time for the next two days.
>> So we should (I hope) have some working page-sharing to play with by the
>> end of the week.
>>
>>>
>>> Ate
>>>
>>>
>>>> ====
>>>>
>>>> Paul and I are really interested in seeing if we can develop something along
>> the lines of model (1) in a sprint next week as it would be a good fit for a
>> project we're working on. This wouldn't include the OpenSocial Spaces
>> extension (I'm sure someone else could implement it later) but would include
>> the basic functionality of sharing pages, selecting users, and extending the
>> relevant PermissionEvaluator classes for non-Owner roles.
>>>>
>>>>> Support shared spaces
>>>>> ---------------------
>>>>>
>>>>> Key: RAVE-103
>>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>>> Project: Rave
>>>>> Issue Type: Epic
>>>>> Reporter: Matt Franklin
>>>>>
>>>>> Support shared, or common, spaces with group managed pages, widgets,
>> and security
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>>>
>>>>
>>>
>
>
RE: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by "Drozdetski, Stan A." <dr...@mitre.org>.
Some input from the UX perspective:
Navigation does depend on the architecture of the application (in essence, the user learns about the architecture from the navigation structure).
You want the possibility of inheritance, but having too many levels makes it hard/impossible to navigate/visualize the structure.
I'd suggest coming up with a basic skeleton first, and then working backwards to implementation. For example:
Environment
- one (or more) workspaces
- zero (or more) sub-workspaces (or sub-spaces - useful if the workspace gets too large... however, I'd end inheritance there)
- one (or more) pages
- zero (or more) widgets
In my way of thinking, the workspace defines the context (+1 for context-sensitive implementation!). The user may or may not need/want to navigate to other workspaces. As Matt stated, traditionally the header is used to show the current context - and to allow the user to navigate to a different context.
A workspace will have one or more owners* who get to decide who can:
- edit the workspace (i.e., join the ranks of administrators)
- access the workspace (i.e., join the ranks of users)
---
* (from implementation perspective, that could equal "one owner - who can be a group")
The concept of ownership is key. Who owns the content that you create in a workspace? In just about every collaboration-support system I've seen, the author retains ownership. However, that creates problems - when the user leaves the workspace (or the environment), what happens to the content? I'd like to explore the concept of content being owned by the workspace... and if the user is not comfortable with that, they have their own (personal) workspace to work with.
Stan Drozdetski
MITRE
-----Original Message-----
From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
Sent: Tuesday, March 20, 2012 10:42 AM
To: rave-dev@incubator.apache.org
Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>-----Original Message-----
>From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>Sent: Monday, March 19, 2012 5:36 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>
>On 19 Mar 2012, at 13:51, Ate Douma wrote:
>
>> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>>
>>> [ https://issues.apache.org/jira/browse/RAVE-
>103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>>
>>> Scott Wilson commented on RAVE-103:
>>> -----------------------------------
>>>
>>> I think there are two models we can look at:
>>>
>>> 1. Page Sharing
>>>
>>> In this model, a user creates a new page, and from the tab context menu
>selects "Share this page...". A dialog opens, and the user can add people (e.g.
>using a search/filter view), or select an existing group (e.g. friends, family, co-
>workers...). The user chooses OK, and each user is notified when they log into
>Rave of the invitation to add the shared Page. The user who created the Page
>is the Owner; each user they share with is by default a Viewer (read-only).
>However, it should be possible for the Owner to grant other users a "Can Edit"
>role allowing them to add, remove and move widgets.
>>>
>>> 2. Workspace Sharing
>>>
>>> In this model, there is a higher-level entity comprising a collection of
>multiple pages managed by a group. New shared pages can be added as sub-
>pages of the top-level workspace. I'm a bit less clear on the workflow for this
>one, whether its the same as (1) but with sub-pages, or something
>conceptually quite different
>>>
>> IMO we should (eventually) strive to merge both these models into one
>logical model from Rave perspective.
>> For one, we already have a 'shared' page right now: the profile page. With
>sub pages...
>>
>> IMO the current separate/special handling of the profile page should
>technically or model wise not be special at all. What difference is there
>between sharing 'a' page to the public with sharing 'the' profile page(s) to the
>public?
>> To me this seems like just a matter of security configuration, with the profile
>page 'just' representing a common default 'share'.
>
>Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
>Anyone that you could add as a member of your page, or some user-less
>permissions attached to the page.
+1 for modeling them the same. We just have to make sure that we have the right information available when the page is created to apply the right permission scheme; but this could be accomplished by re-working the Page Template to include a default permission set. There is one small OpenSocial concern we need to make sure we have a strategy for supporting: The default view name for profile isn't HOME, it's PROFILE.
>>
>> Interestingly, the current profile page also now has 'sub' pages, which in a
>minimalistic sense maybe could be regarded as a shared 'workspace' already
>(with a single owner).
>
>Indeed - every page is sort of a workspace in that regard, though that isn't
>currently exposed through the UI.
I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it. The workspace would represent the context and could come in the form of a portal, profile, team site, peer-to-peer shared workspace, and any other scenario. The changes in context would allow us to create implementations that have different "UI" for each workspace. This way, each workspace can lay out the entire web page however works best for their use case. We can then create a new construct of "Workspace Template" that is responsible for the overall look, feel & layout of the web page and use the PageTemplates to manage the regions and corresponding widgets.
>>
>> I'm interested in how adding a shared page to the users view of pages will
>work out.
>
>That looks to be the bigger challenge - making the model make sense to users.
IMO, we need to have a smooth navigation in the header to move between various workspaces.
>
>>
>> Right now we do not have yet a navigational representation of pages.
>> Will sharing the canonical 'Main' page with john.doe result in two 'Main'
>pages to be shown? As the name of a page (currently) is only stored in the
>page itself, to prevent 'namespace' clashes, you either need to:
>> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>/person/canonical/pages/Main), or
>> - allow the viewer to *locally* rename that page (ugh: Main1, Main2,
>Main3), or
>> - introduce a mounting or shortcut like feature where the viewer can
>structure its own 'site' and 'inject' shared pages at any desired location, or
>> - ...?
>
>Perhaps the "mounted" pages look in some way different to the normal tabs
>stylistically (e.g. aligned to the right and a different colour, with a tooltip along
>the lines of "Shared with you by Bob"). Or maybe you have to have a separate
>page navigation UI to organise pages - "My pages", "Pages shared with me",
>"Public pages" (etc)
I think what approach we take depends on what is sharable. Assuming we go with the "Workspace" concept, would your users want to share entire workspaces or just individual groups of regions that we now call pages, or both?
>
>>
>> Note: in the above options I'm not referring to page IDs anymore. While
>each page can/should still be addressable by ID (too), if you're going to share
>pages you'll need *also* a logical naming representation to be able for the
>viewer to navigate its own 'site' or even more so a public/anonymous view of
>'the' site. Meaning: we'll need to come up with a navigational structure for
>pages which can be rendered through menu's, site maps, etc. These IMO
>should be accessible and represented as REST resources like the web itself.
>Thus hierarchically structured.
>>
>> Once we get there, I think the workspace vs page discussion becomes easier
>and more 'structured'. A workspace then can simply represent a parent (or
>root) page resource with optional children which happens to be shared,
>somehow.
>>
>> Important this IMO is a discussion on ownership of a shared page or
>workspace, something which was also discussed, but IMO not concluded,
>recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>>
>> I think each page/space/workspace or whatever (Rave) 'social' web
>resource should have a canonical owner. Meaning only one. And if you want
>to 'share' ownership, then a separate and standalone entity like Group should
>be used. Because that will then allow providing both a canonical location (url).
>
>+1 I like the idea of a single owner of any page, even if that owner is a Group:
This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
>
>/portal/app/group/trekkies/profile
>/portal/app/group/trekkies/spock
>
>> Consider for instance searching (public web or from within the portal) and
>finding an entry matching a page or workspace: what or who's canonical url
>should be linked to if you would have multiple owners?
>>
>> There are many different ways to represent a site structure and also many
>different ways to logically blend or merge/share/overlay logical structures on
>top of it, but I think it would be useful to start with something which as a
>minimum provides a canonical representation of the Rave site, and leverage
>that as a start for sharing purposes, without any need to 'OK' a shared page
>before it becomes 'visible'.
>
>Agreed - a predictable and user-readable URL scheme will help with
>understanding how the pages fit together.
>
>At the moment, if you try and access a page without permission, you just get
>an error message - this could instead have a dialog to send a message to the
>owner that you'd like to be added or otherwise start a flow that could lead to
>being added as a page member.
>
>>
>> So for example canonical could have the following 'pages':
>>
>> /portal/app/my/profile
>> /portal/app/my/profile/about
>> /portal/app/my/profile/activities
>> /portal/app/my/pages/main
>> /portal/app/my/pages/social
I am all for intuitive URL structure and think addressable sub-components could make sense. For at least one of our use cases, we would want /portal/app/my/profile/about and /portal/app/my/profile have the same overall structure with user image etc at the top of the page. Maybe in /about the about tab could be active?
>>
>> and have its /profile, /profile/about and /pages/social pages shared with
>john.doe
>>
>> Then, john.doe might be able to see (and have menu/links) to:
>>
>> /portal/app/my/profile
>> /portal/app/my/profile/about
>> /portal/app/my/profile/activities
>> /portal/app/my/pages/main
>> /portal/app/my/pages/social
>> /portal/app/person/canonical/profile
>> /portal/app/person/canonical/profile/about
>> /portal/app/person/canonical/pages/social
>>
>> Of course the above url structure is just an example.
>
>
>>
>> As soon as I have a bit more time I can try to better explain it, but hopefully
>it makes sense somewhat.
>
>I did some hacking on the model, controller, and permission evaluator code
>today to get the backend of page sharing working, and have passed the baton
>to Paul as I don't think I'm going to get any coding time for the next two days.
>So we should (I hope) have some working page-sharing to play with by the
>end of the week.
>
>>
>> Ate
>>
>>
>>> ====
>>>
>>> Paul and I are really interested in seeing if we can develop something along
>the lines of model (1) in a sprint next week as it would be a good fit for a
>project we're working on. This wouldn't include the OpenSocial Spaces
>extension (I'm sure someone else could implement it later) but would include
>the basic functionality of sharing pages, selecting users, and extending the
>relevant PermissionEvaluator classes for non-Owner roles.
>>>
>>>> Support shared spaces
>>>> ---------------------
>>>>
>>>> Key: RAVE-103
>>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>>> Project: Rave
>>>> Issue Type: Epic
>>>> Reporter: Matt Franklin
>>>>
>>>> Support shared, or common, spaces with group managed pages, widgets,
>and security
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>> For more information on JIRA, see:
>http://www.atlassian.com/software/jira
>>>
>>>
>>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Scott Wilson <sc...@gmail.com>.
On 19 Mar 2012, at 13:51, Ate Douma wrote:
> On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>
>> [ https://issues.apache.org/jira/browse/RAVE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>
>> Scott Wilson commented on RAVE-103:
>> -----------------------------------
>>
>> I think there are two models we can look at:
>>
>> 1. Page Sharing
>>
>> In this model, a user creates a new page, and from the tab context menu selects "Share this page...". A dialog opens, and the user can add people (e.g. using a search/filter view), or select an existing group (e.g. friends, family, co-workers...). The user chooses OK, and each user is notified when they log into Rave of the invitation to add the shared Page. The user who created the Page is the Owner; each user they share with is by default a Viewer (read-only). However, it should be possible for the Owner to grant other users a "Can Edit" role allowing them to add, remove and move widgets.
>>
>> 2. Workspace Sharing
>>
>> In this model, there is a higher-level entity comprising a collection of multiple pages managed by a group. New shared pages can be added as sub-pages of the top-level workspace. I'm a bit less clear on the workflow for this one, whether its the same as (1) but with sub-pages, or something conceptually quite different
>>
> IMO we should (eventually) strive to merge both these models into one logical model from Rave perspective.
> For one, we already have a 'shared' page right now: the profile page. With sub pages...
>
> IMO the current separate/special handling of the profile page should technically or model wise not be special at all. What difference is there between sharing 'a' page to the public with sharing 'the' profile page(s) to the public?
> To me this seems like just a matter of security configuration, with the profile page 'just' representing a common default 'share'.
Right - that could be handled by "magic" Users like AnyAuthenticatedUser and Anyone that you could add as a member of your page, or some user-less permissions attached to the page.
>
> Interestingly, the current profile page also now has 'sub' pages, which in a minimalistic sense maybe could be regarded as a shared 'workspace' already (with a single owner).
Indeed - every page is sort of a workspace in that regard, though that isn't currently exposed through the UI.
>
> I'm interested in how adding a shared page to the users view of pages will work out.
That looks to be the bigger challenge - making the model make sense to users.
>
> Right now we do not have yet a navigational representation of pages.
> Will sharing the canonical 'Main' page with john.doe result in two 'Main' pages to be shown? As the name of a page (currently) is only stored in the page itself, to prevent 'namespace' clashes, you either need to:
> - 'expose' the owner /owner/canonical/ as prefix, (e.g. something like: /person/canonical/pages/Main), or
> - allow the viewer to *locally* rename that page (ugh: Main1, Main2, Main3), or
> - introduce a mounting or shortcut like feature where the viewer can structure its own 'site' and 'inject' shared pages at any desired location, or
> - ...?
Perhaps the "mounted" pages look in some way different to the normal tabs stylistically (e.g. aligned to the right and a different colour, with a tooltip along the lines of "Shared with you by Bob"). Or maybe you have to have a separate page navigation UI to organise pages - "My pages", "Pages shared with me", "Public pages" (etc)
>
> Note: in the above options I'm not referring to page IDs anymore. While each page can/should still be addressable by ID (too), if you're going to share pages you'll need *also* a logical naming representation to be able for the viewer to navigate its own 'site' or even more so a public/anonymous view of 'the' site. Meaning: we'll need to come up with a navigational structure for pages which can be rendered through menu's, site maps, etc. These IMO should be accessible and represented as REST resources like the web itself. Thus hierarchically structured.
>
> Once we get there, I think the workspace vs page discussion becomes easier and more 'structured'. A workspace then can simply represent a parent (or root) page resource with optional children which happens to be shared, somehow.
>
> Important this IMO is a discussion on ownership of a shared page or workspace, something which was also discussed, but IMO not concluded, recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
>
> I think each page/space/workspace or whatever (Rave) 'social' web resource should have a canonical owner. Meaning only one. And if you want to 'share' ownership, then a separate and standalone entity like Group should be used. Because that will then allow providing both a canonical location (url).
+1 I like the idea of a single owner of any page, even if that owner is a Group:
/portal/app/group/trekkies/profile
/portal/app/group/trekkies/spock
> Consider for instance searching (public web or from within the portal) and finding an entry matching a page or workspace: what or who's canonical url should be linked to if you would have multiple owners?
>
> There are many different ways to represent a site structure and also many different ways to logically blend or merge/share/overlay logical structures on top of it, but I think it would be useful to start with something which as a minimum provides a canonical representation of the Rave site, and leverage that as a start for sharing purposes, without any need to 'OK' a shared page before it becomes 'visible'.
Agreed - a predictable and user-readable URL scheme will help with understanding how the pages fit together.
At the moment, if you try and access a page without permission, you just get an error message - this could instead have a dialog to send a message to the owner that you'd like to be added or otherwise start a flow that could lead to being added as a page member.
>
> So for example canonical could have the following 'pages':
>
> /portal/app/my/profile
> /portal/app/my/profile/about
> /portal/app/my/profile/activities
> /portal/app/my/pages/main
> /portal/app/my/pages/social
>
> and have its /profile, /profile/about and /pages/social pages shared with john.doe.
>
> Then, john.doe might be able to see (and have menu/links) to:
>
> /portal/app/my/profile
> /portal/app/my/profile/about
> /portal/app/my/profile/activities
> /portal/app/my/pages/main
> /portal/app/my/pages/social
> /portal/app/person/canonical/profile
> /portal/app/person/canonical/profile/about
> /portal/app/person/canonical/pages/social
>
> Of course the above url structure is just an example.
>
> As soon as I have a bit more time I can try to better explain it, but hopefully it makes sense somewhat.
I did some hacking on the model, controller, and permission evaluator code today to get the backend of page sharing working, and have passed the baton to Paul as I don't think I'm going to get any coding time for the next two days. So we should (I hope) have some working page-sharing to play with by the end of the week.
>
> Ate
>
>
>> ====
>>
>> Paul and I are really interested in seeing if we can develop something along the lines of model (1) in a sprint next week as it would be a good fit for a project we're working on. This wouldn't include the OpenSocial Spaces extension (I'm sure someone else could implement it later) but would include the basic functionality of sharing pages, selecting users, and extending the relevant PermissionEvaluator classes for non-Owner roles.
>>
>>> Support shared spaces
>>> ---------------------
>>>
>>> Key: RAVE-103
>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>> Project: Rave
>>> Issue Type: Epic
>>> Reporter: Matt Franklin
>>>
>>> Support shared, or common, spaces with group managed pages, widgets, and security
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>
RE: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by "Drozdetski, Stan A." <dr...@mitre.org>.
>-1
>I have a use case where I don't want a canonical user to own the workspace. If I create a workspace page which should live on for 4+ years I cannot >guarantee that the individual who first created it will still be responsible for the workspace or even an employee for the life of that workspace. I would like >the ability to create workspace pages in a non-owner/group way, e.g. /portal/app/workspace/## where ## is the id of the workspace that you are working >with. Permissions should be attached to the page and updatable by an admin in case the original set of people change work focuses and or positions in the >company.
I see your point. One workaround may be to add a feature that allows admins to reassign workspace ownership to a different a user/group - that comes in handy in a collaborative environment.
Yes, in an enterprise application setting, it makes sense for the system (enterprise?) to own the workspace... however, the challenge is keeping track of who (besides the admins) has edit rights over the workspace.
Stan Drozdetski
MITRE
-----Original Message-----
From: Cooper, Sean D. [mailto:secooper@mitre.org]
Sent: Friday, March 23, 2012 3:00 PM
To: rave-dev@incubator.apache.org
Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Monday, March 19, 2012 9:52 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
>
>On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>>
>> [ https://issues.apache.org/jira/browse/RAVE-
>103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>tabpanel&focusedCommentId=13231993#comment-13231993 ]
>>
>> Scott Wilson commented on RAVE-103:
>> -----------------------------------
>>
>> I think there are two models we can look at:
>>
>> 1. Page Sharing
>>
>> In this model, a user creates a new page, and from the tab context menu
>selects "Share this page...". A dialog opens, and the user can add people (e.g.
>using a search/filter view), or select an existing group (e.g. friends, family, co-
>workers...). The user chooses OK, and each user is notified when they log into
>Rave of the invitation to add the shared Page. The user who created the Page is
>the Owner; each user they share with is by default a Viewer (read-only).
>However, it should be possible for the Owner to grant other users a "Can Edit"
>role allowing them to add, remove and move widgets.
>>
>> 2. Workspace Sharing
>>
>> In this model, there is a higher-level entity comprising a collection of multiple
>pages managed by a group. New shared pages can be added as sub-pages of the
>top-level workspace. I'm a bit less clear on the workflow for this one, whether its
>the same as (1) but with sub-pages, or something conceptually quite different
>>
>IMO we should (eventually) strive to merge both these models into one logical
>model from Rave perspective.
>For one, we already have a 'shared' page right now: the profile page. With sub
>pages...
>
>IMO the current separate/special handling of the profile page should technically
>or model wise not be special at all. What difference is there between sharing
>'a' page to the public with sharing 'the' profile page(s) to the public?
>To me this seems like just a matter of security configuration, with the profile
>page 'just' representing a common default 'share'.
>
>Interestingly, the current profile page also now has 'sub' pages, which in a
>minimalistic sense maybe could be regarded as a shared 'workspace' already
>(with
>a single owner).
>
>I'm interested in how adding a shared page to the users view of pages will work
>out.
>
>Right now we do not have yet a navigational representation of pages.
>Will sharing the canonical 'Main' page with john.doe result in two 'Main' pages
>to be shown? As the name of a page (currently) is only stored in the page
>itself, to prevent 'namespace' clashes, you either need to:
>- 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
>/person/canonical/pages/Main), or
>- allow the viewer to *locally* rename that page (ugh: Main1, Main2, Main3),
>or
>- introduce a mounting or shortcut like feature where the viewer can structure
>its own 'site' and 'inject' shared pages at any desired location, or
>- ...?
>
>Note: in the above options I'm not referring to page IDs anymore. While each
>page can/should still be addressable by ID (too), if you're going to share pages
>you'll need *also* a logical naming representation to be able for the viewer to
>navigate its own 'site' or even more so a public/anonymous view of 'the' site.
>Meaning: we'll need to come up with a navigational structure for pages which
>can
>be rendered through menu's, site maps, etc. These IMO should be accessible
>and
>represented as REST resources like the web itself. Thus hierarchically structured.
>
>Once we get there, I think the workspace vs page discussion becomes easier and
>more 'structured'. A workspace then can simply represent a parent (or root)
>page
>resource with optional children which happens to be shared, somehow.
>
>Important this IMO is a discussion on ownership of a shared page or workspace,
>something which was also discussed, but IMO not concluded, recently on the
>OpenSocial 3.0 kickoff concerning the Spaces proposal.
>
>I think each page/space/workspace or whatever (Rave) 'social' web resource
>should have a canonical owner. Meaning only one. And if you want to 'share'
>ownership, then a separate and standalone entity like Group should be used.
>Because that will then allow providing both a canonical location (url).
>Consider for instance searching (public web or from within the portal) and
>finding an entry matching a page or workspace: what or who's canonical url
>should be linked to if you would have multiple owners?
>
-1
I have a use case where I don't want a canonical user to own the workspace. If I create a workspace page which should live on for 4+ years I cannot guarantee that the individual who first created it will still be responsible for the workspace or even an employee for the life of that workspace. I would like the ability to create workspace pages in a non-owner/group way, e.g. /portal/app/workspace/## where ## is the id of the workspace that you are working with. Permissions should be attached to the page and updatable by an admin in case the original set of people change work focuses and or positions in the company.
>There are many different ways to represent a site structure and also many
>different ways to logically blend or merge/share/overlay logical structures on
>top of it, but I think it would be useful to start with something which as a
>minimum provides a canonical representation of the Rave site, and leverage
>that
>as a start for sharing purposes, without any need to 'OK' a shared page before
>it becomes 'visible'.
>
>So for example canonical could have the following 'pages':
>
> /portal/app/my/profile
> /portal/app/my/profile/about
> /portal/app/my/profile/activities
> /portal/app/my/pages/main
> /portal/app/my/pages/social
>
>and have its /profile, /profile/about and /pages/social pages shared with
>john.doe.
>
>Then, john.doe might be able to see (and have menu/links) to:
>
> /portal/app/my/profile
> /portal/app/my/profile/about
> /portal/app/my/profile/activities
> /portal/app/my/pages/main
> /portal/app/my/pages/social
> /portal/app/person/canonical/profile
> /portal/app/person/canonical/profile/about
> /portal/app/person/canonical/pages/social
>
>Of course the above url structure is just an example.
>
>As soon as I have a bit more time I can try to better explain it, but hopefully
>it makes sense somewhat.
>
>Ate
>
>
>> ====
>>
>> Paul and I are really interested in seeing if we can develop something along
>the lines of model (1) in a sprint next week as it would be a good fit for a project
>we're working on. This wouldn't include the OpenSocial Spaces extension (I'm
>sure someone else could implement it later) but would include the basic
>functionality of sharing pages, selecting users, and extending the relevant
>PermissionEvaluator classes for non-Owner roles.
>>
>>> Support shared spaces
>>> ---------------------
>>>
>>> Key: RAVE-103
>>> URL: https://issues.apache.org/jira/browse/RAVE-103
>>> Project: Rave
>>> Issue Type: Epic
>>> Reporter: Matt Franklin
>>>
>>> Support shared, or common, spaces with group managed pages, widgets, and
>security
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
Re: [jira] [Commented] (RAVE-103) Support shared spaces
Posted by Ate Douma <at...@douma.nu>.
On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/RAVE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231993#comment-13231993 ]
>
> Scott Wilson commented on RAVE-103:
> -----------------------------------
>
> I think there are two models we can look at:
>
> 1. Page Sharing
>
> In this model, a user creates a new page, and from the tab context menu selects "Share this page...". A dialog opens, and the user can add people (e.g. using a search/filter view), or select an existing group (e.g. friends, family, co-workers...). The user chooses OK, and each user is notified when they log into Rave of the invitation to add the shared Page. The user who created the Page is the Owner; each user they share with is by default a Viewer (read-only). However, it should be possible for the Owner to grant other users a "Can Edit" role allowing them to add, remove and move widgets.
>
> 2. Workspace Sharing
>
> In this model, there is a higher-level entity comprising a collection of multiple pages managed by a group. New shared pages can be added as sub-pages of the top-level workspace. I'm a bit less clear on the workflow for this one, whether its the same as (1) but with sub-pages, or something conceptually quite different
>
IMO we should (eventually) strive to merge both these models into one logical
model from Rave perspective.
For one, we already have a 'shared' page right now: the profile page. With sub
pages...
IMO the current separate/special handling of the profile page should technically
or model wise not be special at all. What difference is there between sharing
'a' page to the public with sharing 'the' profile page(s) to the public?
To me this seems like just a matter of security configuration, with the profile
page 'just' representing a common default 'share'.
Interestingly, the current profile page also now has 'sub' pages, which in a
minimalistic sense maybe could be regarded as a shared 'workspace' already (with
a single owner).
I'm interested in how adding a shared page to the users view of pages will work out.
Right now we do not have yet a navigational representation of pages.
Will sharing the canonical 'Main' page with john.doe result in two 'Main' pages
to be shown? As the name of a page (currently) is only stored in the page
itself, to prevent 'namespace' clashes, you either need to:
- 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
/person/canonical/pages/Main), or
- allow the viewer to *locally* rename that page (ugh: Main1, Main2, Main3), or
- introduce a mounting or shortcut like feature where the viewer can structure
its own 'site' and 'inject' shared pages at any desired location, or
- ...?
Note: in the above options I'm not referring to page IDs anymore. While each
page can/should still be addressable by ID (too), if you're going to share pages
you'll need *also* a logical naming representation to be able for the viewer to
navigate its own 'site' or even more so a public/anonymous view of 'the' site.
Meaning: we'll need to come up with a navigational structure for pages which can
be rendered through menu's, site maps, etc. These IMO should be accessible and
represented as REST resources like the web itself. Thus hierarchically structured.
Once we get there, I think the workspace vs page discussion becomes easier and
more 'structured'. A workspace then can simply represent a parent (or root) page
resource with optional children which happens to be shared, somehow.
Important this IMO is a discussion on ownership of a shared page or workspace,
something which was also discussed, but IMO not concluded, recently on the
OpenSocial 3.0 kickoff concerning the Spaces proposal.
I think each page/space/workspace or whatever (Rave) 'social' web resource
should have a canonical owner. Meaning only one. And if you want to 'share'
ownership, then a separate and standalone entity like Group should be used.
Because that will then allow providing both a canonical location (url).
Consider for instance searching (public web or from within the portal) and
finding an entry matching a page or workspace: what or who's canonical url
should be linked to if you would have multiple owners?
There are many different ways to represent a site structure and also many
different ways to logically blend or merge/share/overlay logical structures on
top of it, but I think it would be useful to start with something which as a
minimum provides a canonical representation of the Rave site, and leverage that
as a start for sharing purposes, without any need to 'OK' a shared page before
it becomes 'visible'.
So for example canonical could have the following 'pages':
/portal/app/my/profile
/portal/app/my/profile/about
/portal/app/my/profile/activities
/portal/app/my/pages/main
/portal/app/my/pages/social
and have its /profile, /profile/about and /pages/social pages shared with john.doe.
Then, john.doe might be able to see (and have menu/links) to:
/portal/app/my/profile
/portal/app/my/profile/about
/portal/app/my/profile/activities
/portal/app/my/pages/main
/portal/app/my/pages/social
/portal/app/person/canonical/profile
/portal/app/person/canonical/profile/about
/portal/app/person/canonical/pages/social
Of course the above url structure is just an example.
As soon as I have a bit more time I can try to better explain it, but hopefully
it makes sense somewhat.
Ate
> ====
>
> Paul and I are really interested in seeing if we can develop something along the lines of model (1) in a sprint next week as it would be a good fit for a project we're working on. This wouldn't include the OpenSocial Spaces extension (I'm sure someone else could implement it later) but would include the basic functionality of sharing pages, selecting users, and extending the relevant PermissionEvaluator classes for non-Owner roles.
>
>> Support shared spaces
>> ---------------------
>>
>> Key: RAVE-103
>> URL: https://issues.apache.org/jira/browse/RAVE-103
>> Project: Rave
>> Issue Type: Epic
>> Reporter: Matt Franklin
>>
>> Support shared, or common, spaces with group managed pages, widgets, and security
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>