GWT Blog-Serie – Die Vorteile für Entwickler (4/4)

Zum Abschluss meiner Blog-Serie will ich nun noch die Vorteile für Entwickler von GWT Anwendungen aufzeigen. In den Vorherigen Blogposts habe ich bereits erklärt was GWT ist, wie GWT die Performance der Browser optimal ausnutzt und dass sich GWT auf dem mobilen Markt mit jQuery Mobile und Sencha Touch messen kann.

GWT aus Entwicklersicht

Aus Entwicklersicht geht GWT einen komplett anderen Ansatz als andere Web Developer Frameworks. Normalerweise programmiert man in einem Web Developer Framework clientseitigen Code in JavaScript und serverseitigen Code in einer anderen Sprache wie z.B. Java, C# oder PHP.

Bei GWT wird der client- und der serverseitige Code in Java programmiert. Ein GWT Entwickler brauch theoretisch keine HTML Kenntnisse um eine Top Anwendung zu entwickeln. Praktisch gibt es jedoch viele Vorteile wenn man über diese verfügt, spätestens wenn man eigene Widgets programmieren möchte.

Quelle: The Future of GWT Report, 2012, Vaadin

Quelle: The Future of GWT Report, 2012, Vaadin

Vorteile von GWT

Als Entwickler bieten sich durch die Nutzung von Java als Frontend-Sprache diverse Vorteile. Aus einer Umfrage von Vaadin, haben sich die Entwickler für folgende Vorteile ausgesprochen:

Quelle: The Future of GWT Report, 2012, Vaadin

Quelle: The Future of GWT Report, 2012, Vaadin

Debugging

Aus meiner Erfahrung mit JavaScript Frontend Projekten, weiss ich, dass es nicht immer simpel ist JavaScript Code zu debuggen. Vor allem wenn ein Fehler in einer externen Library auftritt, kann das Debuggen sehr aufwändig werden. Clientseitiger Code kann mit GWT direkt in der IDE gedebuggt werden, als wäre es eine normale Java Anwendung, was eine grosse Erleichterung mit sich bringt.

Refactoring

Es können alle Refactoring Funktionen der IDE genutzt werden.

Community

Hinter GWT steht eine grosse Community. Bei Fragen zu GWT findet man z.B. auf Stackoverflow zu fast allen eine Antwort.

Testing

Automatisches Testen von clientseitigem Code ist immer schwierig in Web Anwendungen. Dank der strikten Trennung zwischen Logik und Layout kann auch der clientseitige Code mit allen bekannten Tools aus der Java Welt getestet werden. So können Tools wie JUnit, Test NG, JMock oder andere Mocking-Libraries eingesetzt werden.

Stateless Server

Dank der Stateless Servers lässt sich GWT sehr gut skalieren.

Back-Button Support

GWT verfügt über einem eingebauten Browser-Back-Button Support trotz der ausgiebigen Nutzung von AJAX-Requests. Als Entwickler muss man sich nicht selber darum kümmern.

Schnelles Entwickeln

Wenn man das Konzept von GWT verstanden hat, ist man extrem schnell im Entwickeln mit GWT.

Google App Engine Integration

GWT bietet volle Integration in Google App Engine. Als Entwickler kann man so schnell eine funktionierende App zusammenstellen und veröffentlichen ohne sich grosse Gedanken über den Backend-Server zu machen.

Nachteile von GWT

In der Umfrage von Vaadin wurde auch gefragt, wo die Nachteile von GWT liegen. Hier bin ich nicht mit allen Punkten gleicher Meinung.

Quelle: The Future of GWT Report, 2012, Vaadin

Quelle: The Future of GWT Report, 2012, Vaadin

Widgets

Es stimmt zwar, dass nicht genügend gute Widgets vorhanden sind. Aber ich empfinde das nicht als Nachteil. Denn eigene Widgets sind schnell programmiert. Wer eine coole Web Anwendung programmieren will, der muss so oder so die Widgets anpassen, damit sie seinen Ansprüchen entsprechen. Es gibt ausserdem viele Libraries wie z.B. Smart-GWT, welche besser Widgets anbieten.

Dev-Mode Refresh Time

