[kde-edu]: KDE-Edu Vision Document

[Danny Allen]

Hi all,
Jeremy Whiting asked me to send my KDE Education Vision to the mailing list.

Keep in mind that this document is unfinished (it is really only a first 
draft), was written by me at Akademy 2005 in Malaga and has not been touched 
or looked at since then!

Danny

p.s. CC me on any replies to this thread.
-------------- next part --------------
KDE Education Project
A Blueprint For The Future
-------------------------------------

Our Purpose and Target Audience
-----------------------------------------------
To create the best educational software for users to enhance their learning, improve their skills, and nurture their creativity. Our target is typically users in the 3 to 18 age range, though we believe that anyone with an educational need will benefit from the tools that we provide.

There are two distinct environments for our software: in the home, and in educational institutions. These two areas overlap, whilst at the same time providing unique challenges that we have not yet identified, let alone started to solve.

The programs that are designed for younger children have traditionally been used more in the home, where a parent or other mentor uses the software in conjunction with other complimentary approaches to personally educate the user. This is contrasted with the applications aimed at more mature users, which have found use as tools within classrooms. There is currently a gap in our offerings in between these two extremes, in the "learning reinforcement" role.

In all these cases, our software has generally been a peripheral tool in the learning cycle. With the wholesale and accelerating move to computerised learning environments both in schools and the home, the design and functionality of our applications meets the possibility of becoming obsolete, especially when compared to our competiton throughout the computing world.


Current and Future Trends
-------------------------------------
Without remarking on wider computing trends, observations can be made about the rise of particular trends in computerised education:

* Focus on content
	- As a project, we are specialists in creating computer software to create learning experiences. However, we have not fully acknowledged the need for content for the applications that we create. In most cases, our programs are simply presentation devices for content: in these cases, we should therefore not expend so much effort only to fail at the final stage.

	Of course, we are not content creators - that specialism is suited to teachers...

* Internet connectivity
	- Let the experts of educational content creation - teachers - create the content for our apps, then maximise the impact of the collaborative revolution through internet connectivity. We need to embrace two main internet technologies in our applications (when it makes sense to do so):

	* Wikipedia Webservices
		For factual and technical information created by group efforts.
	* KHotStuff
		For compiled data and content directly created by single contributors (eg. teachers)

* Targeted learning
	- Computers are very good at collecting and analysing statistics. We should use this fact to implement facilities to track the progress of both individual users (students) and groups of users (classes), and intelligently provide lessons that will best help the student progress, whilst letting the teacher make best use of their time.

	These facilities will make our software ready for the classrooms of the future.

* Interactivity
	- Whilst often stated by technology advocates, the statement "technology brings lessons to life", especially in regard to lessons such as science and geography is almost an expectation from teachers and students alike.

	Computer programs are obviously interactive in nature. However, in many programs, this interactivity stops at the basic GUI level. We need to move to the next level, using graphics, colour and animation to present content that engages the user, whilst still supporting our users with somewhat outdated hardware.

	Young people learn by exploration and interaction: this is no different in the virtual world of the current generation than it is in the physical world.


Project Structure
-----------------------

As a project built on the efforts of volunteers, applications have been created that reflect each contributors specialism and interest in education. This decentralised nature has been portrayed as a weakness of our project structure, because of a lack of collective decision and vision. However, this way of working can easily be remoulded into a strength.

Education systems have an identical structure universally: their efforts are partitioned into several stages based on age. This allows them to meet the specific needs common to each group of students as they progress through the system. By adopting a structure similar to this, with semi-independent groups, effective intercommunication and unity under a common vision, we will enable our volunteer members to follow their passion and continue to do what they enjoy, whilst still working to the betterment of the entire project.

A classroom teaching 6 year olds will generally have no use for our advanced science applications, whilst mature students will not require our basic language aids. Currently, there is no real recognition within our project of this very important distinction.


There are typically 4 levels of education: 5-7, 7-11, 11-16 and 16+ - our project groups would be established following this base. This will enable us to understand and target our users much more effectively, and allow us to recognise the under-developed parts of our offerings. New and strengthed links will be forged with the front-line users of our software in schools.

The maintainers of specific applications know what is best for their application, and there is no doubt that they have the best understanding of the needs of their target audience. Therefore, these members will be entrusted to make decisions within their group. Issues that may affect the wider project can be communicated to other members for consideration. Much of this is already an established informal practice, and it works well. However, having a more formally understood process (whilst still retaining the organic flow that characterises the project) will help to remove some of the misunderstandings surrounding our work.

Any change to our structure will mainly affect internal project issues, as most of the recipients of our work - distributions - already package our software as individual packages.