Omgaan met beperkingen

Smartphone applicaties met APEX
26 jun 2015 - Dick Dral

Mobiele telefoons zijn tegenwoordig kleine computers, die de rekenkracht van een desktop van enkele jaren geleden evenaren, met kleurenschermen van HD resolutie. Toch zijn er duidelijke beperkingen bij het gebruik van smartphones. Het scherm is klein, de netwerkverbinding is vaak niet al te snel en invoer via het on-screen toetsenbord is lastig.
Mobiele telefoons zijn tegenwoordig kleine computers, die de rekenkracht van een desktop van enkele jaren geleden evenaren, met kleurenschermen van HD resolutie. Toch zijn er duidelijke beperkingen bij het gebruik van smartphones. Het scherm is klein, de netwerkverbinding is vaak niet al te snel en invoer via het on-screen toetsenbord is lastig.
 
Op APEX World 2015 behandelde Dick Dral hoe je, rekening houdend met deze beperkingen, APEX applicaties voor smartphones kunt maken. Een aantal punten uit deze presentatie beschrijft hij in dit artikel. 

Klein scherm

Smartphones hebben een klein scherm. De laatste jaren zijn de schermen wel groter geworden, maar er ligt een grens bij een omvang van maximaal 6 inch. Groter past namelijk echt niet meer in je broekzak en het is ook niet praktisch om met een mini-tablet aan je oor te telefoneren. Deze schermen zijn niet geschikt om de websites weer te geven voor desktops en er worden dus ook speciale mobiele sites gemaakt, die rekening houden met de beperkte grootte van het beeldscherm.

APEX biedt de mogelijkheid om mobiele applicaties te maken. Hiervoor wordt gebruik gemaakt van het framework JQuery Mobile (JQM). Op zich is JQuery Mobile bedoeld voor het gebruik met mobiele telefoons, maar het gaat niet optimaal om met de schermruimte. Vooral bij formulieren wordt veel ruimte verloren doordat de labels boven de invoervelden worden geplaatst. Dit wordt veroorzaakt door de implementatie van de responsiveness, waardoor het formulier veel langer wordt. Er kunnen zo nog geen 5 invoervelden op het scherm zonder scrollen. Door aangepaste CSS kunnen de labels naast de invoervelden worden geplaatst, waardoor er ruimte is voor meer dan 6 invoervelden.

 Afbeelding 1. Standaard JQM tegen customized

De volgende HTML wordt door JQM aangemaakt voor een invoerveld.

 
Met CSSis het mogelijk om dit gedrag te beïnvloeden.


Door het element position: absolute wordt bepaald, dat dit element binnen het div element met de class ui-field-contain een vaste positie heeft. Met left, right en top wordt deze absolute positie vastgelegd. Door de labels kort te houden, is er meer ruimte voor de invoervelden, die in dit geval 30% van de breedte innemen. De rest is beschikbaar voor de invoervelden. Door het input-element een breedte van 68% mee te geven wordt overlap met een icoon rechts voorkomen.


Langzame verbinding
Bij gebruik van smartphone is de snelheid van de dataverbinding vaak beperkt. Bij het wisselen van pagina is er veel netwerkverkeer , zowel qua omvang als in aantal berichten. Voor een simpele pagina worden zo al een 20-tal bestanden opgevraagd, CSS, Javascript, images etc. Het netwerkverkeer is zichtbaar in de netwerk tab in de Chrome Developer Tools of in Firebug. Dit netwerkverkeer zorgt ervoor, dat paginawisselingen op de smartphone traag zijn, des te meer naarmate het netwerk trager is.

Het is dus zaak om bij het gebruik van de applicatie paginawisselingen zo veel mogelijk te beperken. De eerste mogelijkheid is om de applicatie functioneel zo te ontwerpen, dat er minder paginawisselingen nodig zijn. Een eenvoudige methode om paginawisselingen te beperken is door gebruik te maken van een popup-menu op iedere pagina in plaats van een aparte menu-pagina.

Veel desktopapplicaties beginnen met een report, waarin met een knop naar een invulformulier gesprongen kan worden. Als dit invulformulier het belangrijkste en meest gebruikte scherm is, kan een paginawisseling worden voorkómen door een registratie-applicatie direct te laten opstarten met dit invulformulier. In zijn algemeenheid gezegd moet er meer aandacht worden besteed aan de optimalisatie van het gebruik van de applicatie.

