Forums | Mahara Community

Developers /
Developing Features for Schools


anonymous profile picture
Deleted user
Posts: 18

13 October 2009, 7:10 AM

Hi All,

Some months ago we ran a pilot Mahara install with about 20 schools in CLEO in the UK. The outcome of this work was mostly inline the school related work which is mentioned on the Mahara roadmap, though some of our feedback was a little bit more draconian than the features there Wink.

We are now beginning to start work on the requests which have come out of our pilot. We are very keen to work with the community as much as possible to ensure what we implement can get merged if it fits with the mahara vision (we are aware that some of the features may be quite 'against the grain' of the mahara philosophy).

At this stage we are still doing initial exploratory work and gathering requirements (we are fairly new to mahara development and not particularly up to date with whats in 1.2).

 Here is a high level overview of the first few features (/restrictions!) we are looking at implementing:

Controlling Group Creation

When a student creates a group it has to go through some sort of approval by a member of instiutional staff/admins before it is made live.

Per institution front page

Schools would like the initial front page which users see when they log in to be customised by institution rather than globally (not sure if this can be achieved with institutional views at the moment?)

Wall and Messaging Disabled By Insitution

Some schools just don't want these features enabled.

Friendship Controls

Restrict friendships to a single institution and only institutional level friendships and allow institutional staff/admins to moderate other friendships.

I think we have two key questions at this early stage:

  • How to implement 'permissions' as a concept - this is the main focus of our work. Using the existing institution staff/admins seems like the place to do this, but does it make sense?
  • How to implement per-institution settings as some of the controls will need to apply at this level. It probably gets quite interesting considering that mahara is user rather than institution centric..
 
cheers,
Dan
anonymous profile picture
Deleted user
Posts: 1643

13 October 2009, 7:08 PM

Hiya Dan - good to see you again. I have a quick question for you before I answer - did you receive any feedback from these schools that would be able to be fed into the roadmap pages? I note you said "mostly inline", any other feedback you have would be most valuable Smile

Controlling Group Creation

This is actually a long asked for feature, although normally expressed as "Can we prevent students from creating groups?". There's no conflict with the pedagogical aims of Mahara to have such a feature, I feel - so code for it would be welcome. You add another layer to that - the idea of approval. I like it - want to sketch up some mockups of how you think it would work? 

Per institution front page

Firstly, no this can not be achieved with institution views (which haven't changed in 1.2 btw). Institution views exist at the moment soley so that institutions can make templates for others to copy.

You touch on two things that the dev  team have bounced around as ideas from time to time:

  1. The idea that institutions currently are rather nebulous in the system, and it would be nice if they had a more concrete presence - e.g. through having their own pages that people can browse to, and being available to choose for view access.
  2. More things in the system should have pages, preferrably built with the View editor 
In other words - institution home pages are a good idea, and they should be implemented as Views Wink
 
However - there is a catch - we eventually want the homepage for users when they log in to be an actionable dashboard - not an institution homepage. Elements of this dashboard might be provided by the institution(s) the user is in, but mainly the dashboard will be about them.
 
So when it comes to code we would accept, things get a little woolly. It would be nice if institutions could use a View as a "homepage", but then we have to allow people to navigate to those somehow, etc. Ideas are welcome.
 
Wall and Messaging Disabled By Institution
 
From 1.2, the wall can be disabled on the site level. Messaging can't though.
 
I think these features would be useful. Take care - users can be in more than one institution. If the wall is enabled for one institution and disabled in the other, I guess the user should still get a wall.
 
I guess the best place for these settings is on each institution's edit screen, and institution admins should be able to set them.
 
Friendship Controls
 
Given that friendships don't really "mean" anything (e.g. two users who are friends don't all of a sudden get to see more about one another or see any of their stuff), what's the logic behind trying to restrict friendships? Not a criticism, I'm interested in the thinking behind it is all Smile
 
Actually, I think this is again touching on something else we've been thinking about - the ability to set up a walled garden within Mahara.
 
The friendship moderation is interesting... are institution staff/admins going to have time to do such a thing? I'm interested to see what screens/workflow you have in mind for this.
 
Your Questions
 
Mahara doesn't have an all encompassing permissions system like Moodle has, and to be honest I think this is a good thing. After watching the Catalyst Moodle team struggle day in and out with the performance headaches caused by it, and hearing horror stories from teachers, I'm not sure we want to go down that road Wink (having said that, I'm sure we could design a better one.. but right now I don't see the need).
 
We currently have a simple permission model, as you've spotted. Site admins tend to be able to do everything, institution admins can do most things to institutions.. etc. I think the stuff you've listed here will fit into that structure nicely Smile
 
Per institution settings will fit on the institution edit pages (Site Admin -> Manage Institutions -> pick one). Institution admins can set some of the settings on this page, not all of them. I think ones you've suggested above, like disabling the wall, would be settable by institution admins on this page. 
anonymous profile picture
Deleted user
Posts: 18

13 October 2009, 8:16 PM

Hey Nigel,

