User talk:Lulu-Ann/lalm

Format

Persönlich mag ich dieses Tabellenformat nicht, weil es im Wiki blöd zu bearbeiten und im Einzelfall unflexibel ist. Ich wäre für Abschnitte für die einzelnen Anforderungen.

Insbesondere die Remarks-Spalte ist für meinen Geschmack zu klein, um ernsthaft darin etwas zu tun. --Jongleur 20:20, 13 December 2010 (UTC)

Fußgänger-Routing: Sicherste Route

Hier sind die Anforderungen an Sicherheit für Blinde ganz andere als für Menschen z.B. im Rollstuhl. Sicherheit ist deshalb nur im Rahmen des Portals eindeutig (oder zumindest deutlich) definiert.

Ich befürchte, diese Routing-Funktionalität wird sich kaum von anderen Routern ohne weiteres verwenden lassen. --Jongleur 20:20, 13 December 2010 (UTC)

Die Sicherheits-Bewertung wird eine Reihenfolge haben wie:

1. Blindenampel,
2. normale Ampel,
3. Zebrastreifen,
4. ungesicherte Querung mit Verkehrsinsel oder nur ein Fahrstreifen zu queren,
5. ungesicherte Querung über mehrere Fahrstreifen

Das sollte mit Ausnahme der ersten beiden Punkte für alle nicht-motorisierten Verkehrsteilnehmer gleich sein, oder?

Das Blindenrouting kann da ohne Zweifel 1:1 für Kinder, Rollator- und Rollifahrer übernommen werden.

Natürlich ist eine "sichere" Querung nach unseren Vorgaben nicht immer Rollstuhl-Barrierefrei.

Sind Blinde Rollstuhlfahrer in der Zielgruppe mit Pareto-Relevanten über 20 % enthalten? Nein, sie sind sicher nicht alleine unterwegs. Hey, wenn's Rollstuhl-Routing wäre, dann hätten wir kein neues Projekt  ;-)

Natürlich brauchen wir ein eigenes Routing! Das heißt ja nicht, daß wir nicht auf bestehenden OSM-A*-Routing Open Source Code aufsetzen können... (Oder meinetwegen auch was anderes als A* - wird dann vereinbart.). --Lulu-Ann 14:22, 14 December 2010 (UTC)

Da hat Jongleur schon recht, hier müssen wir die Anforderungen ganz genau definieren. So geht es beim sicheren Blindenrouting ja nicht nur um die Bewertung von Wegquerungen, sondern auch um die Bewertung von Wegen selbst: dedizierte Fußwege sind gemeinsamen Rad- und Fußwegen vorzuziehen, danach kommen Straßen mit Bürgersteig, dann Straßen ohne Bürgersteig usw. Andererseits bedeutet dies immer noch nicht, dass die Routingfunktionalität neu geschrieben werden muss - nur die Gewichtung muss jeweils eine andere sein. --Ant 17:56, 3 January 2011 (UTC)

Das stimmt wohl, also machen wir einen neuen Punkt "Bewertung von Wegen" auf: --Lulu-Ann 13:38, 4 January 2011 (UTC)

zu "Das Blindenrouting kann ohne Zweifel 1:1 für Kinder, Rollator- und Rollifahrer übernommen werden": Dem stimme ich nicht zu. Gerade bei abgesenkten Bordsteinen sind Rollator- und Rollifahrer fast gegenläufig zu Blinden; Kinder sind vermutlich nicht so viel anders. Beispiele: Nullabsenkung - für die üblichen Billig-Rollatoren ohne Luftbereifung teilweise schon nicht mehr überwindbar, wenn taktile Bodenindikatoren die Kante für Blinde absichern; Wege-Qualität (Kopfsteinpflaster, Sand, Querneigung etc.) - für Blinde nicht unbedingt hinderlich, für Rollstühle teilweise schon. Engstellen im Weg: Absolutes no-go für breitere Rollstühle, Sperre für viele Rollator-Nutzer, die ihr Gefährt nicht drehen und durchtragen können, aber für Blinde mit 'ner Warnung gut passierbar - und sicher vieles Weiteres, was mir so spontan nicht einfällt. --Jongleur 11:32, 10 February 2011 (UTC)