Technisch gezien is er nog een mogelijkheid om paginawisselingen te voorkomen, namelijk de applicatie in zijn geheel in één pagina te bouwen. Binnen APEX betekent dit, dat alle regions op één enkele APEX pagina worden geplaatst, en dat met JavaScript regions (on)zichtbaar worden gemaakt. De getoonde region moet ook met de benodigde gegevens worden gevuld. Bij de logische ‘ paginawisselingen’ binnen een dergelijke Singe Page Applicatie worden alleen de gegevens van de server overgehaald met Dynamic Actions of Partial Page Rendering. Opslaan van
gegevens vindt ook plaats door middel van Dynamic Actions. De foutafhandeling zal ook via JavaScript moeten worden geregeld.

Het mag duidelijk zijn, dat het bouwen van een Single Page Application met APEX aanzienlijk meer programmeerwerk vereist (vooral JavaScript) dan een conventionele APEX applicatie. De snelheidswinst is echter groot en in sommige gevallen kan dit opwegen tegen de extra inspanningen.


Gegevensinvoer via het on-screen toetsenbord 

Het on-screen toetsenbord van een smartphone is niet geschikt voor de invoer van grote hoeveelheden tekst. Het typen gaat niet snel en ook de correctie van onjuiste ingevoerde tekens ( bij uw auteur om de 10 á 20 tekens ) kost nog extra tijd. Daarom is het zaak om de noodzaak van het gebruik van dit toetsenbord zo veel mogelijk te beperken.

Hiervoor zijn verschillende mogelijkheden:

1. invoervelden weglaten

2. voorinvulling

3. mogelijkheid om veld leeg te maken

4. slimme velden ( autocomplete )

5. invoer via touch

6. invoer via spraak

De meest voor de hand liggende optie is het weglaten van invoervelden. Als ze er niet zijn, hoeven ze ook niet te worden ingevuld. Denk bij het ontwerp van een smartphone applicatie extra goed na, welke gegevens echt nodig zijn. Kunnen ze worden afgeleid? Zijn ze wel essentieel voor de applicatie?

Voorinvulling kan een heleboel typewerk schelen. In een tijdschrijfapplicatie ligt het vullen van een datumveld met de huidige datum ligt voor de hand, maar ook andere velden kunnen alvast worden ingevuld. Misschien wordt vaak hetzelfde project of activiteit ingevuld als in de vorige tijdsperiode. Het is dan nuttig om het deze voorgaande activiteit alvast in te vullen. De gebruiker kan altijd nog een andere waarde kiezen of invullen.

Bij een onjuist vooringevulde waarde zal het veld leeggemaakt moeten worden om een andere waarde in te vullen. Zonder voorzieningen betekent dit, dat de Delete toets (vele malen) moet worden gebruikt. In zo’n geval is het handig om een Clear Item knop te hebben, waarmee met één click het veld kan worden leeggemaakt.


Terug van weggeweest: het Autocomplete Item

In de mobiele APEX applicaties komt het Autocomplete Item niet voor in de lijst met standaard item types. Wanneer je Show Unsupported kiest, blijkt het type nog wel te bestaan. De reden waarom is de auteur niet duidelijk, want juist het Autocomplete Item kan worden gebruikt om de invoer van het aantal tekens te verminderen.

In veel gevallen worden namelijk in een veld dezelfde teksten gebruikt. Door voor zo’n veld een autocomplete item te maken en als list of values de bestaande inhoud van het veld te nemen, hoeft de gebruiker vaak maar enkele tekens in te voeren voordat de gewenste tekst gevonden is. Als het een nog niet bestaande tekst is, kan deze gewoon door de gebruiker worden ingetypt. 
Het is wel zo, dat de styling van de autocomplete dropdown list niet is aangepast aan de mobiele applicatie. Standaard is de keuzelijst in de mobile applicatie doorzichtig en de regels staan te dicht bij elkaar. Met de onderstaande CSS wordt het Autocomplete Item bruikbaar in een JQM applicatie.

 

Invoer van tijd via touch

Sinds mijn eerste smartphone heb ik het idee gehad om iets te doen met een analoge klok en invoer van tijd. Zo’ n twee jaar geleden had ik de tijd en technische kennis om dit idee te realiseren. De invoer is gebaseerd op het ‘ tekenen’ van de twee wijzers van een analoge klok op het scherm van de smartphone. Ter ondersteuning wordt een analoge klok op het scherm getoond.

Een dergelijk invoer kan nauwkeurig zijn op één sectie van de klok, dus 5 minuten. Voor veel toepassingen is deze nauwkeurigheid voldoende. Met enige gewenning is deze methode ook sneller dan het invoeren via een toetsenbord.

