留言板

Creating communities in 6.1 and public vs private pages

thumbnail
Jorge Ferrer,修改在13 年前。

Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 2871 加入日期: 06-8-31 最近的帖子
This post is a follow up from the blog post that I wrote a few days ago titled Organizations or Communities, which one should I use? The final answer in which I also described that changes that are being planned for 6.1.

In one of the comments Joss Salinger described their usage scenarios and I found them very interesting. The goal of this post is to create a thread to discuss about them.
It was more from the control panel I was thinking.

In a very complicated portal such as ours where much of the administration is done by a moderation team with assorted permissions, there would be situations where they would need to have control over communities/sites - either because they are creating them or because they need to manage them in a particular way (remove some pages, for instance)

I think I can see some confusion growing between what is a group of people and what is a website.

To me I tend to think of it with the following flow:

1. A group of people come together and we call that a Community of people.

2. The Community has tools to help them interact - although these are web based tools such as forums or personal messaging, they are seen as distinct from a Web Site.

3. The Community decides to create a website for their community using tools provided.

In a slightly odd way Liferay provides for this flow with public and private pages. As an admin I would set up a Community Template that has one public page with something innocuous on it like "Community X" right in the middle. I would then put set community tools on the private pages. (I am ignoring for the moment that the community can add their own pages).

The community uses the private pages for establishing and conducting community affairs.

If they want to create a "Site" then they would edit the public page.

hmmm

Maybe this is where the problem lies - rather than in what a Community is, perhaps it is in defining what the Public and Private pages are.

I am not against changing a "Community" to a "Site" but I feel that it only addresses half a problem or a problem that only some people have.

For some they are grouping people to create sites, for others they are grouping people to create communities. Most, I would suspect, are creating both at the same time - a community which then creates a site.

(You could go cross eyes working out the semantics here)

At the moment, while we are in design phase, we are being tripped up by this very confusion.

A community will be created by an action in the online game. The grouping in the game will define the membership of the community (we will not allow members to join these communities via the portal itself).

Once created, the Community is managed by the person who triggered the creation via the game (interestingly, they will not be the owner - that will be a shadowy figure they have no control over since we do not want any of them to have ownership rights).

So, this is a community.

Now, as part of their tool box, the members of that community can create their Site (public pages) if they so wish.

As you can see there is a very defined difference between the community and their public presence - their "Site" if you like.

Actually, I dont think this is confined to our particular use of Liferay; I think this is how human beings think naturally. We are a tribal creature and we define everything in those sorts of terms.
thumbnail
Hitoshi Ozawa,修改在13 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
I agree that community is more than just a site. Organization is more related with workflow - getting something "stamped" following a process. Community is more ad hoc based on having a shared concept with or without a site without a rigid process - i.e. ad hoc task request.
It may be a good idea to add the concept of a site, but I don't think it's very good to replace communities with sites.
thumbnail
Artur Linhart,修改在13 年前。

RE: Creating communities in 6.1 and public vs private pages

Expert 帖子: 459 加入日期: 07-9-13 最近的帖子
From my point of view the Site is just a place on Web, where the people meet or which is visited by them. From this point of thinking, it does not matter if the site has some public or private part or both - I find it really more clear to name it Site than Community. Always I have talked about the Community, the people not living Liferay every day were confused - we want to have some site for some specific action, not some community... So, it will be more simple to communicate it to the non-development people.

The community functionality is from my point of view just an attribute or additional functionality provided by the site, not vice versa.

Is there some reason and usage to have in the portal a community without any site (even private) defined for it? I do not think, there are a lot of such applications, where I would want to have the community in a concrete meaning without having a site (at least private) for it.

I look forward what the split of the organization structure from the site will mean concretely - from the philosophical point of view it is for me a great step forward, because it makes the things more flexible, etc - but I have no clear imagination about it, how the organizational roles will become site roles, etc., if it is possible to make it simple enough (for example: If the site has already the same role defined like the organization, how it will then work? etc.)

But if it can be done smooth enough, I think it will be nice. And also, like I have spoken about it with friend of mine, if the change of the concept will not bring some other problems, which will be then unsolved for long time, what happened in the past by some other philosophical changes.
I would appreciate the 6.1 - pre-release with the new functionality ASAP (with the longer testphase than usually) to have the possibility to test this new philosophy wider by the community and possibly find a solution and fix all such potential problems - it will possibly mean also some more work on translations, etc., so it could really help to have earlier a preview version.

Another question is the difference between private and public site. I aggree, this is sometimes really confusing... Especially, there is (or was in the past) also possible to define in the public site some "private" pages (without having guest access), but they (at least in older versions) were still accessible by the guests under some circumstances (in 4.x and 5.x versions)... I do not know if it is so also in 6.x, but I think some more "philosophical" clear split of private and public pages or at least fix of such problems would be great to make the concept more understandable (sometimes in the older versions we were not sure if we just understood the concept in some wrong way or if it is an implementation error)
thumbnail
Hitoshi Ozawa,修改在13 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Is there some reason and usage to have in the portal a community without any site (even private) defined for it?


I think the key phrase here is "in the portal". Organization and Communities exists outside of the portal. "Site" is a term specific to a portal. A site is just one concrete method where members of a communities can meet. Limiting community member to only meet in a "site" will prevent new method on how communities members will be able to meet from being added that may be possible when technology advances.

It's also kind of strange to talk about a person belonging to several "sites". A person with access to site A, site B, and site C sounds OK, but saying a person can chat at site A instead of members of community A can chat and exchange information and file with each other seems to have different meaning.

A "site" may also been thought as a room in an office. To work, people work at their desks in a room. To enter a room may require access priviledges. It's possible to say that people have to enter a room and it's difficult to image people to work without entering a room, but a room doesn't properly express loose association between people.

Splitting pages from Organization and community seems like a good idea but replacing site with community doesn's sound too good.

Example:
Organization: Sales, Marketing, Personnel, Engineering
Community: Chess club, Tennis club, SpringFramework group
Site: Public page, private page

Organization(s) and Community(ies) may share a common site.
thumbnail
Artur Linhart,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Expert 帖子: 459 加入日期: 07-9-13 最近的帖子
Yes, I aggree completely, community in the real world is something completely different than a site, but still, we are the "in the portal" and here I really do not see much appliance for the case of the definition of the community completely without its site, representing it in the portal... The only thing what comes to me in mind is, if multiple communities (groups of people with specific roles within) would share one site... But till now the situation was nearly the same for the implementation of such a case.
SZ khan,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Regular Member 帖子: 145 加入日期: 09-10-31 最近的帖子
I consider the change as more philosophical than technical. However, it will be less tedious to sell the concept of a site than of a community to a customer .
thumbnail
Corné Aussems,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 1313 加入日期: 06-10-3 最近的帖子
IMHO it is more a matter of the organisation that is organizing the communities;
ie: In a corporate implementation the term Organization will suite best and in a Public implementation the term Community.

Over the years i have had a lot of discussion on my translated version of the word Community because in dutch it is besides the intended 'Group of people sharing the same interest' also the definition of 'Intercourse'.
Luckily our leading Language Institue (yes everything is regulated over here) decided the english term Community has been accepted in our language as especially a group of people on the internet.

Nevertheless we have had corporate clients who are really put of by the term 'Community' as it has to them a connotation of 'Open Source' and not being Enterprise.

Maybe our community could settle on some other Synonym.

Introducing a new contender
................ Space ............

To be more serious i think this is a big thing and changing such important term in this project should not be taken lightly.

If it is not making things better/clearer it shouldn't be altered.
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Nevertheless we have had corporate clients who are really put of by the term 'Community' as it has to them a connotation of 'Open Source' and not being Enterprise.


I think this is the main point. Is Liferay just going to be for a structured company or should it be open to SNS providers and users as well?

We have an internal portal for work but we currently also have a SNS system so employees can write blogs and meet people with common interest to create a community.

Organization and "site" and "web space" seems more of a terminology used in a structures organization. Similar to server - client in tech technology while a "community" is more like a peer to peer system.

We probably won't do chats, file exchanges, and brainstorming sessions at organization with "sites".

Maybe, this is just a social difference and different marketing strategies in different countries. It may just be a matter of translating it differently in each language for their market.
thumbnail
Miles Huang,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 29 加入日期: 05-8-31 最近的帖子
I felt the topic discussing here can be divided into 2 separated aspects, and build relation between them.

1. Party Concept Generalization
Party is a nice idea which I have learnt from "The Data Model Resource Book" by Len Silverston (Although this is an old book but the concept in this book still shines today).
This is a well abstracted concept that generalizing all kinds of entities who interacting with the Portal system: User, Community, Organization, Partner, etc.
To be short, in OO design graph,
Party
  |
