>-----Original Message----- >From: Ate Douma [mailto:[email protected]] >Sent: Thursday, March 22, 2012 2:13 PM >To: [email protected] >Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces > >On Mar 22, 2012 6:49 PM, "Scott Wilson" <[email protected]> >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:[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 >> >>>>>> >> >>>>>> >> >>>>> >> >>> >> >>> >> >> >> > >>
