Smartphones

Janl · 19. Oktober 2012 18:26

Hallo allen,

haben einie von euch schon ein Dmartphone Design gemacht?

Momentan frage ich mich ob besser "media queries" oder eine eigene Zweig in der Menüstruktur
für Smartphones mit eine Resolution van 800 Pixel oder kleiner.

Wie sinnvoll ist der metatag "viewport"?
Es gibt viel Information im Internet aber leider wiedersprechen sich viele.

Gruss,
Jan

czarnowski · 19. Oktober 2012 19:23

Das Thema ist vom Screen her weniger Smartphone - die Bildschirmgrößen bei Laptop, Notebook, Netbook, Tablets und PC variieren ebenso enorm.

Das Thema Smart TV zählt auch dazu.

Am besten mit media queries arbeiten - mache ich nur noch ohne Ausnahme.

Meine Empfehlung aufteilen in Screenbreiten

bis 240
241 - 480
481 - 720
>721

damit kommt man immer klar, egal ob Smartphone der ersten Generation der aktueller High End Geräte.

320 x 480 ist die Klasse von Smartphones die es weltweit am meisten gibt.

Man sollte sich nicht verleiten lassen nur für Iphone und Galaxy der Oberklasse zu arbeiten - das wäre ein Fehlschlag.

Beitrag geändert von czarnowski (19. Oktober 2012 19:23)

Janl · 19. Oktober 2012 21:06

Danke für deine Reaktion,

ich habe vor folgend Grössen zu "bedienen"
960 - 1360 ist schon fertig

600 - 960 über media query
320 - 600 über media query

Es ist doch ebenso möglich min und max Width für diese Geräte an zu geben oder?

mfg
Jan

otter24 · 19. Oktober 2012 21:33

Weil ich ja ein wenig "faul" bin hab ich mir aus yaml4 das was ich benötige rausgepickt und sozusagen meine eigene Vorlage gebaut. Anhand von Yaml4 kann man ganz gut nachverfolgen wie wann Auflösung man bedienen sollte und wie fein man die Abstufungen einbauen kann.

Der Trend geht ja eh zu "mobile first" und es gibt eine Präsentation auf English, wie man am besten eine Website mit mediaqueries umsetzt. Es ist so das es wohl einfacher ist von unten nach oben die Websites umzusetzen also mit der geringste Auflösung anzufangen und sich immer weiter nach oben zu arbeiten. Ich hab eine innere Abneigung dagegen,
weil ich das ja nicht gewohnt bin, aber bei der nächsten Website wird alles anders.

btw. HTC hat für den japanischen Markt gerade ein 5 zoll Smartphone in Full HD auflösung vorgestellt.

und wir kümmeln mit 320 rum... tztztztztzt

czarnowski · 20. Oktober 2012 23:30

Wie bereits gesagt - das Thema ist schon längst nicht mehr Smartphone sondern einfach responsiv Webdesign.

Wer sich als Webanbieter nicht daran hält wird dauerhaft verlieren.

1.920 x 1.080 Pixel als Fulll HD Auflösung das war gestern - das 4 fache davon, das ist Weihnachten der Fall.

Man surfe auf einem Smart TV auf eine Site die für 1024 optimiert ist - grauenvoll.

Man stelle sich das in 4 fach HD Auflösung vor.
Wie sieht es aber aus mit den ca. 600.000 Smartphones bei uns die auf 320 x 480 herum rubbeln und die Masse darstellen?

In der Web - Welt muss man heute an winzige bis gewaltige Bildformate denken.

Wohl dem der auch genügend Inhalte hat.

Das andere Problem ist tatsächlich die Prozessorleistung von Smartphones die im Bereich von 800 bis 1000 Mhz liegen und die auf X Gb beschränkte Pseudoflat, die dann auf ISDN Niveau fällt.

faglork · 20. Oktober 2012 12:21

czarnowski schrieb:

Das Thema ist vom Screen her weniger Smartphone - die Bildschirmgrößen bei Laptop, Notebook, Netbook, Tablets und PC variieren ebenso enorm.
Das Thema Smart TV zählt auch dazu.
Am besten mit media queries arbeiten - mache ich nur noch ohne Ausnahme.