-----------------
|               |
Person(User)    |
           Party Group
                |
       ---------------------
       |                  |
    Legal Organization    |
       |              Informal Group 
   Company                |
                      ---------------
                      | extensions  |  (Community, UserGroup, Team, Friends, Family, etc)

Then, on the abstract Party entity level, Contacts, Roles, Relations are generally described.
The party design is very flexible: The concept can be applied to a user, an automation system or even a group of friends. Their relationships can also be maintained abstractly and clearly.
Liferay is short of such abstraction. Several parallel entities exist (As show in the graph) without such OO abstractions, which make code duplicated and not easy to extend. Imagine if we need to implement the Family entity in Liferay, no abstract base entity that we can build upon.
What I suggested here is a new Party Framework from ground up can be implemented, consolidates party related common functions, just like what Assert Framework do with content entities.
This is also a facility that make following 3 possible.

2. Web Space (A little different concept from Site in LP 6.1).
May I suggest “Web Space” is a more appropriate term than Website? The site is a little bit easy to make end user confuse with Portal, Instance or Company, whatever.
Actually what I'm talking is Group entity, which already exists in Liferay design, but never exposed to the end user. Seems LP 6.1 will expose half of it emoticon but a little different from what I think.
The problem is: currently the Group concept is never completely exposed to the end user, but "decorated" as their related entities in hard coded 1:1 composite relationship: Community, Organization, User, Page Scope, etc.
I think this is the root cause of the problem been discussed here.

3. To solve the problem
The main difference from Liferay 6.1 way is instead of convert Community to "Website", I'd prefer to expose "Group" directly, give it a more user friendly name, such as "Web Space".
Community is still kept here. And not only Organization can maintain its "Web Space", but also User, Community, or even user extensible Party entity based on Party framework, can also have the ability to allocate one or more “Web Space” to it.
About the relationship design between Party and "Web Site"/Group, consider these:
a) the relationship can be optional. A party can have no related Web Space. (Seems LP 6.1 Organization already do this way)
b) the relationship can be multiple. Why a party can have only one Web Space in the Portal?
c) the relationship can be cross-referenced. May multiple party share a Web Space without pre-built party relations?
Thus a n:m relationship between "Party" and "Web Space" may be appropriate for it.
Let end users aware of the "Web Space" concept and let them maintain the relationship between extensible Party entity and "Web Space" will effectively break the hard coded 1:1 relationship between them, thus resolve the problem.

4. Further consideration of Web Space relationship
Note this is a different story and not directly related to the problem discussed in this thread.
Since LP 6, page can form its own ScopeGroup. I’ve not dig into this deeper. Does this means Group can be organized as Page hierarchical tree structure already? If this is true, this feature combine with the previously described Party/Web Space relationship will bring Liferay content framework flexibility into a new level!
thumbnail
Dave Weitzel,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Regular Member 帖子: 208 加入日期: 09-11-18 最近的帖子
Apologies for joining in this discussion late and many thanks Jorge for starting it and all the contributions so far.

I am "replying" to a post from Miles Huang which most closely represents some points I was wanting to bring to the discussion.

I have been working with (specifying, selling, implementing and developing) community software for over 15 years now with the underlying group functionality being one of our most powerful capabilities and when we looked at Liferay it was one area where there was definite need for improvements.

So the proposal to rename Communities "sites" just isn't enough in my experience to meet the demands of either intranets or in our case extranets.

Firstly I do think you need a separate ability to have sites built quickly and easily using templates. The discussed issue between public and private pages and how to navigate between is I think at too high a level. It is the portlets within the templates that are either public or private, some like calendars will show different data depending on who is viewing, likewise content, recent activity etc will show different data there is no need to force two separate pages. In one scenario in our business we would have a site for a major event with pages for agenda, accommodation speakers and registration perhaps. Other scenarios will have one page with multiple portlets on them. Often sites start as single pages and then need to be assigned to a group of users as well while still having a public view because there is a need to have discussion/community interaction in private around the site content.

Secondly in the "organization" requirements. As mentioned by Miles and others there is a definite need to introduce "group types" which have their own characteristics defined in properties or xml files. Typically a group type (such as standing committee, focus group, chapter, location) will have "group positions" such as chair person, secretary, treasurer, member, Health and Safety officer etc which map onto certain permissions. Each instance of a group type may need to vary their specific permissions from the initial default. Each group type may or may not need a site as defined by a specific template set of pages/portlets with public and private capabilities - typically portlet based not page based - see earlier.

The power that this can then have in assigning people to positions on a committee that immediately inherited permissions to create or manage objects which then leave them when they are removed from that position is exceptionally user friendly and leads to devolved site administration very easily. Currently there is no such ability as you assign roles/permissions separately to individuals which is cumbersome and can lead to mistakes too easily.