Dies ist tatsächlich so, dass es etwas lange dauert, bis man seinen Code testen kann. Aber GWT hat den Super Dev Mode eingeführt, womit sich client code ohne neues Kompilieren schnell testen lässt. Für mich persönlich reichte der normale Dev Mode bis anhin. Den Super Dev Mode habe ich noch nicht ausprobiert.

Getting started with GWT is difficult

Weil der Ansatz wie man Webanwendungen entwickelt von GWT ganz anders ist als bei anderen Web Development Frameworks, braucht es einer ernsthaften Einarbeitung, bis man alle Konzepte verstanden hat. So können in clientseitigem Code zum Beispiel nicht alle Features von Java verwendet werden (z.B. kein Reflection).

Viele Wege führen nach Rom

Es werden immer wieder neue Konzepte eingeführt, welche dann ältere ablösen. Das bringt Vor- und Nachteile. So gibt es z.B. verschiedene Ansätze für die Kommunikation zwischen Server und Client oder verschiedene Möglichkeiten wie man Events behandelten kann. Bei der Entwicklung von GWT Anwendungen sollten sich die Entwickler am Anfang auf eine Technik einigen, wenn die entsprechenden Problemstellungen zur Anwendung kommen.

Persönliche Erfahrung mit GWT

Ich startet im Zuge meiner Bachelor Arbeit an der ZHAW in Winterthur mit dem Programmieren in GWT (2012).

Die Aufgabe bestand darin, ein Framework zu entwickeln, womit sich mobile Apps im Baukastenformat erstellen lassen. Der Benutzer der Anwendung sollte die Möglichkeit haben, verschiedene Module auszuwählen und diese dann als App zu publizieren. Der ganze Inhalt sollte im Web verwaltet werden können, wie in einem CMS. Die Entwickler sollten ausserdem die Möglichkeit haben, dass Framework individuell mit neuen Bausteinen zu erweitern, ohne den Core zu bearbeiten. Ein weiteres Key-Feature sollte die Skalierbarkeit sein. Es sollte möglich sein, das App-CMS auf einem Server zu betreiben und damit tausende Apps zu verwalten.

Architektur

Ich habe mich dann für GWT mit MVP-Architektur  für das Frontend und Google App Engine für das Backend entschieden. Alles wird in Java programmiert. Für die Persistenz wurde JDO verwendet.

Somit konnte ich das Framework losgelöst von den App-Bausteinen programmieren. Jeder Baustein konnte dann im Anschluss wiederum für sich entwickelt werden.

MVP-Archtiektur

Die MVP-Architektur ähnelt sehr der MVC-Architektur. MVP heisst Model-View-Presenter.

Ein Baustein besteht aus Client- und Serverklassen. Auf Serverseite bestehen hauptsächlich Model-Klassen. Die Clientklassen werden unterteilt in View-,Presenter- und Eventklassen sowie Proxy-Interfaces für die Servermodels.

MVP Klassendiagramm

MVP Klassendiagramm, Quelle: http://www.gwtproject.org/articles/mvp-architecture.html

AppController

Als Einstiegspunkt des Bausteins steht auf Clientseite der AppController. Dieser ist für die Logik verantwortlich, welche nicht in einem Presenter behandelt werden kann. So lädt dieser zum Beispiel die notwendigen Presenter-Klassen, welche dann für den Rest verantwortlich sind.

Model

Ein Model stellt eine Businessentität dar. Mit Hilfe von JDO-Annotationen werden diese Klassen auf dem Server persistiert. Der Client greift auf ein Proxy-Objekt zu und kann so direkt mit dem Server kommunizieren.

View

Eine View enthält alle UI Komponenten für diesen Baustein. In einer View werden alle Elemente angeordnet und mittels CSS designt. Ein View weiss nicht, welcher Inhalt in die Felder kommt, sondern nur, dass z.B. drei Labels und ein Bild dargestellt werden müssen.

Presenter

Im Presenter wird die ganze Logik abgebildet. Der Presenter lädt die Daten vom Server und bestimmt welche Daten durch die View dargestellt werden. Ausserdem ist er für das EventHandling der UI Komponenten und das History Management verantwortlich.

Um die Kommunikation zwischen View und Presenter zu gewährleisten, werden im Presenter Display-Interfaces definiert, welche von der View implementiert werden.

Struktur
MVP Struktur

MVP Struktur, Quelle: http://www.gwtproject.org/articles/mvp-architecture.html

Entwickeln mit GWT

