Mobile Detection und HTML5 Videos

rage_all · 05. November 2012 13:01

Hallo zusammen,

ich habe vom Forum einen Entwurf für ein Plugin übernommen und ein bisschen erweitert. Hintergrund: Ich hatte Probleme das Video abzuspielen, bzw. im On-Board-Player vom Mobile Device abzuspielen.
Durch einige Recherche im Netz habe ich herausgefunden dass die aktuelle Smartphone-Generation am liebsten das <video>-Tag ohne zugehörige "type"-Schalter haben möchte — was ich bestätigen kann.

Also habe ich das php-mobile-detect von Google Code übernommen, was bislang einwandfrei funktioniert.
Jetziger Inhalt meines Plugins beginnt also mit

Hier klicken, um den Code zum Kopieren zu markieren

[== PHP ==]
require_once 'mobiledetection/Mobile_Detect.php';
$detect = new Mobile_Detect;
$deviceType = ($detect->isMobile() ? ($detect->isTablet() ? 'tablet' : 'phone') : 'computer');

Wobei mir auffällt, das sich die Funktion auch z.B. im Template hervorragend machen würde, um z.B. aus Performancegründen die großflächige Slideshow nicht zu laden (da JavaScript und nur via CSS mit display:none; ausgeblendet, glaube ich, wird die trotzdem noch mitgeladen).

Ich schaffe es, entweder das Script zu Beginn des Template laden zu lassen und z.B. im Quellcode auszugeben. Auch kann ich in dem Video-Plugin eine Erkennung ausführen und entweder die Variante mit dem "type"-Schalter ausgeben oder ohne. Was mir aber fehlt und großer Wunsch ist, ist zum einen die Variable ins System zu bringen, um z.B. im optimalsten Falle auch im Template nur zu schreiben

Hier klicken, um den Code zum Kopieren zu markieren

[== Template/Smarty ==]
{if $mobile=true}
   <div class='mobiledevice'>&nbsp;</div>
 {else}
   <div class='computerdevice'>&nbsp;</div>
{/if}

und zum anderen die Brücke zu schlagen, um im Video-Plugin mit dem Video im Prinzip dasselbe tun zu können - mit am Besten derselben Variable ohne die mobile-detection erneut auszuführen.

Nun also meine Frage(n) als nicht-coder:
Geht das überhaupt: Via z.B. Plugin eine Smarty-Variable zu platzieren und in einem anderen Plugin diese Variable heranzuziehen und zu nutzen?
Ist das als Plugin sinnvoll und umsetzbar oder lieber gleich als Modul, ggf. mit Einstellmöglichkeiten, etc. — oder ganz anders?

Vielen Dank für Eure Anregungen und Hilfen.
Selbstverständlich stelle ich das fertige Teil gerne hier in der Community zur Verfügung; für SVN, etc. fehlen mir der Zugang, die Erfahrung, etc. Aber ich kann auch eine englische Übersetzung mit dazu erledigen, wenn's hilft.

czarnowski · 06. November 2012 00:33

Natürlich geht es, aber ist es sinnig?

Beim Plugin geht es mal wieder um die Frage warum einfach wenn es auch umständlich geht.

Hier klicken, um den Code zum Kopieren zu markieren

[== PHP ==]
<?php
$useragent=$_SERVER['HTTP_USER_AGENT'];
$mobile=preg_match('/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i',$useragent)||preg_match('/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i',substr($useragent,0,4));
?>

rage_all · 06. November 2012 09:06

Diese, zugegeben, wirklich simple und einleuchtende Lösung, habe ich ein paar Mal im Netz gesehen. Dann wurde hin- und her diskutiert, ob oder wie hoch die Trefferrate nach oder mit WURFL ist. Da steh ich also wieder und denke mir, dass ich lieber eine möglichst umfassende und genaue Unterscheidung möchte, wenn ich schon überhaupt differenziere.

Mangels Fachwissen — was dieses Thema betreffend wahrscheinlich nur die allerwenigsten unter uns haben — habe ich mich für das Google Code Projekt entschieden, weil es den anderen Angeboten gegenüber Vorteile hatte; von der Lizenz über das Hosting auf dem eigenen Server, kein Redirecting auf andere Websites, etc.