The group type hierarchy needs to be definable (current Liferay makes this possible but hard and I don't believe flexible across portal instances?) for instance locations having committees and working groups ... But you also need to be able to have "free standing" groups I guess assignable only to the top level "Organization".

I am left wondering what "User groups" are as these don't seem to have been discussed at all but are part of the liferay terminology and functionality. Are these going away? Can they have sites assigned or are they purely there for permission and role based usage?

I hope this all makes some sense and I will try to keep on top of this forum as much as I can.
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Dave, you've put it better than I did. It's not the renaming, the problem is the limited functionality of "group". I think some of us have tired to use "community" to customized.

The only difference in opiniion is on the following requirement - I would like it to be configurable from GUI by a "instance" admin.
Secondly in the "organization" requirements. As mentioned by Miles and others there is a definite need to introduce "group types" which have their own characteristics defined in properties or xml files.


BTW, I just saw a post by David and invited him over to join in this topic. I think his requirement is common. Sandeep proposed using roles, but it would be better if I can do it with a "group".
http://www.liferay.com/community/forums/-/message_boards/message/8128904?_19_preview=false
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Phew - That was a long read! Sorry for putting my big foot in it!

Hotoshi and Dave

Yes, I agree there is a difference here. When I was speaking to a very non-technical moderator last night about the new portal we are creating I was explaining the liferay Communities as opposed to Organisations.

He put his finger on it immediately:

"Oh, like Facebook Groups!" He did not use the word Site.

I do agree that having a common functionality that can be applied to any grouping of people (whether hierarchical or not) does make a lot of sense and I am not opposed to what is being suggested here, but I am concerned that for certain uses of Liferay, where how people are structured and organized throughout a portal instance is paramount to the use, that by throwing out what is perceived as a community (or group, if you like), we appear to be actually removing functionality. (Even if that is not in fact happening). I want to have a non-hierarchical grouping of people that I can then attach a site to.

The comment has come up several times about communities existing outside of the portal. This is true, of course, but they are also reflected inside the portal for the purpose of organising users and giving them very specific permissions.

Jorge

As for your way of working through private and public pages, I think suggestion number two is closest, but with a bit more potential customisation.

Three times recently I have found the need with various applications to be able to set access for anyone to read (Liferay public), Group only (Liferay Private) and any registered member (umm - liferay doesn't have that one).

Currently, to give a very specific access to a page, you need to go mess with the page permissions and try and remember how you set up the other page that you had like this.

We almost need a bit of a grid. Out of the box you would have Private and Public. But you can add others like, for instance, a registered users column. You then simply drag and drop your pages into the particular column. Something like that.

This could be done on a live "Site" interface or part of a "Site" template.

Just like our Dutch friend's problem with translating the word "community" I think much of this is a language issue. For our purposes, where a community will be created from game code remotely and will need to be a mostly private, stand alone grouping with membership levels and functions, then the word Community works very well. Our Portal will, in the end, have thousands of little communities/villages of people and the ability for players to also join much larger communities and organisations that represent kingdoms, guilds, and much more - all via the game and with the over-site of a non-technical customer relations team (who are scared enough of Liferay as it is)

What might get around part of this is the ability to change the nomenclature for the control panel and other places so that the portal reflects the circumstances in which it is being used. If all of us, in different ways, have trouble explaining to clients and users the functions of various items, and if it would help if they were called different things, then lets have the ability to name them appropriately.

There seems to be two areas in which Liferay Portal is used:

1. As a core solution on top of which is built a variety of, possibly, non related websites - almost a multisite CMS on steroids. In this use, although a user may be able to cross between one site/community and another, the bias is towards the free standing individual website identities and the portal is the holding system for that.

2. As a complete solution in itself that services the needs of a large group of people that have a common association. In this use, although the user might be predominantly associated with being the member of a particular community or organisation, the bias is towards being able to move around the portal as a whole and being part of many free standing but related communities as well as sharing a commonality with all users at all times.

This is not two different ways of saying the same thing, but it is easy to see how one software package would work for both scenarios, but that, with the change of bias, one set of application names may NOT suit both scenarios.

It might be splitting hairs, but people don't identify themselves with a site - they identify themselves with a community or group. That community may HAVE a site and may use website type tools that technically bind the grouping of people together, but it is the community that those tools enable that users will belong to. Most users are not interested in the fact that it is technically a site or even that the community exists outside of the technology, they want it all shoved in the same box and given a nice pretty label that makes sense to how they are using it.

Who can blame them? It is they who have to use the product at the end of the day, not the admins or even the client.

Now, we are off to break Liferay and create the idea of Sub Accounts just to make things even more complicated!
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Joss, finally someone who understands my poing in marketing! emoticon

I do agree that having a common functionality that can be applied to any grouping of people (whether hierarchical or not) does make a lot of sense and I am not opposed to what is being suggested here, but I am concerned that for certain uses of Liferay, where how people are structured and organized throughout a portal instance is paramount to the use, that by throwing out what is perceived as a community (or group, if you like), we appear to be actually removing functionality. (Even if that is not in fact happening).


If we take out the term "community", I would have a VERY difficult time even to get an appointment to talk about Liferay - the in word now is "cloud" and building "community" on it. Nobody is going to come to hear a talk on building a "site".

The comment has come up several times about communities existing outside of the portal. This is true, of course, but they are also reflected inside the portal for the purpose of organising users and giving them very specific permissions.


Agree on this. People with money (e.g. directors and managers) don't care about sites, they want to build a community. I have to admit that the people who actually do the implementation, however, are more focused on sites rather than on community.

Just like our Dutch friend's problem with translating the word "community" I think much of this is a language issue.

or a social issue connected to marketing. emoticon
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
HI Hitoshi

If we take out the term "community", I would have a VERY difficult time even to get an appointment to talk about Liferay - the in word now is "cloud" and building "community" on it. Nobody is going to come to hear a talk on building a "site"
.

Actually, you bring up an interesting point.

I hate most buzz terms that are trying to create something new out of something that already exists - web 2.0 was one of those; I was doing web 2 bits back in the later 1990s and have never really worked out what was so different.

However, one term I do like is the "cloud" especially if you do not try and make it too technical.

I am old enough to have loved the Hitch Hikers Guide to the Galaxy back in the mid 1970s. That radio play and the book "21st Century Blues" nailed what would become the web well and truly, long before either of the authors knew about it. The thing they got was that high technology would not change society but become an extension of it.

I believe that web type communications do not lead thinking but simply enable more of it.

Clients do not want to be lead, they do not want to be told how to think or what to call things, they simply want their existence to be extended to stakeholders in a dead simple way.

When I am not doing this I am a composer and writer working mostly in advertising - I have been for over 30 years. Although everything I do is done via the internet, when a client wants to go over a brief in fine detail, they never use facebook, instant messaging, email, skype, message board or anything else, they pick up the phone and hit 11 numbers and there I am.

A tool like liferay, to be really successful with the users, must be as simple and as obvious as that. It should be "up in the cloud" as it were and ready to connect people and their ideas together. That is its power - the fact that technically you can create websites with it is almost incidental.
thumbnail
Dilip T I,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

New Member 帖子: 4 加入日期: 09-12-21 最近的帖子
This has been an interesting discussion & I have been keenly following this thread - thanks Jorge for starting it.

Joss, it's interesting what you bring up in the last para of your post - a tool like Liferay should be simple, up in the Cloud (Hitoshi san brought in the cloud angle) & bring people and ideas together.

Let me tell you how we use Liferay - we built a product on Liferay to generate and manage ideas within enterprise, academic, research and open Communities! We started with Liferay version 4 and are now moving our product to version 6. And it's on the Cloud!

In our case, we have to reflect the organization hierarchy that exists in the client organizations in our product. We provide for "Themes" which are nothing but focus areas or categories for ideas. Themes and Ideas typically cut across organization hierarchies - therefore we went with Communities for them. And each Theme and Ideas has its own Space (Sites?) - pages with portlets to socialize and collaborate around them.

Another point is, a User has a private and public space too for showcasing capabilities and interests, managing their ideas as well tracking interesting ideas. When Ideas move forward based on community rating & feedback we move them through Teaming and Prototyping (Project) spaces where more private groups work on elaborating and prototyping the idea.

So we use Communities for Themes and Ideas and organizations for Teams and Projects. Of course we make use of custom roles and associated permissions.

It was a challenge achieving this in LR4 - but definitely the capabilities brought in by LR5 & 6, especially Sites with attached templates has been a blessing for us! In fact we had a LR 6.1 version from trunk (Dec 2010) compiled & deployed which shows Community Sets & Communities under organization type, with a regular Community also in existence. We found this very useful since in our use case, communities exist within organizations as well as cutting across organization hierarchies.

My vote is for:
1. Keeping Communities intact, both cutting across Organizations as well as within an organization
2. Enhance Sites with capabilities discussed in detail in this thread, especially with respect to easy visualization and administration
3. Ensure that the Sites capability extends to Individual users to (as in managing their private and public pages)

I am not sure whether I added some confusion to the thread or it was useful. I just wanted to let the Community know that there are folks like us, though far and few, who also use LR for building products that potentially could get used in multiple client scenarios. And flexibility in configuring fundamental capabilities like this will go a long way in making those solutions successful.
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Dilip,

I love the fluid nature of your approach to liferay - if I am reading you correctly it seems to fit in well how people believe and think in real life.

My vote is for:
1. Keeping Communities intact, both cutting across Organizations as well as within an organization
2. Enhance Sites with capabilities discussed in detail in this thread, especially with respect to easy visualization and administration
3. Ensure that the Sites capability extends to Individual users to (as in managing their private and public pages)


The Online game I am involved with (and if anyone wants to help, shout - we have no money, so everything is done on a "love" basis emoticon ) has one main developer who invented it and wrote all the server code and client code in Java, and then a team of people who work for nothing and are all round the world.

Although that sounds wonderful and idealistic, it is actually difficult to maintain. What I miss is the conversations round the water cooler, being able to wander into someone's office and say "help me with this" or just being able to sense the mood of the team.

Now, I don't think that liferay can ever either technically or philosophically ever address that problem to a meaningful extent, but the good developer should be aware of that human mix or formal and casual relationships that can co-exists within any sort of society and at the very least pay tribute to it.

If I were to equate that to liferay I would get:

The Society or Tribe - That would be the portal.
The structural governance of the society - that would be hierarchical organisations.
Family life within the society or tribe - that would be communities.
Dross family friendships - that would be User-groups and would be transitory.

Note: despite the idea of generations families are not really hierarchical as the perceived hierarchy slips each new generation - so communities fit better.

Sites, therefore, would be a common tool - as you say, even to the individual user level - that is used to express the existence of each of the parts of the society as a whole.

Sorry that I am using very prosaic terms here, I am trying to look at this without defining it too much in the terms of one particular use of Liferay.
thumbnail
Dilip T I,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

New Member 帖子: 4 加入日期: 09-12-21 最近的帖子
Thanks Joss - we did try to get the product to fit the natural way people go about Ideas. For us Liferay has been a phenomenal development platform with great services out of the box.

We utilize all of the structures under discussion on this thread as well as the very useful social features that LR provides, especially in versions 5 & 6.

The more flexibility and configurability the platform provides the better for meeting different customer scenarios!
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Thanks Joss - we did try to get the product to fit the natural way people go about Ideas. For us Liferay has been a phenomenal development platform with great services out of the box.


Same goes for me too.
You've asked us for our opinion and that's what I've done. Please take it with a grain of salt. emoticon

The more flexibility and configurability the platform provides the better for meeting different customer scenarios!


This, I highly agree!
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Corné Aussems:
I can't recall but maybe someone else does!
When and foremost why did Liferay changed from the term Group to Community.

Because it seems that everybody has agreement on what an Organization & Community is ...

a group of people emoticon


Yes, when I first played with Liferay a couple of years ago, I had to eat extra fish to translate Community into Group in my head.

But my non-tech friends had no trouble at all.
thumbnail
Ray Augé,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 1197 加入日期: 05-2-8 最近的帖子
Are we talking about a purely philosophical issue based on terminology?

Or, is there some technical underpinning to the conversation!

I want to make sure the issue doesn't get reduced to just one or the other.
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Hi Ray, I think both.

There should be a straight line between the clients needs and the underlying technology.

I dont think clients think of collections of people as Sites, they think of them as Groups or Communities - even tribes, if you want - but definitely not Sites.

A site, to me at any rate, is a collection of information using web technologies.

A community of people my use a site to help the online manifestation of the community, or to publish the community's agenda to the outside world, but they them selves remain a community.

What liferay offers out of the box is technology to help create a community AND to give that community a site. In other words, the community does not need to exist first; tools can be used to create and underpin the community.

That is why, for my clients at any rate, the idea of calling such a collection of tools a "community" makes so much sense.

The philosophical element is also very important therefore in understanding how such tools are used - the use can dictate the labels you put on the tool.

For instance, you may use a puncturing device to puncture your can of drink (well, we did many years ago) but it makes a lot more sense to call it a Can Opener even though it can be used for puncturing all sorts of other things too. (My thumb was a regular victim I seem to remember)

emoticon


(Edited for bad spilling mistalk)
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Okay, so thinking this through a little more ....

We have three possible core parts of liferay:


1. Creating a hierarchical structure that can be used to reflect an organisation - called, quite nicely, Organisations.

2. Creating a non-hierarchical grouping that has an exclusive use and would normally be used to allow the formation of a group of people with a common cause. Liferay calls this a Community, which from a marketing perspective (which I know far more about that I do about the technology) is a much better name than "group."

3. The ability of creating a site that can be used for exposing the output of any part of Liferay - be that a Community or an Organisation or, perhaps, even of a Team.

So, if the proposition is that a "site" should be a transferable tool or asset that can then be attached to any defined part of the portal, then that makes sense to me.

However, that should not be INSTEAD of Liferay's community idea.

In this way a "site" becomes something that has no membership but is simply employed by the Community or Organisation administrator when such a thing is needed, exactly the same way as a single page is currently.

The only argument left in this scenario, is what actually is a site? And I really don't mean from the developers point of view, but from the view of the non-technical person in charge of his or her bit of the Portal.

My gut feeling is that the "Site" would be the public (or global portal membership*) facing part of the community or organisation. In its most basic state it would have a metaphorical door knocker saying "let me in" all the way through to a complete, dynamic on line magazine.

The non-public part, although it would use the same tools, would possibly not be thought of in quite the same way. Ironically, this private side could easily be the more complicated of the two as it would have all the collaborative tools.

However, the same global management functionality could be employed for both, but maybe with the ability for the portal admins to list them in a helpful way - this list of "site templates" being most useful for public exposure, and this other list of "site templates" being really useful for the private side. Of course, some elements may logically appear on BOTH lists!

So, assuming I am understanding the initial idea correctly, the only difference between now and this next stage would be that rather than adding one page at a time to your Community or Organisation, you can add an entire bit all at once, complete with look&feel templates, Web Content templates, various dynamic functionality and the rest - though you can edit it after if you like in the same way as now.

That to me preserves the important structural ideal that Liferay currently offers while giving a powerful extra tool set to make the day to day user operation even simpler.


How does all that sound?



I know that some find the difference between an organisation and a community rather subtle, but in our set up, the difference is really logical. I imagine others have found that too.


* I am still battling for the idea that you can easily set up your Public facing side to only be viewable by portal registered users (without having to go through all the permissions) or, better still, have an option for THREE sets of pages - Public, Registered, Private.
thumbnail
Miles Huang,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 29 加入日期: 05-8-31 最近的帖子
Hi Ray,
Although my initial post is quite technical, introduced "Group" term into the thread, seems most of posts in this thread tends to discuss it in philosophy area.emoticon.
What I mean is the Group Entity in the existing Liferay system play the role of “Site”, which is the container of Web pages and the scope of Asserts.
In the ScopeGroup and Assert area, Liferay has done quite well. Actually my suggestion for Liferay 6.1 or some release in the future is create a "Party" framework, which abstracts all kinds of portal accessers and use an abstract Party entity to represent them. Portal accessers includes user, group of user (Community, Organization), and automation systems. This is just like what Assert framework does to all kinds of portal content entities.
The introduction of Assert framework makes Liferay extensibility great at content area, developers are easy to extend new content entities, and all kinds of services the Liferay platform provide for the OOTB asserts are ready for those user extended asserts.
Just like the assert framework, the introduction of Party framework may complement the extensibility of Liferay framework in another important area - the Portal system accessers, their relationships and all kinds of low level services the Lifeary framework can provide to it, such as Role/Permission assignment. Liferay has already addressed some kind of accessers and their relationships: Individual person as User, group of person as Community (in flat relationship) and Organization (in hierarchical relationship). These terminologies are just fine, and many Liferay customers are accustomed with them. Just keep them along. But I do think these don't cover all kinds of requirements. For example enterprise automation system (not a person that login to the system, but still require permission management), friend relationship in social network (in graph relationship) is not covered OOTB. The extensibility on Party management will bring great value to Liferay (as a application development platform).
What do you think?

Best Regards,
Miles.
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Are we talking about a purely philosophical issue based on terminology?
Or, is there some technical underpinning to the conversation!
I want to make sure the issue doesn't get reduced to just one or the other.


Good questions Ray. I think we're getting to the philosophical issues based on terminology because I can see a slight advantage, but I can't see a great technological difference of the proposed change in view of users to merit a change in the name.

As such, from the argument, it seems the main benefit seems to be from the change in the name rather than from technical change.
thumbnail
Miles Huang,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 29 加入日期: 05-8-31 最近的帖子
I agree with you that in the current situation (LP 6.1 changed way), its just a change in the name, no much technical change happened: in technical perspective, from Group->Site; in end-user term perspective, from Community->Site.
I think the real difference in technical perspective is: the Organization and the Site is now classified into two kind of logical independent concepts, the entity that representing these concepts are much clear than before and the entity relationship can be managed by end user.
Note the difference from the previously Liferay: the Organization and the Community is classified into similar concepts for the end user, but in technical implementation there is no community actually, the Group entity implements too many roles: for example the Site/Scope group, Community representation, and member relationship owner.
In my opinion, the change has made a right step toward the right direction, and makes the entity relationships much clear. But after the change we may soon find out:
1. Since the Community has changed to Site, Liferay is now missing the Community support for the end-user perspective. From the end-user view, the Community should be quite similar as what new Organization looks like, with slightly different membership policy and logical structure. The community concept should not be classified into “Site” concept like what Liferay previously did, either from technical or end-user perspective. This should not be considered
2. How about the old Personal Site? Should they be generalized in the same way as new Organization either and share common code base to maintain the relationship with Site?
3. If we decide to support implement real social network friend relationship management, would it be nice to mapping the friendship relationship to the Liferay underline ROLE/Permission service framework to provide permission control?
What I want to call up in this thread is a little technical architecture foresight, let the problems mentioned previously can be solved by a reusable framework API.

Regards,
Miles
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Hi Miles

Yes, I can see the logic of the idea of a "site" being what the old community was, but I agree, by making that philosophical change we do loose what is seen to be a benefit.

For me, structurally speaking, there is one very major difference between a community and an organisation - a community has no power over anything that is lower down the tree and there is no power over it from above.

Although technically Liferay does not work like this, I suspect many installations can be mapped out like the following where communities are dead ends and are not affected by superior organisations. Although anyone can theoretically belong to any community, in practice it tends to be mostly people from one particular part/level of the organisation structure.



This makes communities very important and valuable in the structure, whereas with organisations, when you create one beneath, the one above has oversite, the community is technically independent, while philosophically part of the whole.

Thus, a community should be accessible by people from within an organisation, and from without it too - as it is currently - And be able to create a "site" in the same way as any part of the organisation can. Er, I think.

(I am going to need a lie down after all this.)
thumbnail
Miles Huang,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 29 加入日期: 05-8-31 最近的帖子
Hi Joss,
Correct me if I'm wrong.
As my understanding from Jorge's summary, LP 6.1 has renamed old Community as Site, then no community term is occupied in Liferay 6.1 now. This makes the room for liferay to future improvement on real community concept, may be just like what you are expecting, may be with even more features. On the other words, no community means new/real community will be implemented sooner or later.emoticon
So no worry, features has been in Liferay is still there, with a more clean re-design concept. Liferay's change in LP 6.1 is just make room to introduce exciting new features to Liferay in new versions.

Regards,
Miles.
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Hi Mike

Yes, the idea is that Communities will be renamed Sites.

However, there is already a community structure in Liferay and it is called Communities.

I think what Jorge wants to do (Jorge, correct me if I am wrong) is have "Sites" as a separately manageable entity that can then be utilised by an Organisation.

I am in full agreement that Sites should be able to managed, be created as templates, be accessed by certain roles only (this site template for that role, another one for a different role, for example) and so on.

However, I think that they should be then available to Organisations AND Communities and not lose the idea of communities in the process.

Actually, what I am proposing is more radical since Jorges idea is really just renaming communities where as I am proposing a unique structure.

I am not a programmer, but it strikes me as easier to take the Community "code," duplicated it, rename it Sites, all the nice addons, but leave the community system intact, than it would be to just rewrite and rename communities and then have to go away and reinvent communities from scratch.

So, leave things as they are, and find a nice wonderful way of utilising the idea of "sites" for any groupings - Organisations, Communities, Teams, User Groups ....

Just seems more logical to me.
thumbnail
Miles Huang,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 29 加入日期: 05-8-31 最近的帖子
Joss Sanglier:


I am not a programmer, but it strikes me as easier to take the Community "code," duplicated it, rename it Sites, all the nice addons, but leave the community system intact, than it would be to just rewrite and rename communities and then have to go away and reinvent communities from scratch.

Just seems more logical to me.

I am a programmer, so I think for Liferay, take the new Organization "code,", duplicated it, remove member user manage ability, remove child organization ability and name it "Community" would be a more easy solution. emoticon
Just kidding. Actually take a serious consideration on technical aspect, code should never be duplicate. Instead make Organization and Community share most of common code would be the right solution.
thumbnail
Ray Augé,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 1197 加入日期: 05-2-8 最近的帖子
There is nothing removed as far as prior functionality (only re-naming, as well as a slight change in behavior with respect to orgs).

Meanwhile, I've been thinking about this subject and I believe that in our lexicon, we don't clearly distinguish between things which are "outcomes" and those which are "components" one leverages to achieve an "outcome".

For instance, what do we generally want to get as outcomes of the portal?

- Organization (n. Something that has been organized or made into an ordered whole.)
- Community (n. A group of organisms or populations living and interacting with one another in a particular environment.)

One, either or both of these could be considered the primary basis under which portals can be considered to have been effective.

So, these are the outcomes we want.

What does the portal provide to achieve these outcomes?

- Organizations (wondering now if perhaps Department wouldn't be better to distinguish between the outcome and the component.)

Department (n. A distinct, usually specialized division of a large organization.)

- User Groups
- Roles
- Sites
- Portlets

Really what we're doing with the name change is simply reclassifying what was known as a community into what it really was, which is a "Site" and this leaves the door open, as suggested for "Community" to be used finally as an outcome of assembling the various parts you might need.

Now, perhaps what is required is a simple "Wizard"-like process that takes you through a few steps to create either a Community or Organization.

- Create community:
	- select existing users or create a User Group of users?
	- assign some default roles?
 	- will this community have a set of private pages?
		- will the site use an existing template? 
			- select from list!
				- default set of community collaboration tools
				- etc.
	- will the community have a set of public pages?
		- will the site use an existing template? 
			- select from list! 
				- default set of activity/progress reporting tools
				- etc.

- Create organization:
	- create child deparments?
	- other org related steps?
	- maybe as above...
	- etc.
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Hi Ray

I think I said somewhere (maybe in Jorge's original blog) that maybe a little bit of functionality in portal properties would not go amiss that allows the admin to decide on the best names for things.

Generally I think Organisations and Communities work well in English (I am a copywriter as part of my trade, but in English only) because Organisations has a slightly formal quality while Communities has a less formal feel.

The word department, in the UK, would be seen as very old fashioned, where as in France it is used as a political region of the country - but I can see where it would have its place. Certainly, with the definition you have below, it is slightly strange that an organisation should be a child of an organisation. Probably not difficult to put a clause in that says "if Organisation has parent, call organisation Department" or what ever the admin would like to call it.

Your thought about outcomes is interesting, and really this is where all this discussion started. Jorge put forward his proposition because he was thinking, quite rightly, of a specific type of outcome based on how the portal may be used.

However, a few of us pointed out that the way we use the same Liferay Portal means that our outcomes, our expectations may be a better term, are different. Actually, in my case, the final outcome will appear very fluid and variable, even if behind the scenes it is, in fact, very structured.

I am very keen for Liferay to be as flexible as possible out of the box. I really like the idea of Sites being a managed tool that can be applied to a group such as Organisation. I am not sure that Sacrificing the attractiveness of "communities" to achieve that is the best approach.

My problem is that having spent 30 plus years in the advertising industry, I need a really serious reason before suggesting renaming anything that is currently working! emoticon
thumbnail
Ray Augé,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 1197 加入日期: 05-2-8 最近的帖子
Oh, and I completely agree with you! I am not suggesting that there be any static limitation for how things work.

I'm simply trying to drive toward some type of workable solution that may appease the majority without limiting those who need more, or clobbering Jorge's already in progress renaming.

Note: As for the naming in the core, those are all customizable via language properties files.
thumbnail
Joss Sanglier,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 60 加入日期: 09-7-15 最近的帖子
Ray Augé:


I'm simply trying to drive toward some type of workable solution that may appease the majority without limiting those who need more, or clobbering Jorge's already in progress renaming.



Oh, very definitely do not want any Jorge Clobbering - he seems far too nice!

I have to say this is not a deal breaker about liferay, but I am wondering whether this has shown that perhaps the idea of "sites" maybe needs to be thought out as a separate issue rather than just renaming communities.

As I said earlier - if you can create specific "sites" that can be attached to bits of an organisation, why not extend that to communities, user-groups, teams, personal communities (profiles) and so on.

Seems like the perfect opportunity.

I don't know about anyone else, but I think there is a logic for a manager of one of liferay's groupings (what ever you name them) to say "I want a site" and presses the big "create site" button on his interface.

Voila, a wizard appears and he can pick one of the lovely stock sites created by the Admins and available to his particular "role" or he can grab a blank one and start from scratch, with the tools he is allowed to use.

I am very fond of opening cans of beans - my apologies!
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Note: As for the naming in the core, those are all customizable via language properties files.


Right. I'm doing that already. There were some grammerical errors in the recent Japanese version and some terms which has become "standard" were changes and users who has been using previous versions of Liferay were getting confused.
thumbnail
Jorge Ferrer,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 2871 加入日期: 06-8-31 最近的帖子
Hey guys,

Just wanted to drop a quick note to let you know that while I'm not talking much I'm still here listening.

We are working hard to try to make sure as many of the suggestions presented here as possible are taken into account. My plan is to be able to have a first milestone or beta release during May that already includes several of the changes discussed.

Once the milestone is out there and can be tested, we can review what is still missing and continue the improvements based on your feedback and that of anyone who wants to join the party emoticon
thumbnail
Björn Ryding,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Master 帖子: 582 加入日期: 07-5-16 最近的帖子
Hi Ray!

We use the current possibility in Liferay to create your own organization types to create different forms of organizations such as consultive bodies, committees, project teams, faculties, classes of students and so on.

Renaming organizations to departments would be very confusing from our point of view.

Cheers,
Björn
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Ray, I think some of us are arguing that it's not the "organization" but "group" that should remain. As was shown in Miles' OO design graph, there's a "group" on top and "organization" and "community" underneath. An "organization" = "community" + structure. The argument is to have a "group" and allow "organization" to be constructed by adding "structural templates" to the "group".

Finally, have another template to assign a page to a "group".

To summerize:
Community = group + site template
Organization = group + structural template + site template

Have default templates so most users do not have to create them. However, allow users who need more flexibility to modify them.

Organization + site template just sounds to decrease Liferay's flexibility. emoticon
thumbnail
Hamish Campbell,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 87 加入日期: 08-8-20 最近的帖子
This is a rearly interesting discussion for people struggling with liferay terminology emoticon
thumbnail
Jorge Ferrer,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 2871 加入日期: 06-8-31 最近的帖子
Hey guys,

Thanks a lot to everyone for such a nice debate about this topic. There are a lot of interesting comments so I'm going to try to do a summary and organize all the questions and answers in topics:

Rename of Community as Site

The origin of this discussion has been the blog entry in which I announced several improvements in 6.1 to fix the confusion between organizations and communities and that included the rename of communities as sites.

The main reason for this change is that Liferay's sites (I'll use the new term going forward) where used not only for building sites for online communities (an that was the initial use for which they were created), but also used for building many other types of sites. And that made things quite confusing and even led to some design mistakes such as hiding the Site associated to an organization which removed quite a bit of flexibility.

It's important to note that while Liferay's sites were called communities, they didn't really have anything special or particular for creating communities (in its functionality or in the backend). I mean, all of its functionality was also useful for many other types of sites.

Even the concept of members which is mentioned in this thread a couple of times is not in my opinion unique to communities any more. In the social Internet that we live, almost any type of site (maybe all) can benefit from having members. For example, a corporate site, which not so many years ago used to be only about publishing information, can now be greatly enhanced by letting people log in an participate. This concept is greatly described in "The cluetrain manifesto" and I think that the fact that Liferay's sites supports members will help leverage this reality.

Regarding the proposal to use the term "Web Space", it was the term that made the second place when we discussed the rename. At the beginning I was an strong proponent of "Web Space", because it is more generic and probably defines the goal and purpose better. But I was convinced to change my vote while trying to explain this change to several people. I noticed that the term Web Space was creating new confusion, because it's a new term, that most people are not used too, so if we decided to use it we would risk running into the same problem that many people had been facing with the term "Community": having to explain it over and over. The term "Site" on the other hand is very common, and while it might not be as accurate as "Web Space" (mainly because it's often used with different meanings) we came to the conclusion that the benefits outweight any possible drawbacks.

How to support communities in 6.1+

This is a completely valid concern that needs to be addressed: Liferay 6.1 should keep supporting creating online communities. In fact, my plan is to make it even easier.

It has been mentioned in this thread that a Community is something that exists outside of the portal. I wholeheartedly agree with this observation. What the portal has to offer is a place where the members of the community can share information and communicate.

In 6.0, if you wanted to build a site you needed to create a community, which didn't make much sense. In 6.1, in order to build an online presence for a community, you can create a site (where you can publish content or place collaboration tools), which makes much more sense.

So to answer Hitoshi, we are not replacing Communities with Sites. We are just fixing the fact that we were using the term "Communities" for what has always been "Sites". That will not only avoid the confusion, but will also let us use the term "Community" where it really belong as we provide better tools to build communities.

Now the question is, what can be done to make it easier to build sites for communities in Liferay? What I have in mind is to provide an out of the box Site template, specially optimized for communities. It would have a front page with a summary of activities, a shared blog, message boards, etc (suggestions are welcome here). In fact this approach is very flexible, since a portal administrator can create several Site Templates for specific types of communities.

For example, Joss mentions that he is using Liferay to allow creation of Game Communities. I think that's an example where using site templates will be very useful. For every Game Community a Site will be created with the appropriate site template. In that scenario it would also be possible to create other types of Sites. So when an administrator goes to Control Panel > Sites he will be able to browse all sites or filter them by "type" (that is the site template).

Related to this, we are going to change the way Sites are created, so that the first step will be to select the "type" of Site that you want to create. And the available "types" will be the site templates that are enabled. We are even thinking of adding extension points in this process so that through plugins it'll be possible to customize the Site creation wizard so that certain site templates can specify their own creation forms and advanced options.

Besides these improvements, do you guys think there is more that can be done to improve the support for building online communities?

Organization Roles

Artur Linhart:

but I have no clear imagination about it, how the organizational roles will become site roles, etc., if it is possible to make it simple enough (for example: If the site has already the same role defined like the organization, how it will then work? etc.)


Thanks for bringing this up, because I think this is the most delicate aspect of the change and it's actually the only one that might require an upgrade. So I want to make sure it's done right.

The issue right now is that an Organization Role was really doing two things at once: setting the permissions for the administration of users and setting the permissions for actions performed on the site. That was of course bad, because if a portal administrator wanted to create a role to allow a user become a "Message Boards administrator" in specific (community or organization) sites, he would need to create that role twice, once as a Community Role and once as an Organization Role. This means additional administration work, doubling the number of needed roles and a bit of duplication in the permissions code.

With the rename, the Community Role will be called Site Role and it should be the way to setup permissions for anything that can happen in a site. So the question is, what happens to Organization roles?

From now on they will be used only to provide permissions related to user management. For old organization roles created in previous versions of Liferay what I have in mind is to write an automatic upgrade process that iterates all organization roles and does the following:
  • Check the permissions associated to a role
  • If it only has permissions related to site resources, make it a Site role.
  • If it only has permissions related to user management, leave it the way it is.
  • If it has both types of permissions, then create a new Site role and move all the permissions related to Site resources to it. An open question is what should be the name of the new role, but I'm leaning to adding a suffix such as "(Site)" and let the portal admin rename it later to something more specific after the automatic upgrade.


What do you guys think?

Public pages and private pages

I've had a love-hate story with the concept of public and private pages since it was introduced in Liferay. At times I hate it and at times I love it. I've talked about it many times with other core developers, with community members in the forums and Symposiums and with customers. I've known cases of people telling me how confusing they think that was and other people who said that it was the best feature Liferay had.

The main difference between the two is that public pages can be accessed by anyone (even non registered users) unless the administrator explicitly removes the permission for a page. Private pages on the other hand can only ever be accessed by users who are members of the community. One minor additional benefit is that when any type of resource is created, if it's created from the private pages the default view permissions in the form field is to be only visible by members while if it's created in the public pages, the default view permission is set to be visible by anyone. It should also be noted that both sets of pages reuse the same content.

The main benefit of having public and private pages is that it fits with the common concept of having a public site and an intranet.

Some drawbacks of having separate public and private pages are:
  • The administrator has to decide ahead of time whether to create private or public pages. Furthermore, there is currently no way to convert a public page to a private page.
  • It might create further confusion when staging is enabled for the Site. Previously, it was necessary to activate it for both public and private pages. Now that's been improved (I'm not sure if it's been for 6.0 or 6.1 right now), and the administrator can chooose whether to activate it for one, the other or both. But there might still be some confusion by the fact that the content is shared so if it's used from both the public and the private pages, then that content needs to be either staged or not that that decission will affect both sets of pages.
  • There is currently no easy way to navigate back and forth between the two set of pages if both are used. The best solution for this is not clear, some people would like to have just a link, some others would want to have a merged site map.
  • With the introduction of the term Site, there is a potential new confusion. I've noticed that both Joss and Hitoshi call Site to an specific set of pages (public or private). I've done that in the past too. And in a way I think it's a good term for it because they have separate navigations, but it's also incorrect in the sense that they both share the content. In 6.1 we've decided to call Site to the mix of public pages + private pages + its shared content.


There have been several proposals to change this to avoid the drawbacks but keep the good parts, but so far I haven't heard one that would really achieve this. Here are some that I have heard (including one that I recently thought of but hadn't shared yet):

  • Allow for only one set of pages and have a setting that determines whether the pages are public or private. The drawback of this solution is that it wouldn't be possible to have both public and private pages and many people consider that to be very useful.
  • Allow for only one set of pages and let the administrator decide which pages are public and which are private one by one. One benefit of this is that it would produce a unified site map. One drawback would be that it would increase the amount of work necessary to create the two sets of pages compared to the current way. This could be fixed by providing shortcuts to make page public or private and also by making this characteristic hierarchical through the page tree.
  • In addition to #2, provide the a way to create pairs of sites (one public and one private) that would have its own set of pages and its own repository of content but which could also easily share content between them


What do you guys think about this proposals? Any other idea? Do you think it should be just left the way it is?

Exposing the Group table and proposal for introducing the "Party" concept

Miles Huang:

Actually what I'm talking is Group entity, which already exists in Liferay design, but never exposed to the end user. Seems LP 6.1 will expose half of it but a little different from what I think.
The problem is: currently the Group concept is never completely exposed to the end user, but "decorated" as their related entities in hard coded 1:1 composite relationship: Community, Organization, User, Page Scope, etc.


That's a very interesting comment because I've thought about it for a long time. In fact, the Group table has always been exposed to the user, but the term used in the UI for it was Community. One issue of this exposure was that only certain entries of the Group table were shown (those with className=com.liferay.portal.model.Group). With the move to Sites in 6.1, other additional entries will be shown because the Sites associated to Organizations (className=com.liferay.portal.model.Organization) will also be shown. In fact we've been careful to make this extensible (through hooks) so that other "types" of group entries can be exposed in the Sites administration if desired. We did not show all of them because we didn't think it made sense. For example, exposing the Sites of users would hide the other sites when there are millions of users. Also the entries for page scopes would cause confusion if shown there.

Miles Huang:

Since LP 6, page can form its own ScopeGroup. I’ve not dig into this deeper. Does this means Group can be organized as Page hierarchical tree structure already? If this is true, this feature combine with the previously described Party/Web Space relationship will bring Liferay content framework flexibility into a new level!


What you call ScopeGroup is a group entry that is associated to an specific page (it has className=com.liferay.portal.model.Layout). It's used so that a page can have content scoped within that page. It allows for example to have several message boards, blogs, wikis, etc in a Site (one per page). You can learn more about it in a blog entry I wrote about it:
New in Liferay 5.2: Support for many independent message boards, blogs, wiki, ... per community

I've had a lot of thoughts about expanding this for 6.1 (if we have time, or 6.2 otherwise). What I had in mind I think it's similar to what you are asking for. I had thought about creating a concept which could be called Sub-sites. A Sub-site would start at an specific page and would have its own scope for data (like is possible since 5.2) but also a set of pages. It could also have its own administrators.

Is that the same thing you had in mind?

Looking forward for your answers emoticon
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
So to answer Hitoshi, we are not replacing Communities with Sites. We are just fixing the fact that we were using the term "Communities" for what has always been "Sites". That will not only avoid the confusion, but will also let us use the term "Community" where it really belong as we provide better tools to build communities.


I think some of us are using "communities" very differently from just a set of "pages" as you've mentioned - i.e. we have "communities" without any pages.

Communities can be used to define user boundaries for something like a chat function which doesn't have any pages. Like an organization, community is used to defined boundaries between users and in the current release of Liferay, it's also connected to a page.
The difference between concept of an organization and a community is that organization has a structure defined boundaries while a community does not.

For example, Joss mentions that he is using Liferay to allow creation of Game Communities. I think that's an example where using site templates will be very useful. For every Game Community a Site will be created with the appropriate site template. In that scenario it would also be possible to create other types of Sites. So when an administrator goes to Control Panel > Sites he will be able to browse all sites or filter them by "type" (that is the site template).


In this situation, we probably would need to limit viewable site to to a member of a community. As an example, a member of a D&D 1 community would be able to see sites "Dark Castle" and "Snow Peaked Mountain", while member of Fantasy community would may be able to see sites "Dark Castle" and "Never Ending Ocean". A member of Action Adventure may not have any site on Liferay but be able to chat, Skype, trade files, and visit each other's wall.

I just read a thread by Michael about being able to define a custom group. I thought this may also be an interesting.
http://www.liferay.com/community/forums/-/message_boards/message/8110800

I hope you don't mind but I'm inviting other users who've posted related topics to take part in this discussion.emoticon
thumbnail
Michael Charles,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

New Member 帖子: 15 加入日期: 11-1-20 最近的帖子
Thank you Hitoshi for directing me to this thread. I'm very new to Liferay as we are currently evaluating it for use within the federal agency.

With that said I can't speak to some of the issues faced but I can speak to the needs we are trying to support and what we hope to achieve(if possible) through Liferay.

From reading the conversation thus far while I think I understand the reasoning I also think is slightly limited regarding "Communities". The topic of renaming or changing it to support "sites" from what I currently understand might cause further limitations. (granted I don't have a full understanding of all of the Liferay internal working)

From a federal agency perspective the current "Orgnization" structure makes sense and can support an agency and a hierarchy of departments.... Giving each department a presence that is currently public/private pages or what we would call a site.

As for "Communities" our need is to serve as more than giving us ability to create "sites". We can do this with any CMS. Ideally the need is to support multiple groups and define custom "group types" of which "Communities" would be one. Rather than "sites" the need it to have "workspaces" that can support efforts such as projects and engagements. Within a group type of something like a "project" a user assigned to that group should be able to add and delegate management of that group (similar to what communities allow now).

With all that said a "site" seems completely different than a "community" from the perspective of workforce planning and collaboration. My guess is that if further definition of a "site" is needed I'd propose they are always public and workspaces (our terminology) would always be private.

As communities are currently used to create what I think everyone is calling sites it might make sense to separate them altogether as I can see a "group type" or "organization" responsible for defining if they use a "site" or not. (side note - This might also allow a group type i.e "Community" or organization to have multiple sites).

The major need is to, out of the box, define group types (and possibly some rules and attributes) and begin building workspaces a to support projects and collaboration among a group or team of users within an agency.

Please let me know if this not fully articulated as I know it a topic with many sides and opinions. From how this agency would like to use this production (a common need within many federal agencies) the use of "sites" in any form is almost a secondary need.
thumbnail
lucas theisen,修改在11 年前。

RE: Creating communities in 6.1 and public vs private pages

New Member 帖子: 19 加入日期: 11-3-2 最近的帖子
Michael Charles:
... Ideally the need is to support multiple groups and define custom "group types"...


I would like to second the idea of group types. More specifically groups of groups. In our portal, we have Communities which are grouped together logically. For example, you may have a group type of Study, which has groups De-forrestation Study, Iceberg Melt Study, Emissions Study. Then you would have another group type of Program, which would could have groups like 100MPG Car, Sustainable Tree Farm...

We currently do this using an Expando column on our Communities. This is clearly not ideal, but its our only choice at the moment. I was thinking about adding a new type_ value to the Group_ table. Currently it only uses 0,1,2,3, but figured i would be shooting myself in the foot as Liferay may choose to add a new group type themselves. Any thoughts on this?
thumbnail
Hitoshi Ozawa,修改在11 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Lucas, which version of Liferay are you using? There's no longer "community" in Liferay 6.1.
thumbnail
lucas theisen,修改在11 年前。

RE: Creating communities in 6.1 and public vs private pages

New Member 帖子: 19 加入日期: 11-3-2 最近的帖子
Hitoshi Ozawa:
Lucas, which version of Liferay are you using? There's no longer "community" in Liferay 6.1.


We are currently using 6.0 EE SP2. I understand that Communities have gone away in 6.1 (which may make things really difficult for us depending on how much really changed). To my understanding, from this thread, they are replaced by Sites. That being said, I still would like a way to group multiple types of Sites together. So you could take the content of my previous post and replace the word Community with the word Site and the argument remains the same (unless something more fundamental changed during the transition from Community to Site).
thumbnail
Jorge Ferrer,修改在11 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 2871 加入日期: 06-8-31 最近的帖子
Hey Lucas,

Regarding the rename of Communities as Sites you can find more about the reasoning in my blog post about the matter: http://www.liferay.com/web/jorge.ferrer/blog/-/blogs/organizations-or-communities-which-one-should-i-use-the-final-answer

Regarding your suggestion of supporting grouping of sites, that is planned for 6.2. Specifically we are going to support creating a hierarchy of sites with the possibility of inheriting content and memberships from parent (and in some cases child) sites.

As part of that effort we will reevaluate the discussion of public vs private pages. I will open a new thread about that in this same category when the time comes.

Jorge
thumbnail
Hitoshi Ozawa,修改在11 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
Specifically we are going to support creating a hierarchy of sites with the possibility of inheriting content and memberships from parent (and in some cases child) sites.


That's great news! Will definitely be looking forward to this. emoticon
thumbnail
Deb Troxel,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 81 加入日期: 10-2-22 最近的帖子
Hi Jorge,

Thanks for creating this discussion.

Jorge Ferrer:


Rename of Community as Site

... Regarding the proposal to use the term "Web Space", it was the term that made the second place when we discussed the rename. At the beginning I was an strong proponent of "Web Space", because it is more generic and probably defines the goal and purpose better. But I was convinced to change my vote while trying to explain this change to several people. I noticed that the term Web Space was creating new confusion, because it's a new term, that most people are not used too, so if we decided to use it we would risk running into the same problem that many people had been facing with the term "Community": having to explain it over and over. The term "Site" on the other hand is very common, and while it might not be as accurate as "Web Space" (mainly because it's often used with different meanings) we came to the conclusion that the benefits outweight any possible drawbacks.

... With the introduction of the term Site, there is a potential new confusion. I've noticed that both Joss and Hitoshi call Site to an specific set of pages (public or private). I've done that in the past too. And in a way I think it's a good term for it because they have separate navigations, but it's also incorrect in the sense that they both share the content. In 6.1 we've decided to call Site to the mix of public pages + private pages + its shared content.



It sounds like you're suggesting that using the term "Site" has the benefit of recognition - people immediately "get it" because they are familiar with the term. I think that there is a risk of confusion though if Liferay isn't using the term in the same way that it is generally understood. Perhaps all that accomplishes is delaying the conversation where you end up having to explaining what you mean by "Site" if it isn't what they thought a site was.

As you say, Site can have different meanings, but in my opinion the defining characteristic of a Site in most people's minds would be a single unified navigation structure; one "sitemap". That's why people naturally use the terms "public site" and "private site", those terms fit our preconceived ideas of what sites are. I definitely wouldn't naturally infer that a Liferay Site is "the mix of public pages + private pages + its shared content".

Jorge Ferrer:


There have been several proposals to change this to avoid the drawbacks but keep the good parts, but so far I haven't heard one that would really achieve this. Here are some that I have heard (including one that I recently thought of but hadn't shared yet):

  • Allow for only one set of pages and have a setting that determines whether the pages are public or private. The drawback of this solution is that it wouldn't be possible to have both public and private pages and many people consider that to be very useful.
  • Allow for only one set of pages and let the administrator decide which pages are public and which are private one by one. One benefit of this is that it would produce a unified site map. One drawback would be that it would increase the amount of work necessary to create the two sets of pages compared to the current way. This could be fixed by providing shortcuts to make page public or private and also by making this characteristic hierarchical through the page tree.
  • In addition to #2, provide the a way to create pairs of sites (one public and one private) that would have its own set of pages and its own repository of content but which could also easily share content between them


