Mischen von Responsive Design und mobilen Vorlagen

Sie benötigen eine mobile Strategie für Ihre Website. Sie müssen sich zwischen Responsive Design oder einer speziellen mobilen Website entscheiden, richtig? Vielleicht nicht. Vielleicht können Sie eine Vielzahl von Strategien kombinieren.

Ich und das Team arbeiten jeden Tag hart an CodePen. Aber wir sind ein Team von drei Leuten. Unsere mobile Strategie besteht darin, uns so gut wie möglich darum zu kümmern, wenn wir 1) Zeit haben und 2) gute Ideen haben, wie wir die Dinge handhaben sollen.

Beispiel für ein responsives Template

Nehmen Sie unsere Seite "Aktuelle Aktivitäten". Diese Seite ist so einfach, dass das Schreiben von ein paar Media Queries, um Dinge neu anzuordnen, und ein wenig JavaScript zum Umschalten der Filter eine gute Lösung ist.

Beispiel für eine mobil-spezifische Vorlage

Schauen Sie sich nun unsere Detailseite auf dem Desktop an.

Diese Seite ist weitaus komplizierter. Sie teilt sich das gleiche Layout wie die Editor-Ansicht. Sie können den Vorschau-Bereich per Drag & Drop größer oder kleiner machen. Es gibt Tastaturbefehle. Sie auf Desktop-Größe zu belassen, war umständlich, da der Text mikroskopisch klein war. Die Verwendung der richtigen Meta-Tags und die Anzeige in mobiler Größe führten zu einem sehr umständlichen Layout und umständlichem Scrollen, wo dies überhaupt möglich war.

Dies war die schlechteste mobile Ansicht auf der gesamten Website.

Ich hätte mit dieser Ansicht einen Krieg mit CSS führen und sie in Form bringen können. Aber selbst wenn ich das getan hätte, wurde eine ganze Menge JavaScript geladen, das keinen Zweck mehr hatte. Stattdessen entschied ich mich für eine mobil-spezifische Vorlage. So konnte ich die vollständige Kontrolle über HTML, CSS und JavaScript übernehmen und nur das laden, was benötigt wurde. Ich konnte fast alles wiederverwenden, weil wir *alles* aus einer modularen Perspektive angegangen sind. Ich konnte die HTML-Partials, JS-Module auswählen und eine neue CSS-Datei mit nur den benötigten Teilen kompilieren – dabei musste ich nur wenig neu schreiben.

Die Detailansicht ist jetzt viel benutzerfreundlicher, ganz zu schweigen davon, dass sie schneller ist.

Für Neugierige: Wir verwenden das Browser-Gem und wählen die zu rendernde Vorlage auf Controller-Ebene aus. Das ist UA-Sniffing, was sich nicht gut anfühlt, aber zumindest ist es serverseitig¹ und basiert auf einem Open-Source-Projekt, das aktuell gehalten wird.

if browser.mobile?
  render :template => 'details/mobile', :layout => "mobile-pages"
else
  render :template => 'details/index', :layout => "pages"
end

Zur Aufzeichnung: Es gibt nichts, was Sie auf der mobilen Version nicht tun können, was Sie auf der Desktop-Version nicht können.

Beispiel für die Ansicht „Ähm, noch nicht ganz fertig“

Nicht jede Ansicht auf CodePen ist bisher gut auf kleinen Bildschirmen. Der Editor, wohl die wichtigste Seite der App, verwendet kein responsives Design oder eine mobile Vorlage.

Er funktioniert auf dem iPad und großen Tablets ziemlich gut, aber kleiner ist nicht so toll. Diese Ansicht wollen wir nicht halbherzig angehen. Das Belassen des Designs in Desktop-Größe hält es benutzbar, bis wir eine gute Idee dafür haben und es direkt angehen können. Es wird sehr wahrscheinlich eine mobil-spezifische Vorlage sein.

Beispiel für mobil-spezifische Teile in einer responsiven Vorlage

Schauen Sie sich unsere Profilansicht an.

Dies ist eine responsive Vorlage. Ich finde, sie funktioniert gut, **außer im Bereich der „Tabs“**, wo sie in zwei Zeilen aufgeteilt ist. Das ist umständlich und wird nicht skalieren, wenn wir möglicherweise mehr Navigation hinzufügen. Stattdessen servieren wir an dieser Stelle eine andere Partial, die eine Navigation als <code>&lt;select&gt;</code>-Menü anstelle von Tabs ausgibt.

Etwas besser, jedenfalls.

Es ist ein Prozess

Ich blogge dies nicht, um CodePen als Leuchtfeuer der mobilen Designperfektion zu präsentieren. Das ist es sicherlich nicht. Ich finde es interessant, über hybride und iterative Ansätze zur mobilen Entwicklung nachzudenken.

Keine separaten Domains/URLs, keine separaten Repositories/Codebasen, keine separaten Teams. Alles zusammen als ein großer Monolith. So wie es meiner Meinung nach sein sollte.

Sehr verwandt

RESS: Responsive Design + serverseitige Komponenten

---

¹ Ich habe das Gefühl, dass serverseitiges UA-Sniffing besser ist, weil 1) die richtige Vorlage sofort geliefert wird, es ist kein Redirect und 2) clientseitiges UA-Testing bedeutet, einen großen Teil an JavaScript nur zu diesem Zweck bereitzustellen.