Ontwikkelen voor mobile devices: best practice?

[Dark Blue]

Ik ben bezig met het ontwikkelen van een omgeving waarin onze klant z'n projectstatus kan zien. Ontwikkelen voor desktop is geen probleem: maar nu is de wens van de klant om het op een 'mobile device' te tonen. Fijn als het is is dat device niet gespecificeerd, en willen we in onze demo gewoon de klant z'n mobieltje laten pakken en zeggen 'dit is de link, dit is je inlog, kijk maar'. En dan moet de site, door mij ontworpen, goed weergegeven worden.

Ik heb er nu twee dagen aan gezeten, met twee verschillende benaderingen, en ik kom er niet uit. Aan het einde van dag 1 hebben we de site getest met een iPhone, een Windows Mobile IE en een paar Android telefoons. Op de iPhone en de Android devices zag het er belabberd uit, op mijn WM zag het er redelijk uit. De iPhone stond, werd mij gezegd, niet op desktop modus, en de Android wel... enfin op die telefoons was de body huge geïnterpreteerd en werd de site piepklein in een hoekje weergegeven. Op mijn WM mobiel paste de site net (geen desktopmodus iig).

Nou had ik dat laatste graag op alle drie de platformen gezien. Maar, ik heb het mezelf wat moeilijk gemaakt
Omwille van handige duimnavigatie heb ik in de ontwerpschetsen het hoofdmenu onderaan de pagina geplaatst met dikke knoppen (op Apple-advies 44px hoog, ook dat is nog testen). De content moet daar onderdoor scrollen als die langer is dan schermhoogte-44px.

Dat onderaan plaatsen is an sich geen probleem dmv. de positionering van objecten die ik al jaren toepas:

Cascading Stylesheet:

#menu
{
position: absolute;
width: 240px;
height: 44px;
left: 50%;
bottom: 0;
margin-left: -120px;
}

Dat is even uit mijn hoofd, zo heeft hij in mn testomgeving ook gewerkt. Het gaat allemaal goed zolang je content maar niet groter wordt dan je scherm, dan blijft het menu staan onderaan de origineel berekende body-hoogte. Helemaal erg wordt het wanneer je het device draait; dan houdt hij de origineel berekende body-hoogte aan en staat het menu doodleuk midden op de pagina.

Ik denk dat ik me wat onmogelijks op de hals heb gehaald met die div.
Ik ken WSAbstracht en DynamicDrive en ik zou daar een javascriptje vandaan kunnen halen dat telkens dat menu naar de onderkant schopt. Maar dat levert volgens mij haperingen op, en zolang als ik van javascript af kan blijven doe ik het. Nog niet serieus naar gekeken dus.

Ik heb aan frames gedacht (lang, diep denken, tien jaar terug ) en gezegd: nee. Mobiele browsers van vandaag de dag wil je geen frames voeren. De content hoeft niet met een zoekmachine gevonden te worden, maar dan nog: liever geen frames. In dezelfde hoek heb ik aan een oplossing met tabellen gedacht. Ook dat vind ik not-done omdat je tabellen moet gebruiken voor tabular data, niet voor het geforceerd uitlijnen van je page.

Maar wat dan? Ik weet mijn schermhoogte nooit. Ik kan het ook niet beter gespecificeerd krijgen dan dit, en morgen moet ik verder (en moet het tegen vijf uur toch wel af ).

Ik wil wel een splitsing maken tussen css media: screen en css media:handheld, en dan wat testen (als daar nog tijd voor is...).
Ook heb ik artikelen gelezen over het toevoegen van een metatag met daarin de deviceheight / devicewidth. Ook daar ben ik nog niet helemaal achter wat daarmee het beste te doen. Kan ik daar een hoogte opgeven, in de html/body-css ook een fixed hoogte opgeven, en hopen dat alle mobile browsers snappen dat dat z'n viewport-hoogte is? Heeft iemand een goed artikel of een goede tutorial hoe ik dat toe hoor te passen?

Ik ben bereid om vanavond nog wel even wat te testen, ik kan hier lokaal ook een site aanmaken en met wat mobile emulators testen. Maar morgen moet er keihard geproduceerd worden, en is er geen tijd om nog een dag aanvliegroutes uit te proberen. Kan iemand me even een stukje op weg helpen hier?

[Maaark]

Ik meen gelezen te hebben dat je juist nergens het aantal px moet zetten maar alles in %'s moet zetten?

[Dark Blue]

Zo dacht ik ook (vandaar ook de tabel-benadering eventjes...) maar wat doe ik dan met mijn plaatjes? Die kan ik moeilijk procentuele groottes mee gaan geven.