What do you guys think about this proposals? Any other idea? Do you think it should be just left the way it is?



In #1, I think you meant to say that it wouldn't be possible to have both public and private sites (rather than pages)?

I think #2 is a terrific idea. If this was the method of creating pages, then it would eliminate my objection to using the term Site. Creating the sitemap with some pages public and some private feels very comfortable within the context of a Site.

Maybe I have a naive understanding of what's involved in the separation of public and private sites (quite likely!), but in my mind I think of them as navigational alternatives. The Admin could choose whether the pages at the public URLs include links to the private pages in the navigation. If so, the private page links would only appear in the navigation when the currently logged in user is a community member. Similarly the Admin would determine whether the private URLs trigger the navigation to select only the private pages or if the public pages are also included in the nav items.

Next it would be great if the template for User public and private pages could be added to the unified sitemap as well, so that if the Admin wishes to they can build a Site having navigation that doesn't require any cross-linking or custom ServicePreAction magic to create the navigational feel of a what I expect from a "normal" site; that is, all the pages that I have access to can be reached through a single navigational tree.

Would that be feasible?
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
This is a little off the topic of "community" and "site", but I'm feeling that more people are confused with "instance" and "organization".

Following thread is just an example, but I've encountered many such situation when the same question has been asked.
http://www.liferay.com/community/forums/-/message_boards/message/7872450

