JavaScript Refactoring

Diese Woche bin ich über ein kleines .. simples JavaScript gestolpert. An dem möchte ich aber zeigen wie man auch sehr kleine Scripts grenzenlos schlecht machen kann. Das Script verwendet die Qooxdoo BaseLib.

Der Bug kam zu mir mit dem Hinweis daß das Script im IE8 und IE7 nicht funktioniert und das restliche JS der Seite lahmlegt.

Die Aufgabe des Scripts ist ein einfacher Container / Bildwechsel alle 5 Sekunden. Ein Container wird eingeblendet .. zwei andere werden ausgeblendet.

Orginalscript

Hier das Orginal Script mit Markup und JS.

Das kann im IE 7/8 nicht funktionieren .. weil der Browser noch nie document.getElementsByClassName unterstützt hat. Das muss man jetzt nicht wissen wenn man Junior Entwickler ist. Aber man sollte das doch auch im IE testen was man so baut. Außerdem werden da irgendwie viele Variablen übergeben .. und wer außerdem bei so ner kleinen Aufgabe 2 Schleifen ineinander baut und dann noch nen break verwendet .. okay .. das Ding stinkt .. und zwar auf den ersten Blick.

Wie gesagt .. aber es läuft in modernen Browsern klaglos.

Quickfix

Hier der Quickfix Code.

Als erstes musste natürlich ganz schnell ein Bugfix her .. keine Zeit sich groß Gedanken zu machen. Fixen .. online stellen war die Ansage.

Ich habe dem Container eine ID gegeben und hole mir das Element via ID ins JS und ermittle die Children. Die Basisfunktion habe ich dann für später aufgehoben. Außerdem kann ich ganz schnell noch 2 Variablen sparen. Die zwei Schleifen waren mir immer noch suspekt .. aber gut es soll ja erst mal nur tun.

Refactoring

Hier das Script Refactoring.

Nachdem online stellen habe ich es dann neu geschrieben. Mir gefiel der Ansatz im Markup 2 (oder mehr) Container auf hidden zu setzen und nur einen einzublenden und dies nicht per JS zu machen. Das wollte ich behalten. Alle andere habe ich gelöscht.

Auf beide Schleifen konnte ich verzichten .. ich muss ja immer nur ein Element einblenden und eins ausblenden. Alle anderen Elemente haben ja immer ein hidden. Das break konnte weg, eine zweite Zähler Variable war ebenso unnötig.

Das Interval wird gesichert indem es nur ausgeführt werden kann wenn die Variable auch wirklich ein Objekt enthält. Elemente und Children hole ich mir mit nativen JS Methoden ins Script die auch über alle Browser funktionieren.

Fertig. Elegant. Klein. Simpel.

Was lernen wir draus?

Erstmal das dies jedem passieren kann. Ich habe auch mal einen schlechten Tag oder stehe so unter Zeitdruck das ich so einen Müll schreibe .. Hauptsache es tut dann irgendwie.

Wenn man aber weiß das man da nur was hingemurkst hat muss man 1-2 Tage später (oder wenn wieder mehr Zeit ist) es so aufräumen und besser machen das es funktioniert.

Wenn man das nicht kann .. dann hat man doch zumindest das Gefühl es nicht wirklich gut gemacht zu haben. Dann geht man eben zu jemandem der besser JavaScript kann und lässt sich helfen .. und plötzlich lernt man vielleicht noch was.

SEO Spider .. enlarged

Vor Weihnachten war ich mit einer netten kleinen freelance Arbeit für eine Agentur beschäftigt .. hat auch was mit SEO zu tun .. nur darf ich noch nix drüber erzählen. Mal sehen vielleicht bekommen wir es im Januar / Februar online.

Nach Weihnachten hat mich dann der Seorch Scanner weiter beschäftigt. Anfang Dezember habe ich eine erste BETA online gestellt und dann auch gleich drei Bugfix Releases hinterher geschoben. Mittlerweile läuft er stabil und ich finde kaum noch nennenswerte Fehler.

Für 2013 habe ich mir gleich 2 neue Dinge vorgenommen.

1. WDF*P*IDF

Die Berechnung der Inverse-Document-Frequency. Seorch kann ja schon die WDF (Within-Document-Frequency) eines Keywords berechnen .. nun ist es durchaus interessant zu sehen wie sich das auf die weiteren Dokumente der Website verteilt.

