KDE Edu & KDE4

[Torsten Rahn (KDE)]

Am Donnerstag, 11. August 2005 04:40 schrieb George Wright:
> Given that discussions are now raging for KDE4 and how KDE should change
> for it, I would like to propose some changes for the KDE Edu module.
>
> In my opinion, the module is far too big and confusing. The compressed
> tarball for the module weighs in at a hefty 28MB; bigger than any of the
> other KDE application modules, which is a bit ridiculous.

While I think that of course we shouldn't ship redundant stuff it's important 
to note that the success Educational/Edutainment-Software relies very much on 
the user's experience. It's not just about the pure functionality the 
application delivers but also on the graphics and eyecandy that improves the 
motivation.

KDE-EDU has proved to be a widely successful project _because_ of:

- the broad offline functionality it delivers (which has been a critical 
factor for being chosen in projects like SkoleLinux, Edubuntu, etc.) 
This is even more important in countries where the Internet is barely 
existent. Follow the discussion in the EDU-area and you'll realize that just 
delivering "stubs/skelets" which download all the data using KHotNewStuff 
without delivering an appealing offline dataset  will reduce the number of 
KDE-EDU supporters by large. 

- the wide range of audience it targets. Yes it's true that KDE-EDU contains a 
mixture of pre-school software, High school Software, Edutainment Software 
and rather Scientific Software. But this makes it a more successful "showcar" 
 than putting each of them into its niche. It's a common procedure at linux 
events to just install KDE-EDU and just by doing it you have a wide range of 
software that appeals to the whole family. 

- because of it's game-items. If you look at the number of gtk-applications 
that were suggested for Edubuntu for example which had to compete with the 
respective KDE-EDU applications you'll realize that many KDE-EDU applications 
were chosen that had an edge over the gtk-version because of the 
"game-factor" that is perceived critically important for this kind of 
software.

> Of course, converting the graphics to SVG will really help in 
> this scenario,

.. but might not be a viable option in all cases. I agree e.g. that kgeography 
is rather inefficient in this respect but I am currently working on that 
problem.

I agree that we should try to squeeze the data as much as possible and deliver 
the biggest bang for the byte :-)  But not at expense of the quality and the 
experience which relies on the illustration of the software in terms of 
graphics and documentation.

On the other hand an average size of 4MB for an application isn't really 
"large" these days. It's not an aim to get all of this stuff on a 3.5" floppy 
disc after all ...

Sorry, but I feel that the measures you are suggesting if followed thoroughly 
will hurt one of KDE's most successful projects.

-- 
Mit freundlichen Grüßen / Kind regards,

        Torsten Rahn

--
Dipl.-Phys. Torsten Rahn, credativ GmbH
Karl-Heinz-Beckurts-Str. 13, 52428 Jülich, Germany
Tel.:  +49 (2461) 6907-91
Fax:   +49 (2461) 6907-11
Mobil: +49  (160) 7452624
Email: Torsten.Rahn at credativ.de
Mit freundlichen Grüßen / Kind regards,

        Torsten Rahn

-- 
Torsten Rahn <rahn at kde.org>
http://www.kde.org