In a strict sense, I think what's now being called an instance should actually be called an "organization" or a "domain" and what's being called an "organization" should be called an "organizational unit" (OU).
thumbnail
Hitoshi Ozawa,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Liferay Legend 帖子: 7942 加入日期: 10-3-24 最近的帖子
It sounds like you're suggesting that using the term "Site" has the benefit of recognition - people immediately "get it" because they are familiar with the term.


I think there is a difference between stance on how we view Liferay - whether is sale or in implementation. If I'm trying to sale Liferay, people nowadays aren't going to buy a software to create a "site". If they want a "site", they just go on an Internet and fill out a form or buy a hosting service online. People are familiar with the term because there are already so many "sites" on the Internet. In terms of "marketing", Liferay is more than just a software to create a "site"; it enables users to create an "online community" where people can associate. We sell the concept of making online "communities" not "sites". It may be better to get people from marketing involved in this discussion instead of just having "technies" make the discussion.

On the otherhand, once decision to install Liferay is done, it's easier to talk about creating a "site" because the term is already commonly used, and people are more interested in getting pages (aka "site") up and running.

This is a little bit off topic, as I was answering somebody else's question, I came across "Virtual Hosting(Communities)". I think the word "Site" would be a better here than "Communities".
http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Virtual+Hosting+(Communities)

