Mit AJAX Links vor Google verbergen

In der Firma hatte ich letzte Woche wieder die Diskussion ob man Links die mit dem Thema einer Seite nichts zu tun haben vor dem Google Bot verbergen soll oder nicht.

Ich arbeite bei 1&1 wir verkaufen DSL, Mobilfunkverträge, Webspace, Server usw. Wenn sich der Google Bot nun beispielsweise im Bereich Server befindet sollen keine störenden Links zu DSL Produkten zu finden sein. Sondern nur Links die zu artverwandten Themen führen. Man nennt dies eine Clusternavigation. Alle Links eines Themenbereichs sollen sich nur im selben Kategorie-Themen-Cluster bewegen. Also konkret .. keine Links von DSL zu Hostingprodukten.

Problem ist jetzt, das wir das dem User sehr wohl anbieten wollen und auch müssen. Über die Hauptnavigation hat der Kunde jederzeit die Möglichkeit von DSL zu SERVERN zu springen.

Um dies aber dem Google Bot nicht zu ermöglichen sollen Links zu Fremdthemen per Ajax nachgeladen werden.

Dies erfolgt in der Annahme das Google kein JavaScript auf den Seiten ausführt und somit die Links nie zu sehen bekommt.

Mein Kollege Nico hat schon bewießen das selbst ein BASE64 codierter JavaScript Link von Google gefunden wurde.

Headless Browser?

Seit einigen Jahren gibt es allerdings Headless Browser wie z.b. der PhantomJS. Mit diesen kann man auch programmatisch, ohne großen Aufschlag, JavaScript inkl. Ajax ausführen und die Seite also so rendern wie das ein stinknormaler Firefox oder Chrome macht.
Dieser Headless Browser sieht also alles was der User auch sieht. Wenn Google mit Headless Browser crawlt dann kann man per Ajax keine Links verbergen.

Testszenario

Ich habe in einer Seite die sich im Google Index befindet zwei Ajax Requests untergebracht. Diese laden Textdateien in denen sich ein ganz normaler A HREF befindet.
Nach dem Laden werden die Links per JavaScript in den Quelltext eingebunden. Beide verlinkten Seiten habe ich neu angelegt. Sie wurden nicht in Google Chrome aufgerufen und sind auch nirgendwo sonst verlinkt. Beide Seiten haben ein eindeutiges Keyword: PfaffenroterHeavyMetalHamsterpuff und NordKoreanischerPupsnasenEiterich 🙂

Ich bin jetzt mal gespannt was passiert und halte euch direkt hier auf dem laufenden.

Update 14.09.2013

Die zwei Keywords befinden sich nun im Index. (Klickt einfach oben auf die Keywords). Allerdings nicht die Seiten die per AJAX verlinkt sind. Die Keywords habe ich extra auf der Seite von der die Links weggehen nochmal erwähnt um zu sehen wann/ob der Google Crawler vorbei kam.

Update 03.10.2013

Beide Seiten befinden sich immer noch nicht im Google Index. Aktuell gehe ich davon aus, daß Google eine bestimmten Trigger benötigt um die Seiten mit nem Headless Browser aufzurufen. Insofern muss ich derzeit davon ausgehen das sich per AJAX Links vor Google verstecken lassen.

Google scrapen

Über diesen Artikel auf Golem musste ich letzte Woche etwas schmunzeln. Google versucht mit allen Mitteln das maschinelle auslesen von Daten einer Website (scrapen) zu verhindern und hat viele gute Methoden gefunden das zu unterbinden .. aber manchmal schlagen die halt zu früh zu ..

Warum macht Google das?

Googles Daten sind seine heiligen Kühe. Also auch die Suchergebnisse. Weltweit sind viele Firmen dran interessiert mit ihren Keywords ganz oben in Google zu stehen. Oder zumindest vor dem Wettbewerber. Für umfangreiche Analysen usw. geben die dann auch gern viel Geld aus weil jeder natürlich wissen will wie sich das Ranking verändert. Kein Problem wenn man da nur 2 Keywords beobachten will .. aber wenn man täglich viele hundert Keywords im Auge behalten will wird das entweder aufwendig oder recht teuer.

Google verlangt für 1000 API Calls a 10 Suchergebnisse 5 USD und deckelt das dann auch noch auf 10000 API Calls am Tag. Übersetzt bedeutet das, ich kann für 1000 Keywords pro Tag die Top 100 Suchergebnisse bekommen .. dann ist Schluss. Dafür zahle ich dann aber auch 50 USD.

Grund genug um sich drumrum zu hacken ..

Baut man sich nun in der Programmiersprache seiner Wahl einen Scraper der diese URL aufruft: https://www.google.com/search?oe=utf-8&hl=en&num=100&q=seorch wird Google nach ca. 20 – 50 Anfragen einen Captcha vorschalten und die IP von der die Anfrage kommt wird temporär gesperrt.

Okay jetzt kann ich mir natürlich irgendwelche Proxys zusammensuchen oder vielleicht habe ich auch ein paar Server mit verschiedenen IPs im Netz stehen .. oder ich nutze Dienste wie SEO-Proxies, HideMyAss usw. es gibt viele Möglichkeiten und wahrscheinlich noch mehr Ideen das Problem zu lösen .. alle sind mehr oder weniger aufwändig oder kosten Geld.

Zuviel Aufwand find ich doof!

und außerdem möchte ich auch nicht dafür bezahlen .. also nicht Google 🙂 Darum habe ich mir für SEORCH etwas ausgedacht .. naja .. eigentlich fast 9 Monate drauf gebrütet bis ich es dann mal getestet habe.

