Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

user-scalable=yes

Sonntag, 28. Juni 2015

Responsive Web Design RWD und Barrierefreiheit: Das sollte nun wirklich kein Widerspruch sein; ganz im Gegenteil. Leider gibt es immer noch und immer wieder "Designer", denen ihr — "gephotoshoptes?" — Design so wichtig erscheint, dass sie den dummen User hindern, es durch Zoomen zu verunstalten.
Wie das geht? Ganz einfach:

<meta name="viewport" content="width=device-width, maximum-scale=1.0, minimum-scale=1.0, initial-scale=1.0" >

in den Header.
Der Meta-Tag "viewport" ist schon richtig und wichtig, um mobile Geräte anzuweisen, den Inhalt entsprechend der Bildschirmgröße richtig zu skalieren.
Aber

maximum-scale=1.0, minimum-scale=1.0

Was soll das? Auch Laien leuchtet anhand der sprechenden Syntax sofort ein, dass damit jeglicher Versuch des Users, den Seiteninhalt zu zoomen, vereitelt werden soll.

Warum macht so etwas eine Agentur, die für sich in Anspruch nimmt:

Darüber hinaus spielen auch Aspekte wie die barrierefreie Nutzbarkeit Ihres Webangebots, die responsive und adaptive Darstellung Ihres Designs auf Endgeräten mit unterschiedlicher Bildschirmauflösung (Smartphone, Tablet) … eine zentrale Rolle im Gestaltungsprozess.

Unwissenheit? Gedankenlosigkeit? Schlamperei?

Dabei wäre es so einfach:

Screenshot
Mit "Pinch" (zwei Finger auseinanderziehen) kann der User jedes Detail einer Webseite nach Bedarf zoomen — wenn der "Webdesigner" das nicht mutwillig unterbindet.

<meta name="viewport" content="width=device-width, user-scalable=yes, initial-scale=1" />

Also

user-scalable=yes

Und alles ist gut.


RSS Feed und Smartphones / Tablets

Dienstag, 23. Juni 2015

RSS Feeds sind (zu Unrecht) etwas aus der Mode gekommen. Ich vermute die Ursache in der Tatsache, dass sich nie ein Standard für die Anzeige von RSS Feeds etabliert hat, dass jeder Browser das anders handhabt, dass eine Unzahl von Programmen, Apps u. Ä. mit unterschiedlichsten Features im Umlauf sind, aber auch oft genug Services ihren Dienst quittieren.
Erinnert sei an den Google Reader, der vor einiger Zeit ohne Vorankündigung eingestellt wurde. Oder an das Hin und Her mit der Art, wie RSS Feeds in verschiedenen Browsern behandelt wurden und werden.

Ich habe daher schon immer einen direkten Link zum xml file des Feeds auf den entsprechenden Seiten eingebaut.



Firefox zeigt den Feed damit ordentlich an. Auch der Internet Explorer. Chrome und Opera (die Webkit-Engine) können offensichtlich mit einem xml file gar nichts anfangen, und zeigen den Quelltext. DerSafari-Browser wiederum behandelt Feeds wie Social Media Links, und zeigt sie — nach längerem Gefummel — in einer Seitenleiste an.

Da wohl (hoffentlich) die meisten Surfer die Eigenarten ihres Lieblingsbrowsers einigermaßen kennen, belasse ich es vorläufig bei dem Link.

Ganz schlimm wird es dann aber in Smartphones und Tablets. Nachdem mein iPhone den RSS Feed partout mit der Podcast App Instacast anzeigen wollte, und den Link aus Wordpress, der sich hinter einer .php Dateiendung (anstelle von .xml) versteckt, gar als PDF (!?), habe ich mich kurzerhand entschieden den Link zum RSS Feed auf Smartphones und Tablets nicht mehr anzuzeigen. (siehe Kommentare)


UTF-8 und Historisches

Donnerstag, 11. Juni 2015

