Latest Entries »

WebComponents: Stand der Dinge

Ich habe mir vorhin mal die Google IO 2013 Talks zu WebComponents angesehen. Sehr, sehr spannend, vor allem weil sich viele Dinge heute schon einsetzen lassen. (Auch wenn ich für den produktiven Einsatz noch ein wenig warten würde)

Einführung zu WebComponents: http://www.youtube.com/watch?v=fqULJBBEVQE&list=PL1uo-wZOAVBuqjBLDG_ccZcUEVLwFvBxb

WebComponents in Action: http://www.youtube.com/watch?v=0g0oOOT86NY

Google hat ein Javascript-Polyfill (platform.js) geschrieben um mit folgenden neuen Techniken arbeiten zu können.

  • Mutation Observers
  • Pointer Events
  • Shadow DOM
  • Custom Elements
  • HTML Imports
  • MDV
  • Web Animations

Diese Techniken sind so noch nicht in den Browsern verfügbar. Das Polyfill-Javascript von Google, ermöglicht es aber schon heute all diese Techniken zufriedenstellend zu benutzen.

Alle Source liegen hier: http://www.polymer-project.org/

Wenn die Browserhersteller Stück für Stück die neuen Standards implemetieren wird das plattform.js irgendwann wieder wegfallen können.

 

Polymer bleibt aber (und wird eventuell irgendwan auch mal Standard werden)

Polymer macht ähnliche Sachen wie Angular.js oder Ember.js aber mehr auf Standards basierend.

 

Die Kernprinzipien von Polymer sind:

  • Benutze die Plattform
    • keine Hacks -> gehe zum Chrome-Team und lasse die Platform = RederingEngine fixen
  • Minimiere Boilerplates
    • schreibe nur den Code, der einzigartig für deine App ist
    • Tabs gibt es schon millionenfach benuzte sie nur in deiner Ausprägung
  • Alles, alles, alles ist ein Element
    • Komponentenbasierte Apps
    • Ein PDF Reader in JS kann ein einfaches Element sein. <my-pdfreader src=”myPDF.pdf”></my-pdfreader>

Die Vorteile sind

  • Komplexität wird verringert (= weniger Bugs)
  • Es lassen sich beliebig viele Komponenten zu einer neuen Komponente zusammenbauen. (Youtube Element zusammen mit VoiceInput Element = neues Element)
  • Einmal erstellte Komponenten / Elemente lassen sich ohne Nebnwirkungen in die WebApp einbinden.
  • Es gab vorher auch schon ein scoping nach Konventionen für JS und CSS, das sind aber keine wirklichen Trennungen

Momentane Nachteile:

  • Extra JS, welches geladen und interpretiert werden muss
  • In älteren Browsern wird es langsamer.
    • XHRequests gehen raus.
    • Styles lassen sich nicht scopen
    • Ältere Browser ist der IE9 !!

Soweit der kurze Überblick. Wer etwas mehr in die Tiefe gehen möchte kann sich am Besten das Video ansehen und die Webseite besuchen.

 

Die Financial Times hat eine neue Webapp veröffentlicht und in einem exzellenten Blogartikel ihre Lösung vorgestellt.

http://coding.smashingmagazine.com/2013/05/23/building-the-new-financial-times-web-app/

 

Hier ein paar schnelle lernings, die ich daraus gezogen habe:

  • Flexbox wird sehr langsam, wenn es häufig benutzt wird
  • Sie haben alles modularisiert -> CSS gescoped
  • Retina:
    • Icon fonts
    • Bilder in doppelter Auflösung ausliefern und Compression auf 35 gesetzt
    • Die normalen Bilder hatten Compression von 70
  • Native-like-scrolling

 

  • Offline / Caching
    • So wenig wie möglich im AppCache speichern (Pain in the Ass)
    • Nur Resources, die sich vermutlich nie ändern werden (Fonts / Favicon / Logo)
    • Javascript uns CSS werden per JSON in den localStorage gespeichert und abgerufen

 

Insgesamt ein sehr lesenwerter Artikel.

Ich habe in den letzten Tagen mal etwas intensiver mit Google Now herumgespielt.

