Blog as Repository Object

1 Description

1.1 Initial Proposal

1.2 Workshop PH Thurgau / PH Zürich, Mar 2012

by PH Zurich and PH Thurgau (PHTG)

1.3 Current Core Team Proposal, 12 Apr 2012

2 Status

3 Additional Information

4 Discussion

JF 26 Sep 2011: We highly appreciate the idea. Some conceptual discussion will be needed to work out the behaviour if multiple users add/edit postings to blogs.

Matthias Kunkel, 20 Jan 2012: I have extended the description of the feature and hope it makes it clearer for what a blog could be used in the repository.

Oli Lang (PHTG), 07 Feb 2012: What about the possibility to leave comments? We would highly appreciate two ways of commentating: private comments (only seen by the author of the post and the commentator: e.g. teacher gives a personal feedback to the student) and public comments (e.g. for peer feedback and/or discussion)

Matthias Kunkel, 07 Feb 2012: Because comments are a cross-over function in ILIAS this suggestion should be added as a separate request to the Notes and Comments category. Such comments might be used in learning modules or wikis too. And would think about the naming. While private comments could be understand as my private comments (that only I can see) your interpretation of private comments are more a kind of tutor feedback IMHO. General question: who would be authorised to create such tutorial comments? Do we need a role and a permission for it? If so, it would be a feature of the object where the comments are offered (because comments itself are only a service and have no permission handling). We should continue the discussion in the Notes and Comments thread.

PHTG (Sonja Burgauer): It is absolutely required that tagging is added to the blog concept. Tagging as used in other blogs or blog systems, not personal tags like they are used in ILIAS hitherto.

HJ, 16.2.12: @Sonja: Do you mean the category-concept of Wordpress? We agree categories/themes are is necessary for blogs. Blog-Admins should also have the possibility to decide which element comes first: archive or categories.

PHTG (S.B.), 2012-02-23: @HJ - Nope, I didn't mean the category-concept: I tried to be realistic and down-to-earth :-). no really, I was thinking about categories, too. But more important is tagging and tag clouds, so you can tag every article with a lot of different tags (and not some predetermined categories) and find all articles to one tag easily.

ILIAS_LM, 2012-02-22:
What about the navigation in blogs? The largest blog I've seen 'till now is the official ILIAS blog. What happens if mkunkel posts a lot more? Will the navigation (the posting's overview) expand steadily without grouping or other "optical aid"?

Matthias Kunkel, 28 Feb 2012: How will a repository blog be presented? Similar to a personal blog - i.e. without main navigation bar? What happens if I open a collaborative blog within a course? How do I get back easily to the course? Will there be an intelligent Back button that knows from where I opened the blog? Or do we embed repository blogs within the container in which they are placed (like you embed a blog in a portfolio)?

HJL, 28 Feb 2012: Let us think about two options:
1) Embedded-Mode (default): With this option, blogs are presented like ILIAS-Learning modules without the possibility to add a special header. The header of the ILIAS-Installation, breadcrumb and title of the Blog are always visible.
2) Kiosk-Mode. With this option, the blog will be presented like a personal blog without the main navigation. Maybe it will open a new window like the HTML-Learningmodule, so you do not need an intelligent back button.
 
Users can add new posts to a collaborative blog by using the actions-menu. Or they can click a "Edit site"-Button (like in ILIAS Learning modules)
 

JF 5 Mar 2012: We appreciate the general implementation of blogs in repositories. We will continue with the discussion on the details.
@PHTG: What is your opinion on the Embedd-Mode vs. Kiosk-Mode issue?

PHTG, 2012-03-09: Regaring the presentation modus, we would like the same procedure as used in the personal blog. Kiosk-mode or presentation-mode with intelligent back-button. If I got the rights I get to the edit-mode, if not I get to the place where I came from. It's exactly the same procedure as in the personal blog. The header is important for blogs, espcecially when used as part of a presentation portfolio.
 
We will write some more specs until the end of March.
But some points will be: editing by several authors, private comments by teachers (as feedback), open comments by fellow-students. The process if I want to open a former personal blog (move form my personal working space to a course) should be considered and be specified.

lauener, 2012-03-23: Questions to the specifications (1.1) [E-Mail to PHTG]
 