Ja, *prinzipiell* richtig. Allerdings werden (mindestens) zwei Probleme damit nicht erfasst:

a) könnte man bei großen Bildschirmen evtl. mehr Inhalt anbieten, um den "screen estate" besser zu nutzen. Zb. eine weitere Spalte mit Hinweise auf Inhalte, die tiefer in der Site verborgen liegen ("content surfacing"). Das könnte zb. ein"Produkt des Monats" sein o.ä.

b) haben mobile Endgeräte z.t. Eigenschaften, die ein PC z.t. nicht hat - zb. Übermittlung von GPS-basierten Standortinformationen.

Beides ist mit einer reinen CSS-Lösung nicht zu lösen.

czarnowski schrieb:

Meine Empfehlung aufteilen in Screenbreiten
bis 240
241 - 480
481 - 720
>721
damit kommt man immer klar, egal ob Smartphone der ersten Generation der aktueller High End Geräte.
320 x 480 ist die Klasse von Smartphones die es weltweit am meisten gibt.

Wegen der immensen Vielzahl von Screenbreiten ist eine Vorab-Auswahl IMO nicht so sinnvoll.
Ich schlage einen anderen Weg vor: kontinuierlich von großer Screenbreite runtergehen bis zu 240 ... und sobald die Site vom Design her nicht mehr bedienbar ist (oder hässlich aussschaut) ein Media Query einfügen und anpassen.

czarnowski schrieb:

Man sollte sich nicht verleiten lassen nur für Iphone und Galaxy der Oberklasse zu arbeiten - das wäre ein Fehlschlag.

Auf jeden Fall. Siehe dazu http://vimeo.com/39483947
Unbedingt ansehen. Lang, aber lohnt sich.

Servus,
Alex

czarnowski · 20. Oktober 2012 15:20

Ob hoch oder runter ist eigentlich fast egal.

In den vorgeschlagenen Breiten gibt es Smartphone - Auflösungen, auch wenn sich da die kleinen im Laufe der Zeit egalisiert haben.

Man muss auch sehen, das ein Smartphone gedreht werden kann und da liegen diese Bereiche z.Z. noch gut.

Kritisch sind immer die kleinen aber sehr gängigen Auflösungen da muss man sich richtig etwas einfallen lassen z.B. auch bei der Navigation.

Unkritisch sind die hochauflösenden mobilen Geräte - denen kann man schon fast ein Normalweb vor die Nase setzen.

Deshalb meine Empfehlung von unten anfangen. Hat man das einmal richtig durchgezogen kann man x mal von den Erfahrungen profitieren .

Zu a und b.

Wir gehen hier ganz klar in Richtung HTML 5 und HTML 5 ohne Javascript ist wie eine Flasche ohne Inhalt und JS ohne Ajax wie eine versalzene Suppe.
Die Anforderungen an Webersteller werden nicht nur damit durchaus wesentlich höher, denn wenn zudem noch Informationen tief aus dem DB System des Webanbieters zu holen sind auch noch umfangreiche PHP und Mysql - Kenntnisse.

Man darf bei hochwertigen großer Anbieter Webs nicht davon ausgehen, das man ein CMS nimmt Layout und Inhalte erstellt und das war es dann - da laufen Inhalte aus den Tiefen des ganzen Betriebes ein.

Bei JS Einsatz geht es immer mehr zu kleinen individuellen auf das Web angepasste Einheiten.
Die Zeit der ewigen Standard Slideshows und Standardscripts ist fast vorbei.

Zu a

Aktuelle PC Browser bieten alle Geolocation an. Die Herausgabe muss allerdings vom Besucher bestätigt werden und sie ist je nach Browser mehr oder weniger genau.
Am schlechtesten sind da der IE 9/10 und der FF, da gibt es sogar Abweichungen von einem zum nächsten Aufruf um bis zu 30 km.

Extrem präzise ist Chrome - bei allen Test's von diversen Standorten immer Volltreffer genau vor der Haustür.

