from the results page, to get to a new result, at the moment you need to go back, ask for a new scan, then search for it.
this is three buttons, and two page changes.
can we do this from the results page directly? just "new scan" and stay on the results page?

we should explain that ghini.pocket also produces a (small) stream of information, directly to ghini.desktop.
and you can start odk-collect from ghini.pocket, if you think so.

I know you find the plant physically, so you can see the plant location, but who tells you that the info is correct in the database?

title tells it all. it would avoid you take pics again for a plant already with pics.

I have observed random crashes. and random means I've not investigated yet under which circumstances it crashes. so it's possibly several distinct issues.
please investigate!

did it ever work? from the results page hit 'next' and scan the next code?
we now (1.8) need to go back to the initial page to scan the code.

Hablando del panel de corrección e inserción datos:

Me sería muy útil que también al consultar el género me indique a que familia pertenece.

at the moment we have a database with 28970 taxa, but not all of them have all the complete authorship information: (rank 0: order; 1: family; 2: subfamily; 3: tribe; 4: subtribe; 5: genus)

sqlite> select rank, count(*) from taxon f group by rank;
0|68
1|1388
2|348
3|240
5|26926
sqlite> select rank, count(*) from taxon f where f.authorship is null group by rank ;
1|899
2|59
3|54

there should be a report on google play, I saw the application try to send 5 pictures, 4Mbytes each, and crash during the task. first time nothing was recorded on the server, second attempt 4 pictures were transferred.

