New levels of visibility

New levels of visibility

by Guillaume Gautreau -
Number of replies: 8
Hi,

I'll work on new levels of visibility. I propose :
  1. Visible for all (already exists)
  2. Visible  for enrolled people & professors & creators & admins (already exists)
  3. Visible  for professors & creators & admins
  4. Visible for creators & admins
  5. Visible for admins
I propose to use the same way to manage these kind of visibility than it is currently the case : there is a field in the database for every course and every category named visibility.
However 0 and 1 are already assigned to points 2 and 1. In an idea of not changing the way it works, I'm tempted to use the numbers 2, 3 and 4.
In an idea of being easy to understand for developpers, I'm tempted to use 1 2 3 4 and 5 but it imply to change data in the database on install.
In order to be more scalable, I propose to use something like 1, 50, 100, 150, 200, 250. But I also need to change the codes.
Another code would be used to integrate groups in the future, to say it refers to a rights table for special rights.

Is there already someone tackling the issue ? Are you interested in this feature ?
What do you think about ?
Some advices ?

Average of ratings: -
In reply to Guillaume Gautreau

Re: New levels of visibility

by Miles Berry -
Very good idea. Like it, and would use it.

Even better, link it to the groups system within a course, so some activites could be visisble to one group of pupils and not to another, so as to allow for differentiated activites within a school setting.
In reply to Miles Berry

Re: New levels of visibility

by Guillaume Gautreau -
It can be usefull too, but I'm working on the categories and courses visibility. I think that it's completely another stuff to work on activities, because they are not managed as categories or courses.
In reply to Miles Berry

Re: New levels of visibility

by Vikram Solia -
Hi there!

I also second this approach for visibility based on groups because I think that would allow the same course to be a demo course as well as a full membership course by allowing limited resources / activities to the restricted demo course and do away the need for creating separate demo courses.

vikram solia
In reply to Guillaume Gautreau

Re: New levels of visibility

by John Papaioannou -
This sounds tempting for sure, but I have a few related questions and some reservations. While the idea sounds nice at first, the helpful people in these forums have taught me that in a project like Moodle, the developer of a feature will be about 0.000001% of the total Moodle population that will have to work with the feature. So I 've tried to think about a) if this feature is going to be really useful and b) what negative effects it might have. Here are the results...

1. It could be argued that option 3 already exists: unenrol everyone from the course or the courses inside the category, and you transform option 2 into 3.

2. If we accept that option 3 already exists by the above reasoning, then option 4 would be redundant in my opinion. Regarding a category, a non-creating teacher can do nothing in it so I can't see any harm in letting them know that the category exists. Regarding a course, even if the course is hidden normal access rules apply. Either the teacher is a teacher in this course and therefore should be able to see it even if it's hidden or he is not and therefore can be prevented from accessing the course using Moodle's existing features.

3. That leaves option 5. Admins would normally be technical, and not necessarily education-oriented staff. I would think that something "educational" like the structure of course categories and the courses themselves would be tackled by course creators. Even if in some scenario the admins are responsible for this, what is the benefit of hiding things from course creators?

4. We should remember that a Moodle feature with definite repercussions on everything is the "Roles" concept (there is a link to Martin's draft documentation somewhere but I can't seem to be able to find it at the moment). What you propose is to take an existing access control feature (on/off hiding) and make it more granular (several levels of it). However, Roles will effectively require all access-control-like features to be rewritten in a generalized way to take advantage of roles and their associated permissions.

This means that your work will become redundant when Roles are implemented, and any effort you put into it will lose its significance at that time. When faced with such a situation (my work will become redundant in X months' time), it's a good idea to ask: will it make enough of a difference during these X months to justify the development cost? In this case, my humble opinion is that it will not.

5. And finally, my favorite subject these days: the interface! How do you propose to construct the user interface for your idea? Remember that you are going to be "breaking" a global Moodle concept (the eye icon). Whatever interface is chosen, initially at least it will be unfamiliar to the users to some degree, and we have to be careful not to make bloated or confusing UIs. What do you propose?

Regards,
Jon

In reply to John Papaioannou

Re: New levels of visibility

by Janne Mikkonen -
Picture of Core developers
http://moodle.com/development/plans/roles.html

My thumbs up for roles and DMS.
In reply to Janne Mikkonen

Re: New levels of visibility

by Guillaume Gautreau -
Thanks for these answers.
I have now new questions regarding the roles :
  • For which version of moodle are the roles planned ?
  • Is there already someone working on it ?
In reply to John Papaioannou

Re: New levels of visibility

by Guillaume Gautreau -
Hi Jon, here are my ideas :

1. It could be argued that option 3 already exists: unenrol everyone from the course or the courses inside the category, and you transform option 2 into 3.

I don't think that it's a solution, because you can re-enrol people you unenrolled. Not very intuitive. This option can be useful for compulsory courses, when administration want to enrol all a group of student.

2. If we accept that option 3 already exists by the above reasoning, then option 4 would be redundant in my opinion. Regarding a category, a non-creating teacher can do nothing in it so I can't see any harm in letting them know that the category exists. Regarding a course, even if the course is hidden normal access rules apply. Either the teacher is a teacher in this course and therefore should be able to see it even if it's hidden or he is not and therefore can be prevented from accessing the course using Moodle's existing features.

Even if we consider the option 3 exists (which is not the case for me), I think that the option 4 is not redundant, because I don't speak about doing something in the course, but seeing it. It's actually not harm to let them see the course, but our school need to hide some courses to future teachers, and I suppose we are not alone.
In fact, we need to prepare some courses during a semester, when others are effective. Teachers don't have to see future courses when they're just prepared by creators.

3. That leaves option 5. Admins would normally be technical,  [...].

I agree with you. In a way to have levels of visibility, I supposed that I had to consider all the different possibilities.

Regarding the roles, I ignored they were planned. Thanks for the information, but I would like to know where I could get this kind of information. I asked some things in another post.

5. And finally, my favorite subject these days: the interface! How do you propose to construct the user interface for your idea? Remember that you are going to be "breaking" a global Moodle concept (the eye icon). Whatever interface is chosen, initially at least it will be unfamiliar to the users to some degree, and we have to be careful not to make bloated or confusing UIs. What do you propose?

I have to possibilities in fact, but in the two I have a select form to choose the level of visibility. We will also use different text-colors  and selected options by default in the menu to inform the editor on the selected option.
  1. We decide to let the traditionnal interface with the eye, used only to switch between options 1 and 2. Then, the select form is considered as an advanced editor tool.
  2. We use informative icons (non-clickable), probably something like :
    1. An earth with people.
    2. A group of people.
    3. A group of people with hat (don't know the word for the hat used by graduated in US).
    4. A person with this hat.
    5. A person with a key.
I have no preference between the two.
In reply to Guillaume Gautreau

Re: New levels of visibility

by Bhupinder Singh -

Hi,

Such a feature sounds great from the functional perspective.