Enhancement: Category Types

[epernst]

The current system is a basic discussion/forum system, and because the current programming structure is as good as it is, then I believe that it will not be that difficult to change it into something which is a lot more than a basic forum. Blogs, pages, groups and media are basically just the same. A post with replies. Just with different characteristics and additional features.

Category Type A way to define category "templates". This way the different characteristics of category is defined centrally (from Umbraco). Through these templates you can configure additional features and functions allowed for the category types, and by this change the way the category behaves toward the users. Some of the categories are not much different from the current discussions, but some (like media and jobs) will require a quite lot of additional programming.

Category types could be:

Discussion category The basic configurable category. A post with comments and several features to allow for likes/votes, questions(with answers).

Personal wall category Basically just a discussion category, which is automatically added to all member profiles. But the member may disable the wall entirely, or just disable other members to post on the wall. Whenever someone writes on a personal wall, then it should be possible to define a privacy setting to say who can see the post:

• Public
• Followers
• Friends

Blog category A category with blog posts for members, either personal/profile blogs, or expert blogs. Personal/profile blogs use own template with minimal configuration options. The expert blogs follow the site layout. Blog category may as default only have blog sub categories and blog mirror categories as their "children". Additional blog features/functions required in Dialogue to handle blogs:

• Feedburner - Way to subscribe blog rss feeds
• Blog Ping services - Enables automatic notification to services that new content is available
• Trackbacks - When people link to a post trackbacks are created (optional)
• Archive - The typical archive list ordered by Year, Month etc.
• Ability to post new blog posts via external applications like Windows Live Writer etc.

Blog mirror category Is category typically under either a master blog category, user profile or page, with a mirrored RSS-feed for the users main blog. The blog posts will/may be shared to the users profile as an activity, as well as the page/main blog category, as well as the activity wall of the category members. Additional blog features/functions required in Dialogue to handle blogs mirrors: Define the mirrow:

• Feed ur - This is the URL of the RSS feed you would like to consume.
• Site url - This is the URL of the site providing the feed it should be human readable, and will be used where links to the author are displayed.
• Feed title - This is the name that you wish to use so that you can easily remember what information the defined Feed URL is associated with.
• Pull interval - This is the value, in minutes, representing how often you would like to check for new posts from the above defined Feed URL.
• Excerpt size - This number, in characters, represents how many words will be displayed when only the posts excerpt is shown.
• Post Full Text If this option is checked then the entire body of the feed will be posted. If it is not checked only an excerpt will be posted with a link back to the original article.

Blog list category A simple list of URL links to be defined under a blog, displayed on the blog sidebar. A list is a very simple data structure with a title, a link and eventually a short description. The blog list can be edited by the blog owner/administrator. It is not possible to have sub-categories under a blog list category.

Media category Categories for having "media albums", which can be divided into photos, downloads, documentations etc. Posts in this category type are basically a normal post, with title, content and one or more "attachments" (configurable). The media file may either be uploaded, or just a link to an external URL. Specific for downloads/documents:

• Ability to add a new version. When adding a new version, then the old version is "archived" under the new version (done via a "comment"). This way any external links to the "download" will still be active. The poster should be able to remove old versions.
• There should be a "download counter", which shows both the total downloads for the main post, but also for the individual versions. This way it is possible to make a list of "Most downloaded" post.

Group category A group could be special interests groups (NAV freelancers, Friday jokes, Danish Consultants, local user group chapter etc.). A group is basically a discussion page, with option of Updates and Questions (one or the other or both). A group may have media albums and wikis as subcategories.

Page category Typically a company or product "fan page", similar to how pages works on Facebook. A page again may have jobs, forum, blog, downloads, documentation, photos, videos etc. as sub categories.

Job offer category A category to allow members to add their job offers is an easy way to allow sites to make a little extra money on their site, by allow companies and recruiters etc. to post jobs, but can also just be a free service to their members. Job categories can be added as a main category, or as sub categories to pages. If in a page sub category, then jobs added here, may or may not show up in the site-wide job overview. Ability to add this option could be like an extra service "active services", the page owner can be charged for, or given for free or for points. Besides the normal content, then it should be possible to setup a typically job specifications:

• Job Title
• Country
• Region or City
• Category
• Description/content
• Salary: text, range or amount + currency.
• Job Type: Full Time, Part Time, Contract or Temporary, Project, Internships
• Expiration Date (when should the job post expire and no longer be visible)
• Skills and experiences -- Job Poster can register skills and experiences required (prioritized) . -- Requirements

The job poster may be changed or it can be free according to the site/category settings. If the page already has a paid for profile, then its free for them to add basic job posts. If the poster is a recruiter who as a "every post counts" subscription, then he is not charged for posting full jobs ads under pages for subscribing companies. This is to give a little incentive to recruiters to "sell" subscriptions/sponsorships for us.

