Diskussion:Klips - Versionsgeschichte

UW: /* ATutor + ??? */

2010-04-27T20:37:21Z

ATutor + ???

← Nächstältere Version		Version vom 27. April 2010, 22:37 Uhr
Zeile 65:		Zeile 65:
	=== ATutor + ??? ===		=== ATutor + ??? ===

	Da wir mit ATutor sehr gute Erfahrungen gemacht haben, wollen wir ausprobieren, welches CMS gut mit ATutor zusammengehen kann und Barrierefreiheit ernst nimmt. Ein guter Einstieg wäre natürlich ein CMS für das es bereits eine Brücke zu ATutor gibt. Dies sind derzeitig vier: CMS made easy, Drupal, Joomla und PostNuke. Warum wir CMS made easy auf die Warteliste gesetzt haben, schrieb ich oben. Die Weiterentwicklung von PostNuke ist eingestellt (die Entwickler arbeiten an einem anderen CMS). Bleiben also Drupal und ~~Jommla~~. Von beiden haben wir ja in Frankfurt/Main gehört, dass sie bereits im VIP-Bereich (VIP = visually impaired person) in Deutschland eingesetzt werden.		Da wir mit ATutor sehr gute Erfahrungen gemacht haben, wollen wir ausprobieren, welches CMS gut mit ATutor zusammengehen kann und Barrierefreiheit ernst nimmt. Ein guter Einstieg wäre natürlich ein CMS für das es bereits eine Brücke zu ATutor gibt. Dies sind derzeitig vier: CMS made easy, Drupal, Joomla und PostNuke. Warum wir CMS made easy auf die Warteliste gesetzt haben, schrieb ich oben. Die Weiterentwicklung von PostNuke ist eingestellt (die Entwickler arbeiten an einem anderen CMS). Bleiben also Drupal und Joomla. Von beiden haben wir ja in Frankfurt/Main gehört, dass sie bereits im VIP-Bereich (VIP = visually impaired person) in Deutschland eingesetzt werden.

	Sicherlich werden wir beide in Kombination mit ATutor testen. Doch welches zuerst. Die Antwort war relativ schnell gefunden. Für Drupal gibt es eine Accessibility-Gruppe (http://groups.drupal.org/accessibility), sie behaupten WCAG- und ATAG-Kompatibilität (das erste Barrierefreiheit für die Leser, das zweite für die Autoren) und scheinen derzeit an der ARIA-Implementierung dran zu sein (dass ist der dritte W3C-Standard bezüglich der Barrierefreiheit, der hier infrage kommt und dem Screenreader-Nutzer zusätzliche Navigationsmöglichkeiten schafft, wird noch nicht von allen Screenreadern unterstützt). Anders die Barrierefreiheit bei Joomla. Sie bleibt dort ein Versprechen (siehe: [http://help.joomla.org/content/view/805/125/ Accessibility-Statement]). Was nicht heißt, dass dort nicht auch an der Barrierefreiheit gearbeitet wird [http://community.joomla.org/blogs/community/1005-status-of-accessibility-in-the-joomla-backend.html (1)].		Sicherlich werden wir beide in Kombination mit ATutor testen. Doch welches zuerst. Die Antwort war relativ schnell gefunden. Für Drupal gibt es eine Accessibility-Gruppe (http://groups.drupal.org/accessibility), sie behaupten WCAG- und ATAG-Kompatibilität (das erste Barrierefreiheit für die Leser, das zweite für die Autoren) und scheinen derzeit an der ARIA-Implementierung dran zu sein (dass ist der dritte W3C-Standard bezüglich der Barrierefreiheit, der hier infrage kommt und dem Screenreader-Nutzer zusätzliche Navigationsmöglichkeiten schafft, wird noch nicht von allen Screenreadern unterstützt). Anders die Barrierefreiheit bei Joomla. Sie bleibt dort ein Versprechen (siehe: [http://help.joomla.org/content/view/805/125/ Accessibility-Statement]). Was nicht heißt, dass dort nicht auch an der Barrierefreiheit gearbeitet wird [http://community.joomla.org/blogs/community/1005-status-of-accessibility-in-the-joomla-backend.html (1)].

UW: /* ATutor + ??? */

2010-04-27T20:36:31Z

ATutor + ???

← Nächstältere Version		Version vom 27. April 2010, 22:36 Uhr
Zeile 67:		Zeile 67:
	Da wir mit ATutor sehr gute Erfahrungen gemacht haben, wollen wir ausprobieren, welches CMS gut mit ATutor zusammengehen kann und Barrierefreiheit ernst nimmt. Ein guter Einstieg wäre natürlich ein CMS für das es bereits eine Brücke zu ATutor gibt. Dies sind derzeitig vier: CMS made easy, Drupal, Joomla und PostNuke. Warum wir CMS made easy auf die Warteliste gesetzt haben, schrieb ich oben. Die Weiterentwicklung von PostNuke ist eingestellt (die Entwickler arbeiten an einem anderen CMS). Bleiben also Drupal und Jommla. Von beiden haben wir ja in Frankfurt/Main gehört, dass sie bereits im VIP-Bereich (VIP = visually impaired person) in Deutschland eingesetzt werden.		Da wir mit ATutor sehr gute Erfahrungen gemacht haben, wollen wir ausprobieren, welches CMS gut mit ATutor zusammengehen kann und Barrierefreiheit ernst nimmt. Ein guter Einstieg wäre natürlich ein CMS für das es bereits eine Brücke zu ATutor gibt. Dies sind derzeitig vier: CMS made easy, Drupal, Joomla und PostNuke. Warum wir CMS made easy auf die Warteliste gesetzt haben, schrieb ich oben. Die Weiterentwicklung von PostNuke ist eingestellt (die Entwickler arbeiten an einem anderen CMS). Bleiben also Drupal und Jommla. Von beiden haben wir ja in Frankfurt/Main gehört, dass sie bereits im VIP-Bereich (VIP = visually impaired person) in Deutschland eingesetzt werden.

	Sicherlich werden wir beide in Kombination mit ATutor testen. Doch welches zuerst. Die Antwort war relativ schnell gefunden. Für Drupal gibt es eine Accessibility-Gruppe (http://groups.drupal.org/accessibility), sie behaupten WCAG- und ATAG-Kompatibilität (das erste Barrierefreiheit für die Leser, das zweite für die Autoren) und scheinen derzeit an der ARIA-Implementierung dran zu sein (dass ist der dritte W3C-Standard bezüglich der Barrierefreiheit, der hier infrage kommt und dem Screenreader-Nutzer zusätzliche Navigationsmöglichkeiten schafft, wird noch nicht von allen Screenreadern unterstützt). Anders die Barrierefreiheit bei ~~Jommla~~. Sie bleibt dort ein Versprechen (siehe: [http://help.joomla.org/content/view/805/125/ Accessibility-Statement]). Was nicht heißt, dass dort nicht auch an der Barrierefreiheit gearbeitet wird [http://community.joomla.org/blogs/community/1005-status-of-accessibility-in-the-joomla-backend.html (1)].		Sicherlich werden wir beide in Kombination mit ATutor testen. Doch welches zuerst. Die Antwort war relativ schnell gefunden. Für Drupal gibt es eine Accessibility-Gruppe (http://groups.drupal.org/accessibility), sie behaupten WCAG- und ATAG-Kompatibilität (das erste Barrierefreiheit für die Leser, das zweite für die Autoren) und scheinen derzeit an der ARIA-Implementierung dran zu sein (dass ist der dritte W3C-Standard bezüglich der Barrierefreiheit, der hier infrage kommt und dem Screenreader-Nutzer zusätzliche Navigationsmöglichkeiten schafft, wird noch nicht von allen Screenreadern unterstützt). Anders die Barrierefreiheit bei Joomla. Sie bleibt dort ein Versprechen (siehe: [http://help.joomla.org/content/view/805/125/ Accessibility-Statement]). Was nicht heißt, dass dort nicht auch an der Barrierefreiheit gearbeitet wird [http://community.joomla.org/blogs/community/1005-status-of-accessibility-in-the-joomla-backend.html (1)].

	Ergo wir beginnen mit ATutor + Drupal. Bin gespannt was herauskommt.		Ergo wir beginnen mit ATutor + Drupal. Bin gespannt was herauskommt.

UW: /* Installationsprobleme bei PHP 5.3 */

2010-04-27T20:35:01Z

Installationsprobleme bei PHP 5.3

← Nächstältere Version		Version vom 27. April 2010, 22:35 Uhr
Zeile 48:		Zeile 48:
	===Installationsprobleme bei PHP 5.3===		===Installationsprobleme bei PHP 5.3===

	Auch Papoo (bei mir die Version Papoo Light 3.7.5) hat Probleme mit PHP 5.3. Die auf der [http://www.papoo.de/cms-produkte/free-cms-download-version/#php53 Papoo-Seite] angegebene Lösung für das Problem hat bei mir nicht geholfen.		Auch Papoo (bei mir die Version Papoo Light 3.7.5) hat Probleme mit PHP 5.3. Die auf der [http://www.papoo.de/cms-produkte/free-cms-download-version/#php53 Papoo-Seite] angegebene Lösung für das Problem hat bei mir nicht geholfen. Allerdings bleiben einige der Installationsprobleme auch, wenn ich ein älteres PHP nehme.

	===Nutzerfreundlichkeit (Usability)===		===Nutzerfreundlichkeit (Usability)===

UW: Papoo

2010-04-27T14:43:22Z

Papoo

← Nächstältere Version		Version vom 27. April 2010, 16:43 Uhr
Zeile 49:		Zeile 49:

	Auch Papoo (bei mir die Version Papoo Light 3.7.5) hat Probleme mit PHP 5.3. Die auf der [http://www.papoo.de/cms-produkte/free-cms-download-version/#php53 Papoo-Seite] angegebene Lösung für das Problem hat bei mir nicht geholfen.		Auch Papoo (bei mir die Version Papoo Light 3.7.5) hat Probleme mit PHP 5.3. Die auf der [http://www.papoo.de/cms-produkte/free-cms-download-version/#php53 Papoo-Seite] angegebene Lösung für das Problem hat bei mir nicht geholfen.

			===Nutzerfreundlichkeit (Usability)===

			Auf den ersten Blick ist Papoo deutlich einfacher zu bedienen als Drupal. Würde ich bei Drupal empfehlen, erstmal (fast) alles abzuschalten, um das System verstehen zu lernen, ist dies hier nicht nötig.

			Menschen, die die Addition und Subtraktion bis 100 nicht beherrschen, können in diesem System nichts schreiben (so ist hier nämlich die Captcha-Problem für Blinde barrierefrei gelöst).

			Leider kommt man an die Sprachdateien für die Oberfläche nur mit großem Aufwand heran, so dass man bei der Verbesserung der Rechtschreib- und Tippfehler auf der Oberfläche und bei der Enttechnisierung der Sprache (Stichwort: einfache Sprache) mit den Entwicklern zu verhandeln haben wird. Ob die Sprach-Plugins, sie liegen Papoo Light nicht bei, da helfen, sollte man vor dem Kauf irgendwie prüfen.

			Das Standard-CSS ist an einigen Stellen unglücklich gewählt (so rutschen bei mir Zeilen ineinander und die von der Seite vorgesehene Vergößerung funktioniert nicht), aber das CSS würde man ja ehe überarbeiten, bevor man das Programm in einer Schule einsetzt.

	--[[Benutzer:UW\|UW]] 15:28, 27. Apr. 2010 (CEST)		--[[Benutzer:UW\|UW]] 15:28, 27. Apr. 2010 (CEST)

UW am 27. April 2010 um 13:28 Uhr

2010-04-27T13:28:06Z

← Nächstältere Version		Version vom 27. April 2010, 15:28 Uhr
Zeile 30:		Zeile 30:
	Die Installation von Drupal 6.16 ist aufwendiger als erwartet.		Die Installation von Drupal 6.16 ist aufwendiger als erwartet.

	Statt einer leeren settings.php ~~koppiert~~ man lieber die Datei default.settings.php zu settings.php.		Statt einer leeren settings.php kopiert man lieber die Datei default.settings.php zu settings.php.

	Die Version ist entgegen den Angaben auf der [http://drupal.org/requirements Drupal-Seite] nicht mit PHP 5.3 kompatibel.		Die Version ist entgegen den Angaben auf der [http://drupal.org/requirements Drupal-Seite] nicht mit PHP 5.3 kompatibel.
Zeile 41:		Zeile 41:

	--[[Benutzer:UW\|UW]] 21:17, 26. Apr. 2010 (CEST)		--[[Benutzer:UW\|UW]] 21:17, 26. Apr. 2010 (CEST)

			==Papoo==

			[http://www.papoo.de Papoo] ist deutsches kommerzielles CMS, dass sich die Barrierefreiheit auf die Fahnen geschrieben hat. Ein großer Pluspunkt natürlich.

			===Installationsprobleme bei PHP 5.3===

			Auch Papoo (bei mir die Version Papoo Light 3.7.5) hat Probleme mit PHP 5.3. Die auf der [http://www.papoo.de/cms-produkte/free-cms-download-version/#php53 Papoo-Seite] angegebene Lösung für das Problem hat bei mir nicht geholfen.

			--[[Benutzer:UW\|UW]] 15:28, 27. Apr. 2010 (CEST)

	== ATutor ==		== ATutor ==

UW: /* Installationsprobleme */

2010-04-26T19:21:19Z

Installationsprobleme

← Nächstältere Version		Version vom 26. April 2010, 21:21 Uhr
Zeile 26:		Zeile 26:
	==Drupal==		==Drupal==

	===Installationsprobleme===		===Installationsprobleme bei PHP 5.3===

	Die Installation von Drupal 6.16 ist aufwendiger als erwartet.		Die Installation von Drupal 6.16 ist aufwendiger als erwartet.

UW: +Drupal-Installationsprobleme bei PHP 5.3

2010-04-26T19:17:35Z

+Drupal-Installationsprobleme bei PHP 5.3

← Nächstältere Version		Version vom 26. April 2010, 21:17 Uhr
Zeile 23:		Zeile 23:

	--[[Benutzer:UW\|UW]] 07:21, 25. Apr. 2010 (CEST)		--[[Benutzer:UW\|UW]] 07:21, 25. Apr. 2010 (CEST)

			==Drupal==

			===Installationsprobleme===

			Die Installation von Drupal 6.16 ist aufwendiger als erwartet.

			Statt einer leeren settings.php koppiert man lieber die Datei default.settings.php zu settings.php.

			Die Version ist entgegen den Angaben auf der [http://drupal.org/requirements Drupal-Seite] nicht mit PHP 5.3 kompatibel.

			Deshalb sollte man bei Verwendung von PHP 5.3 in die settings.php die Zeile

			ini_set('error_reporting', 4096);

			in den ini_set-Bereich einfügen.

			--[[Benutzer:UW\|UW]] 21:17, 26. Apr. 2010 (CEST)

	== ATutor ==		== ATutor ==

UW: /* ATutor + Drupal */

2010-04-26T19:14:30Z

ATutor + Drupal

← Nächstältere Version		Version vom 26. April 2010, 21:14 Uhr
Zeile 39:		Zeile 39:
	=== ATutor + Drupal ===		=== ATutor + Drupal ===

	Beim genaueren Hinsehen musste ich feststellen, dass die Brücke zwischen ATutor und Drupal praktisch unbrauchbar ist. Das hat vor allem den Grund, dass das Brückenmodul ~~auf~~ eine alte Version von Drupal unterstützt. Außerdem funktioniert mit diesem Modul der Einschreibemanager nicht mehr. Die Brücke müsste also neu geschrieben werden (oder man arbeitet ohne Brücke mit all den Nachteilen des doppelten Registrierens und Logins).		Beim genaueren Hinsehen musste ich feststellen, dass die Brücke zwischen ATutor und Drupal praktisch unbrauchbar ist. Das hat vor allem den Grund, dass das Brückenmodul eine alte Version von Drupal unterstützt. Außerdem funktioniert mit diesem Modul der Einschreibemanager nicht mehr. Die Brücke müsste also neu geschrieben werden (oder man arbeitet ohne Brücke mit all den Nachteilen des doppelten Registrierens und Logins).

	--[[Benutzer:UW\|UW]] 13:02, 25. Apr. 2010 (CEST)		--[[Benutzer:UW\|UW]] 13:02, 25. Apr. 2010 (CEST)

UW: /* Zukunftssicherheit von CMS made easy */

2010-04-25T12:24:00Z

Zukunftssicherheit von CMS made easy

← Nächstältere Version		Version vom 25. April 2010, 14:24 Uhr
Zeile 16:		Zeile 16:
	Viele Grüße aus Waldkirch, ''Joachim''		Viele Grüße aus Waldkirch, ''Joachim''

	===Zukunftssicherheit von CMS made ~~easy~~===		===Zukunftssicherheit von CMS made simple===

	Da wir ATutor nutzen habe ich geschaut für welche CMS es Brücken zu ATutor gibt. Eines davon ist CMS made easy. Was mich bei diesem System vorsichtig macht, ist, dass es im wesentlichen von einem Entwickler in seiner Freizeit programmiert wird. Was passiert, wenn er aussteigt? Zukunftssicherheit scheint uns ein wichtiges Kriterium bei der Wahl eines Systems.		Da wir ATutor nutzen habe ich geschaut für welche CMS es Brücken zu ATutor gibt. Eines davon ist CMS made easy. Was mich bei diesem System vorsichtig macht, ist, dass es im wesentlichen von einem Entwickler in seiner Freizeit programmiert wird. Was passiert, wenn er aussteigt? Zukunftssicherheit scheint uns ein wichtiges Kriterium bei der Wahl eines Systems.

UW: /* ATutor + Drupal */

2010-04-25T11:02:04Z

ATutor + Drupal

← Nächstältere Version		Version vom 25. April 2010, 13:02 Uhr
Zeile 40:		Zeile 40:

	Beim genaueren Hinsehen musste ich feststellen, dass die Brücke zwischen ATutor und Drupal praktisch unbrauchbar ist. Das hat vor allem den Grund, dass das Brückenmodul auf eine alte Version von Drupal unterstützt. Außerdem funktioniert mit diesem Modul der Einschreibemanager nicht mehr. Die Brücke müsste also neu geschrieben werden (oder man arbeitet ohne Brücke mit all den Nachteilen des doppelten Registrierens und Logins).		Beim genaueren Hinsehen musste ich feststellen, dass die Brücke zwischen ATutor und Drupal praktisch unbrauchbar ist. Das hat vor allem den Grund, dass das Brückenmodul auf eine alte Version von Drupal unterstützt. Außerdem funktioniert mit diesem Modul der Einschreibemanager nicht mehr. Die Brücke müsste also neu geschrieben werden (oder man arbeitet ohne Brücke mit all den Nachteilen des doppelten Registrierens und Logins).

			--[[Benutzer:UW\|UW]] 13:02, 25. Apr. 2010 (CEST)