Afbeelding 2 geeft een beeld hoe de invoer eruit ziet. Links een normaal formulier, waarbij achter de tijdinvoervelden Van en Tot een klok-icon staat. Wanneer daarop wordt geklikt, verschijnt de analoge klok, waarop met vingerbewegingen de wijzers kunnen worden getekend. Met de AM/PM knoppen kan worden gekozen voor een tijd voor of na 12:00 uur ’s middags.


 

                  Afbeelding 2

Over deze invoermethode is een blogpost geschreven, die ook de mogelijkheid biedt om deze manier van invoer zelf te ervaren ( dickdral.blogspot.nl/2015/02 ).

Invoer via spraak
Één van de belangrijkste verbeteringen in iOS8 was voor mij de beschikbaarheid van Nederlandse spraakherkenning. Deze werkt verrassend goed. Omdat de ingesproken tekst op een server wordt geïnterpreteerd, is voor de spraakherkenning wel een netwerkverbinding nodig.

                           Afbeelding 3 Toetsenbord met microfoon en van actieve spraakinvoer


Omdat de spraakherkenning aan het toetsenbord is gekoppeld, kan deze in iedere app met toetsenbordinvoer worden gebruikt, dus ook in webapplicaties. Binnen Android is ook Nederlandse spraakherkenning beschikbaar op een vergelijkbare manier.

Het is dus zonder meer mogelijk om met een smartphone in een bestaande APEX applicatie gegevens via spraak in te voeren. Het is echter zeer onhandig om dit per veld te doen. Bij ieder veld moet namelijk de microfoon worden geactiveerd, daarna moet de tekst worden ingesproken, bevestigd om vervolgens een toets te drukken om naar het volgende veld te navigeren. Dit is alleen zinvol, als binnen een veld veel tekst moet
worden ingevoerd. 
Het is effectiever om in één keer inspreken alle gegevens in te voeren. De applicatie moet dan wel kunnen onderscheiden waar de inhoud van een veld begint en eindigt en in welk veld de inhoud moet worden
geplaatst. Dit kan worden gedaan door gebruik te maken van de labels als scheidingswoorden. Neem als voorbeeld onderstaand scherm. Hierin is een apart veld opgenomen voor de spraakinvoer. Deze invoer wordt met een Dynamic Action geanalyseerd en de opgedeelde inhoud wordt in de jui

ste velden geplaatst.

In bovenstaand voorbeeld wordt de zin datum eergisteren naam Lidl bedrag € 9,65 omschrijving levensmiddelen ingesproken. Deze zin wordt opgedeeld aan de hand van de labels naar datum=gisteren,
naam=Lidl, bedrag=€ 9,65 en omschrijving=levensmiddelen opgedeeld. Deze gegevens kunnen al bijna in de invoervelden van de pagina worden geplaatst. Alleen voor de datum moet gisteren worden omgezet naar een ‘echte’ datum. Verder moet het euroteken voor het bedrag worden verwijderd en de komma afhankelijk van het decimale teken vervangen door een punt.

 

De programmatuur voor bovenstaande acties is geschreven in PL/SQL en wordt aangeroepen in een dynamic action. De labels kunnen worden afgeleid uit de APEX repository. Hiermee weet de programmatuur ook meteen in welk veld de gegevens moeten worden geplaatst. De resultaten worden als resultaatvelden van de DA teruggegeven. 

Nadat de velden gevuld zijn met waarden, kan de gebruiker controleren of de velden correct gevuld zijn. De gegevens kunnen vervolgens – net als bij handmatige invoer – worden vastgelegd door op de knop Save
te drukken.

Op de hiervoor beschreven manier kunnen bestaande applicaties worden voorzien van een mogelijkheid voor effectieve spraakinvoer.

 

Conclusie

Het gebruik van webapplicatie op smartphones kent de nodige beperkingen. Er zijn verschillende mogelijkheden om deze beperkingen om te gaan.

Het ontwerpen met de beperkingen in het achterhoofd legt de basis voor een betere bruikbaarheid. De beperkte schermgrootte moet bewust worden gebruikt. Hiervoor kan CSS worden ingezet om het
schermgebruik van de APEX applicatie te optimaliseren. 
Er zijn een aantal mogelijkheden om de invoer via het toetsenbord te beperken of vermijden. Voorinvulling en autocomplete beperken de noodzaak om het toetsenbord te gebruiken. Touch en spraakherkenning kunnen invoer via het toetsenbord gedeeltelijk vervangen. Met de beschreven technieken kan de bruikbaarheid van APEX smartphone applicaties sterk worden verbeterd.