Job Poster with special permissions (sponsors/advertisers) can add extended company information:

• Extended description with links.
• Upload company logo
• Upload attachments
• Extend Expiration (like +1 month)

As a default post replies are only visible to the poster, and administrators in the category. No activity is reported, but notifications are sent. But there should be an option recommend/share job posts, just like any other posts (share to Facebook, LinkedIn, Twitter, email etc.). Additionally a member may apply for a job directly from the post. The application is basically a "private message" (with auto-email to the job poster) - and will contain text from the applicant, plus link to the applicants member profile, as well as optional attachments (CV, resume etc.).

Additional features for job categories, could be the option of importing jobs using "Job Posting Standards". I don't remember the names of these standards right now, but they are used and supported by many job boards systems.

Job request category This category allows a member to post "I looking for a job". A job request may be anonymous (only highlights are selected) and visible upon request, visible to recruiters only, visible to connections, visible to followers/subscribers or it may be visible to public. The member may add link to LinkedIn, attach CV/resumes, as well as show their full professional profile (with job skills etc.). The foundation for the job requests are an extended professional profile, where the user specify their skills and past experience etc. I'll describe this later in this document, as it is not directly related to the category.

Category type characteristics The individual characteristics/settings of the category types could be:

• Turn on/off votes or likes (including if it should be called votes or likes)
• Turn on/off tags
• Turn on/off points - often you would have categories, where you don't want that points are calculated. In my current site we have a few forums where posts do no contribute to the posters overall points. These are forums like "The Friday Joke" and "Test forum". So categories which are basically unrelated to the actual subject of the site should not calculate points. But it could also be turned off for "commercial" product or company pages. By turning off points, then no contribution is made to the leaderboard and a leaderboard cannot be displayed for the category. Turning off points in a parent category, automatically turns of points in subcategories.
• Aggregate points - almost the same as turning off points, but here points are calculated. They are just only used to generate a leaderboard for the specific category (and sub categories). Points generated here would not show up in the users main points system or count toward badges.
• Site activity - whether or not the posts/activity in the category should show up in the site activity feed, for users who are not logged in. Only possible for "public" categories.
• Who can create? Ability to allow site members to create new categories, done specifying permission group for who can create. This way you can allow members to create new groups or pages. Also it should allow "category owners" to create sub-categories, like adding an Event Category to a Group or Page. "Category owner" is "virtual" permission group. Additionally it should be possible to specify that i.e. only members with X points are able to add the category type.
• Define name/caption for "favorites" - like should it be called follow, favorite or group members. Example: if users follows a category, then they will receive notifications on new posts (with the ability the user can turn it off individually). A site member who follows a category will become members of a "virtual" permission group for that category (ex. Dialogue Followers).
• Who can join/favorite a category -- Set privacy to open - site members can join/follow (discussions, blogs etc.) -- Set privacy to apply - site members can apply (groups, pages) -- Set privacy to invite - only sites members who have received an invite can join
• As default categories inherit the settings from the category type, but it should be possible to define which of the settings it is possible to alter in the actual category: -- Fixed - cannot be changed in the category -- Changeable - setting can be changed in the category -- Inherit - a subcategory will inherit this setting from their master This way you can specify that ex."Favorite names/captions" should not be changeable, but "Who can join" may be changeable. Setting "inherit" would be used to define for example that if a category adds "Downloads" or "Documentation" to a page, then members who follows the main page, automatically follows the subcategory.

Master-types: The more special category types like Wiki (with a Wiki-syntax editor) or Events (with Dates/Times/Places) would have to be defined as subtypes, with individual "templates". Each additional master-type would have to be defined through programming, not setup. The way I'm imagine this done, is similar to the way "Member Types" are defined in Umbraco. The settings are defined in the Umbraco "Dialogue Category Types" section, and instead of "Member Can Edit" and "Show on profile" it would be:

• Type Setting
• Inherit Setting
• Owner Can Edit So if you have a setting that should not be changeable for the individual categories, it would be set as a "Type Setting" and don't select "Owner Can Edit". If you have a setting, which the user may alter, but you have a default setting (could be "Who can join/favorite"), then you select "Type Setting" and "Owner Can Edit". If you have a setting that you want the user to be able to modify (like name, description etc.), then you just select "Owner Can Edit" - the setting will then just be blank (not copied from the type). In the same Umbraco way, then you would have a different "document type" for the different categories, and in the document type the site admin would be able defined the "Allowed child node types", where the different allowed relations would be defined.

Category settings Besides the current settings, then the category inherits some of the settings from the Category Type, as per above.

Additional settings: Category Owner

