D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG]: [ECDL] Re: easing the task



On Tue, 2003-09-30 at 10:17, martin.gautier@xxxxxxxxxxxxx wrote:

> One thing that is apparent from the threads so far is the varying 
> interpretations of the ECDL syllabus. I think we need to clarify what 
> we're aiming at here.
> 
> >From my existing experience & involvement with ECDL, I see it as basically 
> platform independent material aimed firmly as computer *users* (as opposed 
> to hobbyists, techies etc.), it's just that existing Courseware authors 
> have chosen Windows as a basis. I've personally been involved in writing 
> both Win9x/Office 97 based Content and WinXP/Office XP Content. From a 
> Linux point of view, we need to think from the *user's* perspective. They 
> will be sat at a Linux computer that's running any combination of Distro, 
> kernel and Desktop. A user will not be interested in console methods or 
> varying distro pros/cons - they just want to use the inteface with a 
> mouse. On that basis we'll need to cater for either Gnome, KDE or both - 
> I'd suggest both.

 & On Mon, 2003-09-29 at 22:28, Terence McCarthy wrote:
> However, the problem as I see it without further checking, is that of
> deciding which OS programmes we aim to use (i.e. produce
> teaching/learning materials for) to meet the ECDL requirements.
> 
> The ECDL assume people use Windows and Office- so it's clear and easy
> for them to implement within the vagaries of different Windows and
> Office versions e.g. ECDL using XP & Office 2000.
> 
> We FSF/OS types tend to look at a requirement and select the software
> that (a.) will do the job, and (b.) we like, as there will often be
> several programmes that will do (a.).
> 
> This means that we will need to ensure that ECDL concentrates on the
> problem to be set/solved, and its solution, and not upon how the
> solution is derived. This may require (again bear in mind this is
> after a good night out, and without checking sources) persuading the
> powers that be that the requirement is to demonstrate mastery in a
> choice of ANY GIVEN OS ENVIRONMENT, AND ANY GIVEN SET OF ADDITIONAL
> PACKAGES. (Sorry, not shouting but emphasising!)...
> 

I think this relates back to Adrian' s point about underlying
principles. For instance one of the requirements is to learn how to
minimise and maximise windows - when I looked at this it became
immediately apparent that there are many ways of doing this - varying
between window managers, and even between themes on the same window
managers. I do not believe this should be seen as a problem - rather as
an opportunity for smart thinking. The correct way to teach this is to
teach the concepts of minimising and maximising, the ways this can be
achieved (clicking on buttons etc) and teaching through example e.g.
look at the following illustrations. Can you identify which buttons do
what function?

Giving people the tools to learn, by teaching principles and
concepts,and by practical example and experience, rather than aiming for
mechanical reproduction of knowledge, has the advantage of both being
much closer to the unix/free software spirit and also, in my experience
at least, being the *only* way to teach well - regardless of peoples
aptitude or ability - it has been as true for the people who I had to
spend a whole day teaching how to use a mouse[1] as for the people who
could and did rush off by themselves.

All this said I want to make three further points.

1. I do think, in the first instance, at least we need to agree on a
common set of software we will focus on e.g. Gnome/KDE/Open Office.

2. We should treat the ECDL as what needs to be known rather than what,
or how it is taught.

3. None of this need preclude anything else.

I can see a situation where somebody might wish to build on the work we
do to create a basic introduction to the command line for example, using
it a a guide to 'what should be taught'. One of the exciting things for
me, is that my using free/software/open source methodologies and licence
styles we can potentially gain something similar to all the advantages
they have over other methods of software production. e.g. re-usability.
I certainly think it would be useful to aim to produce something that
could be readily adapted and bundled by Debian as a beginners guide if
if our focus is solely on the ECDL.   

> Which brings me neatly to authoring methods. I've mentioned XML/Docbook 
> before and it sounds like people understand the reasons why that's a good 
> idea. I would like to mention now though, a feature of Docbook that allows 
> the management of "dual" Content (ie. Gnome specific and KDE specific 
> content) in the same source XML.

This would be a very useful. I think it is important to distinguish,
however, between final output for which Docbook seems a highly
appropriate format and our own internal materials for which it should be
a case of if the cap fits... If only because I, for one, will have to go
away and learn how to use Docbook and I think there are useful I could
do in the mean time using existing and familiar tools - wiki's, amiling
lists etc.   

> Although ECDL is modular, there is a need to ensure that the overall 
> material flows logically - it's not just a matter of setting questions & 
> answering them. This will require a degree of discipline, firm 
> organisation and (controversially?) a single "editor-in-chief" to pull all 
> the content together and well, edit it.

I certainly agree see point 2 above. Again though I think we can learn
usefully from existing models when it comes to how we go about this.

> I guess that's my input for item 3 (above).
> 
> For items 1 and 4, I'd suggest setting up a project at Sourceforge, that 
> way we automatically open it up for attracting more authors and has the 
> benefit of using CVS to handle files which will be a boon if large numbers 
> of people are contributing asyncronously.

I was thinking along similar lines although we should perhaps exercise a
little caution as to when, bearing in mind Simons note of caution. All
in good time me thinks.

> 2. Let's get the technical/infrastructure stuff sorted first. We can soon 
> dive into the actual creative stuff soon enough. It's important the 
> background project management is sorted first though.

The project management is probably the most important thing, certainly
in terms of making it sustainable. As far as the other things go while I
certainly think we will need to agree on a common set of standards we
should allow for a certain amount of flexibility and organic growth.
Certainly we don't want to get bogged down in it or allow it ot become a
barrier to entry.

> Item 5 should be Licensing. ie. What sort of license is best? 

My personal preference is for the Creative Commons Share Alike Licence. 
http://creativecommons.org/licenses/sa/1.0/ which allows for free
adaption, redistribution, and use (as well as commercial use) with a GPL
like clause stating that redistributed changes must be made available
under simimlar conditions. It is perhaps less restrictive than the GDFL.


Paul M

[1] Actually there's an easy solution to this - playing solitaire (or
Aisleriot).But it was a very important lesson for me - the problem I
faced, time and time again , in teaching people who had *never* touched
a computer before was that they were terrified of them. That in turn
lead to the muscles in their hand and arm tightening up - and its
impossible to use a mouse in this condition (try it). Getting them to
play solitaire was getting them to do something they already knew how to
do - so no fear- and all I had to do was get them started and then
wander and drink tea. When I came  back an hour or so later they had
already taught themselves without even realising it.     

> --



--
The Mailing List for the Devon & Cornwall LUG
Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the
message body to unsubscribe.


Lynx friendly