Wer jetzt auf den Geschmack gekommen ist und mit GWT entwickeln möchte, der Informiert sich am besten unter gwtproject.org. Dort gibt es einige gute Tutorials. Pflicht für jeden Einsteiger ist das MVP Tutorial:

http://www.gwtproject.org/articles/mvp-architecture.html

http://www.gwtproject.org/articles/mvp-architecture-2.html

Wer diese zwei Artikel intensiv durchexerziert wird sehr schnell Spass am Entwickeln mit GWT finden und schnell die Vorteile erkennen gegenüber anderer Frontend Frameworks.

GWT Blog-Serie – GWT im Vergleich zu jQuery Mobile und Sencha Touch (3/4)

mgwt

Quelle: https://code.google.com/p/mgwt/

Wer gegenwärtig ein mobile App entwickelt, der sollte sich vor der Konzeption entscheiden, ob er die App nativ oder als Web-App implementieren will. Die Entscheidung hängt oft davon ab auf welchen Plattformen die App zugänglich sein soll.

Soll die App nur auf einer Plattform verfügbar sein, dann ist die beste Lösung fast immer, die App nativ zu Entwickeln. Soll sie auf mehreren Plattformen erscheinen, dann wird der Kostenfaktor meist zum treibenden Argument gegen eine plattformspezifische Entwicklung, auch wenn die Performance von Animationen und Benutzerinteraktionen nicht das Niveau von nativen Apps erreichen.

Kommen die Entscheidungsträger zu diesem Punkt, fällt die Entscheidung oft auf eine Web-App mit jQuery Mobile. Doch es gibt noch andere Frameworks auf dem Markt, welche mobile Optimierung anbieten. So zum Beispiel Sencha Touch oder MGWT.

Als Mobile-Entwickler bei Namics und während des Studiums habe ich meine Erfahrungen mit all den erwähnten Technologien gesammelt. Ich arbeitete an nativen Apps für iOS und Android sowie plattformunabhängigen Apps mit Sencha Touch, jQuery Mobile und GWT.

Im vorherigen Blogpost ging ich auf die Performance-Optimierung von GWT ein. In diesem Teil meiner Blog-Serie will ich diese drei Frameworks vergleichen und vertieft auf die Performance von MGWT eingehen.

(more…)

GWT Blog-Serie – Wie GWT die maximale Leistung des Browser nutzt (2/4)

Im ersten Teil meiner Serie ging ich auf eine Umfrage über die Zukunft von GWT ein und beschrieb in Kürze, was GWT ist.
Ab 100 Zeilen JavaScript Code soll GWT besser optimiert sein, als würde man den Code selber schreiben. In diesem Teil der Serie, werde ich dieser Aussage auf den Grund gehen.

Performance von GWT dank Compiler

Sobald eine Web Anwendung gebaut wird, welche mehr als 100 Zeilen JavaScript Code verwendet, kann man davon ausgehen, dass GWT den besseren Code auswirft als würde man den Code selber in JavaScript schreiben. Verblüffende Aussage nicht wahr? Ich würde von mir behaupten, dass ich in der Lage sei, bei einem JavaScript von lediglich 100 Zeilen Code, ein Script zu schreiben, welches keine Performance-Leaks umfasst. Doch warum sollte ein von GWT optimiertes JavaScript performanter sein? Der Grund liegt im Java-zu-JavaScript Compiler. Dieser Compiler beschränkt sich nicht darin, den Code perfekt zu minifizieren und zu strukturieren, er offeriert noch einiges mehr.

Features des GWT Compilers:

  • Compile per Browser/Device
  • Dead Code Removal
  • Inlining
  • Renaming
  • Zipping
  • Secure caching

Compile per Browser/Device

Damit die Performanceoptimierung für jeden Benutzer ausgereizt werden kann, wird das JavaScript für jeden unterstützten Browser kompiliert. Dieser kompilierte Code enthält dann alle verwendeten JavaScript und CSS Ressourcen, welche genau für diesen Browser notwendig sind.

browsers

Quelle: http://diminiinc.blogspot.ch/2013/08/windows-browsers-comparison-august-2013.html

(more…)

GWT Blog-Serie – 88.84 Prozent würden Google Web Toolkit wieder einsetzen… (1/4)