• Ability to assign a member to be the "owner" of a category. The owner would have extended permissions, similar to Umbraco administrators, but without having access to the Umbraco back end. The owner can assign additional administrators/editors. Category Administrator
• Similar to Category Owners, except the administrators cannot assign new administrators, or lock the category. Category Editors
• If posting permissions to a category limits regular site users or followers from posting, then the category owner, may assign additional editors, who can post. This would be useful especially for page categories (ex. a Document subcategory to Company Page category, where only selected employees may post new documents). Editors are the same as category moderators.
• The owner/administrators should be able to:
• Add/remove sub-categories (features)
• Change basic category settings (who can post, reply, description etc.)
• Approve new members (if approval required) - or remove/block existing
• The owner/administrators/editors should be able to:
• Post (if posting is restricted)
• Can add media (photo, video etc.)
• Can add polls
• Can moderate posts/replies
• Change (add/remove) tags from posts/replies
• Turn on/off replies
• Turn on votes or likes (likes = only up)
• Turn on and off tags
• Assign default tags to a category, i.e. in the "Dynamics NAV" main discussion category, then all posts are automatically assigned the "Dynamics-NAV" tag, whereas the subcategory "Dynamics NAV Development" then it would be assigned to both "Dynamics-NAV" and "Development". Users should not be able to changes these default tags, unless the post has been moved to another category by an admin/moderator. Default tags should not display to the user on the post, unless added manually.
• Define lists of a required tag. I.e. n a Dynamics NAV category, then the poster needs to select a tag from a list defining which "version" the post is about and additionally which".
• RSS feeds for posts and replies
• Like now, but we must define security settings for this, to prevent post/replies from categories with limited access to be displayed publicly.
• Permissions:
• Who can see the category (basic information, show in category lists, searches etc.) - to everyone else it will remain hidden. Site admins of course can see all categories.
• Category is public = everybody can see the category (including search engines)
• Only site members can see it
• Only category members can see it
• Who can see the category content This is basically managed by the current permissions, but it should be possible to change much easier for the owners/admins without going into Umbraco:
• Category is public = everybody can see the category (including search engines)
• Only site members can see content
• Only category members can see content
• Who can join/follow
• All site members can join
• All site members can apply
• Only members with an invitation can join
• Who can post
• All site members can post
• Only members/followers can post
• Only owners/admins/editors can post
• Who can reply/comment
• All site members can reply
• Only members/followers can reply
• Only owners/admins/editors can reply Sub-categories should be able to inherit settings, including security settings, but it should also be possible to override these settings. Like saying that everybody may post in the main page category, but only editors may post in the download sub-category.
• Besides the above Category Owner, Category Administrator and Category Editors, then anyone how have joined the category, like having favorited a forum, blog, download or documentation category, joined a group, or follows a page or person are considered "Category Members".
• Category administrators must have access to a simple UI for adding or removing users to the standard groups in their category.
• Categories must be able to inherit settings from the parent category, but some limitations needs to be done, like not being able to add more than one of each type. These limitations are defined in the Category Type. It must be possible to manage security settings master category level.

And I'm sorry for the very long "issue", it's based on some notes that I've been doing over some time. Looking forward to hear what you think? Is it too much or do you think we would get too far away from the "simple" discussion forum we have now? I'm sure that there are packages or projects out there to do some of the standard things for blogs and wiki's etc. And just having the framework in place for these category types, would make it possible to design additional types.

[YodasMyDad]

This should all be easily done just using the standard umbraco templates. Using route hijacking as we do, the actionresult in the controller matches the template name.

Just create a new template in Umbraco (Creates a view) for the Category and then add an ActionResult with the same name in the CategoryController. Then you can apply custom logic and pass custom models to your templates.

You can then apply filtering logic for 'Category types' by the template name. I'm guessing create an enum to mimic your templates created or something.

I like all these ideas but I think majority are specific to your site and probably not something I'll implement in the short term.

[epernst]

Yes I know that especially the Job "Category Types" might fall outside of what most communities want. But as I wrote, if we just have the "framework", then it was my expectation that these more specific types could be done as "PlugIns" for Dialogue... :) But the ability to use a category as a blog, that sounds to me like a lot of communities would like.

What you write above about using the standard Umbraco templates sounds good, even when I don't understand exactly how to do. Can you recommend some links to pages where I can read more about this. Because I didn't think that it was possible to use both templates and themes.

[YodasMyDad]

Heres a starting point

http://our.umbraco.org/documentation/Reference/Templating/managing-templates

But it doesn't state anything about route hijacking, but you can get the idea from the code. The Actions name just matches the template. And yes, we currently use templates and themes so it's easily possible.

[epernst]

Thanks a lot will give it a good study. I used to be quite strong in Umbraco, but it's 4-5 years since I've last used any of it. The only reason why I'm back with Umbraco is Dialogue. So I'm "a little" rusty!