Gemeint war: Wir beachtem mehr Aspekte, und weisen ihnen eine Gewichtung zu. Natürlich fällt diese Gewichtung für die einzelnen Benutzerprofile mehr oder weniger stark (oder sogar negativ) aus. Geeignet ist das Blindenrouting deswegen, weil es diese Gewichtung überhaupt anbietet, im Gegensatz zu anderen Routern, die das nicht tun. Lulu-Ann

zu "sollte bis auf die beiden ersten Punkte für alle nicht-motorisierten Verkehrsteilnehmer gleich sein": Als ungewichtete Reihenfolge richtig; mit Gewichtung nicht. Eine blindengerechte Ampel ist für den Blinden bei unübersichtlicher Verkehrssituation 'nen Umweg von einigen hundert Metern wert; Sehende, Erwachsene Fußgänger gehen ja nicht einmal für eine nicht weiter abgesicherte FußgängerINSEL 50 Meter hin und wieder zurück, wenn man die vierspurige Straße rennend überqwueren kann. Dass das so extrem nicht in einen Routing-Algorithmus einfließen sollte, ist eine andere Sache; Umwege für Blindenampeln bei Sehenden oder Rollifahrern werden aber deshalb vermutlich schwer von uns zu begründen sein und noch schwieriger von potentiellen Nutzern akzeptiert werden. --Jongleur 11:32, 10 February 2011 (UTC)

Ich hatte die ersten Punkte doch gerade ausgenommen ?! Lulu-Ann

Bewertung von Wegen

• Fußwege vor Fuß- und Radwegen
• Straßen mit Bürgersteig vor Straßen ohne Bürgersteig - Aber was ist mit Spielstraßen ohne Bürgersteig? Die sind doch sicher!, also Highway-Tag mit auswerten.
• Eine Querung können wir nur vorgeben, wenn überhaupt sicher ist, daß auf beiden Seiten ein Fußweg/Bürgersteig ist (oder das Ziel)

Richtig, das mit der Spielstraße. Auch so Sachen wie Wegoberfläche, Breite usw. spielen eine Rolle... --Ant 18:39, 4 January 2011 (UTC)

Und: Wo eine Fußgängerquerung existiert, gehe ich davon aus, dass diese auch zwei Fußwege oder Bürgersteige miteinander verbindet, sie führt ja wohl kaum gegen eine Wand oder auf die Fahrbahn?! --Ant 18:42, 4 January 2011 (UTC)

Eine Querung über eine kann auf Vieles führen, was kein Fußweg ist: Ein Parkplatz, ein Ziel (Der Eingang eines Gebäudes, neben dem kein Fußweg verläuft), einen senkrecht zur Fahrbahn weiterführenden Fußweg (wo kein Fußweg parallel zur Fahrbahn verläuft), eine Fußgängerzone (naja, das ist ja fast ein Fußweg), Treppen: eine Unterführung oder Brücke bzw. ein Eingang zu einer U-Bahn-Station, ein Fahrstuhl (z.B. wieder ein ÖPNV-Eingang), eine weitere Querung (nach einer Verkehrsinsel), eine Sackgasse (mit oder ohne ein touristisches Ziel wie eine Kneipp-Anlage oder ein Aussichtspunkt). Lulu-Ann

Na gut, das Routing wird ja schon entscheiden, ob die Querung zum Ziel führt oder nicht ;) Idealerweise sollten wir die Gewichtung der Wegtypen noch so spezifizieren, dass wir genaue Werte ermitteln können, z.B. "ziehe einen Fußweg einem Fuß- und Radweg vor, wenn dieser nicht mehr als (dreimal/doppelt/1,7-mal/...) so lang ist". --Ant 07:53, 6 January 2011 (UTC)

Ja, und außerdem sollen durch die Benutzung des Fußweges gegenüber dem Fuß-und Radweg keine weiteren Querungen hinzukommen. Lulu-Ann

Barrierefreie Entwicklungsumgebungen

Was ist eine barrierefreie Entwicklungsumgebung? Ich würde hier fordern, dass NOTWENDIGE Entwicklungswerkzeuge barrierefrei sein müssen; aber nicht zwingend alle. Ich programmiere z.B. meist in gEdit. Wie barrierefrei der ist, weiß ich ehrlich gesagt nicht; SVN ist per Konsole benutzbar, meine SVN-GUI aber vielleicht nicht. Ich weiß, das ist Kleinkariert, aber ich finde diese Unterscheidung trotzdem wichtig.

