wie an anderer Stelle schon erwähnt, arbeite ich im Moment an einem umfassenden Redesign meines Podcast-Templates und stehe nun vor der Frage, ob es sich überhaupt noch lohnt, ein explizites Mobile Theme zu erstellen.
In Zeiten von Podcatchern für jedes Betriebssystem (ja ja, Windows Phone mal ausgenommen), ist es doch fast vergebene Liebesmüh, ein detailliertes Theme zu erstellen. Oder sehe ich das falsch?
Im Moment schwanke ich zwischen der Erstellung eines Themes, das fast einer nativen App gleicht, oder dem Minimalaufwand, der ein wenig die Lesbarkeit erhöht.
Wie definierst du mobile Theme? Als Theme das auch mobil funktioniert, oder als Theme das wie nativ aussieht?
Wenn es nur um die Bedienbarkeit auf mobilen Endgeräten angeht, dann ja: Das lohnt sich absolut. Immer mehr User surfen mit mobilen Endgeräten und immer mehr tun das auch nurnoch so. Natürlich ist das ne total generelle Aussage von mir und meist gibt es nicht die EINE Wahrheit. Schaue doch am besten einfach mal in deine Zugriffsstatistiken. Beim Webgeplapper ist so ca. jeder zweite Besucher mit einem Smartphone oder Tablet auf der Seite.
Das Ganze wie nativ aussehen zu lassen ist meiner Meinung nach eine antiquitierte Herangehensweise. Zum Einen ist die Palette an verschiedenen Look and Feels von (mobilen) Betriebsystemen viel zu groß und unüberschaubar und zum Anderen kann man dem User durchaus zutrauen zu verstehen, das er sich gerade im Web befindet ^^
Das bedeutet natürlich NICHT das man sich nicht trotzdem extra Gedanken über die einzelnen Elemente der Seite machen sollte. Dinge die Aktionen auslösen und nicht verlinken sollten durchaus Buttons sein. Dinge die nur (zB als Link) verständlich sind, weil sie anders aussehen wenn man darüber hovered, sollten neu überdacht werden. Das liegt aber weniger an Gestaltung für mobile Geräte, sondern sind Gedanken die man sich eh immer machen sollte. Bei Usern die auf einmal keinen Cursor mehr haben, fällt es oft nur schneller auf.
Auch wenn es doof ist das viele Seiten damit gleich aussehen, sind solche Gedanken schon ganz gut in Bootstrap und Foundation abgefrühstückt. Da hast du eben zb vernünftige, visuelle Buttonstates.
Nur fürs Verständnis: mit explizitem Mobile Theme meinst du aber nicht ein komplett anderes Theme das je nach Content-Header statt des ‘normalem’ Themes ausgeliefert wird, oder? Sowas löst man heutzutage tendenziell eher mit Media Queries. Macht weniger Arbeit, funktioniert zuverlässiger, deckt mehr Eckfälle ab und sorgt für ein einheitlicheres Erscheinungsbild deiner Seite auf versch. Endgeräten.
Mit mobile Theme meine ich in dem Fall eine auf mobile Endgeräte abgestimmte Darstellung, die optimal mit der Thematik Podcast funktioniert. Ich frage mich halt, wie die Interaktion mit einer Podcastseite auf mobilen Geräten aussieht. Also mein Gedankengang geht über die “normale” Gestaltung hinaus.
Natürlich wird das mit Media Queries und ein paar Zusatzfunktionen gelöst werden. Da ich Wordpress Themes eigentlich immer von Grund auf selbst baue, scheiden Bootstrap und Co für mich an dieser Stelle aus. Vor allem denke ich, dass ein nativ anmutender Ansatz an dieser Stelle am sinnvollsten wäre, da wir ja dank einiger Plugins ja alle relevanten Informationen des Podcasts zur Verfügung haben. Und das teilweise sogar besser als jede native App.
Naja, ich glaube, dass sich mein genauer Ansatz erst durch das fertige Beispiel deutlich verständlich zeigt.
Du willst also mehr eine Webapp zum Podcast, als eine Internetpräsenz bauen, verstehe ich das richtig?
Ich verstehe übrigens nicht in wiefern sich “selbst bauen” und Boostrap/co widersprechen. Genau dafür sind diese Sachen doch da… Als Grundlage. Natürlich kann man darauf auch gezielt verzichten. Das tue ich auch oft, wenn ich für ein Projekt den meisten Kram daraus eh nicht bräuchte / sowieso wieder überschrieben würde. Man sollte halt nur, wie gesagt, daran denken das bst Dinge auch wirklich berücksichtigt sind.
Neben den Buttonstates ist das bei Bootstrap zb ein in den Grundzügen semantischer und barrierefreier Code (Die Formulare sind korrekt ausgezeichnet, die Modals haben entsprechende ARIA-Auszeichnung und sowas).
Im Prinzip ist das die korrekte Formulierung, ja. Sollte ein mobiles Theme mehr zu einer Webapp werden?
Bei dem zweiten Punkt starte ich jetzt mal keine Grundsatzdiskussion Du hast sicher nicht unrecht. Ich mache es dennoch immer wieder gerne um einfach auch in der Übung zu bleiben. Ab und an ist es mal schön, etwas vom absoluten Nullpunkt (sofern man bei der Verwendung von jQuery und Co. überhaupt davon reden kann) zu bauen.
Die weitere Frage ist also quasi: wird die Website zu einem Podcast auf mobilen Geräten eher genutzt um sich kurze Informationen zu beschaffen und dann doch im Podcatcher zu hören (Danke an den Podlove Subscribe Button) oder ist das Hören auf der Website noch aktuell?
Hm, das ist nun sicher Geschmackssache. Was die Schlussfrage angeht: Ich kann für mich persönlich zwar sagen, das ich nie mit mobilen Geräten über die Website höre, das aber in meinen Statistiken erstaunlich oft beobachte (trotz großem Subscribe-Button). Mit Piwik kann man ja super auch individuelle Events tracken und so habe ich ein Event auf Play und eines auf Pause. Habe allerdings auch eine recht kleine Stichprobe…
Ich glaube die Diskussion sähe dann nochmal anders aus, wenn der Webplayer auch vollständig responsive wäre. Ich glaube das ist für die nächste Version vorgesehen.
Unabhängig von Podcasts sagt mir mein Gefühl: Entweder hast du eine responsive Website für alle, oder du hast eine Webapp die beides kann, oder eine Webapp die nur für unterwegs gedacht ist. Aber dem Einem User was anderes anzubieten als dem Anderen und diese Formen unter der selben URL zu mischen fände ich verwirrend. Kann das aber rational/argumentativ auch nicht untermauern.
Zu dem Bootstrap-Thema: Das Argument ist absolut nachvollziehbar (:
Du hast sicher nicht unrecht. Ich mache es dennoch immer wieder gerne um einfach auch in der Übung zu bleiben. Ab und an ist es mal schön, etwas vom absoluten Nullpunkt (sofern man bei der Verwendung von jQuery und Co. überhaupt davon reden kann) zu bauen.