OCR på räkningar

Jag funderade på problemet med felaktiga inskanningar. Det är bra om vi förbättrar bildanalysen, men det kommer nog ändå att förekomma felaktiga inskanningar då och då. Speciellt när användaren flyttar inskanningsrutan över ett nytt fält precis när den tar en ny snapshot. Då finns en viss risk en att inte alla tecken kommer med men strängen valideras som giltig data. Ganska osannolikt men det har hänt mig ett par gånger.

Vad säg om att droidgiro-browser skriver över tidigare ifyllda fält tills en knapp, Radera alla eller kanske Ny faktura, trycks på droidgiro-android. Om användaren då fortsätter skanna kollar droidgiro-browser ifall fälten på banksidan är tomma. Ifall de inte är det så accepteras ingen ny data tills användaren själv tömt fälten på sidan, t.ex. genom att betala räkningen.

 

Jag är rädd att det blir ett onödigt komplext flöde. Man måste på något förklara för användaren att, om du tryckt på "Ny faktura" så kan du inte ändra dina tidigare inmatningar utan att först nolla fälten. Inte helt uppenbart. Dessutom flyttar vi över komplexitet till browser-koden. Då ser jag nog hellre en Pause-knapp likt den vi har idag som pausar kameran. Vi skulle kunna tydliggöra det än mer för användaren genom att lägga en svart layout över hela skärmen med en text som säger typ "Tryck på Start-knappen för att fortsätta skanna". Jag tror det är lättare att förstå applikationen om den alltid beter sig likadant. Dvs om du skannar referensnumret så kommer det alltid matas in i referensfältet (om det finns tillgängligt i någon tab).

Annars håller jag med dig. Vi kommer inte få en bildanalys som fungerar till 100% men jag tror det fortfarande finns förbättringar att göra. En förbättring jag tänkt på är denna.
Säg att man skannar (se det här som den bitmap man skannar):

Kod:

#       10548591914558124 #      20 00   8 >

Den resulterande strängen blir då:

Kod:

#10548591914558124#20008>

Om den inlästa strängen istället skulle innehålla även mellanslagen så skulle jag kunna undvika att kontonumret ibland tolkas som ett OCR-nummer t.ex.

Vid ett tillfälle skannade jag soffan också, bitmappen som lästes av såg bara blurrig ut trots det blev det ett OCR-nummer av det med massa 8or

 

Jag tycker det skulle ha känts naturligt om man i appen endast skickade data till webbläsaren när användaren väljer "skicka". Då kan användaren granska datat innan det skickas, och man skriver inte över sådant som användaren ev redan har ändrat i webbläsaren. Det hade nog även varit bra om man hade haft en pause-knapp i appen.

Oftast skannar man väl en räkning. Fyller i resten, och reggar, sedan är man redo för att skanna nästa räkning.

Som det är nu så ligger då telefonen kvar på skrivbordet och skannar medans man håller på med webbläsaren.

 

Det är inte fallet med Skandiabanken. Där skannar jag gironumret först. Klickar på OK i webbläsaren, sedan skannar jag referensnummer och belopp. Personligen så skippar jag gärna momentet att behöva trycka på en extra knapp per fält för att skicka data till webbläsaren men det kanske bara är jag? Visst, det kan hända att data av misstag skrivs över i formuläret men det är så lätt att bara skanna fältet igen. Och data skickas ju inte utan att man märker det (pip/vibrations-feedback och vi kanske ska ha ett Toast-meddelande också som säger vilket fält som skannades). Nåväl, det kanske ska vara valbart åtminstone.

 

Jag menade inte att man skall trycka en gång per fält utan mer så här:

Sätt igång med att skanna ett fält, lagra värdet i telefonen, skanna nästa fält, lagra i telefonen osv ända tills användaren har skannat de fält han vill skicka. När användaren är nöjd med värdena klickar han skicka.