Die Firma Vaadin lancierte 2012 eine Umfrage in der GWT Community zum Thema “Zukunft von GWT”. Aus den Antworten von über 1300 Teilnehmern entstand ein 32-seitiger Bericht darüber, wer GWT benutzt, in welchem Umfeld GWT eingesetzt wird, wo die Stärken und Schwächen von GWT liegen und wo der Weg von GWT hinführt.

Back_to_the_Future_gwt

Im ersten Teil meiner Serie gehe ich auf Details dieses Reports ein und beschreibe kurz und knapp was GWT ist.

(more…)

Smashing Conference 2013

Die diesjährige Smashing Conference stand ganz unter dem Motto «Personal Experiences». Das Thema war also offener als es gar nicht hätte sein können & die Speakerliste – quasi das Who is Who der Webszene – liess Grosses erhoffen.

Location: Historisches Kaufhaus

Hier mein Versuch, die Konferenz in drei Kernaussagen zusammenzufassen:

  1. Deciding in the Browser
  2. Progressive Enhancement, Progressive Enhancement, Progressive Enhancement
  3. Have fun!

Deciding in the browser

Die Zusammenarbeit zwischen Design & Frontend steht seit Responsive Web Design vor ganz neuen Herausforderungen.

Tools wie Photoshop, InDesign & Co. stehen in der Kritik dem Multi-Device-Web zu wenig Rechnung zu tragen. Dennoch sind sie DAS Tool für Designer, sich kreativ ausdrücken zu können. Das Designen im Browser wiederum benötigt Frontend-KnowHow & bietet zu wenig Platz für Kreativität. Dazwischen gibt es eine ganze Palette von Tools, die den neuen Umständen gerecht werden wollen, oftmals jedoch bloss Zwischenerzeugnisse für die Tonne produzieren.

Die Zeit ist also mehr als reif sich über den sinnvollen Einsatz/Mix von Kreativtools & Frontend Gedanken zu machen. Dan Mall & Jason Santa Maria haben dies getan & teilten ihre Erfahrungen mit uns. Die beiden leidenschaftlichen Webdesigner sind sich einig:

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context – Dan Mall

Ihr Vorschlag um dies zu erreichen ist so einfach, dass er sich in zwei umgemünzte Zitate packen lässt.

Zitat #1

Current design approach

New design approach

Die Design-Diskussion mit dem Kunden soll also nicht auf Basis von fertig gestalteten, pixelgenauen Designs geführt werden.

Denn was ist mit verschiedenen Screen-Grössen? Vernachlässigbar? Wohl kaum! Ein detail- und pixelgenaues Design verleitet aber dazu, die Design-Diskussion auch auf Level von Detail- und Pixelgenauigkeit zu führen. Dabei wird das Wesentliche – wie fühlt sich die Seite unabhängig von Device & Screen-Grösse an – oftmals ausgeblendet.

Dan Mall schlägt vor, statt dessen als Diskussionsgrundlage Styletiles – oder Visual Inventories o.ä. – zu verwenden.

«The Examiner» Styletiles

«The Examiner» – Projektübersicht

I don’t think we’re in a post-PSD era, but I do think we’re moving towards a post-“full-comp” era – Dan Mall

Anschliessend soll der Prozess in den Browser verlagert werden. Denn nur im Browser kann das Verhalten, die Verhältnisse der Elemente zueinander – unter Berücksichtigung von verschiedenen Screen-Grössen – sinnvoll dargestellt werden. Mit diesem Schritt werden zudem gleichzeitig auch andere Risikofaktoren ausgeschaltet & die Machbarkeit implizit sichergestellt.

Das für mich wichtigste Zitat der ganzen Konferenz folgte postwendend.

Zitat #2

… und wirken lassen …

Der Design-Entscheid soll also in den Browser verlagert werden. Damit hätte man auch gleichzeitig eine wunderschöne Definition of done. Nämlich:

It’s done when it’s done

Progressive Enhancement

Das Konzept von Progressive Enhancement ist so alt, dass man als Frontend Engineer schon fast nicht mehr darüber nachdenkt. Nichtsdestotrotz – oder eben vielleicht gerade deshalb – ist das Thema momentan wieder in aller Munde. Auslöser dafür war Nicolas Zakas Präsentation Enough with the JavaScript Already.