Ansonsten können Smartphonebrowser auch nicht mehr als normale Browser abgesehen davon das die vorhandenen systemweiten Gestensteuerungen nutzen, die man als Webersteller mangels vorhandener Events nicht ansprechen kann (und auch nicht muss - da diese vorzugsweise für Apps sind).

Zu b

Das ist angesagte Taktik Zusatzflächen bei großen Monitore via Ajax zu befüllen und darzustellen und umgekehrt Inhalte die vom Transfer her zu aufwendig sind bei Smartphone Klasse X weg zu nehmen oder in völlig anderer Form darzustellen.

Ein grundsätzliches Problem bei mobilen die Verarbeitungsgeschwindigkeit.

Zum einen sind die Ping Zeiten deutlich langsamer als bei PC's (ich meine nicht einen WLAN Zugriff) und die Transferzeiten sind nicht kalkulierbar die können von High Speed bis ISDN gehen.

Aus Erfahrung kann ich sagen das mobile Nutzer nie wieder kommen wenn denen das alles zu lange dauert.
Die meisten haben zudem eine limitierte Flatrate (300..500 MB Transfer), danach winkt ISDN Power.

Da ist auch die Sache welche otter24 an anderer Stelle angesprochen hat -> Angebot von Images passend zum Format - arbeitet man nur mit einem Image für alle liegt man was das Volumen betrifft daneben und schreckt die Besucher ab.

Auch solche Dinge kann mit Ajax etwas PHP vollkommen automatisch regeln.

Man ahnt das Thema ist hier nur angerissen, hat man das einigermaßen im Griff profitieren alle davon PC Nutzer wie auch die Mobilen Nutzer.

Und ein Tipp - pfeift auf die Browsernutzer die mit altem Scheiß unterwegs sind und deshalb HTML5 nicht oder nur eingeschränkt können.
Macht man das denen gerecht tritt man das Publikum in den Hintern die aktuell sind.
Man verliert mehr als man dabei gewinnt, wenn man die Unverbesserlichen unterstützt.

Beitrag geändert von czarnowski (20. Oktober 2012 15:22)

faglork · 22. Oktober 2012 08:38

czarnowski schrieb:

Aktuelle PC Browser bieten alle Geolocation an. Die Herausgabe muss allerdings vom Besucher bestätigt werden und sie ist je nach Browser mehr oder weniger genau.
Am schlechtesten sind da der IE 9/10 und der FF, da gibt es sogar Abweichungen von einem zum nächsten Aufruf um bis zu 30 km.
Extrem präzise ist Chrome - bei allen Test's von diversen Standorten immer Volltreffer genau vor der Haustür.

Mag sein, nur ist die die potentielle Verwendung anders gelagert. Kleines Beispiel: Wir diskutieren gerade im Tourismusverein, ob wir nicht den Wanderern standortabhängige Infos anbieten - die Infos haben wir eh auf der Website, den Standort liefert das Smartphone. Eine klassische Web-App sozusagen. Das ist bei einem stationären PC aber sinnlos ...

Das ist so ein Beispiel für etwas was sich nicht mit CSS erledigen lässt.

czarnowski schrieb:

Man darf bei hochwertigen großer Anbieter Webs nicht davon ausgehen, das man ein CMS nimmt Layout und Inhalte erstellt und das war es dann - da laufen Inhalte aus den Tiefen des ganzen Betriebes ein.

Full Ack.

Servus,
Alex

czarnowski · 22. Oktober 2012 11:24

Zunächst wäre das mal eine sinnvolle Nutzung von Geolocation.

faglork schrieb:

Eine klassische Web-App sozusagen.

Nein - das kann man einfachst auch mit dem Web machen - eine App ist da vollkommen überflüssig.
Wenn man dann auch noch einen Button definiert und anbietet den man sich als Smartphonenutzer auf die Scheibe legen kann und man damit z.B. die Infoseite direkt aufrufen kann, dann hat man alles was man benötigt.

Die aktuellen Smartphonebrowser liefern alle die Geolocation wenn sie denn können.

