Arbeitet ihr mit responsive Design oder mobile template?

[Godzilla]

Es gibt schon sehr gut gemachte Responsive Templates, Google hilft:
https://www.google.de/webhp?ie=UTF-8#q=modified%20responsive%20templates

So ein Zufall aber auch...

Tut euch nur einen Gefallen und testet die Templates ausgiebig mit den euch zur Verfügung stehenden Devices denn es gibt auch Templates mit Serverseitiger Geräteerkennung, bei denen reicht es eben nicht den Screen kleiner zu ziehen...

Wieso? Sind diese "Templates mit Serverseitiger Geräteerkennung" nicht in der Lage zu erkennen wie groß aktuell der Bildschirm ist?
Abgesehen davon handelt es sich nicht um ein responsives Template, wenn dieses erst eine (mit Sicherheit nicht immer aktuelle) Liste abarbeiten muss um dann für das (möglicherweise falsch) erkannte Gerät eine Ausgabe zu generieren. Ein responsives Template passt sich ALLEN Geräten an. Sagt schon der Name.

Daher: Tut euch nur einen Gefallen und testet die Templates ausgiebig und setzt nicht auf die falsche Technik. Eine Gerätekennung kann jeder mit einer Browsererweiterung nach Belieben ändern und Templates die nur auf eine bremsende, wartungsintensive und fehleranfällige "Serverseitige Geräteerkennung" setzen sind dann alles nur nicht responsiv.

[ideeos.de]

Hallo greenhorn,
nicht böse sein - aber ich mag es garnicht, wenn man Fragen "beantwortet", indem man sie mittels Phrasen umschifft.
Wenn Du soviel von SEO verstehst, verstehe ich nicht, warum die Stylesheets und die Javascripts im Headerbereich zu finden sind. Da nicht alle Händler völlig unbeleckt oder neu in der Materie sind wäre es doch sinnvoll durch Leistung zu glänzen. Auch wenn die Optik Deiner Templates gelungen ist - wer will schon in Schönheit sterben?

Das stimmt nicht ganz, denn die Geschwindigkeitsoptimierungen wie JS (CSS ist mir neu!) im Footer sind auf SEO Voragaben ausgelegt. Geladen werden Sie so oder so! Du hast aber recht, einige sind ja bereits im Footer Bereich und die restlichen verschiebe ich auch noch hin. Guter Vorschlag.

Wie bereits im letzten Beitrag geschrieben, bei SEO nicht verlaufen. Und das sind gerade die Dinge, die nicht für den Erfolg entscheidend sein werden. Es gibt weit wichtigeres als das.

Zur Geschwindigkeit, da ist dank modifiedshop schon ein sehr smartes System hinter.

[Matt]

Es ist sicherlich so, dass Geschwindigkeitsoptimierung auch ein Benefit fürs SEO sein können. Aber primär sind sie für den User und sollten daher immer gemacht werden. Denn schnellere Seiten bedeuten geringere Absprungraten und damit vermutlich höhere Conversions.

[squidio]

@Godzilla
Nein, die Serverseitige Erkennung kann nicht die Breite des Gerätes erkennen. Muss es aber auch gar nicht, denn:
1) Die Serverseitige Erkennung ist nur dafür Zuständig z.B. manipulierten PHP Code oder angepasste Grafiken Gerätespezifisch auszuliefern (Was z.B. die Ladezeit einer Seite erheblich beeinflussen kann).
Es hat doch keiner lust darauf einen 1150px breiten Slider mit 4 Bildern auf 300px runterskaliert, oder gar per CSS ausgeblendet, runterzuladen und die entsprechend längere Ladezeit in kauf zu nehmen...
Es ist wohl allgemeiner Usus das jede Sekunde Ladezeit den Shop-Betreiber bares Geld kostet:
http://www.konversionskraft.de/tipps/so-verbrennt-ihr-html-code-1-mio-e-umsatz-pro-jahr.html
2) das ist ja nur eine Ergänzung des Responsive-Design Konzeptes, das greift ja zusätzlich und passt sich JEDEM Gerät an...
3) mit einem ordentlichen Update Rhythmus kann man auch Fehlern bei der Erkennung vorbeugen )

Man kann ja über alles diskutieren aber reale Kunden werden sicher nicht mit einem auf 300px "Kleingezogenem" Browser und umgestellten User-Agent Shoppen gehen, das wirkt mir schon arg konstruiert...
Idealerweise optimiert man für den realen Kunden der von einem Shop ein übersichtliches Design, einen schnellen Seitenaufbau und passende Produkte erwartet!

