Sprung zum Inhalt [/]

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zur Liste der Kategorien | zum Archiv

Parallels Desktop 9 für Mac ist NICHT mit OS X El Capitan kompatibel.

Donnerstag, 30. Juli 2015

Logo Parallels
… und weil ich keine mehr Lust habe, alle 1 oder 2 Jahre 50 Euro für eine VM auszugeben, werde ich wohl Parallels demnächst *) von meinem Macbook löschen.

Glücklicherweise scheint das nicht schwer zu sein:
Schritt 1Schritt 2

Über die Jahre konnte ich folgende Windows-only Anwendungen, die ich beim Umstieg auf Mac für unverzichtbar hielt, durch Mac-kompatible Apps ersetzen:

  • Mein Steuerprogramm SteuerSparErklärung von Akademische Arbeitsgemeinschaft
  • Microsoft Office — die Office 365 (Version 2016) benimmt sich auf dem Mac recht ordentlich.
  • Edit4Win Text-Editor — dort gibt es einige exotische Features, die ich lange für alternativlos hielt, die ich aber mit TextMate emulieren kann.
  • IrfanView — klar, alles, was IrfanView kann, können auch Gimp & Co. Man muss halt ein wenig suchen und üben.

Bleibt noch “mein” Screen Reader NVDA. Ich glaube nicht, dass der NVDA einmal auf OS X portiert wird. Nun gut, muss ich mich halt doch einmal mit VoiceOver auf dem Mac beschäftigen. Es ist ja nur zum Testen. Oder, noch einfacher, NVDA portabel auf einem USB-Stick an einem Windows-Rechner verwenden.

Ich bin mir sicher, dass es meinem Macbook nicht schadet, wenn es ohne Parallels betrieben wird.

*) spätestens vor dem Update auf El Capitan im September? Bis dahin kann ich ja noch gründlich testen, wie sich komplett “fensterlos” fühlt.


Responsive Web Design - Anzeige ist nicht alles

Samstag, 25. Juli 2015

Es ist kein Hexenwerk, eine Website mittels CSS und media queries auch auf kleinen Monitoren wie z. B. Smartphones ordentlich anzuzeigen. Jedes halbwegs brauchbare CMS hat dies heute schon “eingebaut".
Aber “ordentlich anzeigen” ist nur die halbe Miete.
Gestern hatte ich ein Gespräch mit einem Neu-iPhone-User. Er war hocherfreut über die Geschwindigkeit des LTE-Netzes, und wie schnell er jetzt auch unterwegs praktisch jede Website aufrufen kann. Allerdings: nach wenigen Tagen war sein inklusives Datenvolumen aufgebraucht.
Die Erklärung ist recht einfach: Kaum ein Anbieter macht sich die Mühe, seinen responsiven Webauftritt auch hinsichtlich des (mobil) zu übertragenden Datenvolumens zu optimieren. Da werden Bilder mit mehreren hundert kB übertragen, und auf dem Smartphone dann nur 320 px breit, oder möglicherweise gar nicht angezeigt.

Auf letzteren Fall möchte ich hier detailliert eingehen, und zwar an einem Beispiel auf meiner eigenen Site:
Die Artikelübersicht beinhaltet 34 Vorschaubilder. Jedes für sich zwar klein, und hinsichtlich der Dateigröße bereits optimiert (von wenigen kB bis max. 56 kB). Keines dieser Bilder wird beim erstmaligen Aufruf auf dem Smartphone ohne Scrollen ("above the fold") angezeigt. Die komplette Seite “wiegt” aber ca. 650 kB, und diese 650 kB werden bereits beim Aufruf der Seite übertragen, auch wenn der Betrachter gar nicht scrollt, also die vielen Bilder gar nicht sieht.
Nein, sie “werden” nicht! Sie “würden” nur übertragen, wenn ich nicht Unveil einsetzen würde.
Mit wenigen Zeilen Code schrumpft dieses geniale Tool die Seite beim ersten Aufruf auf 71 kB. Und Bilder werden erst bei Bedarf, d. h. beim Scrollen, nachgeladen. Das geschieht, ohne dass der Besucher etwas davon bemerkt.
Vielleicht straft Google irgendwann auch den unnützen Bandbreitenverbrauch ab. Dann würde der eine oder andere Webworker (SEO-Spezialist) ganz schnell zu der beschriebenen und ähnlichen Techniken greifen.

Nachtrag 27.07.2015

Wegen einer Besonderheit in iOS — Unveil triggert erst, d.h. Bilder “above the fold” werden erst angezeigt, wenn der User den Monitor des Geräts berührt — mache ich Bilder “above the fold” statisch. Auch auf Kosten von ein paar kB.


Der Nu Html Checker

Montag, 20. Juli 2015

Ob’s schon jemand bemerkt hat?
Sicher doch: Alle meine Kollegen checken doch regelmäßig ihre Arbeit auf Standardkonformität mit dem W3C Markup Validator. Der W3C Validator ist allerdings ein wenig in die Jahre gekommen. Das letzte Update ist vom März 2012. Das passt irgendwie nicht zur rasanten Weiterentwicklung von Webtechniken. Erwähnt sei hier nur die (Quasi-)Verabschiedung von HTML5. Der W3C Validator hat daher schon lange empfohlen, zur Validierung von HTML5-Seiten den Nu Validator zu verwenden. Weil der Nu Validator aktiv weiterentwickelt und ständig an neue Standards angepasst wird.
Seit kurzem nun wird beim Aufruf des W3C Markup Validators automatisch auf den Nu Html Checker umgeleitet, wenn ein HTML5 Dokument gecheckt werden soll.