at the moment most genera are linked to families, even if families have subfamilies and tribes (no subtribe information yet, see #20).
we should be linking genera to the first available above taxon, whatever that might be.

sqlite> select p.rank, c.rank, count(*) from taxon c, taxon p
   ...> where c.parent_id=p.id group by p.rank, c.rank order by c.rank;
0|1|488
1|2|348
2|3|229
1|5|26926

as you see: all families point to order, all subfamilies point to family, all tribes point to subfamily, but then genera point straight into family.

the species editing control in the collect page offers first verbatim matches then phonetic matches, all in the same list. we could generalize this, and offer the same matches also in the taxonomic help page, where currently you only have (partial) verbatim matches.

From @denadenisse on September 15, 2017 15:56

Mario,
El aplicativo ghini.pocket es muy util, y ha mejorado mucho en este corto periodo de desarrollo. Sin embargo, en algunos dispositivos moviles que usan el aplicativo, al momento de realizar una busqueda, se observa un error de lectura en el campo de familia, donde no se visualiza el nombre como tal de la familia sino la descripcion del contenido de JAVA.
Adjunto una captura de pantalla.

Copied from original issue: Ghini/ghini.desktop#274

when viewing results, it would be faster if we could move directly to the odk-collect program from there, and even with the option of activating a specific form and copying the accession code to the form.
initially, we could also just put the accession code in the clipboard, so the user can copy it in the form.

what should the program do, when a user starts using the program but "forgets" to insert a location code? refuse moving to results page? go to results but warn? not log the action?
I think that the least surprising would be to refuse moving to results page. if the user really wants to work without location, we could add a check (initially unset) that says "do not log", or they could insert a null code. I don't know, I think I would like to discuss it with users.

you probably would have your clients talk with always the same server.
what other settings in the DesktopClientActivity are lost each time?

just like in ghini.web, now that we have a taxonomy search, it would be nice if the search was a bit tolerant of typing mistakes. in ghini.web we have added a phonetic_epithet column, where we keep a reduction of the correct epithet.
noting it down, so we know this should happen sooner or later.

I'm not sure about this one, but if you type an accession/plant code, and you swipe the interface to the right, do you expect the same result as what you get when you hit 'search'?

would it be useful? to have a link to the wikipedia page relative to the species.

our first guess about ghini.pocket was that it would only be showing, not collect data. our first guess was to use a odk-collect form to let users collect additional or corrected information.
then we started using ghini.pocket for inventory, and this is a form of collecting data.
so in the end we've already split the streams in two parts, and that's not good.
what about we examine what data we are collecting with odk-collect, and do that with ghini.pocket?

a request by JBB: when inserting species epithets, they wish to have the complete flora of Colombia in the pocket taxonomy database, so that typing errors would be avoided at the source, instead of corrected after importing in ghini.desktop.
this means doing phonetic match also on the second epithet.

if you do not enter a search code, there's little point in reading results or worse editing anything.

when you can scan a plant code, what's the point of letting the user click on 'search'?, isn't this always what the user would do? we can skip this step, isn't it?

when you do not find an accession/plant, and you add it in the log file, you want to also find it in the log, otherwise how are you remember what you did and what you still have to do?
the immediate effect of this would be: when you hit 'save to log', you go back left to the search result, and you see the information you just entered. in practice, the 'save to log' should become 'save', tout court.

You can always decide you want to edit it further, and go back to the editing pane and correct. This would generate two log entries and alter the same database record.

at the moment we have a database with 28970 taxa, but not all of them have all the complete authorship information: (rank 0: order; 1: family; 2: subfamily; 3: tribe; 4: subtribe; 5: genus) - as you see, 4 is empty.

sqlite> select rank, count(*) from taxon f group by rank;
0|68
1|1388
2|348
3|240
5|26926

in the first ghini.pocket version, we could go to odk-collect and take pics, or correct information. most of all, it was taking pictures what was most interesting, and most complex
Unfortunately, the whole data stream towards the ghini.desktop database hasn't been completed, it's still at the stage of a script doing the job and users having to trust that all that happens is correct.
I think it would be easier if we did not need go through the external odk-aggregate server, but yet, at the moment we have no other option, and I've only removed a functionality without replacing it with something better. That's not good.

this includes the location value, which is not a good thing.

this is part of milestone#6 for g.desktop

we need a user activity that allows the collected data to be sent to g.desktop.
how this proceeds is described in Ghini/ghini.desktop#421,
user documentation goes in readthedocs

License only says "Copying".

crash report from one of our users

Package Name: me.ghini.pocket
Crash Report Date And Time: 2018-04-16T21:39:41Z
Exception Message: Attempt to invoke virtual method 'android.location.Location android.location.LocationManager.getLastKnownLocation(java.lang.String)' on a null object reference
Throwing Class Name: me.ghini.pocket.MainActivity
Throwing Method Name: onCollectSaveToLog

maybe useful: keep a history of the plants that the user has looked up since starting up the program.
so when user goes back to desk, can review what was in the garden and may notice missing plants.

para activar la búsqueda del código de planta insertado, lo puedes hacer de dos maneras diferentes.

• oprimiendo la tecla search
• haciendo swipe a la derecha.

si no insertaste el código de planta, el primer método te avisa y no pasa a la pantalla siguiente, sin embargo el segundo método te lleva a la pantalla de resultados, que no es correcto.

we need a more detailed usage description, and should we keep it here in the README or should it go in the ghini.desktop documentation, where everything starts and we can also have it translated.

you type a location code, and automatically, you hit the key next to the text entry. all history gone.
what about letting the user delete these files manually, and just have the button rename the current log to something else, timestamped? sounds a lot safer.

how do we interact with the typing suggestions, can we add there words from our database, of is it completely under control of the installed keyboard?

the result page holds the information, but it does not state what each field represents.
maybe it's obvious and not needed, maybe better be explicit, I'm not sure, just noting it here as a doubt.

it would be nice to have something that would tell you the higher taxa epithets, given a genus. or given a partial genus, tell you the possible matches. also nice, if it would be able to correct spelling mistakes, like the ones we neo-latins always make, typing ritmo when we really need rhythmus. this part isn't difficult at all and it's already implemented in ghini.web.
back to what there is to do, I think I have to restructure ghini.pocket, build it on a single activity and three fragments, when we now have two activities. it's a bit of work and quite a bit of rewriting and since I still feel as a complete outsider in Android, I guess this is going to keep me busy for longer than a couple of days.

from a comment to #15:

it now would be nice if the lookup term came from the genus of the looked up plant. but that's an other issue, I guess.