Die inverse Dokumenthäufigkeit stellt die Bedeutung eines Keywords in Bezug auf die Gesamtmenge aller betrachteten Dokumente dar. Je mehr Dokumente es zu einem Keyword gibt, umso schwieriger wird die Erzeugung von Relevanz.

Am besten lest ihr das Ganze bei Karl Kratz.

2. Bigcrawls

Aktuell crawlt der Seorch Scanner, je nach Geschwindigkeit der Website die gecrawlt wird, zwischen 30 und 200 Seiten. Das reicht natürlich nicht und mein nächstes Ziel ist es mehrere 1000 Seiten einer Domain zu crawlen.

Damit habe ich auch testweise schon begonnen .. allerdings habe ich recht schnell bemerkt das ich in ein Speicherproblem laufe. Für jede gecrawlte Website wird ein großes DOM Objekt erzeugt, die Seite neu encodiert und die Daten die ich aus der Seite auslese müssen ja noch gespeichert werden. Das alles frisst natürlich RAM.

Die letzten 2 Tage habe ich damit zugebracht große Crawls zu starten und dann die Speicherauslastung meines Servers zu beobachten.

Ich habe gefühlte 100 Artikel gelesen wie man PHP dazu bringt wenig Speicher zu verbrauchen .. das meiste habe ich getestet und auch wieder verworfen .. da es nur zu marginalen Verbesserungen geführt hat.

Man kann in etwa sagen das pro gecrawlter Seite 1 MB RAM belegt wird (Was ich auch irgendwie für realistisch halte). Das ist unproblematisch bei 100 oder 200 Seiten. Bei tausenden von Seiten ist das aber kritisch da ich ja nicht unbegrenzt RAM zur Verfügung habe.

Meine Idee ist nun das in Chunks zu machen. Also immer nur 50 Seiten auf einmal zu crawlen .. die Ergebnisse in eine Datenbank zu speichern .. und auf Basis der gespeicherten Daten dann die nächsten 50 Seiten zu crawlen.

Ich bin mal gespannt ob das so funktioniert wie ich mir das vorstelle.

SEO Spider (Alpha 2)

Ich habe gerade die zweite Alpha Version von meinem SEO Spider veröffentlicht. In den letzten Tagen habe ich jede Menge Bugs behoben, ein paar neue Features eingebaut und etwas an der Optik gefeilt.

Daneben habe ich noch ein paar hundert verschiedene Websites damit gecrawlt um noch weitere Fehler zu finden.

Meine Lieblingskandidaten waren dabei die Websites von Siemens (WTF), Beiersdorf (Umlaute in Pfadnamen), Continental AG (Meta Refreshs) und wie immer die Telekom (SCHMERZEN).

Neue Features:

  • User Agent Switcher (Google, Yandex, Bing, None)
  • CSV Exports
  • Urls mit mehr als 115 Zeichen
  • zu kurze Texte
  • Analyse der X-Robots und Meta Robots
  • Meta Refreshs werden gefunden
  • interne Links, externe Links
  • Seiten mit mehr als 100 ausgehenden Links
  • Seiten mit wenig eingehenden Links
  • HTTP Hops (301, 302) wird korrekt gefolgt und die Zielseite angezeigt
  • Umlaute in URLs funktionieren
  • die Analyse wird gespeichert -> Permalink
  • Links in SCRIPT Tags wird nicht mehr gefolgt
  • korrektes Encoding der Website (DaumenDrück)
  • prüft auf Mime Type / Dateiendung
  • Spider Modul weiter verbessert

Fertig bin ich immer noch nicht .. aber meine ToDo Liste ist merklich geschrumpft. Vor dem ersten Release möchte ich noch etwas an Optik und Layout arbeiten, auf Dateigrößen prüfen, fehlende ALT Tags ausgeben, Inline Styles und Inline JS anzeigen.

Daneben auch noch doppelte, SEO relevante Tags finden (Canonical, Robots), GET Parameter anzeigen usw.

Trotzdem .. ich finde das Tool funktioniert schon so robust wie ich es mir vorstelle.

Es werden maximal 250 Seiten gecrawlt .. allerdings nur sofern die gecrawlte Website schnell antwortet. Liegt die Antwortzeit der Seite über 4 Sekunden können es z.b auch nur 30 Seiten sein.