Durch die Verlagerung von Business- und Renderlogik in den Client, steht das bewährte Konzept von Progressive Enhancement erneut auf dem Prüfstand – Client Side Rendering, Model Driven Views etc. vertragen sich nur bedingt mit dem progressiven Gedanken.

Gleich mehrere Speakers – Andy Hume, Ethan Marcotte, Jake Archibald & Jeremy Keith – riefen uns das Konzept – und dessen Bedeutung im neuen Kontext – zurück ins Gedächtnis.

Dabei wurde oftmals der von BBC geprägte Begriff «Cutting the mustard verwendet. «The mustard» ist im Falle von BBC der «Support von HTML5».

  if('querySelector' in document
     && 'localStorage' in window
     && 'addEventListener' in window) {
        // bootstrap the javascript application
  }

Erfüllt ein Browser die Mustard-Kriterien so erhält er die Schöne-Neue-Welt-Version, falls nicht erhält er eine funktionale Core-Version. Die Mustard-Kriterien entscheiden schlussendlich mit über den Grad des «Enhancements».

Its a myth that progressive enhancement means making lowest common denominator designs. Its just about starting there – Jeremy Keith

Eine schöne funktionale Core-Version – die mit sage & schreibe 1 Request auskommt – zeigte Andy Hume am Beispiel der Mobile-Seite von The Guardian. Dieses Extrembeispiel zeigt, dass vor allem im mobilen Kontext – in dem Netzunterbrüche & fehlgeschlagene Requests keine Seltenheit sind – Progressive Enhancement die «gefühlte Verfügbarkeit» einer Seite drastisch verbessern kann.

Have fun!

Web & Spass gehören zusammen. Sei dies bei der Arbeit & natürlich auch überall sonst – auch an der Smashing Conference.

Highlights waren der als Mystery Speaker getarnte Handorgelspieler Klaus Schmidt

… die spontan aus Speakern zusammengewürfelte «Smashing Conference Lonely Hearts Club Band»

… oder das von WordPress grossartig eingehaltene Versprechen

Free Beer All Night Long

Alles in allem war die Smashing Conference bereichernd, bestätigend, trotz Ausnahmen grösstenteils kurzweilig & unterhaltsam, gespickt mit allerlei Würsten vom Markt & inspirierend.

… hoffentlich nächstes Jahr wieder

Weiterführende Links

Progressive Enhancement
That Emil – Progressive Enhancement: Still Not Dead.
Jake Archibald – Progressive enhancement is still important
BBC – Cutting the mustard

Decide in the Browser
Dan Mall – Responsive Design is Hard/Easy! Be Afraid/Don’t Worry!
Brad Frost – The Post-PSD Era … in response … Dan Mall – The Post-PSD Era: A problem of expectations

Mobile Crossplattform Entwicklung auf Basis von Phonegap – Ein Erfahrungsbericht

Ameisen sind fleissig, tatkräftig, rastlos und oft unterwegs, haben aber kein Internet.

Ähnlich geht es den Namics-Mitarbeitern auf so manchem Außendiensteinsatz, die trotzdem auf verschiedene Services angewiesen sind, wie der Zugriff auf sämtliche Mitarbeiter Kontaktdaten, der nicht immer online erfolgen kann. Die in die Jahre gekommene, mobile Weblösung sollte mit einem mobilen Telefonbuch abgelöst werden. Da bei Namics jeder sein eigenes Mobile Phone nutzen darf (BYOD-Philosophie) muss die erstellte Lösung auf möglichst vielen Plattformen laufen. Die Devices sind zu ca. 80% auf iOS und Android verteilt und diese Devices sollen primär auch unterstützt werden.

Idee – Offline Phonebook App für Samartphones

Das ein oder andere Problem kommt einem bekannt vor: die Adressdaten der Kollegen sind nicht aktuell und eine Internetverbindung zum Aktualisieren besteht nicht zwingend unterwegs im Zug oder im Ausland. Die Einbettung der Kontaktdaten über einen Exchange-Account saugt den Akku beim automatischen Datenabgleich leer und Bedarf einer Datenverbindung. Die neue sollte also in jedem Fall auch in Funklöchern funktionieren.

Wie lassen sich diese Anforderungen mit minimalem Programmieraufwand lösen? Wer will, soll direkt aus der App jemanden anrufen, eine SMS, Mails schreiben oder sogar per Skype eine Nachricht hinterlassen können. Und für diejenigen, die immernoch auf ihr altes Adressbuch schwören: auch einzelne Kontakte dort einspeichern.

