Re: [eGroupWare-developers] E-Learning Project Definition

[<ac...@um...>]

On Tue, 30 Nov 2004 18:33:57 +0100 Drago Bokal
<dra...@fm...> wrote:

> In real applications all this will most probably be admins job.
> Even if this is just individual teacher's help, he will be an admin. To
define things in a group level is probably most useful.

I agree. In our case, there are some teachers looking for full control of
the configuration of their work area within the virtual campus, but some
others prefer to leave the task to admins.


> >I don't think the class should be treated as a user group in and of=20
itself.  I think it should be its own object, so to speak.  Belonging
to a class should neither give nor take away any priveleges from an eGW
user outside of the e-learning application...what do you think?
>
> I agree. This is also the way we implemented it in our Virtual
> university.

Well, I'm not fully aware of eGW ACL internals. Time ago we developed a
virtual campus application conceived mainly as a tool for teachers. The
teacher can create so many "work areas" as he wants. Each "work area" has
some helper tools as calendar, forums, glosary, file manager, chat rooms,
and so on. Restricting access is not mandatory, but if the
teacher owning the work area likes so, he can stablish an ACL for that
area importing the students list of a class (in a controlled format, of
course). After that setup, only the students in the ACL have
individual access to the students application modules for that work area:
contents, forums, file transfers, and so on.

Given that each module is an application by itself (with two components:
for the teacher and the student), we were thinking on the feasibility of
using eGroupWare as a general framework to put those modules. Sure, maybe
we would have to change some details in our apps behaviour to fit into eG=
W
logic, but on the other hand, we could benefit of all the features alread=
y
implemented on eGW. For this reason, we were figuring if the teacher coul=
d
share e.g. a Knowledge Base, a Calendar data or a Site within a restricte=
d
users list.

I do understand your vision, however, where the e-learning application
would stand by itself. If I'm right, in this approach the teacher would
have the eGW core tools mainly for personal use and all the e-learning
activity would be centered on the e-learning module, right?


Jeff said:

> >If we want to provide support for syncing students and teachers with=20
outside databases, that could be done in the future, but it's
> >probably more trouble than it's worth, with my reasoning being that I
don't forsee an entire university using eGroupWare.  I think it is
useful to individual professors...but I could be wrong :-)

Well, I think that both solutions could fit together. I agree that the
tool would be mainly a "teacher's helper" :-), and we see it in the same
way, but it wouldn't prevent to all the teachers from using it in the
whole university, as Drago says:-)


> > ATM I'll just assume that the students' accounts will be entered in b=
y
hand.

In that case, maybe this block of the app could be clearly
differentiated so that any other installation could modify it to fit othe=
r
requirements (in our case, maybe even making use of web services to get
the pertinent data from some external source (SQL, LDAP...))


> >Actually, this is one of the things I'm most worried about.  I don't
see a way to reconcile the access control needed here with the ACL
scheme used by many of the other eGW apps.  The only way I could forsee
it being done is if each class is treated as a group, and for that
group, you specify who has Teaching access, who has Teaching Assistant
access, etc...

This was what I was trying to say: some way to use the class as a group.
Given that users with higher permissions (i.e. Teaching Assistant) would
be only a few, you could define the "default" level for all entries as
Student, and then manually specify those with higher levels. But as I sai=
d
you, I don't have yet a full picture of eGW ACLs, so maybe I'm wrong...

In any case, all this looks as a nice project :-)


JA.