Die Anforderung auf Priorität 2 "Der Dienst soll durch sehende genutzt werden können" zeigt, dass du das ja eigentlich durchaus im Kopf hast ;) --Jongleur 20:20, 13 December 2010 (UTC)

Also, mir ging es da eher darum, daß auch die Anleitungen für die Installation der Entwicklungsumgebung sich auf eine barrierefreie Entwicklungsumgebung beziehen. Ob dann nachher jeder im Team die verwendet, ist mir egal, solange 100% Kompatibilität gegeben ist.

Rechne schonmal mit dem Erst-Kontakt zu uneingerückten Quelltexten wie bei Loadstone *LOL* --Lulu-Ann 14:25, 14 December 2010 (UTC)

Das würde ich nicht so eng sehen. Wer in der Lage ist, zu programmieren - ob blind oder nicht - wird schon seine Werkzeuge dafür haben. Das mit der Anleitung ist natürlich richtig, aber eigentlich eine sekundäre Anforderung. --Ant 17:56, 3 January 2011 (UTC)

Das sieht der blinde Programmierer ganz klar als primäre Anforderung. --Lulu-Ann 13:38, 4 January 2011 (UTC)

Versteh mich bitte nicht falsch... mit "sekundärer Anforderung" meine ich: Es ist keine Anforderung an das Programm selbst, sondern an die Entwicklungsumgebung - ich kann von einem Programm nicht fordern, dass ich es mit Entwicklerwerkzeug XY schreibe... --Ant 18:39, 4 January 2011 (UTC)

keine Geographische Einschränkung haben

Würde ich auf "...skalierbar auf die gesamte Welt sein" ändern; da dies zwar berücksichtigt werden muss, ein Testserver auf dem kompletten Planet aber meiner Meinung nach unrealistisch ist. Ansonsten gehen hier zumindest Anforderungen und Ziele durcheinander. --Jongleur 20:20, 13 December 2010 (UTC)

Wir sind ein Wikimedia-gefördertes Projekt. Wikimedia betreibt die Wikipedia Toolserver. Ich denke, da bekommen wir ein warmes, breitbandiges Plätzchen. Werde ich beantragen. --Lulu-Ann 14:27, 14 December 2010 (UTC)

Gibt's denn da schon Neuigkeiten bezüglich deines Antrags? --Ant 17:56, 3 January 2011 (UTC)

Meine Kontaktperson ist im Weihnachtsurlaub, Account auf Toolserver ist beantragt (für meine Person). Ich habe noch ein paar Variablen für die Budgetschätzung offen, die davon abhängen, ob ich Partner-Organisationen ins Boot bekomme. --Lulu-Ann 13:38, 4 January 2011 (UTC)

Aktuelle Top X Browser unter Y

Was ist aktuell? zu welchem Zeitpunkt? Warum 2 Linux-Browser aber 5 Windows-Browser? Besser wäre hier eine Definition, welche Browser das sind.--Jongleur 20:20, 13 December 2010 (UTC)

Aktuell = Aktuell zur Freigabe des Lastenhefts. Die Anzahl ist willkürlich, ich wollte Linux drin haben wegen der von Blinden viel genutzten Adriane-Knoppix Edition. Die Namen der Browser holen wir uns aus einer Nutzungs-Statistik.

Ich rechne damit, daß

• Internet Explorer ab 7
• Firefox ab 3
• Chrome
• Safari

drin sind. Vielleicht sollte ich Lynx fordern? --Lulu-Ann 14:31, 14 December 2010 (UTC)

Die Frage ist, ob das ganze ohne Javascript voll funktionsfähig sein soll. Mit ARIA ist sowas zumindest prinzipiell möglich - wobei ich mich noch nicht viel näher damit beschäftigt habe; das also nicht sicher weiß. Bei Javascript als Pflicht wäre Lynx allerdings alleine deshalb schon außen vor. --Jongleur 08:49, 15 December 2010 (UTC)

Wir sollten im Einzelnen überlegen, welche Funktionen auch ohne Javascript gehen sollten. So ist es z.B. wohl etwas vermessen, eine visuelle Darstellung ohne JavaScript haben zu wollen - Ausgabe in Textform ist hingegen sicher möglich. --Ant 17:56, 3 January 2011 (UTC)