[Godzilla]

@Godzilla
Nein, die Serverseitige Erkennung kann nicht die Breite des Gerätes erkennen. Muss es aber auch gar nicht, denn:
1) Die Serverseitige Erkennung ist nur dafür Zuständig z.B. manipulierten PHP Code oder angepasste Grafiken Gerätespezifisch auszuliefern (Was z.B. die Ladezeit einer Seite erheblich beeinflussen kann).
Es hat doch keiner lust darauf einen 1150px breiten Slider mit 4 Bildern auf 300px runterskaliert, oder gar per CSS ausgeblendet, runterzuladen und die entsprechend längere Ladezeit in kauf zu nehmen...

Genau dafür gibt es aber clientseitige Lösungen die immer schneller sind als eine serverseitige Erkennung mittels einer langsamen, fehleranfähligen und ständig zu wartenden Liste. Diese Techniken werden ja nicht ohne Grund in moderne Browser eingebaut.

2) das ist ja nur eine Ergänzung des Responsive-Design Konzeptes, das greift ja zusätzlich und passt sich JEDEM Gerät an...

Dieses Konzept sieht häufig aber leider sinngemäß so aus:

Code: PHP  [Auswählen]

if iPhone {
       
}else {
       
}

3) mit einem ordentlichen Update Rhythmus kann man auch Fehlern bei der Erkennung vorbeugen )

Klar. Auf die Kundenbindung sollte man auch immer achten.

Man kann ja über alles diskutieren aber reale Kunden werden sicher nicht mit einem auf 300px "Kleingezogenem" Browser und umgestellten User-Agent Shoppen gehen, das wirkt mir schon arg konstruiert...
Idealerweise optimiert man für den realen Kunden der von einem Shop ein übersichtliches Design, einen schnellen Seitenaufbau und passende Produkte erwartet!

Mit einer serverseitigen Erkennung optimiert man aber einen Shop für alle Kunden die veraltete Technik einsetzen und auf der Strecke bleibt dann die Optimierung für alle anderen Kunden. Aber sowas gab es halt schon immer und früher konnte man solche Seiten daran erkennen, dass unten in der Ecke stand: "Optimiert für den Internet-Explorer"...

[Matt]

Es hört sich komisch an, zumal es aufgrund der Devicevielfalt noch schwieriger ist als im Desktopbereich, aber: (Serverseitiges) Browser Sniffing im mobilen Umfeld ist durchaus beliebt und lange nicht so verpönt wie auf dem Desktop. Gibt sogar spezialisierte Dienste dafür: http://detectmobilebrowsers.com/ oder http://wurfl.sourceforge.net/.

[Godzilla]

@Matt

Das ist schon richtig aber es kommt dann auch darauf an, was mit dem "serverseitigen Browser Sniffing" genau angestellt wird. squidio schreibt dazu:

1) Die Serverseitige Erkennung ist nur dafür Zuständig z.B. manipulierten PHP Code oder angepasste Grafiken Gerätespezifisch auszuliefern

Für die Ausgabe responsiver Bilder gibt es <picture> und entsprechende Polyfills. Daher ist an diesem Punkt "serverseitiges Browser Sniffing" überflüssig und mit Sicherheit NICHT schneller.

Bleibt also nur noch die Ausgabe von "manipulierten PHP Code", der "Gerätespezifisch ausgeliefert" wird.

Das Threadthema lautet: "Arbeitet ihr mit responsive Design oder mobile template?"

Handelt es sich nun um ein responsives Template, wenn dieses mittels serverseitigen Browser Sniffing an mobile Geräte "manipulierten PHP Code" ausliefert oder ist so ein RESS-Template (responsiv webdesign and Server Side Components) nicht strenggenommen ein Template, dass nur "vortäuscht" responsiv zu sein, weil es in Wirklichkeit dann doch ein separates mobile-template auswirft?

Wenn man sich gegen ein separates mobile-template und für ein responsives Template entscheidet (u.a. weil das Suchmaschinen so anraten), dann möchte man doch nicht, dass das vermeintlich responsive Template in Wirklichkeit an mobile Geräte ein mobile-template ausgibt. Oder doch?

[Matt]

Das ist schon richtig aber es kommt dann auch darauf an, was mit dem "serverseitigen Browser Sniffing" genau angestellt wird. squidio schreibt dazu:

1) Die Serverseitige Erkennung ist nur dafür Zuständig z.B. manipulierten PHP Code oder angepasste Grafiken Gerätespezifisch auszuliefern