Ich bekomme es auch einwandfrei zum laufen und kann z.B. eindeutig einen Opera-Browser auf einem Android-Tablet als mobiles Device identifizieren auch wenn die User-Agent-Einstellung auf "Desktop" eingestellt ist - was ich mit der einfachen Lösung nicht geschafft habe.
Meine Frage ist nun bloß wie ich das Ganze von der Logik her angehen soll.

Meine bisherigen Gedanken gehen in folgende Richtung:

Hier klicken, um den Code zum Kopieren zu markieren

[== Template/Smarty ==]
{strip}
{mobiledetection}
{process_pagedata}
{cms_lang_info......

Mobile Detection Code (der als Plugin im Verzeichnis /plugins liegt) ausführen

Hier klicken, um den Code zum Kopieren zu markieren

[== PHP ==]
...$smarty->assign('mobiledevice','true')
   } else {
  $smarty->assign('mobiledevice','false')
};

Im Mobile Detection Kit je nach Ergebnis nur eine einfache Variable setzen, true/false (wobei sich das ja bis zum Exzess aufbauen ließe, inkl. iOS-Device, Android-Device, etc.)

Hier klicken, um den Code zum Kopieren zu markieren

[== Template/Smarty ==]
{if $mobiledevice == true}
   <div class='mobile'></div>
{else}
   <div class='desktop'></div>
{/if}

Und in meinem Video-Plugin (welches ja nur auf zwei oder drei Seiten der gesamten Präsenz läuft) nach der Smarty-Variable fischen und nutzen, evtl.

Hier klicken, um den Code zum Kopieren zu markieren

[== PHP ==]
...$smarty->get_template_vars('mobiledevice');

In meinen grauen Zellen scheint das logisch; die Abfrage ob Mobiledevice oder nicht wird ja nur 1x ausgeführt und nicht an 20 Stellen über das Template verteilt (übertrieben gesagt) — andererseits weiß ich ja, dass z.B. das Template vor dem Header generiert wird. Kommt also die Variable überhaupt rechtzeitig an?
Ist das im Grundsatz überhaupt der richtige Ansatz, welche Abweichungen nach CMSms muss ich außerdem noch berücksichtigen?

Deswegen meine ganzen blöden Fragen. Ich bin kein Coder. Fehler im Code erkenne ich durch Syntaxhighlighter und wenn auf der Seite steht "OMG! You broke this page." big_smile
Also, try & error; Code gefühlte 842x korrigieren, verzweifeln, Sicherung hervorkramen und rücksichern, weitere 211x korrigieren, gutes Ergebnis erhalten - aber mit einem komischen Bauchgefühl was ich damit wohl der Performance und dem Serverprozessor angetan haben könnte. Wenn die Seite dann in <= 1 Sek. aufgebaut wird, komisches Bauchgefühl ignorieren und meine eigenwillige Code-Kreation möglichst schnell vergessen... tongue

Da es bislang keine Module zum Thema "Mobile" gibt und ich auch nicht weiß was ich da GUI-mäßig einbauen sollte (außer vielleicht einem »Update-Knopf« für den Detection Code), dachte ich eben an ein Plugin. Auch andere bisherige Ansätze scheinen nicht richtig zu funktionieren, z.B. habe ich mit CGSmartImage noch kein Bild auf Device-Breite verkleinert bekommen (aber das ist ein ganz anderes Thema).
Da ich dasselbe Problem hatte wie Sigi in seinem Beitrag, kam das eine und das andere eben zusammen und die Idee von zwei Plugins entstand, wo halt das eine auch gut ohne das andere auskommt und das Video-Plugin im Notfall den Detector braucht (aber die Funktion ließe sich doch sicher auch noch irgendwie mit einem Schalter deaktivieren? z.B. {html5video src="pfad_zum_video" width="640" height="480" mobiledetect="false"}).

Daher meine Bitte: Wie gut ist der Entwurf bisher? Kann das funktionieren? Updates und Bereinigungen überlasse ich gerne weiteren Codern im Laufe der Zeit, wenn (und falls überhaupt) sich das Plugin wachsender Beliebtheit erfreut.

nockenfell · 06. November 2012 09:29

Die CGExtensions führt ebenfalls Tools zum erkennen von mobilen Geräten mit. Allerdings habe ich damit nie gearbeitet.