Und hier könnt ihr den SEO SPIDER testen.

Einen SEO Spider bauen

SEO Spider? -> Ein Tool mit dem man ne komplette Website nach gängigen SEO Faktoren analysieren kann, Fehler findet und Verbesserungspotential aufdeckt.

Eigentlich hatte ich damit schon Ende letzten Jahres angefangen. Das Herzstück eines SEO Spiders ist der Crawler oder Spider. Eine Software mit der man alle internen Seiten einer Domain anhand von Links findet. Möglichst auch die, die besonders gut versteckt sind.

Jede Suchmaschine setzt so eine Software ein um alle Seiten einer Domain zu finden. So ganz einfach ist das nicht da es viele verschiedene Arten von URLs gibt (GET Parameter), viele verschiedene Arten intern zu verlinken (relativ, absolut), Subdomains und dann noch so lustige Sachen wie den BASE Tag oder relative Verzeichnissprünge. Ich schätze mal das ist ein Grund warum Google es jedem Website Betreiber ermöglicht XML Sitemaps einzureichen. Man crawlt immer ein bisschen gegen Unbekannt!

Natürlich hätte ich meinen Spider auch um einen fertigen OpenSource Crawler bauen können .. aber wo ist denn da der Spass?

Features

So ein SEO Spider muss einige Dinge können:

  • fehlende Title Tags und Meta Descriptions finden
  • doppelte Title Tags und Meta Descriptions finden
  • HTTP Response Codes auslesen
  • fehlende Headlines finden
  • Meta Robots und den Canonical Tag auslesen

daneben wäre es aber auch noch cool wenn er

  • 301ern und 302ern folgt und anzeigt
  • man bestimmte GET Parameter während des Crawls entfernen lassen kann
  • nur bestimmte Verzeichnisse gecrawlt werden
  • Antwortzeiten der der Website ermittelt
  • Cluster und Verzeichnisse zeigt
  • Levels und Ebenen zeigt
  • Dateigrößen
  • usw.

Ist ja toll ..

Seit einigen Wochen sitze ich an so einem Tool .. das Herzstück .. also der Crawler selbst ist mit 500 Zeilen Code sehr schlank geblieben wie ich finde. Der ist nun auch fertig und ich habe ihn schon ziemlich ausführlich getestet. Aktuell baue ich nun die Analyse und Auswertung und bin gerade etwas im Featurewahn.

Darum habe ich beschlossen heute einfach mal eine Alpha Version zu veröffentlichen: http://www.seorch.de/seo-spider.html um zu sehen ob das Errorlog volläuft und vor allem um vielleicht etwas Feedback zu bekommen.

Diverse Features fehlen noch, Bugs sind sicher auch zu finden und die Crawls sind auf max. 250 Seiten beschränkt (abhängig davon wie schnell der gecrawlte Server antwortet).

Credits an racing_fool mit dem die Urversion des Crawlers entstanden ist und an SenSEO der mich mit seinem Crawler wieder angespitzt hat 🙂

Hier könnt ihr den SEORCH SCANNER testen.

Fronteers 2012

Auch dieses Jahr hat mich mein Arbeitgeber netterweise wieder auf die Fronteers nach nach Amsterdam geschickt.

Für mich persönlich die mit Abstand beste Konferenz rund um Frontend Themen und Webdevelopment .. im legendären Pathe Tuschinski hört man so 2 Tage tolle Vorträge .. trifft viele freundliche Menschen und kann sich vor allem mal über Deutschlands Grenzen hinweg austauschen .. die Veranstalter geben sich richtig viel Mühe und machen nen tollen Job .. Moderator war dieses Jahr Christian Heilmann von Mozilla.

Donnerstag ging es dann los mit:

1. Mark Boulton und Adapting to Responsive Design

  • How responsive design affects business
  • How responsive design affects process
  • How responsive design affects content
  • Fazit: Bericht aus erster Hand was man bei responsive Websites schon in der Umsetzung beachten muss, wo Stolpersteine liegen (Content Fokus, Ads, CMS, Testing, Kosten, grafiklastige Seiten)

