nicht angemeldet
Mobile Device
Matthias Apsel
Gunnar Bittersmann
Auge
MudGuardMoin,
gibt es eine Version/URL vom Forum + Wiki für mobile Geräte (z.B. Samsung S4 Mini)?
Gruß
-
Om nah hoo pez nyeetz, Jörg!
gibt es eine Version/URL vom Forum + Wiki für mobile Geräte (z.B. Samsung S4 Mini)?
Nein.
Matthias
-
@@Matthias Apsel:
nuqneH
gibt es eine Version/URL vom Forum + Wiki für mobile Geräte (z.B. Samsung S4 Mini)?
Nein.
Und das ist auch gut so.
Weniger gut ist, dass die bestehende Plattform auf kleinen mobilen Geräten nicht die beste Figur macht.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Hallo!
Weniger gut ist, dass die bestehende Plattform auf kleinen mobilen Geräten nicht die beste Figur macht.
Irgendwelche Ideen, um es zu verbessern?
Oder was ist mit »bestehende Plattform« gemeint?
Mathias
-
Om nah hoo pez nyeetz, Gunnar Bittersmann!
gibt es eine Version/URL vom Forum + Wiki für mobile Geräte (z.B. Samsung S4 Mini)?
Nein.
Und das ist auch gut so.Für das Wiki könnten wir sicher eine Wikipedia-Variante anpassen, dann allerdings aber auch mit m.wiki.
Weniger gut ist, dass die bestehende Plattform auf kleinen mobilen Geräten nicht die beste Figur macht.
Mein (visueller) Eindruck vom Forum auf kleinen mobilen Endgeräten ist der, dass einzelne Threads (nested-Ansicht) vernünftig dargestellt und auch lesbar sind, die Startseite aber nicht so prall ist. Das liegt natürlich vor allem am thread-Baum, der horizontales Scrollen erfordert.
Ich habe auch noch keine wirklich passende Angabe für meta viewport gefunden.
Für Vorschläge bin ich offen.
Matthias
-
Mein (visueller) Eindruck vom Forum auf kleinen mobilen Endgeräten ist der, dass einzelne Threads (nested-Ansicht) vernünftig dargestellt und auch lesbar sind, die Startseite aber nicht so prall ist. Das liegt natürlich vor allem am thread-Baum, der horizontales Scrollen erfordert.
Ich bezweifle auch, dass man mit demselben HTML eine schönere Darstellung hinbekommt. (Ich stehe auch nicht kategorisch wie Gunnar einer »Mobilversion« entgegen.) Der Threadbaum ist so ausufernd, weil er ständig dieselben wiederholt, nur mit einer weiteren Einrückungsebene:
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
(ZU DIESEM FORUM) Mobile Device von Matthias Apsel, 14.01.2014, 21:45
(ZU DIESEM FORUM) Mobile Device von Gunnar Bittersmann, 14.01.2014, 23:41
(ZU DIESEM FORUM) Mobile Device von Matthias Apsel, 15.01.2014, 08:46
(ZU DIESEM FORUM) Mobile Device von molily, 15.01.2014, 00:53*Falls* ich denn die volle Baumdarstellung auf der Startseite haben möchte, würde folgendes ausreichen:
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53Denn der Titel und der Themenbereich haben sich nicht geändert. Das tun sie im Allgemeinen recht selten (vielleicht ein- bis zweimal in einem Thread mit 25 Posting). Wenn sie sich ändern tun, kann ich diese Infos beim Posting, das sie ändert, anzeigen, muss sie bei Antworten aber nicht wiederholen.
Letztlich ist die Forumshauptseite auch einfach zu lang, um auf Mobilgeräten schnell zu laden. Da es weniger Postingaufkommen gibt, sind die Thread am Ende schon mehr als einen Monat alt. Hier könnte der »Schwanzabschneider« Postings ruhig schneller archivieren.
Mathias
-
Moin,
Letztlich ist die Forumshauptseite auch einfach zu lang, um auf Mobilgeräten schnell zu laden. Da es weniger Postingaufkommen gibt, sind die Thread am Ende schon mehr als einen Monat alt. Hier könnte der »Schwanzabschneider« Postings ruhig schneller archivieren.
Hm, manchmal gibt es auch nach längerer Zeit erst eine Reaktion auf so einen Thread, deshalb denke ich die Archivierung ist ok. Aber vielleicht könnte man in Javascript-fähigen Browsern nicht die gesamte Hauptseite laden, sondern nur die ersten 10-15 Threads und dann dynamisch nachladen?
Grüße Marco
--
Ich spreche Spaghetticode - fließend. -
@@molily:
nuqneH
Ich bezweifle auch, dass man mit demselben HTML eine schönere Darstellung hinbekommt. (Ich stehe auch nicht kategorisch wie Gunnar einer »Mobilversion« entgegen.)
Wenn »Mobilversion« heißt, unter demselben URI per content negotiation eine angepasste Darstellungsvariante auszuliefern, gerne.
Wenn »Mobilversion« heißt, unter einem anderen URI (m dot) dieselben Inhalte auszuliefern, nein.
*Falls* ich denn die volle Baumdarstellung auf der Startseite haben möchte, würde folgendes ausreichen:
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53Denn der Titel und der Themenbereich haben sich nicht geändert. Das tun sie im Allgemeinen recht selten (vielleicht ein- bis zweimal in einem Thread mit 25 Posting). Wenn sie sich ändern tun, kann ich diese Infos beim Posting, das sie ändert, anzeigen, muss sie bei Antworten aber nicht wiederholen.
Genau das hatte ich auch schon im Sinn.
Und dafür braucht man auch keine »Mobilversion«. Denn die ständige Wiederholung desselben Postingtitels ist auch auf Desktopgeräten nicht sinnvoll.
Mobile first rulez.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
@@all:
nuqneH
Ich bezweifle auch, dass man mit demselben HTML eine schönere Darstellung hinbekommt. (Ich stehe auch nicht kategorisch wie Gunnar einer »Mobilversion« entgegen.)
Wenn »Mobilversion« heißt, unter demselben URI per content negotiation eine angepasste Darstellungsvariante auszuliefern, gerne.
Wenn »Mobilversion« heißt, unter einem anderen URI (m dot) dieselben Inhalte auszuliefern, nein.
Ich finde: Weder noch!
Welche "typischen" Anwendungsszenarien gibt es denn, wenn jemand das Forum nicht am Desktop betrachtet (mal davon abgesehen, er hat nur Mobile Devices)?Ich könnte mir u.a. folgende Fälle denken:
- Jemand möchte einen neuen Thread starten
- Jemand möchte einen Thread, in dem er selbst gepostet hat, weiter (mit)verfolgen
- Jemand möchte einen Thread, in dem er selber nichts gepostet hat, weiter (mit)verfolgen
- Jemand möchte neue Threads sehen (um ggf. zu antworten)
In keinem der vorgenannten Fälle ist es erforderlich, den gesamten Threadbaum zu übertragen.
Da dies aber mit einer Änderung der Forensoftware einhergeht, die es nicht geben wird, kann man imho alle Überlegungen an dieser Stelle beenden.Bei jedem Request den gesamten Threadbaum zu übertragen, dürfte für das "mobile Surfvergnügen" ein K.O. Kriterium sein.
*Falls* ich denn die volle Baumdarstellung auf der Startseite haben möchte, würde folgendes ausreichen:
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53Denn der Titel und der Themenbereich haben sich nicht geändert. Das tun sie im Allgemeinen recht selten (vielleicht ein- bis zweimal in einem Thread mit 25 Posting). Wenn sie sich ändern tun, kann ich diese Infos beim Posting, das sie ändert, anzeigen, muss sie bei Antworten aber nicht wiederholen.
Genau das hatte ich auch schon im Sinn.
Ich sehe hier eher den "idealen" Anwendungsfall für AJAX. Der Titel muss dabei anzeigen, ob es "Änderungen" im Thread gab, oder nicht.
Und eine "Mobile Version" sollte über entsprechende Filter/ Anzeigeoptionen (s.o.) verfügen.
Und dafür braucht man auch keine »Mobilversion«. Denn die ständige Wiederholung desselben Postingtitels ist auch auf Desktopgeräten nicht sinnvoll.
Mobile first rulez.
Dass ausgerechnet *du* so etwas von dir gibst ...! :-P
Mobile first ist imho "totaler Quatsch" und keinen Deut besser als andersherum!Gruß Gunther
-
Hallo
Welche "typischen" Anwendungsszenarien gibt es denn, wenn jemand das Forum nicht am Desktop betrachtet (mal davon abgesehen, er hat nur Mobile Devices)?
Ich könnte mir u.a. folgende Fälle denken:
- Jemand möchte einen neuen Thread starten
- Jemand möchte einen Thread, in dem er selbst gepostet hat, weiter (mit)verfolgen
- Jemand möchte einen Thread, in dem er selber nichts gepostet hat, weiter (mit)verfolgen
- Jemand möchte neue Threads sehen (um ggf. zu antworten)
In keinem der vorgenannten Fälle ist es erforderlich, den gesamten Threadbaum zu übertragen.
Öhhm …
- Jemand möchte einen neuen Thread starten
… ja …
- Jemand möchte einen Thread, in dem er selbst gepostet hat, weiter (mit)verfolgen
… aha …
- Jemand möchte einen Thread, in dem er selber nichts gepostet hat, weiter (mit)verfolgen
… wie bitte? …
- Jemand möchte neue Threads sehen (um ggf. zu antworten)
… na schön
Bei den Punkten 1 und 4 stimme ich dir zu, aber warum will ich, wenn ich sehen will, *was* sich an einem bestehenden Thread geändert hat, nicht den Threadbaum sehen, der mir genau *das* zeigt? Und komme mir jetzt nicht mit einer Board-Lösung á la "… hat neue Beiträge". Zumindest *ich* will nicht wissen, *das* sich etwas neues getan hat sondern *was* das war.
Mobile first rulez.
Dass ausgerechnet *du* so etwas von dir gibst ...! :-P
Macht er doch ständig.
Mobile first ist imho "totaler Quatsch" und keinen Deut besser als andersherum!
Im Fall von CSS gebe ich Gunnar bis auf den (für mich) leidigen Leet-Blödsinn recht.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
Veranstaltungsdatenbank Vdb 0.3 -
@@Gunther:
nuqneH
Mobile first rulez.
Dass ausgerechnet *du* so etwas von dir gibst ...! :-P
Du meinst das saloppe z am Ende? Oder überhaut den Ausdruck rules?
Mobile first ist imho "totaler Quatsch" und keinen Deut besser als andersherum!
Oh, du meinst tatsächlich meine Aussage.
Der wohl wichtigste Gedanke hinter „mobile first“ ist, den Inhalt auf das Wesentliche zu beschränken.
So mag man bspw. erst durch die geringere Anzeigefläche darauf kommen, dass es unsinnig ist, bei jedem Posting in der Übersicht den immer gleichlautenden Titel zu wiederholen. Also tut man’s besser nicht, sondern so wie von molily gezeigt.
Was hat man davon? Nicht nur eine bessere Darstelung auf kleinen Viewports, sondern auch auf großen. Denn die Wiederholung der immer gleichlautenden Titel ist dort genauso unsinnig, niemand liest sich das immer wieder und wieder durch. Und Text, der nicht gelesen wird, ist überflüssig.
Hätte man auch drauf kommen können, ist man aber nicht, weil ja genügend Anzeigefläche zur Verfügung stand.
Mobile first ist nicht „totaler Quatsch“, sondern liefert bessere Ergebnisse – nicht nur für mobile.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
@@Gunnar:
nuqneH
Mobile first rulez.
Mobile first ist imho "totaler Quatsch" und keinen Deut besser als andersherum!
Oh, du meinst tatsächlich meine Aussage.
Ja, meinte ich tatsächlich ...! ;-)
Natürlich war mein "Statement" genauso plakativ und parolenhaft, wie deins.Der wohl wichtigste Gedanke hinter „mobile first“ ist, den Inhalt auf das Wesentliche zu beschränken.
Das könnte man auch mit "content first" beschreiben.
Außerdem verstehen/ beziehen viele Autoren "mobile first" mehr auf ihr CSS, als auf den Content.Hätte man auch drauf kommen können, ist man aber nicht, weil ja genügend Anzeigefläche zur Verfügung stand.
Mobile first ist nicht „totaler Quatsch“, sondern liefert bessere Ergebnisse – nicht nur für mobile.
Dafür braucht es kein "mobil first". Da man idealerweise für jede Viewportgröße die (wirklichen) Inhalte jeweils bestmöglich präsentieren sollte. Und dafür spielt es keine Rolle, mit welcher Größe ich anfange oder aufhöre ...!
Aber das ist eben nur ein Teilaspekt von "mobile first". Die Gründe und Argumente, die aus meiner Sicht alle gegen diesen (pauschalen) Ansatz sprechen hier aufzuführen, würde den Rahmen sprengen.
Falls (allgemeines) Interesse besteht, könnte man daraus mal einen Artikel für den Blog machen. ;-)
Gruß Gunther
-
Om nah hoo pez nyeetz, Gunther!
Falls (allgemeines) Interesse besteht, könnte man daraus mal einen Artikel für den Blog machen. ;-)
Natürlich! Gern!
Matthias
-
@@Gunther:
nuqneH
Der wohl wichtigste Gedanke hinter „mobile first“ ist, den Inhalt auf das Wesentliche zu beschränken.
Das könnte man auch mit "content first" beschreiben.
Whatever. Siehe die Beschreibung zu mir unter http://up.front.ug/#01-14-2014 ;-) Me first.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
-
-
-
-
Om nah hoo pez nyeetz, molily!
Ich habe auch schon über eine mobile Version nachgedacht. Es wäre zum Beispiel denkbar und sinnvoll, nur die Startpostings in einer Liste zu haben mit der Info wieviele ungelesene Postings enthalten sind. Mit dieser Version der Forumssoftware wäre das nur für angemeldete Nutzer möglich und ich wüsste auch nicht, wie die Auslieferung der Mobilvariante vs. Desktopvariante erfolgen könnte.
Ich möchte an dieser Stelle nochmals auf V4 hinweisen, Christian sucht da immer noch Unterstützung auf der technischen Seite.
*Falls* ich denn die volle Baumdarstellung auf der Startseite haben möchte, würde folgendes ausreichen:
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53Das wäre relativ einfach mit CSS lösbar,
Denn der Titel und der Themenbereich haben sich nicht geändert. Das tun sie im Allgemeinen recht selten (vielleicht ein- bis zweimal in einem Thread mit 25 Posting). Wenn sie sich ändern tun, kann ich diese Infos beim Posting, das sie ändert, anzeigen, muss sie
Das geht bestimmt mit Javascript, (sollte auch nicht zu schwer sein, dauert aber, weil ja jedes Posting mit seinem Vorgänger verglichen werden muss)
beides bringt aber keinen Gewinn, was die Ladezeit betrifft, im Gegenteil, das JS setzt noch mal einen drauf.
Wenn es gewünscht ist, kann ich gerne eine horizontale Kürzung des Threadbaumes mit CSS vornehmen.
Matthias
-
Om nah hoo pez nyeetz, Matthias Apsel!
Wenn es gewünscht ist, kann ich gerne eine horizontale Kürzung des Threadbaumes mit CSS vornehmen.
*Möglicherweise* erlaubt auch das Template eine Verschlankung, Änderungen an der Forumssoftware selbst wird es nicht geben.
Matthias
-
@@Matthias Apsel:
nuqneH
Änderungen an der Forumssoftware selbst wird es nicht geben.
Das ist nachvollziehbar.
In V4 sollte dann aber drin sein, dass die Information über geänderte Kategorie/Titel irgendwie übergeben wird.
Dann kann das Template bei unveränderten Titel diese weglassen, bei geänderten ausgeben.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Om nah hoo pez nyeetz, Gunnar Bittersmann!
Dann kann das Template bei unveränderten Titel diese weglassen, bei geänderten ausgeben.
Wenn du magst, kannst du es bei GitHub eintragen.
Matthias
-
-
-
Hi,
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53Das wäre relativ einfach mit CSS lösbar,
Wie löst Du denn per CSS, daß die Datenmenge nicht übertragen werden muß (für die wiederholten Kategorien/Titel/Jahreszahlen?
Es war ja einer der Punkte, daß die Datenmenge der Startseite zu groß ist ...
(Die Jahreszahlen könnte man m.E. generell weglassen. Bei Threads, die sich über Silvester/Neujahr hinziehen, ist's am Monat erkennbar, was im alten und was im neuen Jahr war. Und Threads, die sich über zwei Silvester/Neujahr hinziehen, gibt's eher extrem selten ...)
Interessanter wäre ja z.B. dieser Fall:
(ZU DIESEM FORUM) Mobile Device Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
(Menschelei) Das *g* des Tages Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53(Das "von" zwischen Titel und Autor kann m.E. auch komplett wegfallen, ist ja unterschiedlich dargestellt, so daß man sieht, wo das eine aufhört und das andere anfängt. Dito für die Klammern um die Kategorie).
(In Summe - Jahreszahl, "von " und () - sind das schon 10 Zeichen pro Posting auf der Hauptseite weniger. Guckt man hinter die Kulissen, wird für das "von" 2 Tabs + <span class="tn by">von</span>, also 32 Zeichen verschwendet ...)
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Om nah hoo pez nyeetz, MudGuard!
Wie löst Du denn per CSS, daß die Datenmenge nicht übertragen werden muß (für die wiederholten Kategorien/Titel/Jahreszahlen?
gar nicht, wie ich schrieb:
beides bringt aber keinen Gewinn, was die Ladezeit betrifft, im Gegenteil, das JS setzt noch mal einen drauf.
Matthias
-
@@MudGuard:
nuqneH
Wie löst Du denn per CSS, daß die Datenmenge nicht übertragen werden muß (für die wiederholten Kategorien/Titel/Jahreszahlen?
Es war ja einer der Punkte, daß die Datenmenge der Startseite zu groß ist ...
Das Weglassen von Wiederholungen reduziert aber die _bertragene_ Datenmenge nur unmerklich, weil die Kompression schon das Meiste rausholt.
Die Jahreszahlen könnte man m.E. generell weglassen. […] Das "von" zwischen Titel und Autor kann m.E. auch komplett wegfallen
Ja, könnte alles weg. Der Grund dafür ist aber weniger die gesparte Datenmenge, sondern vielmehr der gesparte Platz.
Und natürlich der gesparte kognitive Aufwand für den Leser.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Om nah hoo pez nyeetz, Gunnar Bittersmann!
Das Weglassen von Wiederholungen reduziert aber die _übertragene_ Datenmenge nur unmerklich, weil die Kompression schon das Meiste rausholt.
Ein regelmäßiger Mitleser hat vielleicht eingestellt, das gelesene Threads eingeklappt werden. Bei mir sind das fast alle.
⇒ HTML 50kB vs. 73 kB (820kB vs. 1300 kB unkomprimiert)
⇒ gesamt 154,3kB vs. 177,3 kBDas sind mehr als 10% Einsparung, das würde ich nicht als unerheblich bezeichnen.
Fazit: Eine Anmeldung und geschickte Einstellungen bringen mehr Vorteile als mit der Quelltextreduzierung erreicht werden können.
Matthias
-
Om nah hoo pez nyeetz, Matthias Apsel!
⇒ HTML 50kB vs. 73 kB (820kB vs. 1300 kB unkomprimiert)
⇒ gesamt 154,3kB vs. 177,3 kBUnd wenn man bedenkt, dass sich bis auf das HTML-Dokument alles im Cache befinden sollte, liegt die Einsparung bei 30%.
Matthias
-
-
-
-
@@Matthias Apsel:
nuqneH
Ich habe auch schon über eine mobile Version nachgedacht.
Damit meinst du was?
Denn der Titel und der Themenbereich haben sich nicht geändert. Das tun sie im Allgemeinen recht selten (vielleicht ein- bis zweimal in einem Thread mit 25 Posting). Wenn sie sich ändern tun, kann ich diese Infos beim Posting, das sie ändert, anzeigen, muss sie
Das geht bestimmt mit Javascript, (sollte auch nicht zu schwer sein, dauert aber, weil ja jedes Posting mit seinem Vorgänger verglichen werden muss)
beides bringt aber keinen Gewinn, was die Ladezeit betrifft, im Gegenteil, das JS setzt noch mal einen drauf.
Ja. Die Information über geänderte Kategorie/Titel sollte natürlich vom Backend kommen.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Om nah hoo pez nyeetz, Gunnar Bittersmann!
Ich habe auch schon über eine mobile Version nachgedacht.
Damit meinst du was?zunächst einmal ist ein eigenes Template notwendig. Sowohl die Auslieferung als m.forum oder über content negotiation erfordert Arbeit auf der Serverseite. Dazu fehlen mir sowohl die Macht als auch die Kenntnisse.
Matthias
-
@@Matthias Apsel:
nuqneH
Auslieferung als m.forum
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Was passiert, wenn jemand einen Link m.example.net/foo/bar weitergibt (E-Mail, Twitter o.a. soziale Netzwerke), der Empfänger aber mit Desktop-PC unterwegs ist? Oder andersrum: wenn jemand www.example.net/foo/bar weitergibt, der Empänger aber mit Smartphone unterwegs ist?
Es passieren Weiterleitungen anhand des User-Agents. Oder man bietet anhand des User-Agents prominente Links zur jeweils anderen Version.
Technisch auch nicht viel komplexer, als wenn man *eine* URL und Vary: User-Agent verwendet.
Beide Varianten werden breit eingesetzt; es ist nicht so, als wären hier noch grundlegende Fragen offen.
Mathias
-
@@molily:
nuqneH
Es passieren Weiterleitungen anhand des User-Agents.
Ah, du kennst sämtliche gegenwärtigen und zukünftige Geräte.
Oder man bietet anhand des User-Agents prominente Links zur jeweils anderen Version.
Ah, wenn ein Nutzer aus E-Mail, Twitter, irgendeinem sozialem Netzwerk etc. folgt, ist das erste, was er auf dieser Seite tun muss, den Link zu suchen, mit der er die Darstellung seinem verwendeten Gerät anpassen kann. Seltsame UX.
Beide Varianten werden breit eingesetzt; es ist nicht so, als wären hier noch grundlegende Fragen offen.
Stimmt, mit dem Zitat von Andy Hume von der Smashing Conference wäre wohl alles geklärt.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Hallo,
Es passieren Weiterleitungen anhand des User-Agents.
Ah, du kennst sämtliche gegenwärtigen und zukünftige Geräte.
Nein. Ich verstehe den Einwand aber nicht. Es ist kein weltbewegendes Problem, wenn die Erkennung von Mobilgeräten False Negatives erzeugt. Wer eine solche Erkennung implementiert, der muss sie pflegen. Das gilt für andere technische Aspekte von Websites ebenfalls – zum Beispiel konnte auch niemand High-DPI-Displays antizipieren, bevor das iPhone Retina erschien und die Device-Pixel-Ratio in Media Queries einführte.
Ah, wenn ein Nutzer aus E-Mail, Twitter, irgendeinem sozialem Netzwerk etc. folgt, ist das erste, was er auf dieser Seite tun muss, den Link zu suchen, mit der er die Darstellung seinem verwendeten Gerät anpassen kann. Seltsame UX.
Erstens *muss* er dem Link nicht folgen, zweitens muss er ihn nicht suchen, weil er bestenfalls direkt oben auf der Seite steht. Wirklich problematisch ist nur, dass Mobilgeräten umfangreiche Websites vorgesetzt werden, die der Mobilbrowser bis zur Unleserlichkeit herunterskaliert. Wie z.B. das SELFHTML-Forum.
Stimmt, mit dem Zitat von Andy Hume von der Smashing Conference wäre wohl alles geklärt.
So richtig kapiere ich nicht, worauf du hinauswillst. Niemand behauptet, das Responsive Design mit der Trennung zwischen example.com und m.example.com gegessen wäre. Das wäre tatsächlich ein fatales Missverständnis.
Responsive Design heißt aber auch nicht zwingend, dass ich allen Geräten dasselbe HTML und CSS ausliefern muss. Man sollte das auf jeden Fall tun, solange dabei ein gutes Design herauskommt, das auf allen Geräten funktioniert. Viele Seitenbetreiber sind der Meinung, dass dass auf ihrer Seite nicht möglich ist und eine separate Mobilversion die UX verbessert. Das kann ich in gewissen Fällen nachvollziehen. Auf einem Mobilgerät werden Inhalte anders dargestellt und der Benutzer erschließt sie sich anders. Dass das Auswirkungen darauf hat, welche Inhalte ich überhaupt übertrage, halte ich für logisch.
Ich finde z.B. das SELFHTML-Forum für große Viewports und schnelle Verbindungen ziemlich gut strukturiert. Für Geräte mit kleinen Viewports oder langsamen Verbindungen ist es eine Katastrophe. Mit ein paar Media-Queries und dem Ausblenden von Inhalten wird man das nicht substantiell verbessern, sondern nur mit unterschiedlichem HTML und CSS. Dasselbe gilt für umfangreiche Magazinseiten wie z.B. taz.de und zeit.de.
Ob ich das jetzt unter m.example.com mache oder unter derselben Domain, macht natürlich einen Unterschied. Die Nachteile der m-Subdomain sind bekannt, aber das ist für mich ein Implementierungsdetail. In beiden Fällen muss ich (beim derzeitigen Stand der Technik) eine serverseitige User-Agent-Erkennung vornehmen. Die Nachteile davon sind ebenfalls bekannt. Die Alternative, allen Geräten dasselbe HTML zu liefern und Anpassungsfähigkeit nur mit CSS umzusetzen, ist jedoch keine universell anwendbare Lösung.
Mathias
-
@@molily:
nuqneH
Auf einem Mobilgerät werden Inhalte anders dargestellt und der Benutzer erschließt sie sich anders. Dass das Auswirkungen darauf hat, welche Inhalte ich überhaupt übertrage, halte ich für logisch.
Das ist immer noch kein (gutes) Argument für m dot.
Initial werden die wesentlichen Inhalte übertragen. (Hallo Gunther: „mobile first“) Also dasselbe HTML für alle Geräte.
Ein JavaScript prüft dann die Fähigkeiten des Geräts und lädt bei Bedarf Inhalte nach. Das können weitere Inhalte sein, die auf großen Viewports noch Platz finden. Für diese wird der Link zu dem Inhalt in eine Box mit dem Inhalt umgewandelt.
Das können Scripte speziell für Mobilgeräte sein, die auf Sensoren reagieren, über die Desktopgeräte gar nicht verfügen.
Wenn man progressive enhancement verstanden hat, stellt sich die Frage nach dem Bedarf einer speziellen m-dot-Variante in den meisten Fällen gar nicht.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
-
-
-
-
-
-
-
Om nah hoo pez nyeetz, Matthias Apsel!
In der Entwickleransicht gibt es eine Version mit verkürztem Threadbaum zu sehen. Die Kategorien bzw. Titel der Antworten sind per display: none; ausgeblendet. Vielleicht könnte jemand ein JS zur Verfügung stellen, das den geänderten die Klasse „geändert“ verpasst.
Matthias
-
-
Om nah hoo pez nyeetz, molily!
(ZU DIESEM FORUM) Mobile Device von Jörg, 14.01.2014, 21:34
Matthias Apsel, 14.01., 21:45
Gunnar Bittersmann, 14.01., 23:41
Matthias Apsel, 15.01,, 08:46
molily, 15.01, 00:53Wenn man die Kategorien bereits im Template rausschmeißt, läuft der Themenfilter ins Leere.
Matthias
-
Om nah hoo pez nyeetz, molily!
Das hätte aber den Nachteil, dass Änderungen der Kategorie bzw. des Titels nicht sichtbar sind.
Matthias
-
Mahlzeit,
Das hätte aber den Nachteil, dass Änderungen der Kategorie bzw. des Titels nicht sichtbar sind.
Das könnte man aber z.B. durch farbliche Hervorhebung kompensieren. Und per Touchevent kann man die Kategorie einblenden lassen.
--
42-
@@M.:
nuqneH
Das könnte man aber z.B. durch farbliche Hervorhebung kompensieren. Und per Touchevent kann man die Kategorie einblenden lassen.
Warum sollte man das erst per Touchevent darstellen?
Egal wie man es visualisiert, die Information über eine Änderung muss man erstmal haben. Wenn sie die Forumsoftware nicht serverseitig zur Verfügung stellt, muss man clientseitiges JavaScript drüberlaufen lassen.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Mahlzeit,
Warum sollte man das erst per Touchevent darstellen?
Weil es Platz am Viewport schafft, relativ unnötige Infos erst auf Bedarf anzeigt.
--
42
-
-
-
-
-
-
-