Ziel ist also zum einen das Unterstützen von verschiedenen Plattformen, aber auch das Nutzen von systemnahen Funktionen. Ein netter Use case, um Phonegap auszuprobieren.

Phonegap? Theorie – Crossplattform

Phonegap ist ein Framework das dazu dient einen Programmcode nur einmal zu schreiben und auf die Vielzahl gängiger Betriebssysteme zu verteilen.

Weniger Programmcode schreiben bedeutet häufig, weniger benötigte Zeit. Weniger Zeit resultiert in einem attraktiveren Kostenrahmen v.a. dann wenn mehrere Plattformen abgedeckt werden sollen. Doch wie sieht es in der Realität aus? Wir haben die neue Version von Phonegap an einem internen Projekt auf Herz und Nieren geprüft.

4 Erfahrungen aus der Crossplattform Entwicklung

  1. Entwicklungsaufwand – Die ersten 80% sind schnell geschafft – danach wirds aufwändig
    Der wahre Umfang der versprochenen Funktionalität lässt sich immer schwer einschätzen. Atomar betrachtet ist jede Funktion als solche realisierbar, sogar mit verhältnismäßig wenig Aufwand. Lässt sich das beliebig skalieren? Harmonieren die angepriesenen Funktionen auch miteinander.
  2. Darstellung geht leider nicht „out of the box“
    Wie in der “konventionellen” Web-Entwicklung auch, nutzen die unterschiedlichen Plattformen verschiedene Browser-Versionen, die ihrerseits verschiedene Funktionen anbieten oder eben auch nicht. Das ist kein Fehler am Grundgedanken des Frameworks (genau so wie HTML und CSS eine schöne Sache sind), erschweren jedoch die angepriesene “write once, run anywhere”-Ideologie.
    Hier kann man leider nicht unterschiedliche Browserfenster parallel bemühen und die Unstimmigkeiten identifizieren. Denn auch hybride Apps sind Konstrukte, die “nativiziert” zu einem spezifischem Fragment des Systems werden. Dieses Fragment muss seinerseits aber auf die jeweiligen Betriebssysteme verteilt werden, die wiederum unterschiedliche Umgebungen wünschen.
  3. Optimieren der dyamischen Elemente zur Laufzeit ist zeitaufwändig
    Einfache Layoutings – wie von üblichen Umgebungen unterstützt – funktionierten nicht und erforderten ein manuelles Manipulieren der sichtbaren Elemente wie zum Beispiel das automatische Anpassen aller Elemente auf gleiche Höhe. Das Programm wird zur Laufzeit interpretiert und speicherverwaltung wird hier klein geschrieben. Es ist der Komfort der nativen Entwicklungsumgebung, der für die Code-Singularität und ihre inhärenten Vorteile aufgegeben wird.
  4. Animationen und Interaktion – Es gilt den grössten gemeinsamen Nenner zu finden
    Vorkompilierter Code muss nicht während der Laufzeit interpretiert werden, was auch bei Animationen eine entscheidende Rolle spielt. Es ist schwierig viele alte Testgeräte parat zu haben, um zu prüfen, auf welchen das Layout noch visuell ansprechend ist und wo nicht. Eine Eingrenzung der Geräte und Firmwares könnte hier natürlich die Vielfalt ebenfalls etwas einschränken.
    Zudem zeichnen sich unterschiedliche Systeme durch ihre vielfältigen Interaktionsformen aus. Ein generischer Ansatz muss diese Vielfalt auf den größten gemeinsamen Nenner bringen, ohne fremd für die jeweiligen Nutzer der verschiedenen Systeme zu sein.

Fazit

Für diesen sehr spezifischen Hintergrund mit klar bekannten Animationen und Interaktionen ist eine Crossplattform-Lösung eine geeignete Wahl, die nichts desto Trotz nur ein universelles, visuelles Erscheinungsbild mit sich bringt, wenngleich mehrere denkbar wären. Die Gefühle bei der Umsetzung des Projektes polarisierten hier sehr stark. Zum einen waren die Herausforderungen gern gesehen, dennoch rief die plattformbedingte Inkompatibilität des Öfteren Verzagen hervor und erforderte neue Lösungsansätze.