Nach BITV [1] ist JavaScript natürlich für Funktionalität zu vermeiden, aber natürlich brauchen wir es für die Slippymap. Stellt aber kein Problem dar, wir machen einfach einen noscript-Tag, der vom Screenreader genannt wird. Die Blinden sollen die Slippymap ja nicht benutzen können. Frech formuliert: "Wir können JavaScript überall dort benutzen, wo den Blinden nichts entgeht, was ihnen nicht sowieso schon entgeht." --Lulu-Ann 13:38, 4 January 2011 (UTC)

Genau :) --Ant 18:39, 4 January 2011 (UTC)

Es sollen mindestens die n häufigsten Tags von OSM für X unterstützt werden

Wieso? Was bringt das, wenn created_by und source unterstützt wird? Selbst oneway, was relativ häufig ist, ist für die Fußgängernavigation nur bedingt sinnvoll. Dafür fehlen andere deutlich. Die Frage, die sich mir dabei stellt ist: soll das ein barrierefreier OSM-Browser sein, oder eine sinnvolle Beschreibung der Karte? In letzterem Fall wäre eine Konfigurierbarkeit von unterstützten Tags sinnvoll, aber keine Anforderung, die auf statistischen Verwendungsdaten basiert.--Jongleur 20:20, 13 December 2010 (UTC)

Unterstützen heißt nicht "auf jeden Fall vorlesen". Unterstützen heißt auch: Ich weiß, daß ich "Created by" stets weglassen kann, anstatt es als unbekannter Tag vorsichtshalber auf Nachfrage ansagen zu können.

Oneway ist eine für Blinde wichtige Information über die zu erwartende Straßenbreite und die Richtung, aus der Fahrzeuge kommen.

"Mindestens" sagt, daß Tag 51 und 1284654 (Tactile_paving z.B.) natürlich auch angesagt werden dürfen, wenn sie sinnvoll sind. Diese Anforderung will nur sicherstellen, daß außer Straßen und Hausnummern noch ein großzügiger Mindest-Umfang umgesetzt wird. ("Messbare Anforderung")

Wenn es für die häufigsten Tags jedes Data Primitives funktioniert, sollte es ja bei Bedarf einfach auf weitere durch Text- und Übersetzungs-Ergänzungen erweiterbar sein.

--Lulu-Ann 14:36, 14 December 2010 (UTC)

Oneway lässt nicht wirklich auf die Straßenbreite schließen. Da hilft width=* oder auch lanes=*. --Ant 17:56, 3 January 2011 (UTC)

width und lane helfen nur, wo sie gesetzt sind (und das ist super selten). Oneway ist gut für eine Fallback-Annahme. Wir deuten auch nicht aus Oneway --> Width=3,5m, sondern wir lassen das Oneway vorlesen, und der Nutzer nimmt dann halt selbst eine geringere Straßenbreite an, mit einer Fehler-Wahrscheinlichkeit. --Lulu-Ann 13:38, 4 January 2011 (UTC)

Top 2 kostenlose Screenreader

Warum hier keine Unterscheidung nach Betriebssystem? Gilt Apples Onboard-Screenreader auch? Wie "top" ist der?--Jongleur 20:20, 13 December 2010 (UTC)

Ich nehme an, daß wenn ein Browser vom Screenreader unterstützt wird, er auch mit einer barrierefreien Webseite volle Funktionalität entfaltet. "Kostenlos" ist insofern falsch, "Beigaben" zählen auch. (VoiceOver auf allen Plattformen:Ja)

Aber wollen wir dafür wirklich jedesmal testen? Das treibt die Projektkosten in die Höhe, wenn wir zum Testen der "Beigaben"-Screenreader die Betriebssysteme bzw. PDAs anschaffen wollten. Daher: Wenn wir Zugriff haben (G.'s iPhone zum Beispiel, oder die Macs im -Lab), dann können wir gerne testen, wenn nicht, dann nicht. Das ist bewußt Pareto. --Lulu-Ann 14:41, 14 December 2010 (UTC)

Für Sehgeschädigte barrierefrei nutzbar

Wieso ist das eine neue Anforderung zusätzlich zur Barrierefreiheit für Blinde? Was ist dann barrierefrei? Für welche Schädigung?--Jongleur 20:20, 13 December 2010 (UTC)

Hier denke ich an vergrößerbare Schrift, extremen Kartenzoom (mal sehen, ob wir das hinbekommen, oder lieber die Bildschirmlupe nehmen), eine einfache CSS Umschaltung auf Invers und beliebte Farbkombinationen für die häufigsten Sehbehinderungen (Ein schönes Gelb für die Achromaten ;-) )