Jag tycker det är bra att det piper till, men min tolkning av ett pip är "japp, jag har lyckats läsa ett värde".

 

Hej,

Jag har inte testat droidgiro än men undrar hur kameradelen fungerar/kommer fungera med tanke på diskussionen ovan om felaktiga inskanningar. Hur stor roll spelar tydligheten i bilden för att den sedan skall tolkas rätt? Det jag är fiskar efter är att kamerainställningarna borde vara viktiga, typ makro och ljusinställningar. Kanske är något att ha i bakhuvudet?

// Richard

 

Då måste man ha någon möjlighet att ta bort enstaka fält också då. Ta följande scenario:

• Skannar kontonummer.
• Trycker skicka.
• (Alla fält nollställs i android)
• Skannar belopp.
• Skannar OCR (som av misstag tolkas som ett kontonummer).
• Skannar OCR igen.

Innan jag trycker skicka nu vill jag ju utesluta kontot som skannades av misstag.
Men det här scenariot kanske inte är realistiskt när jag tänker efter. För om jag valde att skicka konto först så tyder det förmodligen på att kontot anges på en separat webbsida (som skandiabanken) och isåfall är det väl mer eller mindre ofarligt att skicka kontot igen. Däremot kanske användaren känner sig obekväm med att skicka kontonumret igen, speciellt om man vet att det är felaktigt, om man inte vet att det är ofarligt.

 

Ett problem jag upplever är att bildanalysen ibland blir matat med en suddig bild som följd av att kameran inte har fokuserat färdigt. Egentligen är väl inte det ett problem med bildanalysen utan snarare med kamerahanteringen vi ärvt från barcode scanner.

 

Det problemet har du väl redan nu? Nu skickas ju alltid det man skannar direkt när man skannar, och alltså hade det felaktiga kontot skickats utan att användaren "sett det".

 

Man "ser" ju det iom att man får feedback att ett fält har lästs in. Sen får vi väl tänka oss ytterligare en form av feedback som berättar precis vilket fält som har lästs (även om vi inte har det i den här alpha-versionen).

Hur som helst. Jag är mest intresserad av att hitta ett naturligt och snabbt flöde i appen. Vi konkurrerar trots allt med alla de som tycker att det är minst lika enkelt och går lika snabbt att knappa in fakturan manuellt. För att det ska vara värt att hämta mobilen och starta droidgiro så vill det till att:

1. man är snabbt igång med första skanningen
2. skanningsflödet känns naturligt och går snabbt

Ett sätt att göra det mindre "kostsamt" att införa ett bekräftelsesteg är att ändra orienteringen på skanningsaktiviteten. Jag finner det åtminstone väldigt besvärligt att hålla mobilen i landscape och samtidigt interagera med UI:t, med en hand. Att göra det i portrait är ju däremot ingen konst. Har provat att ändra från landscape till portrait men fick inte till det. Kamerabilden blev väldigt märklig för att uttrycka sig milt. wulax, har du testat det?

Om man kan köra skanningen i portrait så går det väldigt snabbt att trycka på t.ex. "Skicka" eller "Skanna igen" direkt efter en skanning. Så pass snabbt att jag nästan kan tycka det är okej att bekräfta varje fält för sig. Isåfall skulle vi kunna, efter varje skannat fält, öppna en ruta som säger t.ex. "OCR läst: 17517399652. [Skicka] [Skanna igen]".

Vi skulle då kunna ha en inställning för "Bekräfta varje fält före sändning" samt "Skanna i landscape" (kan tänka mig att man kanske behöver det för vissa telefoner).

Jag måste samtidigt säga att det är väldigt roligt och intressant att försöka hitta det mest optimala (i någon bemärkelse) användargränssnittet som möjligt.

 

Om man håller telefonen i landscape mode tycker jag det är lättare att interagera med den övre delen av skärmen oavsett om jag håller telefonen med en eller två händer.

Sedan behöver man ju inte göra allt via knapparna, man kan ju även ha "shortcuts".

