Leser Glynn schreibt:
Ich frage mich, ob Sie jemals ein responsives Webdesign gesehen haben, das einen „gesamte Seite anzeigen“-Link enthielt. Ich weiß, dass wir beim Entwickeln eines responsiven Designs Inhalte nicht komplett verstecken sollten. Einige Benutzer ziehen es jedoch möglicherweise vor, auf ihren Geräten zu zoomen und zu kneifen und klassische horizontale Menüs zu verwenden.
Haben Sie ein Beispiel dafür gesehen und wie glauben Sie, könnte man das angehen?
Ich halte das für eine ziemlich interessante Frage.
Es gab eine Zeit, da haben wir jeden auf eine mobile Version umgestellten oder mit einem „Vollständige Website anzeigen“-Link versehenen Website kritisiert. Aber mit dem Aufkommen des responsiven Designs sehen wir das immer seltener. Tatsächlich bin ich mir nicht sicher, ob ich es jemals auf einer Website gesehen habe, die ausschließlich responsives Design verwendet, um mobile Bildschirmgrößen zu berücksichtigen.
Warum sehen wir kein Opt-out-Responsive-Design? Meine Vermutung ist zweigeteilt:
- Es ist technisch etwas anspruchsvoll zu implementieren und es gibt wenig Vorbilder.
- Es ist ein Eingeständnis, dass man die responsive Gestaltung nicht sehr gut gemacht hat.
Letzteres ist wahrscheinlich der größere Faktor. So nach dem Motto: Warum erstellen wir dieses responsive Design überhaupt, wenn wir uns nicht *sicher* sind, dass es eine bessere Benutzererfahrung ist?
Eine möglicherweise legitime Situation sind unterschiedliche Anwendungsfälle für verschiedene Benutzer. Vielleicht besuchen *die meisten* Benutzer die Website, um zu lesen, und Ihr responsives Design eignet sich sehr gut zum Lesen. Aber einige Benutzer kommen, um eine andere Aufgabe zu erledigen, und für sie behindert das responsive Design.
Umsetzung
Ich habe das noch nicht gemacht, aber theoretisch würde ich es so machen. Das wird einfacher, wenn Sie einen Desktop-First-Ansatz gewählt haben und nicht einen Mobile-First-Ansatz (würde ich denken).
1. Query-Parameter zum Umschalten
Vielleicht
http://yoursite.com/?resp=no2. Viewport-Meta-Tag entfernen und Body-Element klassifizieren
Dann prüfen Sie diesen Parameter. Ich verwende hier nur PHP, aber es könnte alles sein. Wir entfernen das Viewport-Meta-Tag nur, wenn sie kein responsives Design wünschen, und fügen eine Klasse zum Body-Element hinzu.
<head>
<title>My cool site huzzah</title>
<?php
if (!$_GET['resp'] == 'no') { ?>
<meta name="viewport" content="width=device-width">
<?php } ?>
</head>
<body class="<?php if (!$_GET['resp'] == 'no') { echo "resp"; } ?>">Sie werden wahrscheinlich etwas komplexer vorgehen müssen. Sie werden einen Cookie setzen wollen (oder vielleicht localStorage verwenden), um die Präferenz des Benutzers zu speichern. Dann prüfen Sie nicht *nur* den Query-Parameter, sondern *auch* den Wert dieses Cookies, bevor Sie die Entscheidung treffen, das Viewport-Meta-Tag wegzulassen oder nicht (und die Body-Klasse hinzuzufügen).
3. Medienabfrage-Styles qualifizieren
Eine Möglichkeit wäre, das Laden eines separaten Stylesheets auszuschließen, in dem alle Ihre responsiven Stile enthalten sind. Das könnte für Sie funktionieren, aber ich bin generell dafür, so viel CSS wie möglich in einer Datei zu halten. Wenn Sie es in einer Datei belassen, können Sie diese „resp“-Body-Klasse verwenden, um sicherzustellen, dass die Medienabfrage-Styles nicht greifen, wenn sie es nicht sollten.
.page-wrap { width: 80%; }
@media (max-width: 600px) {
.resp .page-wrap { width: 100%; }
}Auf diese Weise greifen die responsiven Stile *nur*, wenn die Medienabfrage übereinstimmt *und* die entsprechende Klasse am Body vorhanden ist, die anzeigt, dass responsive Stile verwendet werden dürfen.
4. Gute Benutzeroberfläche zum Umschalten bereitstellen
Was auch immer Sie sich einfallen lassen, stellen Sie sicher, dass klar ist, wie man zwischen den beiden Website-Stilen wechselt und dass die Cookie-Einstellungen ordnungsgemäß vorgenommen werden.
Ich habe das noch nicht in der Praxis gesehen, habe es aber schon einmal für die Nachrüstung einer Website mit RWD in Betracht gezogen. Das Prinzip war, dass bestehende Benutzer verwirrt sein könnten, da sich das Desktop-Design nicht änderte, daher war es besser, ihnen zumindest die Möglichkeit zu geben, die „Desktop“-Version von ihrem Mobiltelefon aus anzuzeigen.
Ich habe eine Demo geschrieben, wie ich das machen würde: http://neilcarpenter.com/2012/05/creating-a-faux-view-full-site-button-for-responsive-sites/
Und dann habe ich woanders eine weitaus bessere Lösung gefunden, die eine feste Breite im Viewport-Meta-Tag setzt: http://creativeandcode.com/responsive-view-full-site/
Außerdem erlaubt Boris Smus' Device.js (http://github.com/borismus/device.js) im gleichen Sinne das Umschalten zwischen verschiedenen Ansichten on-the-fly – zunächst basierend auf der Viewport-Breite, aber auch manuell vom Benutzer auswählbar. Demo hier: http://borismus.github.com/device.js/sample/desktop.html
Ich habe vor einiger Zeit eine Lösung dafür ausgearbeitet (habe sie auch im CSS-Tricks-Forum gepostet!). Verwendet JS, um das Viewport-Tag zu ändern, erfordert keine Klassenqualifizierung, was zu potenziell aufgeblähtem CSS führt. Verwendet auch localStorage, um die Präferenz des Benutzers zu speichern.
http://creativeandcode.com/responsive-view-full-site/
Ja, das ist dasselbe, was ich mir gedacht habe. Ich habe sogar eine kleine Bibliothek dafür erstellt und sie noch etwas weiterentwickelt.
http://responsiveviewport.com
„ReView ist ein dynamisches Viewport-System, das eine effiziente Auswahl der Ansicht für responsives Webdesign bietet.“
Es stellt sich heraus, dass es recht schwierig wird, wenn man in beide Richtungen wechseln möchte, besonders beim Zoomen der Seite, aber es ist trotzdem machbar.
Wenn jemand helfen möchte, was ich bisher gemacht habe, werde ich es bald Open Source machen.
Ich bin sehr froh, dass Sie den Teil über das Speichern der Präferenz des Benutzers aufgenommen haben. Es ist so ärgerlich, wenn man auf einem Mobilgerät auf „Gesamte Seite anzeigen“ klickt, was einen zur vollständigen Seite weiterleitet, aber sobald man dort etwas anklickt, wird man wieder zur mobilen/responsiven Version zurückgeleitet, anstatt auf der vollständigen Seite zu bleiben.
Ich habe gerade neulich darüber nachgedacht. Es wäre interessant, das zu implementieren und dann Analysedaten darüber zu verfolgen, ob die Leute es tatsächlich nutzen.
Ich stimme definitiv Ihrer Aussage zu, dass, wenn dies gewünscht wird, die responsive Website in einigen Bereichen mangelhaft sein muss.
Das habe ich mich tatsächlich selbst schon gefragt.
Vielleicht wäre das Setzen eines Cookies eine einfachere Option und würde nicht unbedingt serverseitigen Code erfordern.
irgendwie verwandt.
Ich habe css-tricks in Chrome für Android geladen und auf „Desktop-Seite anfordern“ geklickt, um zu sehen, ob das das Ziel dieses Beitrags erreichen könnte. Es funktionierte nicht.
Aber aus irgendeinem Grund sah Ihre Kopfzeilen-Schriftart wie ein Lösegeldbrief mit einer seltsamen Mischung aus fetten und normalen Buchstaben aus. Was ist damit los?
Ich denke, das Wichtigste ist, sich daran zu erinnern, dass man nur wissen kann, was die meisten Leute wollen. Manche Leute sind stur und wollen nichts mit Ihrem schicken responsiven Design zu tun haben.
Anzunehmen, dass jeder Ihre Designs mag, ist töricht und unverantwortlich. Die Leute werden es auf einer Website akzeptieren, weil Ihre Website so ist, aber wenn Sie sie für Mobiltelefone ändern, haben sie jetzt etwas, womit sie es direkt vergleichen können. Manche Leute wollen es auf die alte Art.
„Vertrauen Sie mir, es ist besser für Sie“ ist einfach eine unhöfliche Denkweise. Bedienen Sie die Mehrheit zuerst, aber stellen Sie sicher, dass Sie die Minderheit nicht verärgern. Und die Leute sind sehr verärgert, wenn sie wissen, dass Sie haben, was sie wollen, sich aber weigern, es ihnen zu geben.
Ich denke, diese Art des Denkens ist wichtig. Benutzer zuerst. Seien Sie nicht töricht mit einem responsiven Design und implementieren Sie es schnell nur, weil wir das Gefühl haben, dass wir es tun „sollten“. Es ist alles Kontext – Art der Website, Art der Besucher usw. – basierend auf Forschung und Analyse von Fall zu Fall. Ich bin selbst auf dieses Problem gestoßen, dass ich mir gewünscht hätte, ich könnte auf die vollständige Website zoomen und kneifen – aber das war hauptsächlich auf Websites, bei denen der responsive Aspekt des Layouts schlecht gemacht war und „kleinere“ Dinge willkürlich versteckt wurden.
Eine weitere *große* Hürde ist JS. Einfaches RWD kann mit reinem CSS auskommen, aber JS wird unweigerlich für die komplexe, schwere Arbeit herangezogen. Es ist nicht nur eine Frage des Austauschs von Stylesheets. Sie müssen möglicherweise clientseitige Funktionalitäten für den Anwendungsfall „Desktop-Ansicht skaliert auf Mobiltelefonen“ portieren oder neu schreiben. Nicht schön oder ansprechend.
Ich habe gerade neulich genau darüber nachgedacht, und Sie haben eine Lösung aufgezeigt, die mir nicht eingefallen ist. Das Problem, das ich beim Hinzufügen einer Zeichenkette zur URL sehe, ist, dass, wenn der Benutzer den Link kopiert und irgendwo teilt, er die nicht-responsive Version der Website teilt, was wahrscheinlich nicht wünschenswert ist.
Ich wünschte, ich könnte Ihnen etwas Nützlicheres sagen, das mir eingefallen ist, aber das kann ich nicht. Außer einem Cookie bin ich mir nicht wirklich sicher, was man überhaupt tun könnte?
Im Grunde bin ich zu dem Schluss gekommen, dass, wenn man sich Sorgen macht, ob man einen „Vollständige Website“-Link benötigt oder nicht, man wahrscheinlich nicht in der Lage ist, eine responsive Website zu liefern. In meinem speziellen Fall wurde ich gebeten, ein responsives Stylesheet für ein langjähriges CMS und all seine Kunden zu erstellen. Aus offensichtlichen Gründen ist dies unglaublich komplex und es gibt keinen Weg, ein einziges Stylesheet zu liefern, das für alle Lösungen passt (hauptsächlich, weil ihr Code nicht semantisch ist), daher sind wir aufgrund von Zeitbeschränkungen gezwungen, den Weg der Umleitung zu einer mobilen Website zu gehen.
Wie wäre es, wenn der Link auf sich selbst verweisen würde und JS den Cookie setzt, so dass die URL niemals geändert wird?
PS. Offensichtlich hängt der Klassenname am Body vom Cookie ab...
Nur ein Gedanke
Sie könnten nur example.com/?resp verwenden und dann Ihre If-Bedingung wie folgt aussehen lassen: `if (array_key_exists($_GET[‘resp’]))’`.
Meine Idee, als ich diesen Text gelesen habe, war, es mit etwas kleinem JS zu machen: http://codepen.io/WouterJ/pen/HBukj
Normalerweise mag ich responsives Design bis zu einer bestimmten Breite und danach fest, weil ich kein großer Fan von Textbereichen bin, die zu breit für ihre Höhe sind, wobei lange Absätze oft nur zwei oder drei Zeilen füllen. Das stört die Lesbarkeit, meiner Meinung nach. Wenn Sie Ihre Breite bei einem bestimmten Punkt festlegen, ist es wahrscheinlich besser, zwei CSS-Dateien zu verwenden: eine für die Basis- oder Maximalbreite und eine zweite für alles, was responsiv ist. Auf diese Weise, wenn die URL oder der gespeicherte Cookie besagt, dass sie nicht responsiv sein sollen, müssen Sie nicht einmal die zweite CSS-Datei laden, was möglicherweise viel Bandbreite spart.
Es ist eine zusätzliche HTTP-Anfrage für diejenigen, die das responsive Design DO wollen, aber besonders wenn Sie eine ziemlich komplexe Website haben, können die Einsparungen bei der gesamten Datenübertragung für diejenigen, die es nicht wollen, wirklich ins Gewicht fallen.
Dafür gibt es einige gute Gründe
– wie andere bereits sagten, Benutzer sind verwirrt wegen der Änderungen zwischen Desktop- und Mobilansicht
– responsive Designs, die alte Handys nicht unterstützen (mit meinem Gerät kann ich keine Icon-Schriften sehen, also sehe ich A, M als Navigation… und die Desktop-Version hat vollständige Wörter neben den Icons)
– die Art, wie wir mit Bildern umgehen (max-width: 100%) kann ein Problem sein. Wenn man hineinzoomt, um Details zu sehen (denken Sie an eine Infografik)… kann man das nicht. Natürlich denkt man „langes Antippen und in einem anderen Fenster ansehen“, ja, das mache ich, aber ich habe kürzlich einen Tweet von jemandem gesehen, der sagte: „RWD nervt… ich kann keine Bilder zoomen“.
Müssen wir einen Link mit target: _blank auf alle Bilder legen und ein Icon oder Text hinzufügen, um zu sagen, dass es möglich ist? Vielleicht…
– Seiten mit Codebeispielen. Ich habe *diese* Seite zuerst mit meinem (alten) Handy geöffnet… ich kann den Code nicht sehen, Zeilen sind unterbrochen (fehlendes word-wrap: break-word für kleine Bildschirme?). Das ist oft der Fall (vielleicht geräteabhängig?).
Mit immer mehr Smartphones und RWD-Websites wird das „verwirrende“ Problem meiner Meinung nach abnehmen.
Keine Unterstützung für font-face wird kein langfristiges Problem sein.
Wir können über Bilder nachdenken und dem Benutzer zeigen, dass er sie im Vollbildmodus sehen kann…
Das Argument mit dem Code ist meiner Meinung nach kein Problem, wenn wir es sehen müssen, kommen wir wieder mit einem größeren Bildschirm ; )
Wir hatten eine ausführliche Diskussion über „Sollen Benutzer zu einem responsiven Design gezwungen werden (ohne die Möglichkeit des Opt-out)?“ auf ux.stackexchange. Der Konsens war „nein, Opt-out anbieten“, aber ohne Beispiele aus der Praxis, wie man es macht. Das ist eine schöne Lösung.
http://ux.stackexchange.com/questions/20824/should-users-be-forced-into-a-responsive-design-without-the-ability-to-opt-out
Das vorherige Design Ihrer Website war viel besser.
Ich hoffe, Sie ändern es zurück.
Sie sollten einen Blogbeitrag darüber schreiben und eine ernsthafte professionelle Kritik veröffentlichen, warum die alte Website besser war, das wäre für uns beide hilfreich.
Ich werde diesen Thread schließen, da er nichts mit diesem Artikel zu tun hat.
Wir machen das jetzt in einer Webanwendung, an der ich arbeite (Mobile-First-Design). Die Seite hat zwei Stylesheets
Stylesheet1 enthält alle mobilen und universellen Stile.
Stylesheet2 enthält alle Desktop-spezifischen Stile und wird durch eine Medienabfrage im <link>-Tag qualifiziert. Das <link>-Tag hat auch eine ID.
Wenn der Benutzer die Vollversion erzwingen möchte, wenn die mobile Version angewendet würde oder umgekehrt, haben wir einen Button, auf den geklickt werden kann, um „Zu Mobil|Desktop wechseln“. Wenn Sie auf diesen Button klicken, wird JavaScript verwendet, um die Medienabfrage für Stylesheet 2 zu ändern.
Wenn Desktop erzwungen wird, wird die Medienabfrage auf „all“ geändert. Wenn Mobil erzwungen wird, wird die Medienabfrage auf „none“ geändert.
Dann wird die Präferenz in localStorage gespeichert und bei jedem nachfolgenden Seitenaufruf angewendet, wenn die Präferenz gesetzt ist.
Das Ergebnis ist erstaunlich. Der Wechsel zwischen Layouts ist sofort. Kein Seitenneuladen und kein Warten auf den Download eines weiteren Stylesheets. Funktioniert perfekt für uns.
Natürlich erfordert es JavaScript, aber unsere App benötigt es sowieso schon.
Tolle Idee, hoffentlich können Sie dafür eine Demo machen. :) Danke!
Der „Gesamte Seite anzeigen“-Link auf mobilen Websites ist ein Relikt aus Zeiten, in denen Unternehmen „mobile Lite“-Erlebnisse anboten. Wenn ein Benutzer etwas Kompliziertes tun wollte, musste er die mobile Website verlassen und die Desktop-Website besuchen. Es war eine Flucht aus dem „mobile Lite“ und es funktionierte.
Ich denke, da Designer nun auf Inhalts- (und Funktions-)Parität im responsiven Webdesign abzielen, ist diese Funktion (obwohl in einigen Fällen hilfreich) keine Priorität mehr.
Hallo Pon,
Ihr Punkt ist sehr valide, kann aber nicht auf alle Anwendungsfälle angewendet werden. Zum Beispiel verkauft unsere Website formelle Kleidung für Kinder, daher ist der Großteil unseres Marktes 30-40-jährige Mütter. Sie haben vielleicht das neueste Mobilgerät, surfen aber möglicherweise nicht regelmäßig auf mobilen Websites oder nutzen Apps wie Facebook, wo sie mit mobilspezifischen Navigationsmustern vertraut werden. Manche Leute in diesem Anwendungsfall navigieren einfach lieber mit Menüs, die sie gewohnt sind, und sollten daher die Möglichkeit erhalten. Das bedeutet nicht, dass das Design in irgendeiner Weise mangelhaft ist, es bedeutet lediglich, dass wir als Unternehmen die Vorlieben unserer weniger technisch versierten Kunden nicht ignorieren.
Hallo Glynn,
Ich stimme zu, dass der spezifische Kontext Ihrer Website und die Bedürfnisse Ihrer Zielgruppe Designentscheidungen beeinflussen sollten.
Ich würde die Verwendung einer Query-Zeichenkette vermeiden, da bei der Weitergabe des Links der nächste Benutzer die mobile Version ausgeschaltet hat.
Das ist wirklich die gleiche Beschwerde, die ich über mobile Websites habe. Man geht zur vollständigen Website, wird nervig auf die mobile Website umgeleitet – und wenn man den Link zur Seite teilt, bekommt jeder die mobile Website, selbst wenn er auf einem Desktop ist, weil Ihr Link auf mobile.blah… verweist.
Davon abgesehen halte ich das tatsächlich für eine interessante Frage. Vielleicht ist das aber etwas für den User-Agent, um es zu implementieren!
Gute Frage.
Meine persönliche Meinung ist, dass es nach Niederlage riecht, ein Layout anzubieten, das nicht für den verwendeten Bildschirm optimiert ist… besonders wenn man Zeit damit verbracht hat, es überhaupt optimiert zu machen!
Manchmal stelle ich fest, dass das Gegenteil der Fall ist, die mobile Website ist einfacher zu navigieren und zu bedienen als die superbreite Bildschirmversion. Man interessiert sich nur für einen kleinen Bereich des Bildschirms, aber dieser ist jetzt voller Werbung oder Seitenartikel usw.
Würden Sie eine Option anbieten, um „Einfaches Layout anzeigen“?
Ich hätte auf jeden Fall die Option für bestimmte Websites gerne. Entweder das oder sie erlauben mir immer noch, alles mit dem responsiven Design zu erreichen, wenn ich es brauche. Manche sind viel zu restriktiv!
Ich stimme diesen beiden Gründen auf jeden Fall zu, besonders dem zweiten. Ich denke auch, die meisten Benutzer werden nicht wissen, was das Opt-out aus einer „responsiven“ Version bedeutet. Es ist eine kleinliche Namensgebung, aber meine Eltern würden wahrscheinlich davon ausgehen, dass sie eine träge/langsam ladende Seite anfordern.
Ich hatte vor ein paar Wochen eine sehr ähnliche Idee. Ich denke, bevor wir eine MOBILE Website anzeigen, sollten wir einen „Staging-Bereich“ haben, in dem wir eine schnell ladende Seite mit zwei Schaltflächen und einer Frage anbieten. „Welche Version der Website möchten Sie?“ Mobil oder vollständige Website.
Ich höre *ständig* Leute, die auf ihre Handys schreien wegen einer lustlosen mobilen Website oder in endlose Weiterleitungsschleifen geraten, weil Leute einfach nur eine Variable in eine Website einfügen und nichts damit tun, um sie „gesetzt“ zu halten (Sessions, Cookies usw.). Sobald der Benutzer klickt (oder tippt), ist die Variable weg und BOOM, zurück zur mobilen Website.
Machen wir es besser, Leute!
Ich bin mir nicht sicher, ob das unbedingt die beste Lösung ist. Erinnert an Splashpages.
Außerdem, wie vermittelt man den Unterschied im Inhalt zwischen den beiden Arten von Websites? Was ich suche, wenn ich die Website besuche, könnte in der „mobilen Version“ verfügbar sein oder nicht.
„Manche Leute sind stur und wollen nichts mit Ihrem schicken responsiven Design zu tun haben.“
Dem bin ich auf einer großen Sportnachrichtenseite, die ich betreibe, begegnet, nachdem ich vor einigen Monaten ein adaptives Design eingeführt habe (nicht streng responsiv, da es RESS-Techniken verwendet).
Einige Benutzer beschwerten sich, dass sie es nicht mochten, gezwungen zu werden, das Layout für „kleine Bildschirme“ anzuzeigen, und wollten die Möglichkeit, sich abzumelden und das „Desktop“-Design zu zoomen/kneifen/scrollen, also habe ich eine Cookie-Lösung implementiert, um ihre Präferenz zu speichern. Scheint gut zu funktionieren.
Ich wäre sehr, sehr daran interessiert, Metriken von Leuten zu hören, die Versionen dieser Techniken verwendet haben.
Ich habe das Gefühl, dass „Responsive Design“ bald „tabellenbasierte Layouts“ in all Ihren Lieblings-Webdesign-Einzeilern im Stil von „Erinnern Sie sich an…“ ersetzen wird. Und wir werden erröten, wenn Leute unsere alten Designs ausgraben, bei denen alles zu einem dünnen, riesigen Bein aus endlosen Scroll-Bewegungen zerquetscht wurde.
Wir hören immer wieder von der spannenden Entwicklung des „responsiven Designs“. Aber für mich hat es nichts mit der spannenden Entwicklung von mobilen Browsern zu tun. (Die übrigens bereits sehr, sehr gut darin sind, alte Websites aus der Desktop-Ära darzustellen. Und uns bald, vermutlich, native Möglichkeiten bieten werden, das Laden von Assets relativ zur Bandbreite zu verwalten.)
Kann jemand über seine Opt-out-Metriken sprechen?
Ich habe einen ersten Versuch unternommen, einige responsive Dinge für die Website Friends of the Earth EWNI zu machen, http://www.foe.co.uk. Sie ist bei weitem nicht so elegant wie das, was Chris hier gemacht hat, aber ich habe beschlossen, unten den Link „Vollständige Website wechseln“ einzufügen. Der Hauptgrund, warum ich mich für diesen Link entschieden habe, war, dass die mobilen Designs, an denen ich gearbeitet habe, viel Zeug versteckt haben und ich den Benutzer nicht frustrieren wollte, wenn er nach mehr suchte. Ich bin mir nicht sicher, ob die Implementierung gut war, aber sie hat funktioniert
– Ich habe ein normales, nicht-responsives Stylesheet und ein paar responsive CSS-Dateien.
– Wenn Sie auf den Link „Wechseln zu…“ unten klicken, wird ein Cookie gesetzt und gelöscht.
– Dann prüfe ich in JS, ob es IE <9 ist, ob JS ausgeschaltet ist oder ob der Cookie gesetzt ist. In diesem Fall wird nur das nicht-responsive CSS verwendet. Wenn nicht, werden die responsiven CSS-Dateien gesetzt.
Ich würde das gerne überarbeiten und verbessern (wie z.B. richtig optimieren – das braucht es dringend!), aber wir finden kaum die Zeit dafür…
Jedenfalls war ich wirklich überrascht, diesen Beitrag zu sehen, da ich dachte, ich sei der Einzige, der versuchen würde, einen „Vollständige Website wechseln“-Link auf einer responsiven (na ja) Website einzufügen!
Ich habe keine Statistiken darüber, wie viele Leute darauf klicken, aber ich glaube, ich werde versuchen, ein Event-Tracking hinzuzufügen – stimme anderen Poster zu, es wäre toll, das zu wissen.
Entschuldigung, ich wollte mich nur korrigieren – ich verwende kein JS, um IE <9 oder ob JS ausgeschaltet ist zu erkennen – das wäre Wahnsinn! Ich teste nur mit JS auf den Cookie, die anderen beiden werden mit bedingten IE-Tags und Tags gemacht… Zeit fürs Bett jetzt!
Ich würde gerne eine Analyse zu diesem Thema sehen, ähnlich wie Ihre Zusammenfassung zu responsiven Tabellen; ein Blick auf die verschiedenen Methoden zur Bereitstellung von Links zur mobilen oder vollständigen Version einer Website.
Zum Beispiel bekomme ich oft auf meinem iPad eine iPad-Version der Website, aber ich brauche sie nicht und will sie auch nicht. Ich möchte dieselbe Website sehen, die ich auf meinem Laptop sehe. Mit einem iPad sehe ich keinen Bedarf für eine spezielle Version, da es sehr einfach ist, Seiten anzusehen. Natürlich gibt es Ausnahmen, aber im Allgemeinen würde ich auf einem Tablet lieber die vollständige Website sehen oder zumindest die Option dazu haben.
Toller Artikel und Kommentare. Er kommt genau zur richtigen Zeit, in der ich mit der Entscheidung kämpfe, mit der aktuellen Website, die ich baue, zum responsiven Design überzugehen. Ich habe mir gewünscht, ich hätte eine Schaltfläche wie die von Ihnen beschriebene.
Die Safari-Lesefunktion in der Adressleiste von Safari auf meinem iPhone erledigt das perfekt für meine Website (die nicht responsiv ist). Sie ruft genau die Inhalte von der Titelseite ab, die ich ausgewählt hätte, angezeigt in einer gut lesbaren Schriftgröße in einem Reader-Fenster, das über meine Website gelegt wird. Vielleicht werden Webbrowser in Zukunft eine größere Rolle bei der Optimierung von Websites für Mobiltelefone spielen.
Das könnte eine große Herausforderung sein. Ich sehe jedoch keinen Sinn darin: Wenn Ihre Benutzer die responsive Version ausschalten möchten, warum dann eine responsive Version erstellen?
Ich meine, wenn die Frage aufkommt, ist Ihre UX wahrscheinlich schlecht.
Für mich, auch wenn die Idee interessant ist, würde sie unnötige Komplexität in Webprojekte bringen.
Manchmal möchte ich einfach sehen, wie die „große“ Seite aussieht. Responsives Design kann großartig sein, aber was schadet es, die Option anzubieten, besonders wenn es einfach ist?
Nun, wenn Sie WordPress verwenden, könnten Sie einfach das Theme Switcher Plugin verwenden und Themes haben, die identisch sind, außer dass eines responsiv und das andere nicht ist.
Ich war schon immer ein Skeptiker gegenüber responsivem Design. Ich denke, es IST eine großartige Lösung und sie wird definitiv bleiben. Ich war jedoch schon immer etwas zurückhaltend, wie unsere Branche als Ganzes einfach darauf aufgesprungen ist und entschieden hat: „Das ist die Lösung“.
Ein Teil meiner Zurückhaltung war dieser: Responsives Design „nimmt an“, dass der Benutzer mit massiven Mengen an Scrollen nach oben und unten einverstanden ist. Das ist wirklich eine schlechte Annahme. Viele Leute mögen es, doppelt zu tippen, um in Abschnitte hineinzuzoomen, oder mit Gesten usw. zu zoomen.
Dem Benutzer eine Option zu geben, ist definitiv etwas, über das man nachdenken sollte. Guter Beitrag.
Ich würde persönlich gerne Metriken von Leuten sehen, die auf einen „Website in voller Ansicht anzeigen“-Button klicken. Ich persönlich denke, es ist eine schlechte Idee. Wenn man eine responsive Website richtig erstellt, dann entfällt sicherlich die Notwendigkeit, auf eine Desktop-Website zurückzufallen.
Ich bin persönlich 50/50 bei dieser Sache, es ist eine tolle Frage. Ich kann wirklich keinen Vorteil darin sehen, eine vollständige Website auf einem kleinen Bildschirm anzuzeigen, aber vielleicht ist das die Wahl des Benutzers? Es wird interessant sein zu sehen, wie sich das entwickelt :)
Beachten Sie, dass mobile Browser so konzipiert sind, dass sie „vollständige Websites“ optimal darstellen.
Wenn wir responsiv gestalten (und entwickeln), gehen wir davon aus, dass unser maßgeschneiderter Ansatz für jede Größenklasse ideal ist, aber das ist möglicherweise nicht immer für jeden Benutzer der Fall. Wie Sie andeuten, geht es um die Wahl für den Benutzer.
###Was ist mit dem folgenden 3-Schritte-Verfahren
> Schließen Sie alle Tablet- und Mobiltelefon-Medienabfragen in body:not(.normal-view) {…}
> Beim Klick auf den Schalterbutton
Viewport-Meta-Tag entfernen Hinzufügen der Klasse {.normal-view} im Body
> Benutzereinstellung speichern
Ich denke, es sollte funktionieren.
Habe das selbst im Mai behandelt: http://russellbishop.co.uk/writes/code/responsive-web-design-opt-out/
Aber besser ist es, ein Canonical-Tag für diese Lösung zu verwenden, sonst haben Sie vielleicht Probleme mit duplizierten Inhalten...
Mir gefällt die Idee, dem Benutzer die Wahl zu lassen, wie er eine Website sehen möchte. Aber ich überlege gerade: Macht das in einer Mobile-First-RWD-Website wirklich Sinn?
Guter Tipp, nur ein Kommentar
es wäre besser, wenn Sie verwenden
<?phpif(isset($_GET['resp'])){
// code
}
?>
denn wenn nicht isset verwendet wird, geht PHP davon aus, dass die Variable gesetzt ist und prüft nur, ob sie wahr ist, und löst einen Fehler wegen undefiniertem Index aus.
Uhhh, ehrlich gesagt, was sind die Anwendungsfälle dafür? Benutzer, die mit der Desktop-Version vertraut sind? ...
Ich nenne einen im Artikel.
Das passiert mir bei einem Kunden, er hasst die Idee, dass eine Website nicht gleich aussieht. Ich denke, er hat zu viele schlechte responsive Websites besucht, die die Erfahrung völlig vermasseln... aber am Ende des Tages bezahlt er die Rechnungen und seine Meinung ist: "Ich möchte nur ohne Zweifel wissen, dass alles da ist und ich nichts vermisse."
Ich persönlich denke, dass das Anbieten eines Opt-out-Links in diesen Fällen eine großartige Idee ist. Zugegebenermaßen haben die meisten Browser die Option "Desktop-Version anfordern". Aber meiner Meinung nach ist der Benutzer, der "die vollständige Desktop-Version" möchte, wahrscheinlich auch der Typ Benutzer, der sich nicht durch App-Menüs wühlt. Ich weiß es nicht, das ist eine Vermutung.
Es ist jedoch so einfach zu implementieren.
Großartig. Ich dachte gerade daran, mit dem Erlernen von Responsive Webdesign und Media Queries zu beginnen und ein paar wirklich wichtige Dinge zu erfahren. Danke für den Artikel.
Mit freundlichen Grüßen,
TheIToons.
Ich halte das für eine großartige Idee. Nicht alle mobilen Websites sind großartig und die Option zu haben, wäre meiner Meinung nach von Vorteil.
Ich habe gemischte Gefühle dazu. Obwohl ich zustimme, dass gutes RWD bedeuten sollte, dass die UX für die wichtigsten Bildschirmgrößen optimiert ist, bin ich der Meinung, dass es einen Fall gibt, in dem eine Desktop-Version verfügbar sein sollte.
Abgesehen von den gültigen Gründen, die in den Kommentaren genannt werden – insbesondere das Zoomen von Bildern und das Gefühl des Benutzers, möglicherweise nicht die "vollständige" Erfahrung zu erhalten – hat der Benutzer möglicherweise ausdrücklich "Desktop-Site" in seinen Browsereinstellungen angefordert. Solange ich keine mobile Version einer Website mit dem Präfix "m." aufrufe, hat diese Einstellung bei responsiven Websites keine Wirkung. Oder besser gesagt, sie bewirkt etwas (ändert den User-Agent), hat aber keine Auswirkung.
So sehr ich mich auch hasse, wenn ich es vorschlage: Könnte dies ein gültiger Grund für User-Agent-Sniffing sein? Wenn der User-Agent "mobile" ausschließt – aber die Viewport-Größe etwas anderes vermuten lässt –, können wir dann davon ausgehen, dass der Benutzer die Desktop-Version anfordert und entsprechend handelt?