I think I know where the term "site" can from. It's from the page selection pull-down menu.
thumbnail
Miles Huang,修改在12 年前。

RE: Creating communities in 6.1 and public vs private pages

Junior Member 帖子: 29 加入日期: 05-8-31 最近的帖子
Jorge Ferrer:
Regarding the proposal to use the term "Web Space", it was the term that made the second place when we discussed the rename. At the beginning I was an strong proponent of "Web Space", because it is more generic and probably defines the goal and purpose better. But I was convinced to change my vote while trying to explain this change to several people. I noticed that the term Web Space was creating new confusion, because it's a new term, that most people are not used too, so if we decided to use it we would risk running into the same problem that many people had been facing with the term "Community": having to explain it over and over. The term "Site" on the other hand is very common, and while it might not be as accurate as "Web Space" (mainly because it's often used with different meanings) we came to the conclusion that the benefits outweight any possible drawbacks.

It’s fine that Lifeary has decided to name it as Site. I think it will not be a problem after LP 6.1 release. Let’s accustom with it emoticon
Jorge Ferrer:

That's a very interesting comment because I've thought about it for a long time. In fact, the Group table has always been exposed to the user, but the term used in the UI for it was Community. One issue of this exposure was that only certain entries of the Group table were shown (those with className=com.liferay.portal.model.Group). With the move to Sites in 6.1, other additional entries will be shown because the Sites associated to Organizations (className=com.liferay.portal.model.Organization) will also be shown. In fact we've been careful to make this extensible (through hooks) so that other "types" of group entries can be exposed in the Sites administration if desired. We did not show all of them because we didn't think it made sense. For example, exposing the Sites of users would hide the other sites when there are millions of users. Also the entries for page scopes would cause confusion if shown there.