Das Verfahren ist einfach:

1. Inhalte müssen Geopositionen lat und lon enthalten zu denen sie gehören sonst läuft nichts

2. Geoposition abholen und bei Erfolg (das kann der Smartphonebesitzer auch unterdrücken oder sein Gerät kann es nicht) eine Umkreissuche zu den Inhalten mit Geopositionen machen.
Eine solche Umkreissuche dauert nur Millisekunden , Zeit kann man also vernachlässigen.

3. Bei Treffer via Ajax darstellen - fertig

So etwas kann man in wenigen Minuten erstellen, wenn die Datenbasis vorhanden ist.

Erheblich mehr Arbeit hat man damit das im Backend zu organisieren bzw. zu schreiben, den hat man auch wenn man sich eine App bastelt.

-------------------------

Bei stationären Geräten ergibt es dann auch einen Sinn wenn man auch massiv Inhalte zu den verschiedensten Regionen hat.

Solche Beispiele sieht man laufend wo man z.B. Werbung aus der betreffenden Region angezeigt bekommt.

Janl · 22. Oktober 2012 12:16

Danke für diese Beiträge,

czarnowski wie werde so etwas aussehen für ein Taxibetrieb?

Es gibt einige "Apps", sogar umsonst, aber man braucht doch ebenso ein Server wo alle Taxi's dieser Zentrale mit ihre Geolocation bekannt sind oder?

Das werde heißen,
- ständige Ortund der Fahrzeuge
- bei Anruf: Ortung der Anrufer
- vergleichen der Geolocations und die Taxi, wo der Unterschied am kleinsten ist, aussuchen
- ausgewählte Taxi ein Bericht schicken mit Geolocation der Anrufer

Wie sieht euch das?

mfg
Jan

czarnowski · 22. Oktober 2012 13:40

Für Taxis und andere "Fuhrbetriebe" gibt es sogenannte Flottenmanagementsysteme.
Da verfügen die Taxis über eine GPS Ortung.
So manche der Zentralen verwenden tatsächlich Smartphones im Taxis, dann aber meist nur als Ersatz für die angestaubten PDA's.
Sind die Im Einsatz weiß die jeweilige Zentrale stets wo sich ihre Fahrzeuge aufhalten.
Und sie wissen auch welche davon frei und verfügbar sind.

Ruft ein Kunde über eine App eine Taxizentrale an gibt die App die Position bekannt.
Ist das Ziel eine eingespeicherte Position (z.B. nach Hause), dann wird auch die Zielposition bekannt gegeben, ansonsten ist es ein normaler Anruf bei dem man den Einsteigeort und Uhrzeit ansagen muss.

Diese Apps machen eigentlich wenig bis nichts - ein Anruf - Postionsnennungen und das war's.
Der ganze Rest läuft in der Zentrale ab.

Auch dort macht man eventuell eine Umkreissuche zum nächsten freien Taxi und kann den über eine neue Tour informieren.
Da in der Regel auch eine visuelle Darstellung der Standorte gegeben ist und auch die Besetzung der Zentrale hervorragende Ortskenntnisse besitzt wird man sicher auch so eine Entscheidung treffen.

So eine Umkreissuche hört sich nach riesigem Programmieraufwand an ist es aber nicht.
Ein Durchlauf ist in Nullkommanix gemacht.

Forum für CMS/made simple

#1 19. Oktober 2012 18:26

Smartphones

#2 19. Oktober 2012 19:23

Re: Smartphones

#3 19. Oktober 2012 21:06

Re: Smartphones

#4 19. Oktober 2012 21:33

Re: Smartphones

#5 20. Oktober 2012 23:30

Re: Smartphones

#6 20. Oktober 2012 12:21

Re: Smartphones

#7 20. Oktober 2012 15:20

Re: Smartphones

#8 22. Oktober 2012 08:38

Re: Smartphones

#9 22. Oktober 2012 11:24

Re: Smartphones

#10 22. Oktober 2012 12:16

Re: Smartphones

#11 22. Oktober 2012 13:40

Re: Smartphones

Fußzeile des Forums