a) Titel: Da steht "gilt für Objekte im persönlichen Arbeitsbereich und Magazinobjekt"
» Gilt auch für Blogs in Kursen und Gruppen? Oder wie ist das zu verstehen
 
b) Tagging:
» In den Einstellungen des Blogs soll man dies aktivieren/deaktiveren können.
 
» Das Problem hier kann sein, dass die User das Gleiche sehr unterschiedlich taggen (z.B. E-Learning, e-Learning, eLearning, ...). Da wäre deshalb sinnvoll:
a) Der User hat eine Zeile zur Verfügung, wo man zum eigenen Posting eigene Tags hinzufügen kann
b) Darunter gibt es eine Option: In diesem Blog vorhandene Tags hinzufügen. Wenn man darauf klickt, öffnet sich ein Akkordeon und zeigt alle alphabetisch geordnet alle in diesem Blog bereits vorhandenen Tags. Nun kann man auf verschiedene Tags klicken, und diese Tags werden dann dem Blog hinzugefügt.
 
» Wenn es nun noch eine Option gäbe: User kann nur vorgegebene Tags verwenden, dann würde a nie angezeigt, sondern immer nur b (bereits aufgeklappt). Der User kann dann nur auf Tags (bzw. Kategorien) klicken, die im Adminmodus getaggt werden.
 
c) Einzelne Postings zu einem Portfolio hinzufügen
» Da wäre bei der Auflistung eine Vorschau sinnvoll.
» Und: Werden die Postings verknüpft oder kopiert oder ist beides möglich?
 
d) Benachrichtigung
» Heisst "gemäss Wiki und Forum": Mailbenachrichtigung?

ILIAS_LM, 2012-03-29 @lauener
 
To a)
As we defined the "repository" we meant the creation in every container object in the repository: Category, Folder, Course, Group.
The blog in working spaces is already defined.
 
To b)
We don't like the thought of a (possible) large accordion. If there must be a help (or soft restriction) so we suggest kind of autocomplete function of already used tags in that one blog.
But we don't think this will fit into our budget... Maybe in a next step?
 
To c)
Linking we consider as dangerous because an administrator could edit the content and change (without knowing it) the personal portfolio of another person. That's why we suggest only to copy the postings (without comments).
 
To d)
In a wiki it's possible to get notifications about a single page or the whole wiki. The same in a forum: Notification about single threads, the forum or single postings. This should be possible also in blogs. Status quo: I only can subscribe the whole blog and get notifications about a new posting and news comments. Wish: I can choose if I want to be notificated about the whole blog or only about the comments of single postings. || And to answer your question shortly: Yes, e-mail. ;-)
RSS: The RSS-functionality is already funded by University of Stuttgart. So it won't be a part of our specs.

ILIAS_LM, 30-03-2012 @lauener
 
Just to be sure: That second kind of notification is not included in the default ILIAS but is an ELBA-thing, isn't it? The notification settings I can find on our installations are only about membership-notifications...

lauener, 30-03-2012 @ILIAS_LM
 
That second kind of notification is INCLUDED in the default ILIAS !!
see: Administration » General settings » Cronjob » Daily Mail for Groups and Course News

ILIAS_LM, 2012-03-30 @lauener
 
Ah, interesting. Never seen, because we don't work with those cron-jobs. But you don't have to shout at me. ;-) We'll see what the PHTG (Sonja Burgauer) says about budget and implementation. Anyway: Thanks for bringing it up.

ILIAS_LM (2012-04-19) @JF:
 
About "Local Role"
Why we want a local role (as it already exists in forums > additional moderator)


Scenario:
We have a course with 40 members and want 10 different collaborative blogs. On each blog work 4 students.
If we have no local role but the course member's, everyone can mess around (intentionally and non).
 