Im April d. J. habe ich mich endlich dazu entschieden, meine uralte Webpräsenz komplett auf UTF-8 umzustellen.
Die alten Blogposts — alt, d. h. bis 2004 zurück — musste ich manuell anfassen. Der Grund: Dort waren Umlaute als Entities codiert, und diese Entities wurden bei einer Suche im Blog nicht gefunden. Die manuelle Durchforstung brachte leider auch Fehler aller möglichen Art zum Vorschein, und artete dadurch echt in Arbeit aus. Ich war zwischenzeitlich versucht, ab einem gewissen Alter (2010?) Fehler einfach stehen zu lassen, hab' mich aber dann doch immer wieder aufgerafft. Heute bin ich endlich bei meinem ersten Blogpost aus 2004 angelangt.
Die letzte Teilstrecke war für mich wirklich interessant. Bereits 2004 habe ich mich intensiv mit Dingen beschäftigt, die auch heute (für mich) noch unverändert gültig sind: Optimierung "für alle Browser", Barrierefreiheit, Design für kleine Monitore (damals PDAs, heute Smartphones), usw.
Wer sich gerade langweilt, und mich in die Geschichte begleiten will, der kann gerne mal in meinem Blogarchiv stöbern.


Neues vom TBL-Kommunikator

Donnerstag, 4. Juni 2015

TBL-Kommunikator Hilfe

Beta 1.11 01.06.15

Der TBL-Kommunikator ermöglicht die asynchrone elektronische Kommunikation mit taubblinden oder hörsehbehinderten Menschen. Asynchron bedeutet, dass Schreib- und Lesegeschwindigkeit entkoppelt sind. Der/die taubblinde oder hörsehbehinderte Leser(in) bestimmt selbst seine/ihre Lesegeschwindigkeit.

Diese Anwendung ist auf den Schreiber (TBA, Schriftdolmetscher) registriert. Der Schreiber kann beliebig viele Leser einladen.

Voraussetzungen beim Schreiber:

  • ein internetfähiges Gerät (PC, Notebook o. Ä)
  • Internetzugang mittels WLAN oder Mobilfunknetz (mindestens UMTS/3G).
  • Kürzel / Textbausteine, die systemweit auf dem Gerät des Schreibers verfügbar sind, können bei der Eingabe benutzt werden.
    Darüber hinaus können Kürzel innerhalb des Systems individuell konfiguriert werden.
  • Spracheingabesysteme, die in ein Textfeld schreiben (in vielen Betriebssystemen, z. B. iOS, Mac OS X, Win 7 enthalten), werden unterstützt.

Voraussetzungen beim Leser:

  • ein internetfähiges Gerät (PC, Notebook, Tablet oder Smartphone, Organizer wie z. B. Pronto!)
  • Nach Bedarf: Ein installierter Screen Reader und angeschlossene Braillezeile
  • Internetzugang mittels WLAN oder Mobilfunknetz (mindestens UMTS/3G).

Bedienung

  1. Der Schreiber öffnet http://w7t.de/t2b (passwortgeschützt) und erstellt eine neue Sitzung.
  2. Der Name der Sitzung hat die Funktion eines Passworts. Er sollte nicht leicht zu erraten sein.
  3. Dort findet sich eine Angabe wie: "Die folgende Adresse muss der/dem Leser(in) mitgeteilt werden: http://w7t.de/t2b/xyz"
  4. Diese (neu erstellte) Adresse muss dem Leser mitgeteilt werden.
  5. Von der Sitzungsseite führt ein Link zur Eingabeseite.
  6. Die Sitzung startet automatisch, sobald der Schreiber eine erste Nachricht eingibt.
  7. Der Schreiber kann Rückmeldungen zulassen.
  8. Neue Meldungen (auch Rückmeldungen) werden durch einen Ton angekündigt. (Nicht iOS und Adroid)
  9. Der Schreiber kann die aktuelle Sitzung bei Bedarf jederzeit leeren, oder eine neue Sitzung starten.
  10. Sobald der Schreiber die erste Nachricht erstellt hat, kann der Leser asynchron lesen. D. h., der Leser bestimmt seine Lesegeschwindigkeit selbst, unabhängig von der Eingabegeschwindigkeit.
    Am Ende jeder Nachricht findet sich ein Link "weiter", der zur nächsten Nachricht führt. Falls es (noch) keine weitere Nachricht gibt (falls also der Leser den Schreiber "einholt"), muss die Seite vom Leser manuell neu geladen werden (eventuell wiederholt).
  11. Das Protokoll der aktuellen Sitzung kann jederzeit vom Leser eingesehen werden. Der Link zum Protokoll befindet sich auf der Seite mit der letzten Nachricht. Dieses Protokoll kann mit der entsprechenden Browserfunktion ausgedruckt, oder als .html (formatiert, barrierefrei) oder .txt (unformatiert) gespeichert werden.

Archiv:

Kategorien:

Creative Commons Lizenzvertrag
Alle Texte (nicht Bilder!) Creative Commons CC BY-NC-SA 3.0 DE