In dem Fall sind wir natürlich einer Meinung: Das braucht kein Mensch (mehr).

Für die Ausgabe responsiver Bilder gibt es <picture> und entsprechende Polyfills.

Und mit Chrome 38 ist seit gestern auch der erste Browser mit picture-Support stable. \o/

Handelt es sich nun um ein responsives Template, wenn dieses mittels serverseitigen Browser Sniffing an mobile Geräte "manipulierten PHP Code" ausliefert oder ist so ein RESS-Template (responsiv webdesign and Server Side Components) nicht strenggenommen ein Template, dass nur "vortäuscht" responsiv zu sein, weil es in Wirklichkeit dann doch ein separates mobile-template auswirft?

Ich würde sagen: Kommt drauf an. Wenn du z.B. deinen Polyfill für responsive images mit http://adaptive-images.com/ implementierst, dann würde ich noch immer von einem responsive Template sprechen. Wenn du natürlich anfängst, anderen Code auszuliefern, weil du meinst, ein mobiles Device erkannt zu haben, dann nicht mehr.

Wenn man sich gegen ein separates mobile-template und für ein responsives Template entscheidet (u.a. weil das Suchmaschinen so anraten), dann möchte man doch nicht, dass das vermeintlich responsive Template in Wirklichkeit an mobile Geräte ein mobile-template ausgibt. Oder doch?

Korrekt, genau das möchte man nicht. Auch das Debugging wird ungleich schwerer, wenn man auf dem Telefon plötzlich anderen Code bekommt als man durch das einfache zusammenschieben des Browserfensters erhält.

[p3e]

Danke Matt!  http://adaptive-images.com/ kannte ich noch nicht. Sieht ganz gut aus ...

[squidio]

Es ist auch aus meiner Sicht die Frage wie man das technisch umsetzt, es gibt in so einem Shop-System einige Seiten wo es absolut Sinn macht diese z.B. für ein Pad oder Smartphone anders zu strukturieren, mit RWD ist das nicht so einfach möglich ohne sich andere Baustellen aufzumachen.

Ich verstehe auch nicht ganz warum Client-Seitigen Lösungen besser sein sollte?
Ganz im Gegenteil, bei einem Server hab ich als Shop Betreiber die Performance selbst in der Hand. Bei Client-Seitigen Lösungen hab ich es mit vielen Faktoren (Internet-Leitung, Leistung des Endgerätes usw.) zu tun die ich nicht beeinflussen kann, mal ganz abgesehen von dem Overhead den diese Losungen erzeugen.

Im Grunde ist es auch so das die Server-Seitige Erkennung als "Aufsatz" zu verstehen ist, im schlimmsten Fall (nicht erkanntes Mobilgerät) sieht man eben ein normales Responsive Template, wenn es aber funktioniert ist eine deutlich verbesserte User-Experience zu erwarten. Das “Geschäft” erscheint mir ein gutes zu sein!

Für mich ist hier eine gute Referenz sich mal den H&M Shop mit dem Desktop und mit einem Pad aufzurufen.
Die gehen sogar so weit eine veränderte Menüstruktur für das Pad zu erzeugen und mehr mit Filtern zu arbeiten... das macht absolut Sinn aus Usability Sicht.

[Godzilla]

Für mich ist hier eine gute Referenz sich mal den H&M Shop mit dem Desktop und mit einem Pad aufzurufen.
Die gehen sogar so weit eine veränderte Menüstruktur für das Pad zu erzeugen und mehr mit Filtern zu arbeiten... das macht absolut Sinn aus Usability Sicht.

@squidio
Wie ich bereits sagte: Das ist kein responsive Design.
Fehlt eigentlich nur noch, dass Handy-Nutzer noch mit einer dritten Menüstruktur vertraut gemacht werden.

Die "verbesserte User-Experience" besteht darin, dass Kunden des H&M-Shops nun in ihrer Erwartungshaltung bestätigt werden, welche darin besteht, dass sie sich beim Aufruf einer vertrauten Seite mit einem anderen Gerät an eine andere Fehlkonstruktion zu gewöhnen haben. Ist auch eine User-Experience, nur keine gute...

Welche der beiden Menüstrukturen (Desktop / Pad) ist denn "aus Usability Sicht" so schlecht, dass man sie nicht allen Kunden auf allen (richtig erkannten) Geräten anbieten kann?

[helle2007]

ich arbeite mit dem "responsive template" von (( Wir dulden keine kommerziellen Werbelinks - Bitte Forenregeln beachten! )) wenn Interesse besteht?
Gruß Helle