2. Addy Osmani und The New And Improved Developer Toolbelt

  • Craftsmanship is about choosing tools well
  • Learn to love the command line. It isn’t scary
  • Sublime Text 2
  • Fazit: Wie der Workflow eines modernen Frontend Devs aussehen sollte (SVN, GIT, Shell, Aliases, SublimeText, SASS, InBrowser Dev Tools, Scaffolding, Testing, Package Management, Generators)
  • Slides

3. Peter-Paul Koch und A Pixel is not a Pixel

  • CSS Pixels Like in width:20px;
  • Device pixels -> the actual pixels on the screen
  • Density-independent pixels
  • Fazit: Einige hilfreiche Tipps für Mobile Development (Viewports für Mobile und Desktop sind unterschiedlich definiert, position:fixed funktioniert nicht wirklich auf Mobile, ‘width’ in einer media query benutzt CSS pixes, ‘device-width’ benutzt device pixels, immer width=device-width in Zusammenarbeit mit Media Queries benutzen)
  • Slides

4. Alex Graul und Using JS to build bigger, better datavis to enlighten and elate

  • Animationen und Visualisierungen mit JavaScript
  • Flash ist fast nicht mehr notwendig
  • IE7 Support = 1/3 der Zeit
  • Fazit: Sehr geile Beispiele was so alles mit JavaScript als Ersatz für Flash möglich ist Miso Project, D3.js, Demo

5. Mathias Bynens und Ten things I didn’t know about HTML

  • body bgcolor=”chucknorris”
  • document.all returns ‘false’
  • Browser sind noch zu nett zu Entwicklern und verzeihen zu viele Fehler
  • Fazit: Hardcore Talk .. und ich wusste definitiv nichts davon .. und frage mich gerade ob ich das überhaupt wissen wollte ..

6. Stephen Hay und Style guides are the new Photoshop

  • Photoshop eignet sich nicht für Mockups von responsive Websites
  • anstatt von PSDs soll man einen Stylguide direkt in HTML entwickeln
  • wartbar, mit Screenshots, automatische CSS Updates, Syntax highlighting etc.
  • Fazit: es gibt nichts auf dem Markt aber mit diversen Tools kann man sich sowas bauen: Dexy, PhantomJS und CasperJS, Template Engines, SMACSS .. ein bisschen CLI chi chi und zack boom ..
  • Slides

7. Antoine Hegeman, Bor Verkroost, Bram Duvigneau & Chris Heilmann und Accessibility panel

  • 3 körperlich behinderte Menschen erklären wie sie mit dem Web umgehen, navigieren und wo sie auf Probleme treffen
  • Fazit: Probleme mit Dropdowns, Touch Devices, wie Websites vorgelesen werden, Semantik ist wichtig, Blinde benutzen meist Custom Screenreader

8. Lea Verou und More CSS secrets: Another 10 things you may not know about CSS

  • Box-shadows mit background-attachment: scroll;, calc(), CSS3 Lightboxen
  • unterstrichene Texte mit CSS, rotating Images, Schatten und Sprechblasen
  • Glass, Blur Effekte mit CSS, Animationen
  • Fazit: die Hälfte gewusst, die andere Hälfte war neu und spannend
  • Slides

Am Freitag:

1. Marcin Wichary und The biggest devils in the smallest details

  • der Meister der Google Doodles, Pacman, Reißverschluss
  • Gamepad API, Google crushinator
  • Creating the doodles always feels a little dirty because you have to deal with different Browsers
  • Fazit: lustiger, spannender und sehr inspirierender Talk, aus dem Google Nähkästchen

2. David DeSandro und Open Source Ain’t Free

  • Quelltext anzeigen ist die beste Quelle für die Arbeit eines Frontend Developers
  • unsere wichtigsten Tools sind eigentlich nur Hobbyprojekte von Entwicklern (HTML5 Boilerplate, Modernizr, Bootstrap)
  • um Zeit für guten Support zu haben muss man damit aber Geld verdienen können
  • Fazit: put a price on it, verlange Geld für Premium Support oder Email Support, verlange Lizenzgebühren für kommerzielle Nutzung, “There is nothing wrong with making money off of honest work”
  • Slides

3. Jeroen Wijering und The State of HTML5 Video

  • Entwickler des JW Players
  • das erste YouTube Video
  • Player wird auf über 1 Million Websites eingesetzt
  • Fazit: Flash ist tot, HTML5 Videos sind schnell, zugänglich, sicher und stabil, 80% aller Webnutzer haben HTML5 video Support im Browser, MP4 und WebM, Kapitelmarken, Untertitel etc.