Plaatjes zijn in mijn geval iconen op buttons, er staan geen plaatjes in de content.

[Voor 21% gewijzigd door Dark Blue op 15-05-2011 19:30]

[R4gnax]

Dark Blue schreef op zondag 15 mei 2011 @ 19:30:
Zo dacht ik ook (vandaar ook de tabel-benadering eventjes...) maar wat doe ik dan met mijn plaatjes? Die kan ik moeilijk procentuele groottes mee gaan geven.

Plaatjes zijn in mijn geval iconen op buttons, er staan geen plaatjes in de content.

Plaatjes geef je een statisch grootte mee. Welke grootte en welk formaat hangt af van de gebruikte device en dus zul je daarvoor media queries of serverside detectie moeten gebruiken.

Overigens, voordat je te hard van stapel gaat lopen met de Window Mobile ondersteuning: hou er even rekening mee dat de Internet Explorer bij Mobile 6 een ietwat veredelde desktop IE4 is( <- ouch! ) en dat Phone 7 hier in Nederland verhoudingsgewijs nog in de kinderschoenen staat. De Internet Explorer bij Phone 7 stamt voorlopig ook nog af van desktop IE7. In de toekomst moet Phone 7 gaan beschikken over een build van IE9.

Mijn advies zou te zijn om te mikken op Android & iPhone webkit browsers en op Opera Mobile. Vervolgens zorgen dat de site nog werkbaar is onder Windows Mobile / Phone en Blackberry, desnoods met minder features of bling.

[TERW_DAN]

Dark Blue schreef op zondag 15 mei 2011 @ 19:30:
Zo dacht ik ook (vandaar ook de tabel-benadering eventjes...) maar wat doe ik dan met mijn plaatjes? Die kan ik moeilijk procentuele groottes mee gaan geven.

Wat ik heb gedaan toen ik bezig was met embedded devices met nog gaardere browsers als die je daar nu hebt (denk aan Ant Galio en niet gedocumenteerde versies van Opera for devices), is de grootte van de plaatjes door javascript uit te laten rekenen afhankelijk van de schermgrootte, of de daadwerkelijke grootte van het element.
Niet ideaal (verre van), maar op die manier was het tenminste voor elkaar te krijgen en was ik niet afhankelijk van de schermgrootte van het apparaat (wat verschilde tussen 576i tot 1080i resoluties).

Als je de mogelijkheid hebt om je browsers te beperken tot webkit en opera mini, dan zou ik dat doen, dat scheelt je al heel veel ergernissen. IE op WM is echt een grafbrowser, als je die kan omzeilen, dan zou ik dat lekker doen.

[orf]

Heb je naar CSS media queries gekeken? Daarmee kun je handig je layout aanpassen aan de schermgrootte. Apple heeft goede guidelines waarmee je web-apps kunt ontwikkelen. Zoom uitschakelen en een initial zoom instellen.

[Dark Blue]

orf schreef op zondag 15 mei 2011 @ 20:07:
Heb je naar CSS media queries gekeken? Daarmee kun je handig je layout aanpassen aan de schermgrootte. Apple heeft goede guidelines waarmee je web-apps kunt ontwikkelen. Zoom uitschakelen en een initial zoom instellen.

Ja, daarvan had ik documentatie gevonden... daar had ik ook die info over die metatag vandaan. Ik weet even niet meer waar ik die gevonden had. Even snel Googlen brengt me nu alleen naar de developer guide van iOS, doelend op applicaties, niet op websites.

Maar, ja, zoom uitschakelen? Dat lijkt me het kreupelslaan van een goede browserfeature omwille van je eigen layout. Ik heb er namelijk ook van gelezen dat als je dan met forms werkt, de browser nooit zal inzoomen op formuliervelden. Als ze groot genoeg zijn, soit; maar als ze te klein zijn, kun je verder niks dan je loep pakken.

En initial zoom? Die zou ik op 1.0 zetten, tenzij je precies weet hoeveel maal 'n webdevice moet zoomen om je website fullscreen te zien?

[orf]

Initial zoom zet ik op 1 inderdaad. Dat maakt het ontwikkelen makkelijker. Zoom kun je uitzetten als je niet wilt dat er gezoomed wordt. In een goede mobiele webapplicatie of mobiele website is zoomen niet nodig.

Voor je menu kun je gebruik maken van position:fixed. Zowel Android als iOS hebben browsers die veel HTML5 specs ondersteunen. Dat maakt het een stuk makkelijker om te ontwikkelen. Media queries worden genegeerd door browsers die het niet ondersteunen, waardoor je in die browsers de gewone versie ziet.

Hier een voorbeeldje van een aardige website die goed schaalt. Kijk ook even naar de persistent-bar onderaan: http://sasquatchfestival.com/. Maak je browservenster kleiner in een browser die media-queries ondersteunt.