T.ex klick på skärmen pausar skanning, dubbelklick skickar.

Mitt flöde skulle vara
* Para ihop telefonen med webbläsaren. (Btw varför försvann qr-koden, eller är den tillbaka igen?)
* Skanna ett fält, sedan nästa fält, och nästa...
* Klickar skicka när allt jag velat skanna är inskannat. Detta pausar automatiskt.
* Fixar allt i webbläsaren som jag behöver göra
* Klickar "resume" vilket påbörjar en ny inskanning och tömmer alla fält.

Jag tror inte att det flödet skulle upplevas som jobbigt, och det skulle fungera även för banker där man behöver mata in fält på flera olika sidor.

Har man väl skickat ett fält till webbläsaren så behöver man väl inte skicka samma data på nästa sida också?

 

QR-koden försvann för att vi inte har integrerat någon QR-läsare.

Med knapparna så menade jag inte de fysiska knapparna utan knappar på skärmen.

Man ska komma ihåg att de flesta användarna inte har en aning om hur programmet fungerar. Om webbsidan de ska skicka data till innehåller endast OCR + belopp och användaren av misstag råkar få en skannträff på konto (t.ex. genom en felskanning som uppfattas som ett konto) så är deras enda utväg att radera alla fält och börja om igen. Visst, i praktiken kan de trycka Skicka ändå eftersom kontot inte kommer användas men jag tror inte användaren tar chansen om man inte vet vad som händer i bakgrunden. Men jag kan ha fel. Folk kanske struntar i det faktum.

Ska vi buffra fält så behöver vi även presentera vilka fält som är skannade. Nu har vi ju debug-raderna som tjänar det syftet. De kanske ska vara kvar isåfall?

Det skulle också vara intressant att höra hur andra skulle vilja se själva skanningsflödet om de fick bestämma.

 

Jag röstar för att debugraderna skall vara kvar

Edit: En motivering till att behålla dem är att när jag skannar så kollar jag ned på blanketten och telefonen. I telefonen ser jag om rätt blivit skannat utan att behöva lyfta på huvudet för att kolla vad som står på skärmen.

 

En bekräftelseruta som jag nämde tidigare får samma effekt iofs.
Men i ärlighetens namn tror jag att du tittar en extra gång på skärmen iaf för att se det som faktiskt går till banken

 

Japp, jag experminterade lite med det innan jag lade upp första versionen av aGiro på GitHub, men övergav försöket på grund av krångel. Jag provade koden överst i den här frågan men hade problem med att Viewen gav fel dimensioner, höjd istället för bredd och tvärt om. Koden roterar alla child views 90 grader så man lägger alla views utom kameran i den. Det fungerade men som sagt med fel dimensioner, vilket kanske kan lösas om man inte använder xmllayouter utan kodar in Views i CaptureActivity. Det kändes dock inte värt problemen.
Nu när jag letade rätt på den sidan såg jag att någon har löst problemet sedan jag kollade senast. Kanske kan vara värt att prova LayoutAnimationController ifall vi nu ska använda portrait mode.

 

Finns tydligen en app på market nu: ocrwire från http://ocrwire.integracious.com/

 

Angående att kolla mellanslagen, det borde inte vara några större problem att lägga in den funktionen i Scanner. Tecknen är ju i monospace så det är väl bara att lagra positionerna av de vita pixelkolumnerna, dividera summan av de som är bredare än vad den tror är ett tecken (måste förbättra den delen tror jag) med bredden av ett tecken plus avståndet mellan vad den tror är två sekventiella tecken.

 

Inget akut, men det skulle kunna förbättra avkodningen av strängar till fält. Jag tittar lite på möjligheten att köra i portrait mode också (efter länken du skickade).

 

Det var på tiden! Men verkar som den bara stödjer Windows och då har jag ingen möjlighet att testa.

 

Har du testat den Buzz?

Jag kan inte heller testa ifall den bara stödjer Windows.