4. Anne van Kesteren und Building the web platform

  • Harcore Talk über Enconding
  • Browser Layers, Live DOM Viewer
  • Render Tree, Dom Tree, CSS Selecting
  • Fazit: ja .. das war hart .. fast zu detailliert .. einen Nutzen?

5. Phil Hawksworth und I can smell your CMS

  • Frage: braucht man wirklich ein CMS, Kanonen auf Spatzen
  • viele CMS machen mießen Quelltext -> Negatives Beispiel
  • CMS killen Performance .. das schnellste ist immer noch plain HTML
  • Alternativen: Jekyll, Perch
  • Fazit: das erzähle ich seit Jahren .. aber keiner will es hören .. erst mal checken was der Kunde braucht und dann nicht pauschal ein Joomla und Typo3 auf die Website klatschen .. Phil Hawksworth gibt mir Zuversicht
  • Slides

6. Peter Nederlof und Beyond simple transitions, with a pinch of JavaScript

  • Peter animiert nur noch per nativem CSS3,
  • CSS3 Matrix Tool, 3D Canvas
  • warum CSS3 Animationen: keine reflows, Hardware beschleunigt (auch auf Mobile Devices), FPS++, batterieschonend, alle modernen Browser unterstützen die Spec
  • Fazit: Animationen nur noch per CSS, User Interaktion / Start / Stop per JavaScript, beeindruckende Demos

7. Rebecca Murphey und JS Minty Fresh

  • diverse Beispiele üblicher Code Smells .. Wiederholungen, Spaghetticode, riesige Funktionsblocks die 3 Aufgaben hintereinander erledigen
  • don’t Repeat yourself, nutzt Objekte, Data Storage
  • Asynchrone Requests mit while prüfen
  • Fazit: Nichts neues für mich .. mein liebstes Hobby in den letzten Monaten, aber sicher gut für JS Einsteiger und Leute die bisher nur mit jQuery gearbeitet haben
  • Slides

8. Alex Russell und The Web Platform & the Process of Progress

  • Polyfills Are A Tax, Seitengrößen
  • The Price of Delay -> IE8 und IE7
  • Your Browser is outdated!
  • Fazit: Aufruf an alle Webdevs alte Browser auszuschließen um den Fortschritt zu beschleunigen, Beispiele: Facebook, G+, Yahoo Mail, YouTube
  • Slides

Auf der Fronteers 2011 fand ich die Talks etwas fesselnder .. aber vielleicht auch nur weil ich das erste mal dort war.

Übergroße Formelemente für die Darstellung auf Smartphones

Wenn man Formularelemente in einer Website übergroß darstellen möchte muss man sich was einfallen lassen. Den Radiobutton oder die Checkbox kann man nicht einfach per CSS width und height in der Größe variieren.

In meinen Beispiel blende ich die nativen HTML Elemente aus und arbeite nur noch mit den Labels .. hier füge ich dann wahlweise ein grafisches Element oder per CSS gestylte Elemente ein die das selbe verhalten wie die nativen Formularelemente haben.

Hier das komplette Beispiel

CSS3 Tooltips

die ohne JavaScript funktionieren .. ich habe mal 3 verschiedene Arten einen CSS3 Tooltip zu bauen in einem Beispiel zusammengefasst.

Ein HTML5 Data Attribut via :before oder :after Pseudoselector auszulesen ist sicher die sauberste Methode. Allerdings bekomme ich in den Inhalt des Tooltips auch kein Markup. Außerdem eignet es sich auch nicht für lange und umfangreiche Texte da hier ja die Lesbarkeit gewährleistet bleiben muss. (siehe Variante 1)

Eine weitere Methode wäre den Inhalt des Tooltips als Kindelement dem zu öffnenden Element zuzuordnen .. für CSS kein Problem .. allerdings steht dann der Inhalt des Tooltips für Screenreader, Spider und Menschen die ggf. custom CSS zum anzeigen der Seite benutzen direkt im Fließtext. (siehe Variante 2)