[Dark Blue]

Naar dat position:fixed zal ik eens kijken.

Manmanman, wat is dat ontwikkelen voor 'n mobiele app een vak apart!
Ik wou dat ik me dáar al tien jaar in had verdiept (met 'n glazen bol...) ipv. desktop webontwikkeling.
Gets man, hoe meer ik lees, hoe minder ik geloof dat ik dat morgen in 8 uur werkend ga krijgen

Wtf, zo op w3schools te lezen is position:fixed een hele normale property, ... die door alle browsers ondersteund wordt? waarom kende ik die niet... morgen eens mee experimenteren.
http://www.w3schools.com/css/pr_class_position.asp

[Voor 27% gewijzigd door Dark Blue op 15-05-2011 23:20]

[Bosmonster]

Position fixed werkt niet op mobile Safari (weet niet hoe het zit met andere mobiele browsers).

[R4gnax]

Dark Blue schreef op zondag 15 mei 2011 @ 20:32:
Ik wou dat ik me dáar al tien jaar in had verdiept (met 'n glazen bol...) ipv. desktop webontwikkeling.

Geloof me: dat wil je niet. Dan had je namelijk het tijdperk mee gemaakt van gare WAP browsers, waar Blackberry en IE Mobile nog als 'modern' beschouwd konden worden.

[Dark Blue]

R4gnax schreef op maandag 16 mei 2011 @ 08:49:
[...]

Geloof me: dat wil je niet. Dan had je namelijk het tijdperk mee gemaakt van gare WAP browsers, waar Blackberry en IE Mobile nog als 'modern' beschouwd konden worden.

Dat is ook weer waar, maar dan had je gewoon bij alle vorm van fancy opmaak de deur dicht kunnen gooien en zeggen 'kan niet, los het maar op in tekstlinks!'
Dan was het positioneren van 'n knoppenrij onderaan gewoon out of the question, gewoon hup, twee links onder je inlogform...

De richtlijnen van Apple, waar ook die device-width in staat, staan trouwens hier:
http://developer.apple.co...ef/Articles/MetaTags.html

[OkkE]

Het is nog vroeg en ik heb weinig koffie op; maar wil je nu een speciale mobile versie van een website met een status raport maken? Of wil je een desktop site iets aanpassen en op mobile devices laten zien?

[Bosmonster]

R4gnax schreef op maandag 16 mei 2011 @ 08:49:
[...]

Geloof me: dat wil je niet. Dan had je namelijk het tijdperk mee gemaakt van gare WAP browsers, waar Blackberry en IE Mobile nog als 'modern' beschouwd konden worden.

Idd. Juist de kennis van een aantal jaar geleden heb je 0,0 aan vandaag de dag. Het mobiele landschap is met iPhone/Android etc en Webkit-based mobiele browsers compleet veranderd.

Verder met OkkE. Het is mij ook niet helemaal duidelijk wat je nu precies wilt en/of al hebt.

[Dark Blue]

Nou, op dit moment is in scope dat we een aparte versie maken voor mobiele browsers.

De 'desktopversie' van de projectversie is namelijk een Silverlight-applicatie, met een veel uitgebreidere interface.

[OkkE]

Jullie hebben een eigen systeem waar klanten de status van hun project kunnen bekijken (met Silverlight) en daar wil/moet jij nu een mobile-version van maken?

Schrap alle functies die niet direct nodig zijn. Bouw het bijvoorbeeld met 320andUp op, en hou het ontwerp simpel; doe zo veel mogelijk met CSS3.

[wackmaniac]

Een menu dat statisch onderaan je pagina staat gaat een hele uitdaging worden; je scrollt namelijk niet op een mobile device (iOS en Android), maar je verschuift je viewport. Een statisch menu onderaan zal dus haast wel afhankelijk zijn van javascript.

Met de metatag:

HTML:

<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1">

kan je voorkomen dat je website heel klein wordt weergegeven.

Nog even een tip: iOS testen kan heel makkelijk met Safari en de developer bar; daar kan je de user-agent instellen op iPhone, vernstergrootte aanpassen en testen maar!

[Tharulerz]

Met wackmaniac ^^

Je moet voor iPhone zeker de meta viewport tag gebruiken, maakt alles er een stuk handiger op. Zoek maar eens wat meer info erover, vind je zat tutorials/guides rond.

[Bosmonster]

wackmaniac schreef op maandag 16 mei 2011 @ 18:27:

Nog even een tip: iOS testen kan heel makkelijk met Safari en de developer bar; daar kan je de user-agent instellen op iPhone, vernstergrootte aanpassen en testen maar!

Er zitten echter wel flinke verschillen tussen de desktop Safari en iOS Safari. Zoals het scrollen dus bijvoorbeeld wat al eerder genoemd is.

[kwaakvaak_v2]

dus is het makkelijker om als je de beschikking hebt over een mac, xcode te installeren en te testen in iPhone simulator. Of beter nog, gewoon op de echte hardware. Gelukkig kun je hiervoor ook een veel goedkopere iPod touch gebruiken omdat die precies dezelfde browser heeft dan alle andere ios speeltjes.

Voor android telt ongeveer hetzelfde, en is de android devkit best goed te noemen en kun je redelijk makkelijk de verschillende telefoons emuleren. En die android kit draait in java, dus ook prima op windows,linux en osx.

[wackmaniac]

Allemaal waar, maar aangezien de engine vrijwel gelijk is, is het makkelijker om Safari heel vaak te vernieuwen, dan om telkens te vernieuwen op je iPhone

[Dark Blue]

OkkE schreef op maandag 16 mei 2011 @ 10:36:
Jullie hebben een eigen systeem waar klanten de status van hun project kunnen bekijken (met Silverlight) en daar wil/moet jij nu een mobile-version van maken?

Klopt. We ontwikkelen applicaties in Silverlight, daar kunnen klanten ook in bewerken. De klant wil het graag op 'een mobile device' kunnen inzien - welk device is nog niet zo afgebakend - en omdat Silverlight nog niet op alle devices ondersteund wordt, doen we het nu via de browser. Al het ontwikkelde spul wordt in Umbraco gehangen. Ik doe het ui-ontwerp + de html, mijn collega's programmeren de functionaliteiten .

Schrap alle functies die niet direct nodig zijn. Bouw het bijvoorbeeld met 320andUp op, en hou het ontwerp simpel; doe zo veel mogelijk met CSS3.

Interesting... ga ik eens lezen

wackmaniac schreef op maandag 16 mei 2011 @ 18:27:
Een menu dat statisch onderaan je pagina staat gaat een hele uitdaging worden; je scrollt namelijk niet op een mobile device (iOS en Android), maar je verschuift je viewport. Een statisch menu onderaan zal dus haast wel afhankelijk zijn van javascript.

Oh god, dat kan m'n hele pagina die ik gisteren op heb gezet nog wel eens om zeep helpen

Met de metatag:

HTML:

<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1">

kan je voorkomen dat je website heel klein wordt weergegeven.

Nog even een tip: iOS testen kan heel makkelijk met Safari en de developer bar; daar kan je de user-agent instellen op iPhone, vernstergrootte aanpassen en testen maar!

Goeie tip, ik had Safari hier op Windows al draaien, was alleen dat developer-menu even vergeten
Ziet er op zich wel goed uit als ik hem toon ook het scrollen van de content onder het menu door...
Hij maakt alleen z'n viewport 330 breed en geen 240!

Uit mijn boek 'Designing for Small Screens' had ik een size van 240 breed x 320 hoog getoverd... klopt die wel?

wackmaniac schreef op dinsdag 17 mei 2011 @ 09:03:
Allemaal waar, maar aangezien de engine vrijwel gelijk is, is het makkelijker om Safari heel vaak te vernieuwen, dan om telkens te vernieuwen op je iPhone

Ja, we hebben hier een iPhone tot onze beschikking, een WM telefoon en een paar Android beestjes... nadeel is dat de site dan eerst in de testomgeving gehangen moet worden die van buitenaf te benaderen is
Dus ik kan niet voor iedere update en elk css-wissewasje dat ding vernieuwen. Iets met emmertjes water doorgeven

[Shrimp O Vis]

http://jquerymobile.com/

Is dit misschien iets wat je kan gebruiken?

[Voor 40% gewijzigd door Shrimp O Vis op 17-05-2011 10:01]

[Dark Blue]

Shrimp O Vis schreef op dinsdag 17 mei 2011 @ 10:01:
http://jquerymobile.com/

Is dit misschien iets wat je kan gebruiken?

Iets meer uitleg erbij had wel gemogen

Maar, ziet er wel mooi uit, even kijken wat ik er mee kan.

[OkkE]

Dark Blue schreef op dinsdag 17 mei 2011 @ 09:58:
Uit mijn boek 'Designing for Small Screens' had ik een size van 240 breed x 320 hoog getoverd... klopt die wel?

Het lijkt me toch niet geheel onverstandig om minimale eisen vast te stellen. Leuk die 320x240, maar als de klant daar op admin taken wil gaan doen? Ik wens 'm succes.

Overgens kun je met Media Queries al een hoop oplossen. Zo kun je de iPhone 4 gebruikers gewoon een 960x640 site toesturen, en de gebruikers met een kleiner scherm weer iets anders.

Handig: Luke W. is (een van de) bedenker(s) van "Mobile First" en in mijn ogen heeft hij heel veel goede tips en ideeen.


--- edit ---

@fsve;
Het zijn prima libraries hoor, dat is het niet, maar als ik DarkBlue hoor over resoluties van 320x240, dan denk ik aan oude mobile devices, en vraag ik me af of het wel slim is om zulke Javascript geintjes toe te gaan passen.

--- edit 2 ---

@Dark Blue;
Om wat voor soort taken gaat het eigenlijk? Is het alleen data/stats bekijken in tabelvorm? Is het simpele key=value aanpassen? Of hebben we het over complete CMS of CRM applicaties? Zonder meer informatie over wat er precies gebeuren moet is het vrij lastig goed advies te geven. Juist met Mobile is context het belangrijkste.

[Voor 28% gewijzigd door OkkE op 17-05-2011 10:21]

[fsve]

Dark Blue schreef op dinsdag 17 mei 2011 @ 10:05:
[...]

Iets meer uitleg erbij had wel gemogen

Maar, ziet er wel mooi uit, even kijken wat ik er mee kan.

jQueryMobile, of jQtouch (http://jqtouch.com/) zijn javascript frameworks waarmee je heel eenvoudig mooi ogende webapps kunt bouwen (voornaamste ondersteuning voor webkit browsers, maar binnenkort ook WP7 ondersteuning).

Als het kan zou ik afstappen van de navigatie onderaan te plaatsen, maar gewoon in de header bovenin. Dan zit je altijd goed. Het scrolt prima naar boven en de meeste browsers hebben de feauture om "bovenin te tikken, iOS" om weer helemaal naar boven te gaan.

Daaronder kan je gewoon je pagina opbouwen zonder rekening te houden met je menu.

Succes met bouwen!

[Dark Blue]

OkkE schreef op dinsdag 17 mei 2011 @ 10:12:
[...]

Het lijkt me toch niet geheel onverstandig om minimale eisen vast te stellen. Leuk die 320x240, maar als de klant daar op admin taken wil gaan doen? Ik wens 'm succes.

Gelukkig hoeven ze er geen admintaken op te doen. Het is het inzien van projectstatus, niet het bewerken.

Overgens kun je met Media Queries al een hoop oplossen. Zo kun je de iPhone 4 gebruikers gewoon een 960x640 site toesturen, en de gebruikers met een kleiner scherm weer iets anders.

Ja en dat wil ik juist vermijden... aparte CSS-files, allemaal @media declaraties met afwijkende dingen. Ik weet wel dat het zo wérkt, maar ik krijg er een nare smaak van in m'n mond sinds ik met een developer samen heb gewerkt die niet zo snugger in z'n CSS overal !important had geplaatst. Ik heb dagen lopen zoeken waarom bepaalde afgeleiden niet werkten, sindsdien wil ik gewoon zo straightforward mogelijk dingen bouwen, niet 'browsertje hier dit, browsertje daar dat, maar browserversietje zus weer zo'. Ergens vrees ik dat we daar toch niet aan gaan ontkomen.

@fsve;
Het zijn prima libraries hoor, dat is het niet, maar als ik DarkBlue hoor over resoluties van 320x240, dan denk ik aan oude mobile devices, en vraag ik me af of het wel slim is om zulke Javascript geintjes toe te gaan passen.

Nou, de resoluties die ik noem impliceren niet gelijk dat we ontwikkelen voor oude devices. Punt is juist dat ik geen idee heb wat mijn ondergrens is, daarom ook dit topic.

--- edit 2 ---

@Dark Blue;
Om wat voor soort taken gaat het eigenlijk? Is het alleen data/stats bekijken in tabelvorm? Is het simpele key=value aanpassen? Of hebben we het over complete CMS of CRM applicaties? Zonder meer informatie over wat er precies gebeuren moet is het vrij lastig goed advies te geven. Juist met Mobile is context het belangrijkste.

Ik kan er niet teveel over zeggen maar we hebben projecten, en resources (personen die op dat project werken). En één zo'n persoon moet met z'n mobieltje een URL kunnen bezoeken, inloggen en daarop zien: hé, ik heb vandaag dit project te doen, ik moet om X uur op locatie Y zijn, en ik werk samen met Piet, Klaas en Kees. Ze kunnen niks wijzigen, het is alleen dat de resources onderweg zijn, en niet naar een desktop-pc terug kunnen om hun project in te zien: dat willen ze op een mobieltje ter plekke kunnen doen.

Het managen / inplannen en meuk gebeurt wel via de desktopapplicatie.

Inmiddels hebben mijn collega's even naar dat JQuery-framework gekeken, dat vinden we wel interessant. Ik denk niet dat het 'te zwaar' is voor de devices waar we op doelen (nogmaals: dat is 'n wazig gebied, we weten ook niet precies wat de klant heeft, iig geen iPads, wel telefoons). Bedankt tot zover

[Voor 5% gewijzigd door Dark Blue op 17-05-2011 10:57]

[OkkE]

Nu is het mij duidelijk.

Dan lijkt het me allemaal zo lastig niet; het is dan eigenlijk alleen tekst. Pak een standaard CSS file waar je alleen de font- en color-styles in zet. En gebruik Media Queries om één extra css-file in te laden voor devices met bijv. een resolutie van 480x320 en hoger. Daar kun je dan iets van stijling toepassen, zoals een menu-balk bovenin, een CSS3 gradient, box-shadow, ...

Aangezien het gaat om informatie opzoeken "on the road", is de voornaamste taak dus ook die informatie zo snel en eenvoudig mogelijk vinden. Het zal die gebruikers dan echt niets kunnen schelen of de knopjes een gradient en ronde hoekjes hebben. Leuk, maar niet noodzakelijk. Snelheid en overzichtelijkheid is waar het om draait.

Eventueel kan je met CSS3 transitions mooie extra effecten toevoegen voor de devices die dat ondersteunen.

[Voor 6% gewijzigd door OkkE op 17-05-2011 11:07]

[brtk]

Misschien heb je hier ook nog wat aan:

http://webdesignerwall.co...n-with-css3-media-queries

Good luck!

[Dark Blue]

Shrimp O Vis schreef op dinsdag 17 mei 2011 @ 10:01:
http://jquerymobile.com/

Is dit misschien iets wat je kan gebruiken?

Wegens succes quote ik hem nog een keer. Machtig, dat werkt snel!
Even de js- en css-files linken, juiste tags in de html zetten... klaar!

Mooi framework, deze ga ik gebruiken. Hopen dat ASP.net controls 'n beetje willen samenspelen hiermee

[Anoniem: 156868]

Nog een mooi linkje: http://teixido.co/

Is het misschien leuk om een algemeen topic te maken? Maak te lange dagen
Ik ben namelijk ook bezig met webapps (jqTouch in dit geval).

[Voor 8% gewijzigd door Anoniem: 156868 op 17-05-2011 22:26]

[Anoniem: 156868]

Ik kan nu nog niet achter de broncode komen dus hoe deze site in elkaar zit weet ik niet, maar ook een mooi voorbeeld;
http://asidemag.com/

[Voor 3% gewijzigd door Anoniem: 156868 op 17-05-2011 21:49]

[Anoniem: 156868]

Hoe vordert het Dark Blue?
Kun je al wat leuks laten zien?

[alienfruit]

Ik moet zeggen dat jQuery Mobile mij wel wat tegenvalt. Allemaal vage scroll problemen

[Anoniem: 156868]

alienfruit schreef op vrijdag 27 mei 2011 @ 09:09:
Ik moet zeggen dat jQuery Mobile mij wel wat tegenvalt. Allemaal vage scroll problemen

Gisteren toevallig mijn webapp omgezet naar jQuery Mobile vanwege dit probleem. JQM zit natuurlijk nog in zijn alpha status

[erwin85]

Voor mijn afstudeeronderzoek ontwikkel ik nu een applicatie in Sencha Touch. Dit is een Framework net als jQuery mobile. Vergeleken met jQuery Mobile is Sencha Touch veel beter en krijg je het gevoel dat de webapplicatie een native applicatie is.
Ik moet toegeven dat beginnen in Sencha Touch best lastig is. De applicatie wordt volledig in ExtJS ontwikkeld wat gebaseerd is op JavaScript.

Kijk eens op hun website: http://www.sencha.com/products/touch/

[Anoniem: 156868]

erwin85 schreef op vrijdag 27 mei 2011 @ 09:42:
Voor mijn afstudeeronderzoek ontwikkel ik nu een applicatie in Sencha Touch. Dit is een Framework net als jQuery mobile. Vergeleken met jQuery Mobile is Sencha Touch veel beter en krijg je het gevoel dat de webapplicatie een native applicatie is.
Ik moet toegeven dat beginnen in Sencha Touch best lastig is. De applicatie wordt volledig in ExtJS ontwikkeld wat gebaseerd is op JavaScript.

Kijk eens op hun website: http://www.sencha.com/products/touch/

Sencha is wel erg uitgebreid! Ziet er wel goed uit, maar ik heb dat zelf even op de lange baan geschoven.
Kun je kort vertellen hoe het in elkaar zit? Zijn de pagina's ook opgebouwd uit div met bijvoorbeeld data-role="page" class eraan?

[Voor 13% gewijzigd door Anoniem: 156868 op 27-05-2011 09:54]

[Bosmonster]

Ik krijg met jQuery Mobile hetzelfde gevoel als met jQuery UI. Een rommelig en buggy initiatief met een onduidelijke lijn en weinig vooruitgang. Slecht gemanaged dus, samengevat.

Met Sencha Touch of jqTouch ben je volgens mij een stuk beter af.

[Voor 19% gewijzigd door Bosmonster op 27-05-2011 10:12]

[Anoniem: 156868]

Bosmonster schreef op vrijdag 27 mei 2011 @ 10:05:
Ik krijg met jQuery Mobile hetzelfde gevoel als met jQuery UI. Een rommelig en buggy initiatief met een onduidelijke lijn en weinig vooruitgang. Slecht gemanaged dus, samengevat.

Met Sencha Touch of jqTouch ben je volgens mij een stuk beter af.

Dat zijn veel aannames

JQT werkt niet met FancyBox -->

[Voor 4% gewijzigd door Anoniem: 156868 op 27-05-2011 10:13]

[Bosmonster]

Dat zijn geen aannames, maar waarnemingen

En jqTouch en Fancybox... tja.. Lightboxes op een mobiel device lijkt me sowieso af te raden.

[Anoniem: 156868]

Bosmonster schreef op vrijdag 27 mei 2011 @ 10:16:
Dat zijn geen aannames, maar waarnemingen

En jqTouch en Fancybox... tja.. Lightboxes op een mobiel device lijkt me sowieso af te raden.

Als je je app maar redelijk licht houd. Check deze maar is op een iPad, hier wordt FancyBox ook gebruikt, ziet er erg goed uit.

[Bosmonster]

jqTouch is alleen niet bedoeld voor tablets, maar mobieltjes.

Voor een full size tablet is jqTouch redelijk zinloos. Dan kun je veel beter Sencha Touch pakken.

Iets met right tool for the job

[Voor 58% gewijzigd door Bosmonster op 27-05-2011 10:49]

[Anoniem: 156868]

Bosmonster schreef op vrijdag 27 mei 2011 @ 10:46:
jqTouch is alleen niet bedoeld voor tablets, maar mobieltjes.

Voor een full size tablet is jqTouch redelijk zinloos. Dan kun je veel beter Sencha Touch pakken.

Iets met right tool for the job

Waarom is dat zinloos?
Bij mij werkte het perfect, draaide heerlijk, mooie page transitions.
Het is alleen dat ik te koppig ben om fb los te te laten…

[erwin85]

Anoniem: 156868 schreef op vrijdag 27 mei 2011 @ 09:52:
[...]


Sencha is wel erg uitgebreid! Ziet er wel goed uit, maar ik heb dat zelf even op de lange baan geschoven.
Kun je kort vertellen hoe het in elkaar zit? Zijn de pagina's ook opgebouwd uit div met bijvoorbeeld data-role="page" class eraan?

Nee, in Sencha Touch doe je eigenlijk helemaal niets met HTML. Je maakt een index html pagina en de rest doe je allemaal in JavaScript. Op de website van Sencha Touch staan paar goede tutorials. Zie http://www.sencha.com/learn/Sencha_Touch.

Ik zou zeggen, probeer is enkele kleine demo's te maken. Als je hulp nodig hebt hoor ik het wel.

[Bosmonster]

Anoniem: 156868 schreef op vrijdag 27 mei 2011 @ 12:09:
[...]

Waarom is dat zinloos?
Bij mij werkte het perfect, draaide heerlijk, mooie page transitions.
Het is alleen dat ik te koppig ben om fb los te te laten…

Omdat jqTouch voornamelijk gericht is op fullscreen controls ala iPhone. Dat is 90% van de library. Dat beetje touch-events en page-transitions heb je overal wel inzitten.

Dus kun je beter een library nemen die gericht is op touch-interfaces en apps in zijn algemeenheid.

[Voor 35% gewijzigd door Bosmonster op 27-05-2011 12:17]

[Jaap-Jan]

wackmaniac schreef op maandag 16 mei 2011 @ 18:27:
Een menu dat statisch onderaan je pagina staat gaat een hele uitdaging worden; je scrollt namelijk niet op een mobile device (iOS en Android), maar je verschuift je viewport. Een statisch menu onderaan zal dus haast wel afhankelijk zijn van javascript.

Met 'statisch' bedoel je toch niet een element die positioneerd is met position:fixed? Want dat is niet ten opzichte van de viewport, maar ten opzichte van het scherm van de browser en zou per definitie altijd onderaan het scherm moeten staan.

Hmm, en dat staat 'ie dus niet.

Als je dit toevoegt werkt het wel:

HTML:

<meta name="viewport" content="width=100%; initial-scale=1; maximum-scale=1; minimum-scale=1; user-scalale=no;">

Dit gaat goed tot een bepaald moment (zo te zien op het moment dat div onderaan over de tekst erboven valt).

Test pagina: http://vdvn.net/test-fixed.php

[Voor 31% gewijzigd door Jaap-Jan op 27-05-2011 13:21]

[Anoniem: 156868]

Ik heb bij mijn jQuery Mobile site deze code erbij gezet zodat swipe up en down ook werken

Ik krijg het alleen niet aan de praat. Bij jQtouch gebruikte ik deze

JavaScript:

      $('#page1').swipe(function(e, info){
                    if (info.direction === 'left') {
                    goTo($('#page2'), 'flip');
                    }
                });

Ik weet alleen niet hoe ik dit bij jqMobile toe moet passen

[Bosmonster]

Wat doet ie niet? Het event of de goTo?

[fsve]

Jaap-Jan schreef op vrijdag 27 mei 2011 @ 12:39:
Als je dit toevoegt werkt het wel:

HTML:

<meta name="viewport" content="width=100%; initial-scale=1; maximum-scale=1; minimum-scale=1; user-scalale=no;">

Beetje late quote, maar zie het nu pas... maar hou er even rekening mee dat dit op een iPhone perfect werkt, maar dat het laatste stukje "user-scalable=no;" niet werkt op HTC Androids... en dat zijn er nogal wat.
Heb ook een webapp voor een bedrijf gemaakt waar die meta in stond, iPhone werkte perfect, maar Android dus niet waardoor de user de hele layout kan vernaggelen wanneer hij zoomt.

[Bosmonster]

Maar ja, wat ondersteunt de Android-browser wel? Blijft toch een beetje aanmodderen. Html5 input-types ondersteunt ie ook niet (laatste keer dat ik keek iig).

Uiteindelijk maak je het voor de iPhone en hoop je maar dat het goed gaat op de honderden Android-toestellen.

Qua marktaandeel is Android op mobiele telefoons misschien hoger, maar qua browser-gebruik blijft Android ver achter op iOS. Dat maakt het ook wat minder noodzakelijk om er echt heel veel tijd in te investeren.

[Voor 28% gewijzigd door Bosmonster op 08-06-2011 11:17]

[fsve]

Bosmonster schreef op woensdag 08 juni 2011 @ 11:15:
Maar ja, wat ondersteunt de Android-browser wel? Blijft toch een beetje aanmodderen. Html5 input-types ondersteunt ie ook niet (laatste keer dat ik keek iig).

Uiteindelijk maak je het voor de iPhone en hoop je maar dat het goed gaat op de honderden Android-toestellen.

Qua marktaandeel is Android op mobiele telefoons misschien hoger, maar qua browser-gebruik blijft Android ver achter op iOS. Dat maakt het ook wat minder noodzakelijk om er echt heel veel tijd in te investeren.

True, maar het blijft altijd vervelend als de IT-manager die eigenaar is van het project een Android heeft

[OkkE]

Het is niet echt een nieuw topic waard, maar wilde het toch even melden. Safari in iOS 5 krijgt weer een hoop extra ondersteuning waardoor het nog makkelijker wordt geweldige mobile websites te bouwen:

http://davidbcalhoun.com/...-web-workers-ecmascript-5

[list]
• position: fixed;
• overflow: scroll;
• New input types: date, datetime, month, time, range
• Web Workers (JavaScript)
• New ECMAScript 5 stuff (JavaScript)

[fsve]

OkkE schreef op donderdag 09 juni 2011 @ 09:02:
Het is niet echt een nieuw topic waard, maar wilde het toch even melden. Safari in iOS 5 krijgt weer een hoop extra ondersteuning waardoor het nog makkelijker wordt geweldige mobile websites te bouwen:

http://davidbcalhoun.com/...-web-workers-ecmascript-5

[list]
• position: fixed;
• overflow: scroll;
• New input types: date, datetime, month, time, range
• Web Workers (JavaScript)
• New ECMAScript 5 stuff (JavaScript)

Thanks voor de info! vooral de fixed position is voor mij erg bruikbaar!

[kwaakvaak_v2]

fsve schreef op donderdag 09 juni 2011 @ 09:10:
[...]


Thanks voor de info! vooral de fixed position is voor mij erg bruikbaar!

Niet zolang die ICT manager hierboven nog steeds op die brakke android browser kijkt hoor