>-----Original Message----- >From: Scott Wilson [mailto:[email protected]] >Sent: Thursday, March 22, 2012 10:54 AM >To: [email protected] >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:[email protected]] >> Sent: Tuesday, March 20, 2012 10:42 AM >> To: [email protected] >> Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces >> >>> -----Original Message----- >>> From: Scott Wilson [mailto:[email protected]] >>> Sent: Monday, March 19, 2012 5:36 PM >>> To: [email protected] >>> 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 >>>>> >>>>> >>>> >> >>