Variante 1 und 2 funktionieren per mousehover .. doof für Touch Interfaces und wenn man den Text vielleicht herauskopieren möchte. Variante 3 bedient sich darum beim :target selector .. man muss also explizit auf den Link zum öffnen klicken. Danach wird das versteckte Target Ziel eingeblendet … ein CLOSE Button ist dann natürlich auch notwendig. (siehe Variante 3)

Hier alle CSS3 Tooltips zum testen .. das CSS steht direkt im Quelltext.

Google Venice Update

SEO kommt hier im Blog gerade etwas zu kurz .. aber ich glaube ich muss mal die nächsten Wochen vom coden an SEORCH etwas wegkommen und wieder mehr bloggen.

Venice?

wurde schon Mitte Juni von Google ausgerollt und zielte zu 100% auf lokale Suchergebnisse ab .. diese tauchen nun direkt in den organischen Suchergebnissen auf. Das bedeutet das man von Stadt zu Stadt für den gleichen Suchbegriff unterschiedliche Suchergebnisse erhalten kann.

Google versucht bei jeder Suche den Standort des Users zu ermitteln, zusätzlich ob es ich um eine ortsbezogene Suche handelt (Trigger können hier verschiedene Keywords sein) und blendet dementsprechend Suchergebnisse von lokalen Geschäften, Restaurants, Veranstaltungen usw. ein .. das habt ihr sicher schon gesehen.

Man ging davon aus, daß Google über die IP ungefähr ermitteln konnte wo man sich befand (zumindest in welcher Stadt). Mit Venice wurde nun scheinbar die Genauigkeit gesteigert und Google kann wohl in einigen Fällen bis auf wenige Meter genau ermitteln wo der Suchende sich befindet.

Aha .. und jetzt?

Ganz einfach .. wenn man mit seiner Website oder seinem Produkt eine gewisse Region oder Stadt ansprechen will muss Google das ja irgendwie rausbekommen können.

Die wichtigsten TODOs:

  • der Name der Region oder Stadt muss mehrfach auf den Seiten auftauchen, am besten in TITLE Tags und Headlines
  • eine Landingpage die auf eine bestimmte Region abzielt schadet auch nicht
  • diese Landing Page sollte dann die Adresse der lokalen Niederlassung beinhalten .. am besten nochmal zusätzlich als Microdata oder hCard .. auf jeden Fall gut lesbar im Markup
  • ein ausführlicher Eintrag, mit Link zu Website auf Places for Business ist Pflicht, dieser ist auch Voraussetzung um eine Anzeige in Google+ Local zu bekommen
  • bei Google Mapmaker kann man sich zur Not auch selbst hinzufügen (aber nicht spammen)

Außerdem ..

Sollte man drauf achten das man in Branchenverzeichnissen ebenfalls mit der korrekten Adresse und einem Link zur eigenen Website vertreten ist. Spontan fallen mir da Gelbe Seite, Yelp, Qype usw. ein.

Man sollte peinlichste genau drauf achten das die Adressen die man so im Web verteilt hat nicht voneinander abweichen. Ebenso die lokale Festnetznummer. Bilder als Adresse zu hinterlegen (aus Angst vor Spam) ist Tabu.

Sollte es mehere Möglichkeiten geben wie eine Region oder Stadt benannt ist sollte man eine für sich wählen und überall die gleiche Benamung verwenden.

Wer ganz sicher gehen will reicht noch eine Geo Sitemap ein.

Sich um mindestens 5 Erfahrungsberichte kümmern.

Alle üblichen OnPage und OffPage Regeln beachten die so gerade mal wieder aktuell sind.

Bloß nicht!

  • Postfachadressen oder Handynummern auf der Website verwenden
  • Mehrere Places Einträge faken
  • Unterschiedliche Adressen
  • Mehrere Adressen oder Telefonnummern auf einer Seite
  • Duplicate Content (durch Austausch des Ortsnamens) vermeiden

Meanwhile – CSS3 Loading Animation

Ich hab da mal eine Ladegrafik in CSS gebaut .. funktioniert in Webkit und Firefox .. die Styles für andere Browser müsste man noch ergänzen. Der Browser muss aber zwingend CSS3 transform, animation und keyframes unterstützen.

Ich hab jetzt aufgehört weiter dran zu basteln .. sonst fange ich noch an mit CSS3 ganze Bilder zu malen 🙂

Das CSS steht direkt im Quelltext.

Hier das Beispiel der CSS3 Ladegrafik.