Das müssen wir noch genauer definieren. Ich sag mal, wir nehmen wieder die Top 80% der Augenkrankheiten nach Häufigkeitsverteilung in Industrienationen mit Internetzugriff? --Lulu-Ann 14:44, 14 December 2010 (UTC)

Nice to have wären zusätzliche Mapnik-Kartenstile für Sehgeschädigte (hoher Kontrast etc.). --Ant 17:56, 3 January 2011 (UTC)

Guter Hinweis - Gibt es da schon was? --Lulu-Ann 13:38, 4 January 2011 (UTC)

Nicht, dass ich wüsste... --Ant 18:39, 4 January 2011 (UTC)

Auch für Sehende benutzbar sein

Ist das jetzt eine Barriere für Blinde, wenn eine optische Karte eingebaut wird, die diese nicht nutzen können? Oder ist es andersherum eine Barriere (die du zugegeben nicht ausschließt) für Sehende, diese Karte NICHT anzubieten?--Jongleur 20:20, 13 December 2010 (UTC)

Es wäre eine Barriere für Sehende / Mausbenutzer, wenn z.B. die Visuelle Karte nicht mit der Maus zoombar/schiebbar wäre, und sie sich auf die Kommando-Eingabe bemühen müßten. Anwendungsfall ist hier ein Blinder und ein Sehender nebeneinander vorm Rechner, die beide die für sie optimale Ausgabe erhalten. Da uns die Slippymap ca. 30 Minuten Arbeit kostet, lohnt die Diskussion nicht :-)

--Lulu-Ann 14:46, 14 December 2010 (UTC)

...dann aber bitte auch mit Start-/Ziel-Pointer und eingezeichneter Route und POI! --Ant 17:56, 3 January 2011 (UTC)

Brrrr. Prio 25. Wenn der Sehende am Rechner neben dem Blinden auf die Karte klickt, dann ist das genauso ergiebig, wie wenn er auf der Straße auf einen Plan zeigt. Zum Zurechtfinden muß der Blinde "Überblick" erlangen, und das geht nicht durch Pins setzen, sondern durch Hinnavigieren in Zusammenhängen. Startpunkt setzen ist allenfalls sinnvoll bei Ankunfts-POIs (Haltestellen ÖPNV oder selbstgesetzte Favoriten). So toll das wäre, es ist wohl nur nice to have und damit spätere Prio. Für Sehgeschädigte hingegen wäre es wieder wichtig, auf der Karte auch den Weg eingezeichnet zu bekommen. Prio sehe ich also erst dann, wenn die Karte schon kontrast-optimiert ist usw. --Lulu-Ann 13:38, 4 January 2011 (UTC)

Ja, das war auch eher als eine Art Extrawurst für die Slippymap-BenutzerInnen gedacht. Hat sicherlich keine hohe Priorität. --Ant 18:39, 4 January 2011 (UTC)

Braille-Druck

Ist das Clientseitig bei einer Browser-Anwendung überhaupt machbar? Ist das nicht im Gegenteil eine Textfassung, die vom Anwender auf dem Braille-Drucker ausgedruckt werden kann? (Hier hab ich echt einfach keine Ahnung bisher) --Jongleur 20:20, 13 December 2010 (UTC)

Ja, das ist eine Textfassung für den Braille-Drucker (Datei-Download-Angebot ?!) Da gibt es eine Java-Library namens LibLouis, die macht das schon. Guck mal in die Karte von Ant, die kann das schon, glaube ich. Außerdem könnte ich mir optional vorstellen, das Braille als Grafik zum Ausdrucken für Schwellkopierer anzubieten. --Lulu-Ann 14:49, 14 December 2010 (UTC)

Genau, siehe hier --Ant 17:56, 3 January 2011 (UTC)