nicht angemeldet
Wie baue ich eine mobile Website
0 0 
Gunnar Bittersmann
Wie baue ich eine mobile Website
Hallo Forum,
jetzt, wo ich mit eurer Hilfe das Rätsel HTML5 für mich geknackt habe, will ich's wissen;)
Ich stehe vor der Aufgabe, eine mobile Landingpage umzusetzen. Das Projekt fängt bei 0 an, sprich es müssen keine vorhandenen Inhalte übernommen werden. Dazu kommt, dass bei dieser Site wohl mit einer Halbwertszeit von vielleicht 6 Monaten gerechnet wird. Dennoch gibt es ein individuelles Design und es sollen Features eingesetzt werden, die eine mobile Website ausmachen. D.h. Teaser werden hin- und hergewischt, Inhalte werden per Ajax nachgeladen, das Menü wird ein und ausgefahren usw.
Nicht, dass ich sowas nicht schonmal gemacht hätte:
Vor etwa 3 Jahren habe ich mal für eine bestehende, von mir gebaute und betreute XHTML-Site eine mobile Variante gebaut. Ich war damals total begeistert, wie sich mein CSS-basiertes Layout in dem Moment bezahlt machte, denn es war relativ wenig Arbeit, dieses 600 Unterseiten umfassende Projekt für die mobile Darstellung zu optimieren. Einfach ein paar andere Stylesheets dazu laden. Fertig! Irgendwann hatte ich dann nochmal einen Swiper dazugebaut oder das Menü bei google.com abgeguckt. Kurz, das Ganze sieht ganz ordentlich aus aber es ist gewachsen.
Jetzt will ich's richtig machen:
Nicht, dass ich das, was ich bis hierher gemacht habe, für falsch halten würde. In dem Kontext war es richtig, aber die Tatsache, dass ich bei 0 anfange, bietet sich an, um mal in die Runde zu fragen.
1. Stichwort: Framework
Ausser jQuery habe ich mit nichts was am Hut, was sich so nennen könnte, denk aber immer, ich müsste. Aus dem Grund habe ich mir kurz jQuery Mobile angesehen. Mein Eindruck, was sich wohl dahinter verbirgt, hat sich relativ schnell bestätigt: Ich kann hier relativ schnell und einfach eine Anwendung bauen, die sich wie eine native App anfühlt, aber eben auch aussieht, wie jQuery Mobile das vorsieht. Das ist (in meinem Fall) aber nicht der Sinn der Sache. Ich bräuchte etwas, das mir die Arbeit erleichtert und nicht dem Designer.
beste gruesse,
heinetz
-
Hallo Forum,
ok, vielleicht fehlen hier konkrete Fragen. Das Ganze ist bis hierher also als die Vorgeschichte zu verstehen und ich versuch's mal konkreter:
Ich stehe, wie gesagt, vor der Aufgabe, eine mobile Website zu bauen und würde mit einem leeren Dokument beginnen. Auf dieser Site wird es ein sliding Menu, wie auf der mobilen google.de oder m.facebook.com, Content in Tabs und Accordions dargestellt geben usw.
Ich würde nun mit "<html></html>" anfangen und das Ganze Tag für Tag hinschreiben, für bestimmte Funktionalitäten würde ich mir bestimmte jQuery-Plugins aussuchen und hinterher Darstellung und Funktion auf so vielen Endgeräten testen, wie mir einfallen.
Nun habe ich aber von mobilen Framesets gehört und stelle mir darunter etwas vor, das mir a) ganz viel Arbeit erspart und b) quasi von Haus aus ganz viele Problematiken schon abdeckt, ich mir sozusagen sicher sein kann, dass das auf den Endgeräten laufen wird und zwar nicht auf denen, die mir einfallen, sondern auf allen relevanten. Das was ich jetzt von jQuery mobile gesehen habe ist aber etwas, das garkeine individuelles Design mehr zulässt, bzw. dass sich die Individualität auf ein Farbschema beschränkt, dass ich festlegen kann.
Ist es das, was sich grundsätzlich hinter einem mobilen Framework verbirgt oder/und gibt es so auch eine Art Baukasten, mit dem ich ein wirklich individuelles Design umsetzen kann?
danke für Tipps und
beste gruesse,
heinetz-
Das was ich jetzt von jQuery mobile gesehen habe ist aber etwas, das garkeine individuelles Design mehr zulässt, bzw. dass sich die Individualität auf ein Farbschema beschränkt, dass ich festlegen kann.
Nicht wenn Du des CSS mächtig bist.
Cheers,
Baba-
Das was ich jetzt von jQuery mobile gesehen habe ist aber etwas, das garkeine individuelles Design mehr zulässt, bzw. dass sich die Individualität auf ein Farbschema beschränkt, dass ich festlegen kann.
Nicht wenn Du des CSS mächtig bist.Heisst, wenn ich dessen mächtig bin, kann ich es auch vollkommen individuell gestalten. Ja, dass das technisch funktioniert, kann ich mir vorstellen. Aber ist das auch praktikabel? Den Beispielen, mit jQ mobile umsetzter mobiler Websites sah man deutlich jQ mobile an und die Frage ist, ob es tatsächlich weniger Aufwand ist, eine Web-App mit jQ mobile umzusetzen und dann das Layout zu individualisieren oder ohne Framework mit einem leeren Dokument anzufangen.
Ich bin mittlerweile auf Mobile Boilerplate gestossen und versuche, den Ansatz einzuordnen. Bis hierher habe ich davon den Eindruck, dass das genau das Gegenteil ist. Nämlich ein Grundgerüst, dass explizit nur das mitbringt, was keinerlei gestalterische Vorgaben enthält, sondern nur das notwendige Standardgerüst enthält.
Was mir da nicht ganz klar ist, was das build script soll und ob es wirklich notwendig ist.
beste gruesse,
heinetz-
die Frage ist, ob es tatsächlich weniger Aufwand ist, eine Web-App mit jQ mobile umzusetzen und dann das Layout zu individualisieren oder ohne Framework mit einem leeren Dokument anzufangen.
Genau. Und ich würde sagen: ersteres. Aber das kommt natürlich darauf an, wieviel von den
sliding Menu, (...) Content in Tabs und Accordions
du verwenden möchtest. Wenn solche Elemente Deine Seite prägen, würde ich diesen Weg vorschlagen.
Ich bin mittlerweile auf Mobile Boilerplate gestossen und versuche, den Ansatz einzuordnen. Bis hierher habe ich davon den Eindruck, dass das genau das Gegenteil ist. Nämlich ein Grundgerüst, dass explizit nur das mitbringt, was keinerlei gestalterische Vorgaben enthält, sondern nur das notwendige Standardgerüst enthält.
Ja, sieht so aus. Allerdings ist mir nicht klar, wie es mit dynamischen Content zusammengeht, z.B. aus Deinem CMS?!?
Was mir da nicht ganz klar ist, was das build script soll und ob es wirklich notwendig ist.
Hier jedenfalls wird das gesagt.
Cheers,
Baba-
Genau. Und ich würde sagen: ersteres. Aber das kommt natürlich darauf an, wieviel von den
sliding Menu, (...) Content in Tabs und Accordions
du verwenden möchtest. Wenn solche Elemente Deine Seite prägen, würde ich diesen Weg vorschlagen.Naja, ob diese Elemente meine Anwendung "prägen", kann ich nicht sagen. Es gibt ein Menu und der Content wird als Accordeon dargestellt. Die Inhalte im Accordeon werden sinnvollerweise per Ajax geladen, sobald sie gebraucht werden. Dann gibt es ein paar Standardseiten mit mehr oder weniger plaintext.
Um das final einschätzen zu können, braucht man sicher Erfahrungswerte mit jQuery mobile.Ich bin mittlerweile auf Mobile Boilerplate gestossen und versuche, den Ansatz einzuordnen. Bis hierher habe ich davon den Eindruck, dass das genau das Gegenteil ist. Nämlich ein Grundgerüst, dass explizit nur das mitbringt, was keinerlei gestalterische Vorgaben enthält, sondern nur das notwendige Standardgerüst enthält.
Ja, sieht so aus. Allerdings ist mir nicht klar, wie es mit dynamischen Content zusammengeht, z.B. aus Deinem CMS?!?In meinem Fall gibt es garkein CMS. Die dynamischen Contents (Rezepte) kommen aber aus einer DB-Abfrage. Ich stelle mir vor, per Ajax JSON zu laden. Aber die Tatsache, dass Dir nicht klar ist, wie das mit dynamischen Content gehen soll, wirft in mir die Frage auf, ob ich vielleicht doch nicht verstanden habe, was das Boilerplate ist. Oder warum sollte man im <body> nicht statt <p>hallo welt<p> auch <? echo "<p>hallo welt</p>"; ?> schreiben können?
Was mir da nicht ganz klar ist, was das build script soll und ob es wirklich notwendig ist.
Hier jedenfalls wird das gesagt.ja, gesehen hatte ich das auch schon und gelesen hatte ich es auch. Geht es nur darum, den Code zu komprimieren?
gruss,
heinetz-
Naja, ob diese Elemente meine Anwendung "prägen", kann ich nicht sagen. Es gibt ein Menu und der Content wird als Accordeon dargestellt. Die Inhalte im Accordeon werden sinnvollerweise per Ajax geladen, sobald sie gebraucht werden. Dann gibt es ein paar Standardseiten mit mehr oder weniger plaintext.
Von dem was Du schreibst, würde ich es empfehlen. Siehe auch.
Was mir da nicht ganz klar ist, was das build script soll und ob es wirklich notwendig ist.
Nein, ist es wohl doch nicht: Punkt 4.
Oder warum sollte man im <body> nicht statt <p>hallo welt<p> auch <? echo "<p>hallo welt</p>"; ?> schreiben können?
Nun, so wie ich das verstehe, kann man nur Seiten optimieren, die starr auskompiliert sind. Unter dynamisch verstehe ich, dass Content + Template getrennt lagern und bei Bedarf zusammengeführt werden. Wie möchte man solchen dynamischen Content automatisiert optimieren? Vielleicht verstehe *ich* den ganzen Laden nicht. Mangels Beispielen fehlt mir auch gerade die Motivation mich mit mobile boilerplate mehr zu beschäftigen.
Cheers,
Baba-
Von dem was Du schreibst, würde ich es empfehlen.
"like a mobile app or a website?" Ich tuhe mich ein bisschen schwer damit, den Vergleich zu verstehen. Worin unterscheidet sich die mobile app oder Web-App von einer mobilen Website oder allgemein einer Website? "if it's ok to be like a mobile app". Meint "To be like" in dem Kontext das selbe wie "To look like"? Die einzige Abgrenzung, die ich nachvollziehen kann ist eine optische. Wikipedia sagt dazu:
"Eine mobile Web-App verhält sich im Idealfall genau so wie eine native App, wird also vom Nutzer nicht wie eine Webseite wahrgenommen, sondern bietet stattdessen eine Benutzeroberfläche, die sich in das mobile Endgerät optisch und ergonomisch integriert."
Unabhängig davon, wie interaktive Elemente gestaltet sind, ist doch auch eine mit jQuery mobile umgesetzte Web-App immernoch eine Website, wenn ich daraus hinterher keine native App mache. Meine Frage war ja ursprünglich, ob es Sinn macht jQuery mobile einzusetzen, um dann die interativen Elemente, die ja zunächst mal in einem von jQuery mobile vorgesehenen Standardlayout daherkommen entsprechend Kunden-CI umzugestalten und nachdem ich mir ein paar Sites, Web Apps oder wie auch immer aus der jQuery Mobile Gallery angesehen habe, kann ich mir das sogar vorstellen und neige dazu, Deinem Rat zu folgen. Ich finde aber, die Argumentation bei stackoverflow steht im Widerspruch dazu.
Was mir da nicht ganz klar ist, was das build script soll und ob es wirklich notwendig ist.
Nein, ist es wohl doch nicht: Punkt 4.Das hatte ich auch gelesen und deshalb hatte ich geschlussfolgert, dass es dann eigentlich nur einer Optimierung dient. Die einzig automatisierbare Optimierung, die ich mir aber vorstellen kann, ist ein komprimieren des Codes.
Oder warum sollte man im <body> nicht statt <p>hallo welt<p> auch <? echo "<p>hallo welt</p>"; ?> schreiben können?
Nun, so wie ich das verstehe, kann man nur Seiten optimieren, die starr auskompiliert sind. Unter dynamisch verstehe ich, dass Content + Template getrennt lagern und bei Bedarf zusammengeführt werden. Wie möchte man solchen dynamischen Content automatisiert optimieren? Vielleicht verstehe *ich* den ganzen Laden nicht. Mangels Beispielen fehlt mir auch gerade die Motivation mich mit mobile boilerplate mehr zu beschäftigen.Ja, um bei meinem hallo_welt-Beispiel zu bleiben, müsste die Optimierung den Teil innerhalb von <? ?> in Ruhe lassen und wenn dort statt echo "<p>hallo welt</p>"; include "welt.txt"; steht, ist natürlich, der Inhalt der welt.txt nicht und nur der Teil im Template komprimiert. Ob der nun durch so ein Skript komprimiert werden muss finde ich eh fragwürdig. Wenn ich mir bspw. die Sourcen von m.spiegel.de ansehe, ist da alles hübsch formatiert und nicht komprimiert.
gruss,
heinetz-
Ich finde aber, die Argumentation bei stackoverflow steht im Widerspruch dazu.
Aber nur, wenn Du eine mobile Website anstrebst, die nicht wie eine native App aussieht. Eben dies wusste ich aber bis jetzt nicht. Also, nun hast Du die Qual der Wahl. Jqery mobile, und das Design anpassen oder Bootstrap um eine gute Grundlage für responsive Websites zu erstellen.
Ich bräuchte etwas, das mir die Arbeit erleichtert und nicht dem Designer.
Das kommt immer noch darauf an, wieviel von was Du drin haben möchtest. Bei Jquery steckst Du mehr Arbeit in das Layout. Bei Bootstrap mehr Arbeit in die Funkionalitäten. Letzteres könnte schwerer werden, um es für alle Endgeräte hinzukriegen.
Cheers,
Baba-
Aber nur, wenn Du eine mobile Website anstrebst, die nicht wie eine native App aussieht. Eben dies wusste ich aber bis jetzt nicht. Also, nun hast Du die Qual der Wahl. Jqery mobile, und das Design anpassen oder Bootstrap um eine gute Grundlage für responsive Websites zu erstellen.
Ich strebe ja auch keine mobile Website an, die NICHT wie eine native App aussieht. Ich muss anhand eines bestehenden vom Kunden freigegebenen Layouts eine mobile Website umsetzen. Was für Elemente zur Darstellung/Interaktion in dem Layout vorgesehen sind, hatte ich ja geschrieben. Es gibt auf der mobilden Website bspw. irgendwelche Buttons und Accordeons, die natürlich der CI von FaXYZ folgen. Würde FaXYZ sich eine native App bauen lassen, würden diese Buttons aber sicher auch dieser CI folgen. Von daher vestehe ich diese ganze Unterscheidung zwischen Web App und mobiler Website nicht.
Ich bräuchte etwas, das mir die Arbeit erleichtert und nicht dem Designer.
Das kommt immer noch darauf an, wieviel von was Du drin haben möchtest. Bei Jquery steckst Du mehr Arbeit in das Layout. Bei Bootstrap mehr Arbeit in die Funkionalitäten. Letzteres könnte schwerer werden, um es für alle Endgeräte hinzukriegen.Meinst Du ich würde mit jQuery mobile mehr Arbeit in die Umsetzung eines Layouts stecken, als mit Bootstrap? Warum? Weil es viel müssiger ist, das bestehende jQuery mobile CSS anzupassen, als ein neues zu erstellen?
beste gruesse,
heinetz-
Ich strebe ja auch keine mobile Website an, die NICHT wie eine native App aussieht.
$Vote["jquery_mobile"]++;Von daher vestehe ich diese ganze Unterscheidung zwischen Web App und mobiler Website nicht.
Es ist eben ein optischer Unterschied, ob man eine für mobile Endgeräte optimierte Website oder eine native App vor sich hat. Soll ich Dir die Unterschiede aufzählen? Das gilt auch, wenn Du in beiden Fällen von einem abgesegneten Layout startest.
Ich muss anhand eines bestehenden vom Kunden freigegebenen Layouts eine mobile Website umsetzen.
Das ist doch die beste Ausgangslage: Du weißt, was Du willst.
$Vote["jquery_mobile"]++;Meinst Du ich würde mit jQuery mobile mehr Arbeit in die Umsetzung eines Layouts stecken, als mit Bootstrap?
Nicht einmal. Insofern revidiere ich es zu: Bei Bootstrap kommt die Arbeit in die Funktionalitäten dazu.
$Vote["jquery_mobile"]++;Weil es viel müssiger ist, das bestehende jQuery mobile CSS anzupassen, als ein neues zu erstellen?
Das kann manchmal sein, aber Du hast ja Erfahrung mit CSS-basiertem Design (OP) also denke ich sollte es für Dich nicht zutreffen.
$Vote["jquery_mobile"]++;var_dump($Vote); /* array 'jquery_mobile' => int 5 'bootstrap' => int 1 */Cheers,
Baba-
Von daher vestehe ich diese ganze Unterscheidung zwischen Web App und mobiler Website nicht.
Es ist eben ein optischer Unterschied, ob man eine für mobile Endgeräte optimierte Website oder eine native App vor sich hat. Soll ich Dir die Unterschiede aufzählen? Das gilt auch, wenn Du in beiden Fällen von einem abgesegneten Layout startest.Zunächst mal Danke für die Auseinandersetzung. Das hat schon sehr zur Klärung beigetragen. Zur Klärung, mit welchem Hilfsmittel ich meine ... mein Projekt am besten umsetze. Vor Allem finde ich aber die Klärung, was denn nun die Unterschiede zwischen einer 1. nativen App, 2. einer Web App und 3. einer mobilen Website sind. Wodurch sich eine native App von den anderen beiden unterscheidet ist klar: Sie muss installiert werden und dann "darf" sie auch weiter in's Betriebssystem eingreifen, sprich z.B. die Kamera ansprechen. Die anderen beiden werden über den Browser aufgerufen und alle Contents werden (wenn noch nicht im Cache) per http(s) zum Client geschickt, aber worin unterscheiden sich die beiden nun? Letztlich sind doch beide Websites, die mehr oder weniger Funktionalität bieten und irgendwie gestaltet sind. Die Web App möchte so daherkommen, als sein sie eine native App? Das heisst, die Steuerelemente sollen aussehen, wie die des OS-Gui? Eine Web App ist mehr durch Interaktion und Funktionalität geprägt, als eine mobile Website?
Ich selbst habe nur sehr wenige native Apps auf meinem iPhone aber das was ich so kenne, hebelt diese ganze Unterscheidung aus. Die Apps sind alle samt gebrandet, sprich natürlich mit den Steuerelemeten gebaut, die sich durchgesetzt haben, weil sie in etwas denen, der GUI des OS entsprechen, aber der Login-Button meiner INGDiba-App versucht weniger auszusehen, wie ein iOS-Button als ein INGDiba-Button, wie er auf ingdiba.de zu finden ist. So und wenn dann eine WEB-App versucht so daherzukommen, wie eine native App, bspw. meine INGDiba-App, sieht doch wieder alles gleich aus. Oder was ist m.ebay.de? Ist das nun eine Web-App oder eine mobile Internetseite?
Wie auch immer, ich werde mich jetzt mal dransetzen und schauen, ob ich mit jQuery mobile eine kleine ... bzw. besser eine kleines Projekt aufsetzen kann und wie schnell ich mit den Standard-Widgets mein Sliding Menu, Accordeon-Inhalte, Buttons umgesetzt kriege. Wenn ich mich nicht weiter um die individuelle Gestaltung kümmere und alles im Standard-Theme umsetze, sollte das ja zu Einen recht schnell gehen und ordentlich aussehen. Danach gucke ich dann mal, wie schwer oder besser wie einfach sich mein Layout als individuelles Theme umsetzen lässt und ob man da womöglich an Grenzen stösst, was ich tatsächlich nach der ganzen Auseinandersetzung nicht glaube (und nicht hoffe, weil ich dann wieder bei 0 anfangen muss;).
beste gruesse,
heinetzbeste gruesse,
heinetz-
@@heinetz:
nuqneH
native App […] "darf" sie auch weiter in's Betriebssystem eingreifen, sprich z.B. die Kamera ansprechen.
Es wird daran gearbeitet, dass Web-Apps/Webseiten das über APIs auch dürfen.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer) -
Moin,
[...] Wodurch sich eine native App von den anderen beiden unterscheidet ist klar: Sie muss installiert werden und dann "darf" sie auch weiter in's Betriebssystem eingreifen, sprich z.B. die Kamera ansprechen.
Man kann auch eine App auf Basis von HTML5 und Javascript schreiben die trotzdem Zugriff auf OS-Funktionen hat. Die Plattformunabhängigkeit ist (in eingeschränkter Weise) auch vorhanden, sofern man die "üblichen Verdächtigen" abdecken will.
Grüße Marco
--
Ich spreche Spaghetticode - fließend.
-
-
Hello,
fast fertig ;)
Ich hatte mich für die Lösung mit jQuery mobile entschieden und bis hierher habe ich das Gefühl, meine Entscheidung war goldrichtig!
Was ich bisher gemacht habe:
Ich habe zunächst mal einen Wireframe mit dem jQ-mobile-Standardtheme umgestzt, denn ein Design gab's noch garnicht. Das heisst, ich habe zunächst alles mit jQ mobile Standardfunktionalitäten umgesetzt, die ohne zusätzliches JS/Qj auskommen und danach die Abweichungen, die zusâtzliches JS/Qj bedurften. Damit habe ich quasi einen Dummy geschaffen, der dem Design als Vorlage dient. Ich habe bis hierher den Eindruck, das meine Herangehensweise sich auszahlt...
Jetzt muss es nur noch optimiert werden ;)
Mein Dummy läuft nämlich noch sehr, sagen wir, ruckelig und ich kann nicht einschätzen, was davon auf das jQ mobile Framework an sich, und wasauf meine unsaubere Programmierung zurückzuführen ist. Wo ich konkret Optimierungspotential sehe sind folgende Punkte:
1. Ich habe irgenwo gelesen, dass jQ mit bspw. einem $('#my_element') weniger zu tun hat, als mit einem $('.my_class') oder gar einem $('. elemtent [attr="value"]:not(.his_class)). Das erscheint mir logisch. Ist das so?
2. Ich habe leider das mit dem Event-Handling oder wahrscheinlich eher -Bubbling nicht verstanden, wohl weil man's nicht sieht. Was genau preventDefault() macht und ob wie ich das eventhandling effizient einsetze. Jedenfalls habe ich den Eindruck, das jQ sehr beschäftigt ist, wenn eine Seite geladen wird.
3. Es lassen sich sicher ein pasr Dom-Objekte in Variablen speichern, die wiederverwendet werden.
4. Zuletzt kann man sicher auch serverseitig ein paar Dinge besser machen (Ich füge bspw. auf bestimmten Seiten unter bestimmten Umständen per JS Html ins Dom ein und die Logik liesse sich auch mit php abbilden.
ich freue mich über Tipps
beste gruesse,
heinetz
-
-
-
-
-
-
-
-
-
-
-
@@heinetz:
nuqneH
Die Antwort auf die Frage „Wie baue ich eine mobile Website?“ ist in den allermeisten Fällen: Gar nicht!
“There is no mobile web. There is only The web, which we view in different ways. There is also no Desktop web. Or Tablet web. Thank you.”
–Stephen HayDie Frage sollte sein: Wie baue ich eine Website, die mit allen Geräten benutzbar ist? Und die Antwort darauf ist: responsive web design, progressive enhancement.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
hello,
Die Frage sollte sein: Wie baue ich eine Website, die mit allen Geräten benutzbar ist? Und die Antwort darauf ist: responsive web design, progressive enhancement.
Richtig, dennoch geht man ja irgendwie konkret auf die unterschiedlichen Endgeräte ein, sprich man unterscheidet diese, um u.A. auf unterschiedliche Bildschirmauflösungenen unterschiedlich zu reagieren bspw. durch den Einsatz von Media Queries, die letztlich auch ein IF_THEN_ELSE-Konstrukt und damit irgendeine Art von Weiche zwischen verschiedenen Fällen sind. Wenn nun einer der Fälle keine Relevanz hat, warum sollte er dann beachtet werden. Bzw. sollte er natürlich nicht vergessen werden aber ich konzentiere mich mit meiner Frage nicht auf diesen sondern jeden Fall.
beste gruesse,
heinetz-
Hallo,
Die Frage sollte sein: Wie baue ich eine Website, die mit allen Geräten benutzbar ist? Und die Antwort darauf ist: responsive web design, progressive enhancement.
Richtig, dennoch geht man ja irgendwie konkret auf die unterschiedlichen Endgeräte ein, sprich man unterscheidet diese, um u.A. auf unterschiedliche Bildschirmauflösungenen unterschiedlich zu reagieren bspw. durch den Einsatz von Media Queries, die letztlich auch ein IF_THEN_ELSE-Konstrukt und damit irgendeine Art von Weiche zwischen verschiedenen Fällen sind. Wenn nun einer der Fälle keine Relevanz hat, warum sollte er dann beachtet werden.
Ich glaube, du solltest dich nochmals in RWD (responsive web design) einlesen. Das eine ist das Konzept, das andere das (ein) Mittel es umzusetzen.
Viele Grüße
Siri
-
-