Am Ende ist doch alles HTML

Vortrag auf dem PHPSummit 2012. Die Komplexität des Frontends wird mit vielen Beispielen belegt und eine bessere Kommunikation in Teams gefordert.

Transcript

1. Jens Grochtdreis | webkrauts.de Am Ende ist doch alles HTML
2. • Selbständiger Frontendentwickler • Fachgutachter für Qualitätssicherung • 10 Jahre Agenturerfahrung • 13 Jahre Arbeit im und fürs Web • Gründer der Webkrauts • Blogger (http://grochtdreis.de/weblog) • Autor u.a. PHPMagazin, Webstandards-Magazin, Screenguide • Fachliche Buchbetreuung bei Galileo, O'Reilly, MuT Jens Grochtdreis
3. HTML ist simpel!
4. Im Vergleich zu PHP, Java, Perl, Javascript ... stimmt das sicher!
5. Nicht die Sprache selbst ist das Problem. Es ist die Umgebung!
6. http://bradfrostweb.com/blog/web/mobile-first-responsive-web-design/
7. http://www.flickr.com/photos/fmg2001/679774853/sizes/o/
8. Oft wird das Frontend nebenher gemacht
9. „Typische“ Zeitverteilung • Design und Abstimmung mit dem Kunden • 3 Monate • Umsetzung des Designs in HTML/CSS/JavaScript • 3 Tage • Backendprogrammierung und Implementierung des Frontends • 3 Wochen
10. Frontend ist wichtig • Beim Endkunden kommen HTML, CSS und Javascript an, nicht PHP, Java oder Ruby. • Das Frontend beeinflusst die Performance sehr stark, stärker als das Backend.
11. Typische Frontendaufgaben • source-order für SEO optimieren • Theming • auf mobile Geräte anpassen • responsive Webdesign • Performance • leichte Wartbarkeit
12. Im Frontend läuft alles zusammen.
13. Hier stellt sich heraus, ob das Design bedienbar und wartbar ist.
14. Man erkennt weder ein CMS noch eine Programmiersprache im Frontend.
15. Man erkennt, ob der Entwickler Ahnung und ausreichend Zeit hatte.
16. Das Endprodukt eines Frontendentwicklers ist nur ein Zwischenprodukt.
17. Wir wissen nicht, in welcher Umgebung und in welcher Form unser Endprodukt konsumiert wird.
18. Für Projektmanager und Designer ist das unvorstellbar.
19. http://www.flickr.com/photos/wanhoff/356677564/ Photoshop und Word haben immer EIN Endprodukt.
20. Wir haben viele Endprodukte http://www.flickr.com/photos/danm_cool/3163625498/
21. http://www.flickr.com/photos/artrock2006/4177475479/ Alle Beteiligten sollten frühzeitig offen kommunizieren. http://www.flickr.com/photos/artrock2006/4177475479/
22. Nicht einfach Befehle empfangen. http://www.flickr.com/photos/soldiersmediacenter/3521607551/
23. Voneinander lernen!
24. Schlechte Qualität sieht man http://failblog.files.wordpress.com/2009/10/epic-fail-door-fail.jpg
25. Auch im Internet
26. Auch im Internet http://stern.de
27. Typische Fehler
28. Ein Slider - Grobskizze   IMAGE Kategorie Überschrift Hier steht ein kurzer erklärender Text. Infos Zusatzinfo1 Zusatzinfo2 IMAGE Kategorie Überschrift Hier steht ein kurzer erklärender Text. Infos Zusatzinfo1 Zusatzinfo2 IMAGE Kategorie Überschrift Hier steht ein kurzer erklärender Text. Infos Zusatzinfo1 Zusatzinfo2
29. Mal ohne Semantik
30. Mal mit Semantik
31. Das falsche Element!
32. Warum keine Überschrift? http://www.faz.net/
33. Wir sind in einer Übergangsphase
34. http://thenewdesignguidelines.derekevanharms.com/ Opera Chrome Best viewed in ... (2012)
35. Problematische Strategie Irgendwie bekommen wir das geregelt ... http://blog.crusy.net/wp-content/uploads/2008/09/macgyver.jpg
36. An ein Fallback denken! moderne Browser IE8 http://jsfiddle.net/Flocke/BEJRM/
37. Gutes Fallback http://jsfiddle.net/Flocke/VzSHG/ IE8 moderne Browser Diese Demo arbeitet mit einem CSS3-Selektor. oldIE kann man in diesem Falle mit JavaScript weiterhelfen.
38. Recherche ist wichtig. Und am Ball bleiben!
39. Technische Hürden http://api.html5please.com/
40. http://css3test.com/
41. http://html5please.com/
42. http://caniuse.com/
43. Moderne Techniken helfen Kosten zu sparen!
44. Umgekehrt sollten wir Aufschläge kalkulieren, wenn oldIE eine Extrawurst benötigt.
45. Mögliche Strategie • Genauer definieren, welche Zusatzaufwände eine möglichst gute Simulation moderner Techniken für den IE bedeutet. • runde Ecken und Schatten für die gesamte Site • mit CSS3: 30 Minuten, 1 Frontendentwickler • für oldIE: ca. 4 bis 5 Stunden für den Frontendentwickler, mindestens die gleiche Zeit für Grafik und Backend
46. Graceful Degredation • Fokus ist auf den modernsten Browsern • ältere Browser bekommen eine abgespeckte Version http://stuffandnonsense.co.uk/ - alte version
47. Progressive Enhancement http://www.alistapart.com/articles/understandingprogressiveenhancement/ • Fokus ist auf den Content, denn um den geht es am Ende (fast) immer
48. Brutal Degredation bis einschließlich IE8 moderne Browser http://www.fillerati.com/
49. Graceful degredation in der Realität
50. http://www.flickr.com/photos/jdn/3365996669/ Eine Rolltreppe wird zur Treppe, wenn sie nicht läuft. Die Nutzung ist so prinzipiell gesichert!
51. http://www.flickr.com/photos/markhillary/3187775792/sizes/l/in/photostream/ Eine solche „horizontale Gehhilfe“ soll nur beschleunigen.
52. Zeitersparnis, weil alles in einer Hand ist!
53. http://maddesigns.de/teaserboxen-komplett-ohne-bilder-css3-adventskalender-tag-9-489.html
54. http://jsfiddle.net/Flocke/azvGv/ CSS3-fähiger Browser IE8
55. • runde Ecken • linear-gradient • transform • box-shadow • text-shadow • content-Generierung mit :after und :before
56. Buttons mit CSS3
57. Skalieren mit Inhalt und mit der Seite.
58. http://www.webdesignerwall.com/demo/css-buttons.html
59. runde Ecken
60. Runde Ecken für oldIE http://www.vertexwerks.com/tests/sidebox/
61. Wartungshölle • Für jede Farbe eine eigene Grafik (auch für hover bei Links!) • Runde Ecken auf Verläufen oder Transparenzen sind ganz übel als Grafik • Jede Änderung und Anpassung geschieht in Photoshop/Fireworks • Viele Requests • Keine Skalierung
62. http://jsfiddle.net/Flocke/9mgm7/ Runde Ecken mit CSS3
63. Webseiten sehen nicht überall gleich aus!
64. Einfacher Test • Folgendes in unterschiedlichen Browsern auf Windows XP, Windows 7 und Mac OSX anschauen: • beliebige Webfonts • alle Formularelemente - ungestylt • Checkbox & Radiobutton padding geben
65. Der IE macht viel Arbeit • Je älter der IE wird, umso mehr muss man sich Zeit für seine Fehler nehmen. • Erst ab Version 9 werden moderne Techniken unterstützt. Für ältere Versionen brauchen wir Tricks oder Polyfills. Da kostet nicht nur das Testen Zeit.
66. IE-CSS bei haz.de http://www.haz.de/
67. neue semantische Elemente
68. An die Konsequenzen denken http://code.google.com/p/html5shim/ http://www.modernizr.com/ • HTML5-Seiten funktionieren in alten Browsern nur mittels Javascript. Das betrifft im Wesentlichen IE bis einschließlich Version 8.
69. Mit JavaScript
70. Ohne JavaScript
71. Gut: in Alternativen denken!
72. http://www.deutsche-bank.de/pbc/pk-index.html
73. http://www.deutsche-bank.de/pbc/pk-index.html
78. Hilfe holen
79. Frameworks nutzen!
80. Theorie vs. Realität
81. Mit HTML5 ist alles einfacher und einheitlich
82. HTML5 Video-Testcase • Über ein HTML5-Video einen Layer mit einem oder mehreren Links legen. • Die Links sind auf dem iPad nur anklickbar, wenn man das Attribut „controls“ entfernt. • Dann muss man aber die Bedienelemente mit JavaScript und CSS nachempfinden. • Alle anderen OS sind okay. http://jsfiddle.net/Flocke/durge/
83. Barrierefreiheit kommt in Phase 2!
84. Paradigmenwandel: Barrierefreiheit als nachträglicher Einfall, drangedübelt http://www.flickr.com/photos/beelzebozo/1503756/
85. Barrierefreiheit als integrales Element http://www.flickr.com/photos/pixeldiva/2109688648/
86. http://www.flickr.com/photos/johnmcbride1109/2875819859/ Barrierefreiheit als integrales Element
87. „Barrierefreiheit ist nicht wichtig. Wir haben keine blinden Kunden.“
88. Barrierefreiheit ≠ Webseiten für Blinde • Blinde und Sehbedinderte • körperlich Behinderte (bspw. Contergangeschädigte) • Gehörlose • Lernbehinderte • Farbfehlsichtige http://snipurl.com/11s6vd
89. Barrierefreiheit hat viele Zielgruppen • Durch temporäre Schäden wie einen Armbruch ist man auch in seiner Motorik stark beeinträchtigt. • Ältere Menschen sind weniger aufnahmefähig und sehen schlechter. Diese Zielgruppe wächst stetig und hat die größten Zuwachsraten. • Designing for our future selves!
90. http://images.oddlyspecific.com/oddlyspecific/2009/11/fpthedevilyouknow.jpg Versteckspiel
91. http://images.oddlyspecific.com/oddlyspecific/2009/11/fpthedevilyouknow.jpg
92. Über Barrieren nachdenken
93. Keine vermeidbaren Barrieren • Das Netz ermöglicht es erstmals, dass JEDER auf Informationen zugreifen kann und in Interaktion treten kann. • Warum also sich selber und die Reichweite des eigenen Angebotes beschränken? http://failblog.org/2010/04/08/epic-fail-photos-hand-rail-fail/
94.  Kleiner Bildschirm  Keine Maus  Keine Popups
95. Fokus
96. So nicht!
97. Den Fokus nicht vergessen!
98. Jens Grochtdreis http://grochtdreis.de http://twitter.com/Flocke http://webkrauts.de Diese Präsentation steht unter der Creative Commons Lizenz „Attribution-ShareAlike 2.0“ http://creativecommons.org/licenses/by-sa/2.0/de/