In der ToolBox habe ich das MobileDetect welches du verwendest als Smarty-Plugin eingebaut. Allerdings ist die aktuelle ToolBox Version noch nicht released worden. (werde ich in naher Zukunft machen. Aktuell warte ich noch auf die Englisch Übersetzung. Ich werde die Version wohl ohne Übersetzung veröffentlichen)

Mit der ToolBox erfolgt dann die Abfrage einfach direkt im Template:

Hier klicken, um den Code zum Kopieren zu markieren

{if $tbmobile->isTablet() == true}

Man kann also direkt auf die Klasse zugreifen und alle Methoden nutzen.

rage_all · 06. November 2012 10:51

Englisch kann ich. Jedenfalls um etwa 638% besser als PHP... big_smile
Nee, ernsthaft: Wie umfangreich ist das? Nicht um mich vor der Arbeit zu drücken, nur um abschätzen zu können ob ich Dir die Übersetzung in den nächsten Tagen liefern kann.

Ich bin mit meinem Projekt soweit fertig, würde jetzt gerne mit dieser Nummer noch was drauflegen. Ansonsten gehe ich jetzt gegen Veröffentlichung und werde die Funktion wenn's mal live steht nicht mehr einbauen wollen.

czarnowski · 06. November 2012 11:18

Eine Detektion muss grundsätzlich an oberster Stelle einer Abarbeitung erfolgen damit nachfolgende Einheiten davon profitieren können.

Am sinnvollsten ist es eine Zuweisung bereits dann vorzunehmen nachdem Smarty geladen wurde.

Aber nur true / false ist eigentlich überflüssig, da man heute via responsive Design arbeitet und somit nur noch width und height verwendet und andere spezielle Funktionen via Javascript auslöst.

Ich habe bei mir daher diese in der Core implementierte Funktion der Browserdetektion entfernt , da sinnlos.

Zudem wird regelmässig bei Emulatoren die man zum Test gerne verwendet die Kennung des Parentbrowsers verwendet.