Leider gibt es da ja einen recht großen Unterschied zwischen Deutschland und den USA im Funktionsumfang.

Wenn man Google Now sagt werden häufig diese 3 Bereich gemeint:

  • Google Voice Actions
  • Knowledge Graph Ergebnisse
  • Google Now Karten

Hier mal mein Ergebnis für die Google Voice Actions in Deutschland mit Deutsch als Systemsprache.

 

Funktionieren bei mir

  • Rufe das Atlantic Hotel in Hamburg an (Anruf wird aufgebaut – Das Hotel ist nicht bei mir in den Kontakten, die Info zieht er sich aus dem Netz)
  • Sende eine Email an {Vorname Nachname}
  • Anrufen {Vorname Nachname} mobil (_privat_ und _geschäftlich_ funktioniert nicht)
  • Navigiere zu / Fahre zu Arriba Erlebnisbad Norderstedt (Mit Sprachausgabe: Navigation zu Arriba Erlebnisbad)
  • Wo ist das nächste Kino / Supermarkt / Bücherei
  • Fahre zum Supermarkt (Aber nicht: Fahre zum nächsten Supermarkt) Zeigt eine Liste nahe gelegener Supermärkte, die man dann per Klick in der Navigationsapp öffnet
  • Wie weit ist es von hier nach Bremen?
  • Öffne Facbook (Mit Sprachausgabe: Webseite wird geöffnet)
  • Öffne App Facebook (Mit Sprachausgabe: App wird geöffnet – funktioniert aber eher unzuverlässig. Einige Apps werden geöffnet, andere nicht)
  • Kalendertermin erstellen: Abendessen in München am Samstag um 19:00 Uhr
  • Kalendertermin erstellen: Zahnarzt am Donnerstag um 11:00 Uhr morgens (ohne morgens kommt 23:00 dabei raus)
  • Termin morgen 14:00 Uhr Sport
  • Wecke mich morgen um 8 uhr früh (9:00 Uhr Wecker gestellt)
  • Wecker einstellen auf 14 Uhr (Mit Sprachausgabe: Alarm wird eingestellt)
  • Wecker 12 Uhr 30
  • Erinnere mich in 5 Minuten
  • Notiz Sonnenschirm bei Ikea kaufen (Mit Sprachausgabe: Notiz wird gespeichert – Man kann sogar Evernote auswählen)
  • Spiele Peter Fox
  • Spiele Where the wild roses grow (Man kann jeweils zwischen GooglePlay App und Youtube oder weiteren Playeren auswählen)

 

Hier noch ein paar Voice Actions, die aber Ergebnisse vom Google Knowledge Graph ausgeben

Blendet jeweils eine “Google Card” oberhalb der Suchergebnissliste ein

  • Wann ist muttertag 2014
  • Regnet es morgen?
  • Wie sind die Öffnugnszeiten von JamJam in Hamburg?
  • Was ist 10 euro in Hongkong Dollar
  • 100 Dollar in Euro umrechnen
  • 11 prozent von 2500
  • Wo liegt New York
  • Karte von Hamburg
  • Sattelitenkarte von Hamburg
  • Bilder von Schiffen (Öffnet die Bildersuche von Google)
  • Definition Erbschein (Öffnet Google Card mit Definition)

 

Funktionieren nicht (jedenfalls bis heute 22.5.13)

