In the LiveConnect platform, Application owners and admins can selectively permission members to comment within the Application. An Application's administrator might allow all registered members to comment within the Application, or may empower only a subset of members (or none at all) to comment. As always, permissions can be declared to the granularity of individual people.

Non-logged in, anonymous guests are never allowed to comment.

Comments are made with via the same WYSIWYG text-editor available in most Posts, and can be threaded or dispalyed chronological.

Below: Sample Posts with comments

<-- previous feature | index | next feature -->

Hives or Community Applications can be used to manage and share any type of information (e.g., discussion areas, product reviews, testimonials, community feedback on new product ideas, press clippings, bookmarks, notes, journal entries, contacts, or company profiles, profiles, even favorite wines, coffees, chocolates). Applications are easy to configure and can also be used for a wide range of familiar, community-based applications (e.g., blogs, forums, feedback forms, knowledge repositories, FAQs, and more).

Applications are the permissionable containers that hold and organize information in a LiveConnections Community in the form of semi-structured Posts. They can be public, private, or selectively shared with other members. Because of the flexibility of the posting structure of an Application each community can easily introduce domain specific language and interactions that increase connection and communication with community members.

An Application is owned by the Member who creates it, who can share administrative rights with other members, empowering them to add or remove Members or Groups (or, more generally, change visibility settings), assign Types and Tags, delete Comments, or change the default summary page view settings of an Application.

Community administrators can define any number of Application Types so that 'blogs' can be browsed separately from 'forums' or 'recipe exchanges' or whatever other Application Types are relevant to the community.
 

Below: a Discussion Area

Below: an Idea Center

<-- previous feature | index | next feature -->

People (and their information) are the reason the LiveConnect platform exists. All content within a LiveConnect powered community is created and owned by its Members.

All Members in a LiveConnect Community have a display name, an associated avatar and a rich profile that may include: video, images, text areas and much more. Each Member has a "home page" that shows his or her personal profile and a record of his contributions to the community - which Applications, Types, Posts, Groups, and Comments are his.

The structure of a member's profile is defined by the Community Administrator. Example profile fields include: Name, Address, Phone Number, Email Address, Company, Title, Instant Message ID, Photo, T-shirt Size, vCard Attachment, Favorite Movie. Each Member can permission individual profile fields to the appropriate audience (wwww public, community, network, private).

A sample member profile. Note the permission icons on each field.

Members can belong to an infinite number of Groups. If empowered to do so they may create and manage Groups and/or Applications either from a curated template or on a custom ad hoc basis. Members can be individually permissioned to view and/or post new information in specific Applications, or can be permissioned to the Application as part of a Group.

Some LiveConnect powered communities allow Guests to browse appropriately permissioned content within the community. Guests are anonymous and do not have a personal profile, cannot post or comment in the community, and can view only the content that has been explicitly made available to non-members.

See a list of Members in this Community, or see your own network.

Below: a sampling of user images

-- previous feature | index | next feature -->

In the Permissions overview post, the basic rules of the permissions model were outlined. Below is an expanded explanation of how we reconcile permissions on a member by member basis, as well as a few details about the permissions form itself.

How does HiveLive reconcile permissions conflicts?

Members can be permissioned to the Application individually, as a member of one or more Groups, or as part of an application level audience (e.g. "Registered Users"). It is therefore possible that a single member is permissioned to the Application as a member of more than one audience. How does HiveLive reconcile the permissions in this case? In short, we start at the bottom of the form and work our way up.

1. If a member is named individually to the Application, then the LiveConnect platform honors the permissions explicitly assigned to the member. Though the most common use case is to provide individuals with additional privileges (incremental permissions), it is possible for a specific member to be given less privilege (decremental permissions) than a Group that they are a part of or even all registered users.
2. If a member is not named individually to the Application, but has been implicitly assigned as part of a Group, then HiveLive honors the permissions assigned to the Group. (Again, a Group might have more or less privileges than registered users as a whole). If a member is part of more than one Group assigned to the Application, then HiveLive sums the permissions across all Groups to which the member belongs. For example, if Pat Smith is part of Group A, with Read permission, and Group B, with Post permission, then Pat will have both Read and Post permissions.
3. If a member is not named indivually or as part of a Group, then they will be given whatever permissions are assigned to all registered users.
4. In communities that have enabled visibility to the public www, "Guest Users" - anonymous browsers from the www - can be given permission to Read content within a Application.

Why is there an auto-check columns feature?

By default, the LiveConnect platform automatically updates the checkboxes by column in the permissions form. We do this to discourage Hive admins from accidentally creating members with decremental permissions (Application members with fewer privileges than their Group membership or registered user status would suggest). What actions do we take in this effort?

• In short, we auto-check down a privileges column, updating individual members and Groups whenever a super-set to which they belong is updated.
• For example, if an admin decides to give all registered users Comment permission in the Application, we assume that in most cases the admin intends to extend Comment permission to any Groups or Members individually assigned to the Application, as well.
• The same is true when an administrator updates permissions for a Group - the LiveConnect platform assumes that the Application administrator does not intend to exclude individually named members when upgrading the permissions for a Group to which they belong.
• In all cases, permissions for individually named members can be updated after the higher level user and Groups settings have been made, and the exact status of the form is what you get when pressing the 'save' buttons.

If you would like to disable the auto-updating feature of the form, simply uncheck the "auto-check columns" checkbox at the top of the form. When using the form in this mode, take care to create decremented users only if that is your intent.

<-- previous feature | index | next feature -->

Tags within the LiveConnect platform are bound to a particular Application, and members can be given different permissions to create and/or apply them. Tags are not freely created by all members, but instead are applied from a custom list. An Application owner or admin can define which members of the Application have the ability to create and/or apply Tags within the Application. For example, an Application owner might create a set of category like Tags within an Application (Financial Services, Retail, etc) and allow all authors within the Application to apply their own tags, in effect categorizing their Posts. Alternately, an Application owner might use Tags to represent an internal workflow (submitted, in development, in testing, released) and allow only a tiny set of members to apply the Tags.

Application owners and admins can manage the Tags available in the Application via the 'settings' tab, in a similar manner to managing Post Types.

<-- previous feature | index | next feature -->