Get the point. Now its exposing as “Site”, with selective types distinguished by their relating Organizations, Users, reintroduced Communities in the future, ... IMHO, do need to introduce an abstract “Party” concept here, isn’t it? emoticon

Jorge Ferrer:

I've had a lot of thoughts about expanding this for 6.1 (if we have time, or 6.2 otherwise). What I had in mind I think it's similar to what you are asking for. I had thought about creating a concept which could be called Sub-sites. A Sub-site would start at an specific page and would have its own scope for data (like is possible since 5.2) but also a set of pages. It could also have its own administrators.

Is that the same thing you had in mind?

Yes, very similar.
The sub-site concept may also be used to solve private/public layoutset problems if you decided to do some re-design on it. The sub-site node needn’t be forced to start from a specific page. It can be a direct child-node of the site, just like private layoutsets/public layoutsets do. Or a special hidden page type may be introduced for the sub-site node, which may reduce the change on the existing structure.

Jorge Ferrer:

The issue right now is that an Organization Role was really doing two things at once: setting the permissions for the administration of users and setting the permissions for actions performed on the site. That was of course bad, because if a portal administrator wanted to create a role to allow a user become a "Message Boards administrator" in specific (community or organization) sites, he would need to create that role twice, once as a Community Role and once as an Organization Role. This means additional administration work, doubling the number of needed roles and a bit of duplication in the permissions code.

