Sorry about being unclear! At an architectural level the differences are basically non-existent at the moment, and we don't expect the two products to diverge architecturally in any meaningful way. Rather, from a functional (feature) level they will diverge more strongly over time. The current feature differences stem from different configuration defaults and exposed functionality. Special thanks to Aaron, he blogged about this internally in Clearspace 3 months ago and this content is pulled straight from there.
The two products contain different default profile fields: X contains 'location', 'occupation', 'biography', 'expertise', and 'homepage'. Clearspace Internal contains 'location', 'title', 'phone number', 'biography' and 'expertise'.
Create Blog Permission
Registered users are given permission by default to create a blog in the internal version but are not allowed to create a blog unless given permission in Clearspace X.
Anonymous / guest users are allowed to view content in Clearspace X by default, the internal edition turns that permission off requiring users to first login before viewing any content.
Private messages are enabled by default in Clearspace X and disabled by default in Clearspace internal.
Blog trackbacks are off by default in Clearspace but on by default in Clearspace X.
Blog pinging (http://en.wikipedia.org/wiki/Ping_blog) is enabled by default in Clearspace X and disabled by default in Clearspace internal. Blog pinging is a process that happens behind the scenes in most blog software, your Clearspace instance will send an XML-RPC ping to weblogs.com, google blog search and technorati IF blog pinging is enabled when a new blog post is created / published on your system.
Email addresses on user profiles are hidden by default in Clearspace X (and thus are visible by default in Clearspace internal, I believe this is new to 1.1.1)
Clearspace X uses 'Community' when describing the containers for content while Clearspace internal uses 'Space'
Clearspace X uses a different design (obviously): the difference? jive-external.css vs. jive-internal.css
Over time there will be certain features or changes that only make sense in one or the other product. Examples include:
changes to the reputation and recognition system that make sense in only one use case
read/write webdav support for Clearspace
certain integrations with other systems that only make sense in one of the use cases (sorry, I'm being vague here intentionally)
As for building out one facility for both internal and external communities we've talked a lot about this internally and think that having an instance of Clearspace and an instance of Clearspace X connected in a meaningful way makes the most sense. We would love to get your input on what would be most valuable in your scenario, both architecturally and functionally.
Thanks - this confirms my observations. It is very useful to know this information to help assess and plan an appropriate information architecture.
I think we are now able to fully engage with determining how Clearspace(x) can be used to support both internal and external communities. I can see the logic of large organizations having separate facilities for both sets of communities, but for SME's there is a tremendous opportunity to build an integrated collaborative environment.
I've done some experimenting with trying to structure Clearspace to span both internal & external needs. The following snapshot depicts the high-level structure.
I'll explain a bit more about the structure and logic. The facility is split into two main space areas, External & Internal. In essence they are only structural containers. Both only have blogs enabled (since you have to have at least one blog/discussion/document). Indeed, the next level down is also structural only and also only has has blog enabled. Below this level Sub-spaces and Tag Groups are used to manage the bulk of the content.
I am using blog aggregation, but carefully to ensure that only appropriate blog content is shown at the higher levels.
I feel comfortable about the appropriate use of Spaces and Tag Groups; I also accept plans to enable free form Wiki landing pages, but I'd personally like to use the structuring ability of the product as the main organization and navigation method.
The first obvious one is the limitation of space hierarchy levels i.e. only one level of nesting. I need, at least, another level in my structure. Ideally, it would be an expandable tree interface. I appreciate that multiple levels could get visually messy. I have also mentioned before that I'd like to have Tag Groups also appear in the organization hierarchy panel i.e. the diagram above.
Whilst it is could be useful to have blogs for high-level structural containers, this is not necessarily the case. Perhaps the Clearspace architecture could support just a pure structural container concept. It would be useful to be able to have a 'page' of detail to explain the structural level/sub-content (some thing more rich that the space description).
I'm not sure how the main page What's New works in regard to aggregation. There is a possible bug with the current see separate reported issue
. I assume the aggregation of What's New ( a very important aspect of the product) is space permission based? If so this should enable the correct exposure of content. I've noticed that you have to set a space to implement discussions and documents if you want to get an aggregated list.
Popular Tags could pose a problem. They appear to expose all popular tags. (1) Offer things that return nothing is crude/unkind, (2) Even short names can expose sensitivities.
Similarly and more deeply related to controlled segmentation of external & internal is Popular Contributors. Even though personal details can be hidden and non real usernames used, the exposure of people could cause problems with client confidentiality even on a pure external community implementation (a classic use for Clearspace is for project collaborative environmemt).
In summary, to achieve a Internal & External split, whilst retaining the advantages of one system and shared content, poses some architectural challenges. It would be useful to chase out the feasibility and also look in more detail at how two instances could be integrated together.
An interesting use case is the one in the original Re: Internal & External Feature Discussion
Thank you so much for the exceptional feedback. You bring up several areas that we've wrestled with a lot, like exposing deeper nesting of the hierarchy, presenting tag groups differently, and how to bridge an internal and external deployment. Your input here is tremendously helpful to understanding how you would like it to work. As mentioned in another message today we're looking hard at how to approach a lot of these areas and we'll post details as we work through them.
Another thing to consider with the external & internal at the same time is that top users exposes everybody to guests and theres no way that i can see to privatise a profile.
There may be people posting in Internal groups who dont want all (or any) of their details pushed to guests but are happy to have it pushed to registered users.
We runner a similar setup using ClearspaceX where by theres a public facing community and then a whole lot of little locked off communities of 6 or so people engadged in discussions in topics half the others dont care about. Most people in these communities, dont want their profiles available to guests, but theres no way to stop it. The visible flag in the user profiles section only works for custom fields and also means that only admins can view it. There should be some way to block access to profiles or even certain non-space areas of the site to non-registered users, ie. search,popular tags.
Ok, a flurry of blog posts on this topic. Thanks for bringing it up, it generated some great output for the community!
Thanks Greg, the blogs are good and confirm the direction of dialogue we have been having. I support your whole approach to focusing on solution areas, rather than getting driven by features. Indeed, the positioning of Clearspace & Clearspace is much clearer and logical.
Your post update and blogs, together with the line that my thread has been taking, sets <span style="border: 0pt none ; margin: 0pt; padding: 0pt; background: transparent none repeat scroll 0% 50%; font-style: normal; font-variant: normal; font-weight: bold; line-height: normal; font-size-adjust: none; font-stretch: normal; position: static; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial; text-align: left; text-indent: 0pt; text-transform: none; text-decoration: underline; cursor: pointer"></span>me up nicely for the suggestion of a new solution use case - Clearspace Y. This is for organizations who want to operate and integrate both Clearspace & Clearspace X use cases in one solution. The benefits of which include:
Collaboration continuum between the internal and external communities - Web 2.0 Max
Improved information management costs by integrating front-end and back-end operations
Increased leverage of ideas and talents - synergistic
Increased adoption success - internal world rather use one than two systems, external see benefits of closer access to SME's<span style="border: 0pt none ; margin: 0pt; padding: 0pt; background: transparent none repeat scroll 0% 50%; font-style: normal; font-variant: normal; font-weight: bold; line-height: normal; font-size-adjust: none; font-stretch: normal; position: static; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial; text-align: left; text-indent: 0pt; text-transform: none; text-decoration: underline; cursor: pointer">* * </span>
Security segmentation where required for confidentiality
A Clearspace Y organization want<span style="border: 0pt none ; margin: 0pt; padding: 0pt; background: transparent none repeat scroll 0% 50%; font-style: normal; font-variant: normal; font-weight: bold; line-height: normal; font-size-adjust: none; font-stretch: normal; position: static; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial; text-align: left; text-indent: 0pt; text-transform: none; text-decoration: underline; cursor: pointer"></span>:
Clearspace AND Clearspace X (preferably on system or a seamless integration of the two)
Joint Internal & External authoring and approval of information
Project & Customer Communities to run walled garden collaborations with aggregated content/access from/to public/selected communities
Open Communities to engage with the outside world
Traceability and integration to enable coordination of chaotic-to-structured
Can I suggest a new Community section for this topic to see who else might want this, establish the requirements, and validate the benefits?
Indeed, why not also set up specific communities for Clearspace & Clearspace X, perhaps in the Lounge section?
Message was edited by: Magpie
What do you think Greg?
Sorry for the long delay in getting back to you on this one. I like the idea of Clearspace Y. Internally we've been talking about how to connect Clearspace and Clearspace X instances and this is a new idea for that conversation. We've primarily discussed ways of viewing/sharing content and activity between the two types of instances.
Hi Greg - I agree the solution can be either on one system or <span style="text-decoration: underline">a seamless integration of the two</span>.
It may very well be that <span style="font-weight: bold">Clearspace Y</span> is a set of additional tools and facilities to connect and aggregate appropriate information over a number of communities. It may be worth you looking at the concepts of federation.
Whatever the solution, I would still suggest it is worth creating a community/space area to discuss the requirements for Clearspace Y. This could help guide, justify, and shape the solution. I notice that your own poll that 42% of respondent are using both Clearspace X and Clearspace. Whilst this does not mean 42% would want them connected together, I suspect a number would if such a facility existed.