Ich habe also einen Scraper für Google Suchergebnisse gebaut und außerdem werden in SEORCH selbst (wenn man ein Keyword eingibt) die Top 30 Google Suchergebnisse angezeigt.

Alles kommt von einer einzigen IP Adresse, keine Proxys, keine Verschleierungstaktiken .. einfach etwas Software und eine Idee.

Seit einigen Wochen ist das jetzt auch produktiv online und ich konnte für jede Useranfrage immer 30 – 100 Google Ergebnisse ausliefern.

Wie ich das gemacht habe möchte ich zurzeit noch nicht veröffentlichen .. weil ich noch nicht sagen kann bis zu welcher Anzahl von Anfragen / pro Stunde das funktioniert und ob ich nicht doch irgendwann gegen eine Wand laufe ..

Parallel dazu habe ich noch einen Google Suggest Scraper gebaut der pro Tag derzeit ca. 1000 Anfragen an Google raushaut .. bis jetzt auch noch sehr stabil ..

Ich beobachte das jetzt mal eine Weile und schreibe dann nochmal was dazu.

Das Stinktier

The Skunk ist ein Stockscreener den ich mal kurz mit PHP und Ajax zusammen gebaut habe. Die Idee war eher spontan. Ich selbst handle seit über 10 Jahren mit Wertpapieren und zwei Kollegen von mir ebenfalls. Dabei kam dann irgendwie heraus das jeder von uns so 6-10 verschiedene Seiten besucht um eine Aktie zu bewerten.

Man sammelt diverse Informationen in nem Spreadsheet zusammen und am Ende überlegt man sich obs ne gute Aktie ist oder nicht. Aufwand pro Analyse gut und gerne mal 10 – 15 Minuten.

Datenbasis

Ich habe dann beschlossen das zu beschleunigen und herausgekommen ist theskunk.cc. Gestern habe ich die ALPHA veröffentlicht und ich bin schon ein bisschen zufrieden damit.

Wichtig für so ein Tool sind natürlich die Daten. Soweit es geht versuche ich diese über öffentliche APIs zusammen zu sammeln (Danke Yahoo) aber an vieles kommt man dann doch nicht so einfach ran.

Anbieter von guten Finanzmarkt Daten lassen sich in der Regel fürstlich entlohnen .. und da ist man dann schnell bei ein paar tausend Euro für ein paar einfach API Calls.

Die feine Englische ..

Was macht man also wenn man sich nicht weiterhelfen kann .. man scraped die Daten aus seinen Lieblingsseiten knallhart heraus.

Das ist nicht die feine Art (darum wohl auch The Skunk) .. aber oft die einzige Möglichkeit. Scrapen bedeutet, daß ich die Seiten wie ein normaler Browser lade und mir dann die Infos die ich haben möchte herauskratze.

Das ist natürlich alles andere als wirklich zuverlässig. Aber die Idee hinter Skunk ist einen generischen Scraper zu entwickeln der sich selbst meldet wenn er an Daten nicht mehr herankommt. Idealerweise hat man dann höchstens eine kleine Anpassung im Selector zu machen um die Daten wieder zu sehen.

Das steckt jetzt alles noch in den Kinderschuhen. Aber da ich mich scrapetechnisch mit dem Endgegner (Google) schon angelegt habe .. und dementsprechend weiß was da alles an Hürden auf mich zukommen kann .. wir das sicher ganz lustig.

Außerdem brauche ich ein leichtgewichtiges Projektchen .. SEORCH ist mittlerweile so umfangreich das ich mir schon 2-3 Stunden Zeit nehmen muss wenn ich was anpassen möchte.

The Skunk soll klein, schnell und flexibel bleiben ..

SERP Snippet Tool

Am Freitag erreichte mich die Email von einem Spanier aus Saragossa. Er nutzt wohl schon länger SEORCH und wollte sich eigentlich nur bedanken. Allerdings fragte er ob ich ihm nicht noch ein Tool bauen kann das die Google SERP Snippets simuliert.

Darauf rumgedacht habe ich schon ne ganze Weile .. aber wie so oft wenn man dann doch mal einen Tritt in den Arsch bekommt wirds auch irgendwann was. Außerdem tue ich mich auch eher schwer richtige gute Titles und Descriptions in meine Websites einzubauen.

Woraus so ein Snippet besteht

Klar .. man sieht die Snippets jeden Tag und natürlich kann man die Darstellung beeinflussen. Sofern im Markup der Website vorhanden nutzt Google den TITLE Tag für die Überschrift, die URL für den Link und die META DESCRIPTION für die Beschreibung. Wenn man sich nun mit den Texten etwas mühe gibt kann man die CTR für seine Seite durchaus steigern.

Beachten sollte man dabei, daß der Title nicht mehr als 70 Zeichen und die Meta Description nicht mehr als 160 Zeichen hat. Alles was darüber hinaus geht schneidet Google weg. Natürlich inklusive Leerzeichen.

Etwas jQuery und String Funktionen

Kompliziert zu bauen ist so etwas dann auch nicht. Jedes Input Feld erhält Event Listener auf Keyup und übernimmt einfach die Eingaben des Users für die Vorschau des SERP Snippets und für die Ergänzung des Markups.

Ab einer bestimmten Eingabelänge werden TITLE und DESCRIPTION für das SERP Snippet abgeschnitten. Zusätzlich wird noch angezeigt wie viele Buchstaben man noch eingeben kann.

Hier das JavaScript.

Ideen ..

Jetzt habe ich gerade noch diffuse Ideen um das etwas auszubauen. Etwa mit Messung der Textlänge und der Keyword Dichte .. mal sehen ob ich das in den nächsten Woche noch dazu baue.

Hier findet ihr das SERP SNIPPET TOOL

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