Thanks for the useful (and positive!) feedback, just a few comments about our thoughts from discussions today before I go to bed, I will follow up more tomorrow..

We were discussing the ideas around the various restrictions we've been tasked to do and talked more about what is trying to be achieved and think most of the tasks would fit into a 'walled garden' concept of institutions as you mention.  That is that an institution could elect to be a 'walled garden' where by the ideal is that a single institution functions as though its in its own personal Mahara instance. Users from this institution can only message/make friends/interact with other users in their own institution. Similarly users from other institutions can't interact with them.

Another option might be walled garden with approval process. That is that a user could only interact with people in their institution by default, but to make friends with a user from another institution it would need approving from their institutional administrator/staff. Obviously this would be rather complex and difficult to scale for big institutions, but I think the reasoning behind it is to allow cross-institution collaboration where this makes sense, without making mahara into the social network for the whole region (the question there is, who is going to monitor this?).

So we were thinking of 3 'levels' of institution interaction settings:

  • Open (as now)
  • Walled garden (can interact with everyone in your institution)
  • Walled garden (can interact with everyone in your institution) with approval process for users in different institutions.

With regard to restrictions which apply to a user in multiple institutions, we had the same thought as you -  the most privileges you have in an institution wins. How to make this scale is another question!

But there are also the big caveats of non-insitution things like groups.. How does a walled garden control access to that? 

Dan 

anonymous profile picture
Deleted user
Posts: 1643

13 October 2009, 9:37 PM

Hi Dan,

The other thing we have been thinking about in terms of walled gardens is, allow these institutions to interact with those institutions only. So say you have institutions A, B, C, D, E, F:

  • A can't see anyone
  • B and C want to just see each other
  • D, E and F haven't set any preference so they can all see each other - but they can't see A, B and C as they have their own walled gardens.
 
The approval process stuff.. I smell complexity that I think you're right about regarding scaling it. With two thousand students per institution, who is going to care when user X wants to be friends with user Y from another institution? It'll be a very unused function, I think. Feel free to correct that assumption though Wink
 
Your point about groups, well that's interesting too. Groups aren't attached to institutions. It might well be that we have to attach them - at least for ones that students create. This would need some careful thinking about. 

 

Dirk Meyer's profile picture
Posts: 425

14 October 2009, 12:39 AM

Rather than controlling interaction between entire institutions I would probably prefer a mechanism to control interaction based on age or grade level. We have some 1-12 school, 1-6, 6-8 and 10-12 schools. I suppose one could create several institutions within a school and segregate based on age that way.
anonymous profile picture
Deleted user
Posts: 1643

14 October 2009, 1:31 AM

I guess the issue with that is that you have to know how old everyone is, which Mahara doesn't ask for right now Smile. Institutions would work for your case I think, I guess the school's staff and admins would have to be staff/admins in all of those institutions.
anonymous profile picture
Deleted user
Posts: 18

14 October 2009, 5:26 PM

Hmm, having arbitrary groups of users in "walled gardens" which don't have a direct mapping to institutions really does add complexity, if it was an arbitrary list of  users which could cross institutions, you'd need a user to administer that walled garden (rather than say, the institution admin). There would also need to be a good way to decide who was in what garden, a simple way to add users and keep them in sync etc.

anonymous profile picture
Deleted user
Posts: 18

14 October 2009, 5:48 PM

Wall and Messaging Disabled By Institution
We had a bit of a play with this today and thought of generalising this into something along the lines of 'disabling plugin by institution' might be more useful.
 
There would be some sort of UI for disabling plugins at an institution level which would populate an institution disabled plugins table. We made a little proof of concept which disabled blocks from being available depending on the institution.
 
The db table was:
institution_disabled_plugins 
institution  plugin
 a blog
 awall 
 bwall 
 bexternalfeed 

 

 

 

 

 

 

 

User bob was in institution a and b and because these plugins  are disabled in both his institutions, the wall block was unavailable for him, whilst the externalfeed and blog were still available because they were not blocked in both institutions.

Then we realised that sending a message to another user is not a plugin and so is this sort of approach overkill?

anonymous profile picture
Deleted user
Posts: 1643

14 October 2009, 10:06 PM

Well I don't think that the data model is a bad idea. It's a nice structured way to store enabled/disabled information on a per institution basis. I guess one thing it brings up is whether the admin sets it, or the institutional admin can. I can see circumstances where the site admin might not want the institution admins to set a plugin on and off. But I guess that's a lesser use case than the default, which would be to allow institution admins to do that themselves.

Despite it being overkill for you, I think upstream we'd be interested in it being implemented this way, plus adding a way for institutions to turn all plugins off of course. If this was too much work for you guys, then you could easily hack in a checkbox on the institution edit screen to control the wall (& messaging).

Messaging is interesting because it's not a plugin. I think whether you do plugins nicely or not, you're gonna need custom code for that..

We discussed walled gardens in IRC, and came up with a proof-of-concept data model for it. As discussed, this would be a lot of work to implement - however there's interest in this from more than just you guys. You might want to liase with Richard Wyles about this, he's talked on and off about us doing this for some time.

9 results