With the rename, the Community Role will be called Site Role and it should be the way to setup permissions for anything that can happen in a site. So the question is, what happens to Organization roles?

About roles, I have thought it for a long time. It was redundant previously, with 2 separate role types, one for Organizations, one for Communities, which almost same for similar concepts. Now the LP 6.1 change make the two roles types more reasonable, since they are target to different concepts now, make things much clear.
Then think a step further, how many kind of Role Types do Lifeary needs, can they be generalized and acting in a similar manner?
We may consider a Role defines two things: 1) a unidirectional relationship, from the assigned-to user (or party if you accept the concept) to a target object; 2) privileges allocated to the assigned-to user on the target object. And different kind of Liferay Role types is classified by different kind of such relationships.
Take Liferay existing Roles for example:
  • Owner Role:
    This kind of roles is actually implemented by a special case. But it can be considered a kind of role which is aimed on an implicit relationship from the assigned user to the entities he/she creates, describing privileges the user allowed to acting on the target entity.
  • Regular Roles:
    This kind of roles are aimed on an implicit relationship from the assigned user to its belonging company, describing some privilege the user allowed to acting on the target Portal/Company he/she belongs to.
  • Site Roles:
    This kind of roles are aimed on explicitly defined relationship from the assigned user to the target Site, describing some privilege the user allowed to acting on the relationship targeting Site/ScopeGroup.
  • Organization Roles:
    If we generalize organization, user, etc into Party concept, things will become interesting here.
    This kind of role can become “Party Roles” which is aimed on a relationship between two explicitly related parties, and the Role privilege setting can be used to describe allowed action from the assigned-to party to the target party.
    This kind of role would become much powerful. For example, in a school-family network, parents have explicit "Parent Role" to their children. The privilege of such Role can grant access to their children’s study report, but not any child of other parent. Note we needn’t predefine a huge number of Family communities for each family, a simple Role assignment from the parent to his/her child will enable fine-grained RBAC, quite approaching to the flexible social network requirements.


Regards,
Miles