Wer wirklich auf einzelne Fähigkeiten eines Clients eingehen will der muss PHP get_browser ( http://php.net/manual/en/function.get-browser.php ) einsetzen.
Dazu ist die browscap.ini einzusetzen. Um die aber verwenden zu können muss man die php.ini verändern können und man muss diese Datei regelmässig auffrischen.

Über diese PHP Funktion können diverse Fähigkeiten des Clients erkannt werden um nicht so sagen alle die von Bedeutung sein könnten.

Das setzt aber kein Schwein mehr ein da es enorm aufwändig ist und sich der Aufwand mit der Zahl der zu berücksichtigen Parameter steigert.

Und - es sind da tausende von Mobilgeräten enthalten von Asbach Uralt bis aktuelle Modelle, d.h. man trifft also auch auf Eigenschaften die unterschiedlicher kaum noch sein könnten.

Man muss auch sehen das aktuelle Mobileinheiten in mancherlei Hinsicht besser sind als der Durchschnitt von PC Desktops.

So arbeitet der Nexus 10 Tablet mit 2560 x 1600 Auflösung und das auf 10 Zoll und es wird 10 Finger Multitouch eingesetzt.
Gerade diese Multitouchfähigkeiten die über die normale JS Emultaion von click, dblclick u.ä. hinausgeht erfordern - wenn man etwas zur Nutzung dafür hat - einen ziemlichen Einsatz, den es bei normalen PC Desktops z.Z. im Schnitt nicht gibt.

Die weltweit am meisten verbreitete Auflösung bei Smartphones ist z.Z. 320 x 480 Pixel und daher sollte man von dieser Größe bei der Gestaltung ausgehen.

Mein Rat ist daher sich auf responsive Webdesign zu konzentrieren und einen üblichen Javascripteinsatz vorzunehmen.

Ich würde da für andere Ansätze keinerlei Zeit mehr opfern.

Beitrag geändert von czarnowski (06. November 2012 11:36)

faglork · 06. November 2012 12:02

czarnowski schrieb:

Man muss auch sehen das aktuelle Mobileinheiten in mancherlei Hinsicht besser sind als der Durchschnitt von PC Desktops.

Das betrifft übrigens auch die Bandbreite.

Und damit kommen wir zu einem Hauptproblem: *Eigentlich* müsste die Bandbreite mit einfließen, denn:

ein Nexus 10 braucht auflösungsmäßig kein anderes Design, aber wenn dem Nexus nur EDGE zur Verfügung steht dann wäre es besser Inhalte auszuliefern die an die niedrige Bandbreite angepasst sind.

Gibts da ne Möglichkeit? "AutoDetectBandwidth"?

Sowas ähnliches habe ich gefunden:
http://flash.flowplayer.org/plugins/str … check.html
Also muss es irgendwie machbar sein ...

Ein erster Ansatz:
http://coding.smashingmagazine.com/2011 … om-part-1/

Oooh, das gibts als fertiges Produkt:
http://codecanyon.net/item/javascript-b … ter/531891
basierend auf JQUERY? das werde ich mal testen.

Servus,
Alex

Beitrag geändert von faglork (06. November 2012 12:19)

czarnowski · 06. November 2012 12:32

Was eine aktuelle Bandbreite betrifft kann man sich an den Angeboten orientieren die z.B. einen DSL Speed ermitteln.

Um das zu können muss man definiert up - und downloaden um daraus Bits und Bytes pro Sekunde errechnen zu können.
Und man muss dazu auch eine bestimmte Mindestanzahl an Bytes schicken damit überhaupt etwas aussagekräftiges dabei heraus kommt.

Nur eine Angabe wie z.B. ich bin mit 1 MBit verbunden reicht nicht und ist extern auch nicht durch eine einfache Abfrage ermittelbar.

Bei 1 MBit (und bei allen anderen Bandbreiten auch ) entstehen zahlreiche Verluste die eine effektive Bandbreite drastisch reduzieren.
Diese Verluste sind dynamisch und entstehen z.B. über das aktuelle Routing wie auch Belastung der Funknetze, aber auch durch Eingriffe über Tarifparameter (z.B. da hat jemand gerade seine X MB Flat überschritten).
Die Startgeschwindigkeit wird auch über die zur Verfügung stehende Anbindung limitiert, die bei Funkzellenwechsel bereits eine ganz andere sein kann.

Deshalb sind Ergebnisse von Speedmetern auch immer nur Momentaufnahmen.

Jeder der in Abständen mal solche Test's gemacht hat wird wissen - es kommen immer andere Ergebnisse heraus.

Also die Idee - man ermittle mal eben den Speed und mache etwas daraus - die funktioniert nicht.
--------------

Was Bandbreite betrifft - ich gehe mit 100 MBit rein und netto bleibt davon nur ein Teil übrig.
Das hängt auch davon ab wie eine angesprochene Domain eingebunden ist und wie die aktuellen Wege sind.

Wer z.B. unter Windows einen Virenscanner permanent am laufen hat, dem gehen je nach Version und Anbieter bis zu 80% an Bandbreite flöten.

Beitrag geändert von czarnowski (06. November 2012 12:35)

czarnowski · 06. November 2012 12:55

Bei dem geposteten JS Tool zeigt sich das was ich geschrieben habe deutlich - 3 x getestet , 3 x unterschiedliche Werte die bis um 50% voneinander abweichen und sich sehr deutlich von den Ergebnissen meines Providers unterschieden.

Als Testmittel für einen allgemeinen Speedtest also geeignet - aber Momentaufnahme.

Zur Verwendung im Web als Hilfsmittel z.B. beim Layout nicht brauchbar.

Man will wohl auch nicht ernsthaft einem Nutzer 1,5 MB für einen Test aufdrücken der zudem ein paar Sekunden dauert.

Also der Ansatz ist wirklich nicht brauchbar für eine Entscheidungshilfe z.B. bei der Übertragung von Images klein, mittel oder groß.

faglork · 06. November 2012 13:57

czarnowski schrieb:

Also der Ansatz ist wirklich nicht brauchbar für eine Entscheidungshilfe z.B. bei der Übertragung von Images klein, mittel oder groß.

Die Auflösung aber auch nicht.
Und das Endgerät auch nicht.

Bleibt was?

Servus,
Alex

czarnowski · 06. November 2012 14:57

Was Images betrifft ist es doch ganz einfach.
Man hält Images für verschiedene gängige Screengrößen vor und lädt diese per Ajax in Abhängigkeit vom Wert offsetWidth, das war's auch schon.

Das mache ich schon lange und es funktioniert einwandfrei.

Ich halte auch nur 2 Größen vor und sehe zu das das größere Image nicht überdimensioniert ist.

Aber wer will kann natürlich mehr Aufwand betreiben.

Achtung nur Auszug:

Hier klicken, um den Code zum Kopieren zu markieren

[== Javascript ==]
var c = document.getElementsByTagName("body")[0].offsetWidth;
 if (c > 480) {
                    
                    xmlhttp.open("GET","<?php echo ROOT_URL ?>/gp.php?img=" + id + "&end=" + ext);  
                }   
                else if (c < 481) 
                {    
                    xmlhttp.open("GET","<?php echo ROOT_URL ?>/gp.php?img=" + smallid +"&end=" + ext);
                };

Wer will kann mit gleicher Technik natürlich auch unterschiedlich aufwendige Inhalte laden.

faglork · 06. November 2012 15:40

czarnowski schrieb:

Was Images betrifft ist es doch ganz einfach.
Man hält Images für verschiedene gängige Screengrößen vor und lädt diese per Ajax in Abhängigkeit vom Wert offsetWidth, das war's auch schon.

Und was sagt die Screengröße über die Bandbreite? Nix. Einem Nexus 10 über Edge (oder gar gedrosselt nach Aufbrauch der "Volumenflatrate") ist damit nicht geholfen.

Servus,
Alex

czarnowski · 06. November 2012 16:28

Natürlich sagt es nix über die Bandbreite , denn die ist aus bekannten Gründen live und stets präzise überhaupt nicht zu ermitteln.

Und das ist auch völlig wurscht.

Man sollte nur dafür sorgen das die Mittel der Besucher nicht übermässig belastet sind.

Standard UMTS bietet 0,384 MBit / HSDPA 1,8 MBit im Standard kann aber auch wesentlich schneller (LTE) bis 50 MBit - Standard bei LTE 21,6 MBit - das gilt alles nur solange die Funknetze das her geben - kann also schwanken.

Lediglich Billigflatrates fallen nach Ablauf ihres Volumens auf 64 KBit zurück - das aber ist die sogenannte Notleitung und muss nicht berücksichtigt werden.

Also da würde ich mir insgesamt nur Gedanken machen wie man das Volumen reduziert denn die meisten sind mit Billigflats unterwegs.

Einen Sinn einen Steuerungsansatz über die Ermittlung der Zugangspower sehe ich daher nicht - bringt nichts und würde auch nichts daran ändern das man das Datenvolumen an zupassen hätte.

rage_all · 06. November 2012 21:04

Huh, das geht ja ganz schön ins Detail und auch ein bisschen in eine andere Richtung...
Also um das mal aufzulösen: Ich habe einen Button gebastelt, der im Mobile Device direkt die Facebook-App öffnet und auf die Fanpage des Unternehmens zeigt.
Keine Ahnung ob und wie die normalen 'Social-Plugins' auf Mobilgeräten im Gro so unterstützt werden; wegen der im Sommer hochgekochten Datenschutzaffäre der Hannoveraner oder Hamburger habe ich auf dieser Seite sowieso die Plugins nur nach ausdrücklicher Einwilligung dargestellt.

Wie dem auch sei, dachte ich mir dass ein 'kleiner' Button (der am Ende ja doch irgendwie den ganzen Screen eines 320er Gerätes ausfüllt... wink ), mit der Aufschrift "Fan werden auf Facebook" ein geiles Teil sein könnte. Da es auf Desktops keine Facebook-App gibt, kann ein Desktop mit dem Button aber halt auch nix anfangen.
Deswegen ist das via Responsive Design (wie übrigens auch der ganze Rest) ausgeblendet. Alles über 1023 Pixel Breite bekommt das nicht zu sehen - so auch ein iPad im Querformat (shit! da könnte es doch wieder gezeigt werden...).

Natürlich ließe sich - und hier kommt die Nummer mit der Bandbreite auch mit ins Spiel - einiges weiteres machen und dafür einiges anderes sparen. Ich denke z.B. an meine Großformatige Slideshow, die zwar an sich MobileDevice kompatibel ist, weil rein auf JS-Basis unter völligem Verzicht von Flash, aber am Ende knapp 3MB Traffic schluckt.
Anders gesagt: Ich würde mir außerdem knapp 50% des Traffics dieser 3MB vom Server aus sparen, wenn dieser Block gar nicht erst gerendert würde. Ungefähr so liegt nämlich bei dieser Seite das Verhältnis Desktop/Mobile.

Muss das Ding ständig auf dem allerneuesten Stand sein? Nein, muss es nicht - im Augenblick hab ich gar nix und der Kunde zahlt auch keine 24h-7Tage Updates. Isso. Leider. Aber zur Initialisierung lässt sich das gut implementieren und die Leistung sogar verkaufen. Deswegen. Und natürlich der Spielerei wegen. big_smile

Fazit: Responsive Design liegt sowieso an und soll nicht für diese Lösung weichen. Ich würde aber noch ganz gern außerdem z.B. Social Plugins gegen App-Buttons tauschen, schwere Bilder, etc. ganz auslassen und evtl. weitere Funktionen (gaaanz am Ende dieser Straße) wie "Wo bin ich - wie weit habe ich zu diesem Laden?" einsetzen, die auf einem Desktop einfach keinen Sinn machen.

faglork · 06. November 2012 21:16

czarnowski schrieb:

Natürlich sagt es nix über die Bandbreite , denn die ist aus bekannten Gründen live und stets präzise überhaupt nicht zu ermitteln.
Und das ist auch völlig wurscht.
Man sollte nur dafür sorgen das die Mittel der Besucher nicht übermässig belastet sind.
Standard UMTS bietet 0,384 MBit / HSDPA 1,8 MBit im Standard kann aber auch wesentlich schneller (LTE) bis 50 MBit - Standard bei LTE 21,6 MBit - das gilt alles nur solange die Funknetze das her geben - kann also schwanken.

Ob du es glaubst oder nicht, hier bei uns gibts zt. weder UMTS noch LTE, mit viel Glück EDGE. ich empfehle mal einen Blick in den Breitbandatlas
http://www.zukunft-breitband.de/BBA/Nav … suche.html
such mal zb. nach Stadelhofen.

Ich wette du selbst sitzt in einer größeren Stadt. In den strukturschwachen Gebieten sieht das jedoch anders aus. Da kann man nicht einfach "völlig wurscht" sagen.

Vielleicht wäre ein simpler Switch die Lösung?

"Mit niedriger Datenrate unterwegs? Klicken Sie hier für schnellere Übertragung" oder so ähnlich. Und die Einstellung per Cookie speichern. Was meint Ihr?

Servus,
Alex

Beitrag geändert von faglork (06. November 2012 21:22)

czarnowski · 06. November 2012 22:37

Das Thema eigene Bandbreite hat aber nichts mit den empfohlenen Methoden zur Verringerung des Datenflusses für ein Webangebot zu tun.

Natürlich ist die Idee interessant dort etwas auf Basis einer ermittelten Bandbreite zu steuern - aber eben nicht möglich.

Es ist wurscht wie gut die Bandbreite ist da man sowieso nur diese eine Maßnahme treffen kann (eine weitere wäre local Storage - was ich im in einem Rutsch ebenfalls nutze aber erst ab zweiten Aufruf Wirkung zeigt).

Was die eigene Bandbreite betrifft

Nein ich sitze nicht in einer größeren Stadt
Bis vor weniger als 4 Jahren gab es konkret bei mir nur ISDN - heute könnte man bis 1 Gigabit wenn man es bezahlen kann.
Das läuft über den Kabelfernsehen - Anbieter.
Erst jetzt wurden Kabelarbeiten erledigt die der örtliche Stromanbieter übernommen hat und auch ab 1.12. vermarktet bzw. steht zur Verfügung und dann hat auch der Rest hier die kein Kabelfernsehen haben die Chance auf schnelle Leitungen.
Seit drei Monaten steht auch schnelles LTE zur Verfügung und somit sind wir tatsächlich hier auf dem Stand einer Großstadt obwohl es ein kleines Kaff ist.

Gestern Abend war ich in der nächst größeren nur 4 km entfernten Stadt um mir mal ein Smart TV vorführen zu lassen - das Vorhaben scheiterte weil das gesamte Industriegebiet mit nur 1 MBit DSL versorgt wird und da sitzen alle großen Handelsfirmen und Discounter die man so in der BRD kennt.

Also das Thema ist mir sehr bekannt und wer auch über Funk keine Chance hat ist wirklich arm dran.

Natürlich könnte man auch ein Web so aufbauen das man quasi per Schalter eine "Schmalspurversion" anbietet - das ist eine nette Idee und auch einfach zu realisieren.

Allerdings wer responsive Webdesign einsetzt und auch scharf darauf achtet das er keine gewaltigen Images, Slider und ähnliches einbaut der hat schon ein Optimum erreicht.

Ansonsten käme man ja fast auf ein Niveau eines reinen Textbrowsers und den will ja wohl keiner.

Beitrag geändert von czarnowski (06. November 2012 22:38)

czarnowski · 07. November 2012 11:24

Noch eine letzte Bemerkung zum Thema Bandbreite der Besucher.
Wer einen richtigen aber localen Webserver hat und dort bis 1 Gigabit werkeln kann und dann nacheinander jeweils bei gelöschtem Browsercache mal Zeiten testet bei 10 MBit, 100 MBit und 1 Gigabit, wird feststellen das sich die in Stufen von 10x durchgeführte Erhöhung sich absolut nicht linear beim Speed der beim Besucher bemerkbar macht.
Ja es ist sogar überraschend sehr viel weniger was da tatsächlich ankommt.
Es ist sehr stark abhängig davon wie viele Request's ablaufen und wie die Generierungszeit bzw. Reaktionszeit des getesteten Produktes ist.
Ist die G-Zeit bzw. R-Zeit hoch verschwinden die Vorteile zum großen Anteil weil sie nur einen kleinen Teil der Gesamtzeit ausmachen.
Ist die Anzahl der Request's hoch versauen die Pingzeiten das Ergebnis.
Man sollte auch die Anzahl der Ajax Aufrufe unter Beobachtung halten.

Und - die Ergebnisse hängen sehr stark von den Inhalten der jeweiligen Seiten ab d.h. es nützt nichts wenn man nur eine einzige Seite beobachtet.

Eine echte Mitnahme von solchen Geschwindigkeitsvorteilen ist Spezialistentum und lohnt sich nur wenn es darauf ankommt.
Ich verweise auf den Facebook Börsengang bei dem es tatsächlich auf wenige Millisekunden ankam und nun der Nasdaq 40 Mio $ Schadensersatz kosteten.

Unterm Strich - was normale Webseiten betrifft - ist die reale Speedzunahme eher enttäuschend und sie hängt dann auch sehr stark von den Fähigkeiten des Empfangsgerätes und der dort laufenden Programme ab.
Tatsächlich macht sich 10MBit zu 1GBit Speed dort bei der Betrachtung einer Website kaum bemerkbar.

Ja ich möchte sogar behaupten das die meisten Empfangseinheiten (Geräte , Betriebssystem, laufende Systemprogramme und Browser) überhaupt nicht in der Lage sind einen Speed von z.B. gängigen 10,20, 32 MBit voll verarbeiten zu können.

Beitrag geändert von czarnowski (07. November 2012 11:25)

rage_all · 12. November 2012 20:31

Also, Sinn oder Unsinn mal Beiseite (das wollte ich auch nicht wirklich diskutieren... big_smile ), ich habe jetzt die Lösung tatsächlich mit zwei Plugins (ganz ohne Hilfe - STOLZ WIE OSCAR! ) realisiert.

Das eine beinhaltet im Prinzip lediglich den Code vom Google Projekt MobileDetect, sogar ziemlich rudimentär umgesetzt, wenn ich bedenke dass sich ja theoretisch auch ermitteln ließe ob es ein iOS ist oder ein Android, ob es sich um ein iPad handelt oder ein anderes Tablet, 'Chrome' oder 'UC Browser' oder 'Opera Mini' ... etc., etc. (die spinnen, die Coder... wink ).

Der Aufruf findet idealerweise ganz am Anfang im Template statt, mit "{mobiledetection}".
Im Plugin wird das Ergebnis in einer Smarty-Variable gespeichert und ist von dort aus zunächst im Template verfügbar, aber auch in weiteren Plugins, z.B. eben dem {html5video} oder in weiteren Modulen, z.B. dem {Gallery}-Modul.

Ein Aufruf wie ich ihn im Template habe ist

Hier klicken, um den Code zum Kopieren zu markieren

[== Smarty/Template ==]
{if $rawdevicetype == "mobile" || $rawdevicetype == "tablet"}
   <div class='mobileonly container'>...</div>
{/if}

Gibt natürlich irgendwann Kopfweh, wenn z.B. plötzlich irgendwo ein </div> fehlt oder zuviel ist... ops

Das {html5video}-Plugin ist so ziemlich dasselbe wie aus dem Beitrag von Bernd (Klenkes) - DANKE! - Deswegen steht er natürlich auch beim 'Über' an erster Stelle... smile
Aufgebrezelt lediglich um die Punkte
• Mobile Detection vorhanden? --> Dann Ergebnis verwenden und Video-Code ausgeben
• Debug-Informationen erwünscht? --> Dann Kommentare und <p>-Tags mit Hinweisen ausgeben

Mit Sicherheit ließe sich der Code um mindestens 483% beschleunigen und andererstellen Verbessern - mir genügt erstmal, dass er funktioniert und ich es ganz allein zum laufen gebracht hab... devil Wer glaubt diese Teile sollten veröffentlicht werden, möge mir bitte mitteilen wo und wie ich das uploaden, versenden, etc. soll; ich teile das gern mit Euch.

Danke trotzdem für die rege Diskussion, auch das hat mich motiviert das durchzuziehen!

Andynium · 14. November 2012 06:22

rage_all schrieb:

Wer glaubt diese Teile sollten veröffentlicht werden, möge mir bitte mitteilen wo und wie ich das uploaden, versenden, etc. soll; ich teile das gern mit Euch.

Häng es doch einfach hier als Archiv dran wink .

rage_all · 15. November 2012 17:00

Mach ich gern (ich dachte nur irgendwo gäbe es vielleicht eine Plugin-Sammlung oder so...)!

Kreuzigt mich bitte nicht für die Header-Kommentare oder syntaktisch inkorrekte Lizenz-Hinweise, okay?
Das ist mein erstes ganz eigenes Plugin; hab damit noch keinerlei Erfahrungen.

Hier das Paket:
http://www.cmsmadesimple.de/forum/img/m … ctions.zip

Andynium · 15. November 2012 17:40

rage_all schrieb:

Mach ich gern (ich dachte nur irgendwo gäbe es vielleicht eine Plugin-Sammlung oder so...)!

Ist geplant, aber momentan auch 'ne Zeitfrage ...

nockenfell · 25. November 2012 14:07

Mobile_Detect ist neu auch Teil der ToolBox:
http://www.cmsmadesimple.de/forum/viewt … 281#p22281

Forum für CMS/made simple

#1 05. November 2012 13:01

Mobile Detection und HTML5 Videos

#2 06. November 2012 00:33

Re: Mobile Detection und HTML5 Videos

#3 06. November 2012 09:06

Re: Mobile Detection und HTML5 Videos

#4 06. November 2012 09:29

Re: Mobile Detection und HTML5 Videos

#5 06. November 2012 10:51

Re: Mobile Detection und HTML5 Videos

#6 06. November 2012 11:18

Re: Mobile Detection und HTML5 Videos

#7 06. November 2012 12:02

Re: Mobile Detection und HTML5 Videos

#8 06. November 2012 12:32

Re: Mobile Detection und HTML5 Videos

#9 06. November 2012 12:55

Re: Mobile Detection und HTML5 Videos

#10 06. November 2012 13:57

Re: Mobile Detection und HTML5 Videos

#11 06. November 2012 14:57

Re: Mobile Detection und HTML5 Videos

#12 06. November 2012 15:40

Re: Mobile Detection und HTML5 Videos

#13 06. November 2012 16:28

Re: Mobile Detection und HTML5 Videos

#14 06. November 2012 21:04

Re: Mobile Detection und HTML5 Videos

#15 06. November 2012 21:16

Re: Mobile Detection und HTML5 Videos

#16 06. November 2012 22:37

Re: Mobile Detection und HTML5 Videos

#17 07. November 2012 11:24

Re: Mobile Detection und HTML5 Videos

#18 12. November 2012 20:31

Re: Mobile Detection und HTML5 Videos

#19 14. November 2012 06:22

Re: Mobile Detection und HTML5 Videos

#20 15. November 2012 17:00

Re: Mobile Detection und HTML5 Videos

#21 15. November 2012 17:40

Re: Mobile Detection und HTML5 Videos

#22 25. November 2012 14:07

Re: Mobile Detection und HTML5 Videos

Fußzeile des Forums