Im Entwicklungsalltag stellt vor allem das Sicherstellen der Qualität über alle Gerätetypen und Plattformen eine große Herausforderung dar. Eine Änderung muss unter Umständen auf allen Geräten überprüft werden und es ist nicht immer sichergestellt, dass der Fehler damit behoben ist.
Wir unterstützen derzeit zwei Plattformen (iOS und Android). Phonegap unterstützt offiziell 7 Plattformen (http://phonegap.com/about/feature/). Evtl. (e)skaliert der hybride Ansatz dann erst so richtig?

jQuery Europe 2013, Tag 2

jquery-europe

Am 20 bis 22. Februar fand der europäische Ableger der jQuery Conference statt. Dieser Post besteht aus einer Zusammenfassung von Tag 2 der Konferenz. Die Zusammenfassung von Tag 1 wurde letzte Woche veröffentlicht. jQuery Mobile and Responsive Web Design – … Weiterlesen

jQuery Europe 2013, Tag 1

jqconfeu13

Am 20 bis 22. Februar fand der europäische Ableger der jQuery Conference statt. Als Austragungsort wurde das verschneite Wien gewählt; und mit dem Palais Liechtenstein ein würdiger Veranstaltungsort gefunden (siehe Bilder unten). Rund 400 Besucher trafen sich in Österreich um sich an einem … Weiterlesen

Smashing Conference 2012

Was macht der Frontend-Entwickler ab sofort jedes Jahr in Freiburg im Breisgau? Einen ausgedehnten Spaziergang in der schönen Freiburger Altstadt? Badische Köstlichkeiten genießen? Vielleicht auch, jedoch trifft er wohl ab sofort jedes Jahr auch hochkarätige Entwickler, Philosophen und Zukunftsbildner des Webs.

Am 17. und 18. September 2012 fand die erste Smashing Conference statt. Neben einem ungewöhnlichen Veranstaltungsort konnte sich die Konferenz auch mit einem ungewöhnlich gutem Lineup sehen lassen. Es traf sich ein Teil der Crème de la Crème der aktuellen Webszene in der beschaulichen Idylle nahe der französischen Grenze.

Veranstalter war, wie der Name vermuten lässt, das Smashing Magazine, gemeinsam mit Marc Thiele (u.a. Veranstalter der Konferenz Beyond Tellerrand). Marc Diethelm, Thomas Junghans und Daniel Koch hatten das Vergnügen dieser Konferenz beizuwohnen.

Intro-Trailer zur Smashing Conference

Das Programm bestand aus einem ausgewogenen Mix unterschiedlicher Fachrichtungen aller in der Webentwicklung beteiligten Kompetenzen. Wie ein roter Faden zog sich das Thema “Responsive Design” fast durch jeden Vortrag. Neben konkreten Tipps und Tricks standen neue Prozesse und ein nötiges Umdenken bei den bestehenden Entwicklungpfaden im Vordergrund.

Nachdem die Videos jetzt endlich online zur Verfügung stehen, wollen wir nachfolgend einige vorstellen und verlinken:

The Spirit Of The Web – Jeremy Keith

Beyond Media Queries – Brad Frost

To be announced – Christian Heilmann

Weitere
Weitere Videos übriger Vorträge sind bei Vimeo zu finden.

Fazit

Sollte es dieses Jahr eine weitere Smashing Conference geben – und dies wurde angekündigt – auf jeden Fall vormerken: Eine Konferenz nicht nur für Frontend-Entwickler und definitiv lohnenswert!

Weitere Informationen, berichtende Blogposts sowie Slides der Talks sind unter folgender Adresse zu finden:
http://lanyrd.com/2012/smashingconf/coverage/

Nachtrag:

Wer weitere Informationen zum Thema Responsive Design bei Namics bekommen möchte, dem seien die folgenden Links zu empfehlen:

Blog:

Projekte:

Artikel:

Mobile Business Blog-Serie:
Responsive Web Design — Teil 1: Einführung

slide-27-1024

Responsive Die Darstellung einer Site passt sich an die Gegebenheiten im Browser an um überall eine gute Experience zu bieten. Web Durch URLs addressierbare HTML Info-Ressourcen, verlinkbar durch Hyperlinks. Device-agnostisch. Design Der Prozess um ein Produkt innerhalb eines spezifischen Mediums … Weiterlesen

Page 1 of 3123