You mentioned the learning modules. There we already have got the same problem. We always have to create a thousend of sub-groups (pain in the ass because there isn't yet a create-multiple-groups-option) to restrict the course member's write permissions on the learning modules, wikis, etc... And when the work is done we have to move all the learning modules in the course again (because now they are learning material to the others) and have to delete the (now) superfluous sub-groups. This sucks and eats a lot of time.
With the local role we only have to add the 4 members. Yey, less work!
 
> You see we would like to have – or let's face it: WANT – that local "moderation" role on other ILIAS-objects, like LMs or wikis, too. According to me it was a great invention you've done for the forums.

Oli Lang (2012-05-02): I think it is absolut necessary that there is a notification system for new posts/comments (like it is implemented in forums/wikis). The E-Mail notification is nice but not everyone wants to get the whole information about the course activities per mail if she/he is only interested in the progress of the blog. But if there is some money left for the implementation into the mail notification ... why not?
 
I also want to emphasize again the need of a local role. The scenario described by ILIAS_LM is widely used at the PHTG. There is no other solution as to work with sub-groups. With a local role it is possible to give only "write" permissions (create content) to some and read permissions to all course members.
 

Jürg Fraefel, Werner Willi PHZH (2012-05-09) For us is the contributor role important, as descripted form ILIAS_LM the administration work would reduced. As a second point we think, that we need this role, because we have scenarios in which the role of a contributor is essential.
In our most used scenario a lecturer (admin) creates for the students of his class normally several blogs. This blogs were used only from the member of the class. Each blog has 3 members (contributors), which can write the postings. The other students (student) of the class must have only the right to read the blogs. The scenario is only possible, if we have a local moderation role as ILIAS_LM mentioned.
To the question of public and private comments. We agree to the Core Team proposal. The private comments should be better called private feedback. According to the mentioned scenario the lecturer must be able to post public comments to the whole group and private feedbacks to a single student. All other students should have the right to make comments in all blogs of the class.

Oli Lang, 30 May 2012: We know about the possibility to create local roles but the ordinary course admins don't ;-) It’s not always easy for them to understand which permissions should be set in order to give the required rights.
The didactic templates could be a solution. The two scenarios mentioned by Matthias are very helpful. Perhaps one additional template could be: Collaborative blog for only a little group of students – all other users can’t see (and read) the blog. This is one of our favorite group work scenarios. (At the end of the semester the objects are opend in order to give read permissions for all course members). This scenario is currently implemented with closed groups (as already mentioned by Little). One question about the templates: If I change my first choosen template into an other (e.g. from collaborative blog with contributor role to collaborative blog for all) are the permissions automatically updated?
We (Rugy and I) had a little skype brainstorming. What about to install a member list at each (collaborative) object including the three roles admin, tutor and member (similar to the course permissions). By default the object permissions should be similar to the course permissions. But with the member list of the object it would be possible to break up with this setting and give only some course members special rights (a local role is no longer needed). The users know already this procedure from the course settings. E.g. the admin can change the permissions, etc., the tutor can write an read and the member can only read. The rights could be defined by the sys admins in the role templates.
What do you think?
 

ILIAS_LM, 2012-06-07:
 
I officially announce that the PHTG agrees with your suggestions from the 31 May 2012, Matthias Kunkel.
Even Bremen likes the idea of "didactic templates _and_ additional Contributor tab". Now we are waiting for an official statement from the PH Zürich...

Werner Willi, 2012-06-27:
 
We think, that it will be ok, with the idea of "didactic templates _and_ additional Contributor tab". We hope, that our ideas can realised with this technique. Go for it.

Matthias Kunkel, 19 Sep 2012: Blogs in the repository now have a tab "Contributors" (see notice by Jörg below). As far as I understand Jörg's posting every user with contribute permission that makes a posting (contributes) should be listed there. Additionally, I can add users to give them the contributor permission - if the general permissions for the blog do not allow this anyway. Is this correct? At the time being it seems that only users are listed that have been added to the contributor role manually.
 
The general question is: should this tab be only a list to manage users that are enrolled in the Contributor role. Or should it also be a kind of documentation about who is allowed to add blog postings - and who has already done this. If the second way is intended we should also add the number of postings for each user (similar to the "Statistics" of forums).

Sonja Burgauer, 19 Sept 2012: Sounds good, I'm looking forward to try it out :)

5 Implementation

JL 11 Sep 2012: A local role for contributors is added on creation of repository blogs. Blog "admins" (write-permission) can manage contributors in a separate tab. A "contributor" is anyone with the local contributor role, if there are any other roles with contribute permission this will be shown to avoid confusion.