Die folgenden Voice Actions sollen laut unterschliedlichen Angaben im Netz funktionieren, haben bei mir aber keine vernünftige Aktion ausgeführt. (siehe auch: https://support.google.com/nexus/4/answer/2842392?hl=de&ref_topic=2818311)

  • Öffnen {AppName} (funktioniert nicht, öffnet nur Googlesuche oder entsprechende Webseite)
  • Auf Google+ posten: Ich verrreise (Öffnet Websuche)
  • Erinnere mich an Wäsche aufhängen
  • (Musik) hören Peter Fox Haus am See
  • Welcher Song ist das? (Während man auf dem Gerät ein Lied abspielt)
  • Barcode scannen
  • Wecker einstellen auf 19:45 Label Waschmaschine ausschalten

Allgemein finde ich es noch recht kompliziert den genauen Wortlaut zu treffen, um die gewünschte Aktion auszulösen. Ich weiß nicht, ob Siri da wirklich besser ist aber bei den Terminen muss der Text wirklich in der angegeben Reihenfolge gesprochen werden, damit überhaupt erkannt wird, das es sich um einen Termin handelt.

Ich bin aber guter Hoffnung, das Google das in 2-3 Jahren vielleicht in den Griff bekommt… auch für Deutschland.

Was hab ihr für Erfahrungen mit Google Now gemacht? Welche Google Now Sprachbefehle funktionieren bei euch noch?

Diskussionen gerne unter meinem google+ Posting

https://plus.google.com/u/0/103885057599472805071/posts/Kt8pWTJbjtd

 

 

Heute mal nur ein Verweis auf unseren Parship Devblog.
Ich habe da einen Artikel geschrieben über das Testen von mobilen Webapplikationen.

Unsere kleine Testfarm – Testing unserer mobile WebApp

Einige Punkte die ich dabei erkläre:

  • In wiefern kann man sich auf die Simulatoren verlassen?
  • Wie lässt sich mit den realen Geräten auf Team und Testumgebungen testen?
  • Wie kann man auf den Geräten debugging?

Death by AppCache

HTML5 bietet einem tolle neue Möglichkeiten, aber nicht alle Lösungen scheinen mir ganz zu Ende gedacht.

Der Application Cache ist eine großartige Möglichkeit Offline-Applikationen zu erstellen. Man erstellt eine kleine cache.manifest Datei und verweist auf seiner Seite darauf.

CACHE MANIFEST
index.html
stylesheet.css
images/logo.png
scripts/main.js

Dort weden alle Ressourcen aufgelistet, die man offline Verfügbar haben möchte. Zusätzlich cachen die Browser automatisch alle Seiten, die der Nutzer in der Applikation besucht hat (solange sie auch auf die Manifest Datei verweisen.) Das sind die sogenannten MASTER ENTRIES, die sich auch nicht verhindern lassen und eigentlich auch erwünscht sind.

Jetzt kommt aber das Problem: Wenn ich jetzt die Manifest Datei auf dem Server ändere führt dies zu einem refresh in den Browsern. Es werden alle angegebenen Resourcen neu geladen aber auch alle MASTER ENTRIES. Das können bei sehr dynamischen Seiten schnell zu einem Mini DOS führen, da bei tausenden von Nutzern hunderte von Seiten neu herunter geladen werden.

Ich kann nicht genau abschätzen, wie groß das Problem In-The-Wild wirklich ist, habe aber das Gefühl, das das w3c und die Browserhersteller sich darum Gedanken machen sollten. Zum Beispiel ein weiterer Eintrag in der Manifest Datei, die nur die 20 häufigst aufgerufenen Seiten neu herunterlädt und den Rest verwirft.

Ich habe im Internet nicht viel zu dem Thema finden können. Einzig ein Beitrag von Paul Kinlan habe ich finden können. (Von dem ich auch gleich den Titel dieses Eintrags übernommen habe).

Polyfills verantwortungsvoll einsetzen

Hab mir diese Slides (Polyfilling The HTML5 Gaps With JavaScript) von Addy Osmani gerade einmal angesehen und bin noch immer nicht 100% überzeugt.
Polyfills sind für mich immer nur die letzte Lösung. Vielleicht ist das auch eine Blockade in meinem Kopf aber viele Features sollten einfach nicht auf biegen und brechen in alte Browser gezerrt werden. Ich hab da immer so ein Performance fressendes Monster in meinem Kopf.

Ich finde es spannend für große und essentielle Features. Wenn man z.B. mit socket.io die Websockests nachbildet hat man eine prima Abstraktionsschicht und kann tolle Features darauf entwickeln. Da ist Aufwand/Risiko zu Nutzen eventuell gegeben.

Wenn ich aber unbedingt tolle Animationen oder runde Ecken in alten Browsers haben möchte und mir dafür einen riesigen Overhead einhandle rollen sich mir die Zehnägel auf.

5 Regeln für hohe Performance im Mobile Web

Ich hab mir am Wochenende einmal das Video Google I/O 2011: Use Page Speed to Optimize Your Web Site For Mobile angesehen.

http://www.youtube.com/watch?v=_MuVoabSLeY

Neben den üblichen Tipps für Performanceoptimierung, die natürlich auch für mobile gelten, gab es noch ein paar Tipps, die mir nicht bekannt waren bzw. mit interessanten Zahlen untermauert wurden.

Bryan McQuade (technischer Leiter vom Page Speed Team) hat “5 Rules for Mobile Page Speed” näher vorgestellt.

Die wichtigste Regel lautet “Use Application Cache” und leuchtet auch ein. Der Application Cache ist mobile in allen relevanten Browsern vorhanden und kann Roundtrips sowie Downloadzeiten massiv verkürzen, da diese beim zweiten Aufruf nicht mehr anfallen. Diese Regel gilt genauso für Desktop-Webseite, hier ist wie Verbreitung in den Browsern allerdings nicht so groß.

Defer Parsing of Javascript
1Kb Javascript braucht ca 1 Millisekunde zum rendern. Bei einer 100kb Bibliothek würden also ca. 100 Millisekunden für das reine Rendern zusätzlich anfallen. (Wobei ich die Zahlen nicht ganz nachvollziehen konnte. Prototype hat bei ihm eine große von 160kb, was auch mit dem aktuellen Release in unminifizierter Version ohne gzip entspricht. Jquery gibt er aber mit einer Größe von 84kb an. Die 1.7er Version ist aber 240kb unminifiziert.)
Alles in allem soll die Regel aber wohl sagen: Weniger Javascript ist besser, da die mobilen Geräte schwachbrüstig beim Rendern sind.

Make Landingpage redirects cachable
Hier soll hauptsächlich auf redirects verzichtet werden, bzw. die redirects sollen cachable seien, damit der Browser sich unnötige DNS Anfragen und Roundtrips sparen kann.
Der Nutzer gibt z.B. m.foo.com ein und wird auf www.m.foo.com weitergeleitet und von dort wieder auf https://www.foo.com/m.
Sowas kostet unnütz Zeit und sollte also vermieden werden.
Den Cache Header der 301 Seite einfach weit in die Zukunft setzen hilft hier weiter.

Prefer Touch Events
Wenn man ein onclick Event benutzt, wartet ein mobiler Browser 300 bis 500 Millisekunden, bevor er die Anfrage weiterleitet. Diese Zeit nutzt er um herauszufinden, welches Event kommen wird. Also ob es ein Doppelklick wird, oder ein Pinch / Zoom.
Das onTouchStart Event hingegen reagiert sofort und beschleunigt somit die gefühlte Geschwindigkeit für den Nutzer.
(Weitere Informationen findet ihr auch hier dazu: http://cubiq.org/remove-onclick-delay-on-webkit-for-iphone)

Enable Keep-Alive
Damit ist einfach gemeint den Server so zu konfigurieren, das er Keep-Alive für HTTP Requests benutzt und somit nicht für jede Resource, die vom Client angefordert wird eine neue TCP Connection aufmachen soll. Das spart einem eine Menge Overhead beim herunterladen der Ressourcen.

Hier fand ich vor allem die “Prefer Touch Events” Regel interessant. Diese Regel bringt einem satte 300 – 500 Millisekunden for free.

Danach hat noch ein paar Minuten Amir Rozenberg gesprochen. Laut seinem LinkedIn Profil ist er “Head of Mobile Application Performance Monitoring (APM) bei Gomez” Das einzig interessante war hier ein Chart, das er gezeigt hat. Zwölf Prozent der Desktopnutzer verlieren demzufolge nach ca. 1 Sekunde die Geduld und springen ab. Mobilenutzer sind leidensbereiter und warten auch gerne mal 3 Sekunden. Danach sind die 12 Prozent auch wieder abgesprungen.

Zu guter letzt wurden noch ein paar Tools vorgestellt, mit denen man überhaupt die Möglichkeit hat die Geschwindigkeit einer mobilen Seite zu messen.

Page Speed Online
Braucht man nicht viel drüber sagen. URL eingeben und man bekommt das HAR Chart inklusive einer Liste der Verbesserungsvorschläge angezeigt. Also sehr ähnlich zu Page Speed für Firefox oder Chrome.
Der Dienst tweak den User-Agent, damit er die mobile Ansicht der Webseite zu sehen bekommt. Der User-Agent-String lässt sich vom Nutzer aber nicht überschreiben. Page Speed Online kann keine Messungen einer HTTPS Webseite erstellen.

JDrop
Ist von Steve Souders gegründet worden und verfolgt einen sehr interessanten Ansatz. Man ruft ein kleines Bookmarklet in seinem Mobilen Browser auf und bekommt diverse Tools, die einem helfen können die aktuelle Seite zu analysieren.
Die Daten können im mobilen Browser aber auch einfach nur gesammelt und her JSON zur JDrop Seite geschickt werden. Logget man sich dann dort auch ein kann man die gesammelten JSON und HAR Wasserfalldateien am Desktop auswerten.
Ich werde das demnächst mal ausprobieren.

Hier gibt es die Slides der Session als PDF

Der Google Developer Day 2011 in Berlin

Am Samstag (19.11.2011) bin ich auf dem Google Developer Day in Berlin gewesen. Es handelte sich dabei und die Abschlussveranstaltung der GDD World Tour, die unter anderem in Sao Paulo, Prag, Sydney und Berlin stattfand.

Um die Reisekosten nicht zu sehr zu strapazieren haben mein Chef Marc und ich uns für den Termin in Berlin entschieden.
Morgens um 8.30 standen wir mit über zweitausend weiteren Webentwicklern in der Schlange vor dem ICC in Berlin.
Damit war dies auch der größte GDD der außerhalb der USA stattfand.

Anmeldung:

gdd_tag.jpg Bei der Anmeldung gab es dann ein Akkreditierungszettel zum Umhängen, ein weißes T-Shirt des Events (sogar Fair Trade) und einen kleinen Beutel mit 5 Plastik Coins. Auf jedem Coin war das selbe Motiv abgebildet. Insgesamt gab es aber 5 unterschiedlich Motive, die man tauschen konnte. Wer alle 5 Coins gesammelt hat bekam ein Chromebook geschenkt. Per Twitter wurde recht schnell klar, das die Chrome Coins sehr, sehr rar verteilt wurden. Insgesamt wohl 20 Coins, für die einzeln bis zu 100€ geboten wurden.

Keynote:

Voll ausgerüstet ging es dann zur Keynote in den großen Saal 1 des ICC, in dem die Entwickler schon von einem wummerten Bass begrüßt wurden.
Die Keynote wurde von James Whittaker, dem Chef aller Entwickler bei Google geleitet (Neudeutsch: Director Software Engineering) und das durchaus amerikanisch und professionell. Im Gegensatz zu Sparky Rhode der seine Androide Präsentation lieber vorher noch einmal geprobt hätte.
Es gab einen kleinen Rückblick der letzten 20 Jahre des Internets. (Wer von euch hat 1990 schon ein Mobile Phone oder eine Email-Adresse besessen?)
Dann gab es einen Überblick über einige Dinge, die in den Session näher vorgestellt werden sollten. Neue, hippe APIs und Features in Chrome, Androide, App Engine und dem Web Store.

Die Sessions:

Dann begann der Marathon im 45 Minuten Takt. Auf dem Weg zur ersten Session haben wir uns noch schnell bei den Croissants und dem Obst bedient und das ganze mit ClubMate angereichert.
Für mich waren natürlich die Chrome und HTML5 Sessions am interessantesten. Leider blieben die meisten Vorträge für meinen Geschmack etwas zu sehr an der Oberfläche.
Zum Beispiel die Session “Bleeding Edge HTML5″ von Ido Green (Slides) in der er zu großen Teilen Slides von html5rocks.com gezeigt hat. Da hätte ich mir etwas mehr Tiefe gewünscht.

IMG_3996.JPG

Die mit Abstand interessanteste Session war für mich “DevTools Tipps und Tricks” ebenfalls von Ido Green (Slides)
Beim entwickeln bin ich noch immer Firefox/Firebug geprägt und als ich mich vor einem Jahr das letzte Mal intensiv mit den DeveloperTools von Chrome beschäftigt habe, hinkten die noch hinter Firebug hinterher.
Die Zeit ist aber deutlich vorbei. Jeder Webdeveloper sollte noch einmal einen zweiten Blick darauf werfen. Ich werde darüber auch noch einen Blogeintrag verfassen.

Randnotizen:

IMG_3993.JPG Ich fand es erfrischend zu sehen, wie die Entwickler / Redner von Google so ticken. Offensichtlich hält Google diese nämlich nicht nur den Worten nach an der langen Leine, sondern auch unter realen Bedingungen.
So haben die meisten Redner auf ihrem Mac Book präsentiert und dabei einen gesunden Mix von Tools und Webseiten von anderen Unternehmen benutzt.
Es wurden die Twitter-Accounts hervorgehoben, Delicious als Bookmarking Tool benutzt, Flickr zum Bilder teilen. In der Keynote über die Entwicklung des Internets war unter anderem das iPhone abgebildet und kein Androide Phone.
Überraschend war für mich das Rundum-Sorglos Catering von Google. Nerdfood den ganzen Tag. Pizza, Döner, Wraps, Muffins, Bagels und noch vieles mehr. Dazu Cola, Wasser und ClubMate.
So hält man die Entwickler bei Laune :-)

Fazit:

Die Vorträge haben vieles noch einmal in Erinnerung gerufen und einen neuen Blickwinkel für mich ermöglicht. Meine Notizen der Sessions bestehen überwiegend aus kurzen Ideen die sich mir währenddessen aufdrängten, anstelle von konkreten technischen Tipps oder Lösungen.
Dafür hat sich der GDD aber auch wirklich gelohnt.

Bilder des Events:
https://plus.google.com/photos/111133089087698745842/albums/5676649647674963873

Nutzern ein TAFFEE Frontend geben

Hab mal wieder ein wirklich, wirklich großartiger Artikel von Paul Irish gelesen.

http://paulirish.com/2011/tiered-adaptive-front-end-experiences/

Ein Plädoyer für ein tolles Nutzerlebnis, anstelle eines gleichen Nutzerlebnisses in allen Browsern.

Pault nennt dies TAFFEE:
TAFEE (pronounced: taffy): tiered, adaptive front-end experiences. Customizing the experience to the unique capabilities of each browser, prioritizing a fast and good UX over consistency.

Einige Punkte aus dem Artikel
- Optimiere das Nutzererlebnis für alle User. Das bedeuetet zum Beispiel, das ältere IEs eine abgespecktere Variante der Seite bekommen, damit sie schneller gerendert werden kann.
- User benutzen nicht mehrere Browser, um auf deiner Seite zu sufen. Es wird den Meisten also nicht auffallen, das die Buttons mal rund und mal eckig sind.
- Man braucht das Nutzererlebnis nicht immer auf kleinsten gemeinsamen Nenner (Browser) zu beschränken.

Dieser Beitrag auf meinem Google Plus Account.

In Bezug auf mein letztes Post möchte ich einmal kurz teilen, wie ich mit dem Einsatz der neuen Webtechniken umgehe.

Ich habe mir eine Tabelle angelegt in die ich monatlich die Omniture Zahlen für die wichtigsten Browser bei Parship eintrage. (Und die ändert sich in den letzten Monaten ständig, dank der Autoupdates)

In der oberen Reihe stehen die Browser mit ihren Versionen und prozentualen Verteilung aufgeschlüsselt. Links in der ersten Spalte sind ausgesuchte HTML5-APIs, CSS3-Features und DOM-Elemente aufgelistet.
Jeder Browser, der eine der Webtechniken unterstützt bekommt eine 1, alle anderen eine 0 in der Matrix eingetragen.

So kann man auf einen Blick sehen, wieviel Prozent der eigenen Nutzer z.B. schon vom AppCache profitieren würden.
Die Zahlen helfen uns Webdevelopern, beim eigentlich doing, aber auch bei der Beratung der Product Owner für neue Features.

Powered by WordPress. Theme: Motion by 85ideas.