Homepage erstellen - wie anno 1995

Sonntag, 19. Juli 2015

Heute kam per E-Mail eine Anfrage um Verlinkung herein. Der Anfrager hat mein Tutorial “Deine erste Homepage” entdeckt. Das ist an sich kaum erwähnenswert. (In 99% der Fälle entsorge ich solche Anfragen von “SEO-Spezialisten” mit einem Klick.)

Wie auch immer: das Thema des angepriesenen E-Books: “Homepage erstellen", hat mich dazu bewogen, einen schnellen Blick drauf zu werfen, und das PDF kurz auf Barrierefreiheit abzuklopfen.

Meine Werkzeuge zum Schnelltest von PDFs:

Und tatsächlich: Das PDF ist strukturiert, und mit Screen Reader gut lesbar.

Doch jetzt zum Thema “lesbar":

Sowohl das PDF, als auch die Site selbst sind offenbar mit irgendeinem Tool erstellt, das wohl automatisch auf bestimmte Keywords optimierte Texte erzeugt. Lesbar ist das Ergebnis nicht wirklich. Und sinnvoll noch weniger.

Leseprobe (zur Erinnerung: Thema “Homepage erstellen"):

Ein Bild mit einer Höhe von 250 und einer Breite von 100 Pixeln wird also mit dem Tag eingefügt.

oder:

Ein Link ist ein HTML-Element, das sich aus einem -Tag sowie einem Inhalt zusammensetzt. Ein einfacher Link sieht also so aus: Inhalt.

Absolut unverständlich! Das automatisch erstellte Produkt hat anscheinend vor mir noch nie jemand gelesen. (Hinweis: Es handelt sich nicht um ein Darstellungsproblem, sondern dieser Unsinn steht so im Quellcode.)

Aber es geht noch schlimmer:

Tabellen wurden in HTML ursprünglich eingeführt, um den Inhalt der Seite, also den Text sowie die Bilder und Grafiken, übersichtlich darstellen zu können. Mittlerweile haben sich HTML-Tabellen jedoch zu einem grundlegenden Element des eigentlichen Designs der Internetseite entwickelt und werden nicht nur zur Strukturierung des Inhalts, sondern auch zu Erstellen des Seitenlayouts eingesetzt. Wer sich also das Ziel gesetzt hat, die eigene Homepage von Hand mit HTML zu erstellen, sollte sich genau mit HTML-Tabellen, ihrer Funktion sowie den dazugehörigen Attributen auseinandersetzen.

Die 1990er Jahre lassen grüßen! Ich kann nur hoffen, dass dieser Unfug nicht in falsche Hände gerät.
Ach ja, ich sollte doch einen Link setzen: www. homepage-erstellen.de


Nochmal: Kein Flash

Zufällig habe ich in den Tiefen meiner Site noch ein kleines Flash-Filmchen entdeckt, das meiner Aktion “Kein Flash” bis heute entkommen ist:
Das 14-Sekunden-Filmchen zeigt den animierten Link zur Startseite im Logo meiner Seiten.

Natürlich habe ich den Lapsus korrigiert, und den Flash-Film durch HTML5 video ersetzt.
Ganze 3 Zeilen Code sind dafür nötig, wie hier beschrieben.

Webworker können sich ja mal das Code-Ungeheuer anschauen, das nötig war, um den Flash-Film barrierefrei einzubinden:
weiterlesen…


Apple Music und Sonos

Samstag, 4. Juli 2015

Natürlich muss ich Apple Music auch testen. Allerdings unter erschwerten Bedingungen. Doch der Reihe nach:

Mein Streaming-Dienst ist Spotify. Und weil ich zuhause natürlich nicht mit den quäkenden Notebook-/Tablet-/Smartphone-Lautsprechern zufrieden bin, wird Musik auf meinem Sonos-System abgespielt. Sonos und Spotify arbeiten ja nahtlos zusammen. (Noch) nicht aber Sonos und Apple Music.
Auf einem Umweg geht aber auch das: SonoAir heißt die App, die es ermöglicht.

Screenshot
Das Programmfenster von Sonoair. Dort gibt es eigentlich nach dem Programmstart nichts zu tun.

SonoAir macht Sonos AirPlay-fähig. Also Apple Music z. B. in iTunes starten, SonoAir starten, als Ausgabegerät den gewünschten (Sonos-)Raum wählen, und schon läuft’s.

Leider ist SonoAir ein wenig tricky zu bedienen, und eine richtige Doku scheint es auch nicht zu geben. Ich musste mir die Infos im Web zusammensuchen, z. B. mit einer Google-Suche nach “Sonos iTunes".
Der Knackpunkt auf dem Mac ist die Aktivierung. Man darf nicht den AirPlay-Button in iTunes drücken, sondern muss mit alt-Klick auf das Lautsprecher-Icon in der Menüleiste den Raum wählen:

Screenshot
Hier wählt man das Ziel für AirPlay, den Sonos-Raum.

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.

Ältere Beitäge:

Kategorien:

Creative Commons Lizenzvertrag
Alle Artikel des Blogs Creative Commons CC BY-NC-SA 3.0 DE