Plot er en ugly ass bitch når man kun har 2 efforts. Hva med å kun gi plot for k=>2? Hvis brukeren trykker på plot-knappen ved k=1 eller k=2 kan det komme opp en boble som sier "Plot only available for 3 or more efforts". Hva tror dere om det?

1. 20,40,30
2. 0,0,200
3. 1,2,10,15,50,200,1000,2000
4. 1000,1001
5. 1,3

I plot må CI trunkeres ved T (nedre grense for CI kan aldri være lavere enn T). Merk at det her er snakk om T etter det aktuelle antall efforts, ikke total T.

Species should no longer be a part of elfish.

This makes the data model and the view much simpler, going from a three dimensional object to only two dimensional, making it simpler to visualize and work with.

Also, group is simpler to pronounce than species (/ˈspiːʃɪz/? /ˈspiːʃiːz/? /ˈspiːsɪz/? /ˈspiːsiːz/? /ˈspiːʃɪiːz/?)

Work initiated in 479ed0a

Med unntak av confidence threshold som skal fryses nederst på siden

Hatten til N^^i plotets y-akse-tittel er avbrutt av en marg.

Jeg tror det er unødvendig at det står "Summary" her før man taster inn data. Kunne bare vært tomt. Men dette vil jo se annerledes ut hvis vi endrer til Hannah sin interface-løsning.

Man skal ikke måtte trykke på + den første gangen.

Effort-ruten blir dermed grønn når N^=N/A.

For vektor 1,3:

Her skulle Zippin gitt NA for Nhatt, men gir i stedet en feilaktig Nhatt. Årsaken er at jeg hadde glemt at vi må inkludere en forutsetning i matematikken for Zippin: Hvis X <= ((T-1)*(k-1)/2)-1, skal Zippin gi NA. (X = \sum_i (k-i)C_i, allerede definert i koden vår).

Alle disse vises med 3 desimaler, men 2 er nok.

Gjelder alle tre parametre som regnes ut i output, under hver effort.

Det må være et valg som heter "Undefined" eller noe sånt for Confidence threshold. Unødvendig å tvinge brukeren til å ta stilling til dette. Foreslår at undefined er utgangspunktet (default) når man åpner appen. Når "Undefined" er gyldig vil ingen output resultere i grønn effort-rute. Dersom brukeren setter et C. thresh. vil efforts bli grønne hvis threshold er innfridd.

Når Nhatt=N/A blir det 0 i plottet, men skulle vært ingen data.

Jeg tror vi bør bruke ord fremfor forkortelser i summary. Under hvert effort er det kun plass til forkortelser, så det er greit som det står. Forslag for summary:
Efforts =
Estimate =
Total catch =

Y-aksen: Bør ha rotert tittel "Estimate (N^)".

X-aksen: "Effort #", og aksemerkene kan være 1,2,3... i stedet for e1,e2,e3....

In output under hvert effort ligger "N^" for nære den hvite boksen over. Hatten treffer linjen, på min skjerm i alle fall.

Hvis estimat eller CI blir store deles dette på to linjer, og "Total catch" deles også på to linjer. Upent.

Når N^ = N/A kunne kanskje de to andre feltene også vist N/A fremfor "---"? Gjelder output under hver effort.

Nedre grense på y-aksen er nå alltid 0, men det hadde vært bedre om den justerte seg slik som øvre grense. F.eks. vil vektoren 160,80,40,20,10,5,0 kun ha N^ over 300, og nedre CI-grense over 250, slik at intervallet 250-350 eler noe sånt hadde vært optimalt her. Den enkleste løsningen er vel å la laveste viste verdi på y-aksen være lik T ved effort 2. Da vil N^ og nedre CI-grense alltid være synlig for alle efforts.

Øvre grense på y-aksen justerer seg som oftest fint, men i noen tilfeller er øvre grense lik N^, slik at man ikke ser øvre del av CI. F.eks. ved vektoren 2,1,0,0. Normalt er det penest om man ser hele CI over N^. Om CI er altfor stort går ikke dette, så vi trenger en grenseverdi (2 x N^ ?). Uavhengig av CI burde vel plottet minimum inkludere én y-verdi høyere enn N^, for estetikkens skyld (se 2,0,0,0).

Tror det bør stå "CI/N^ < " foran ruten der Confidence threshold skal skrives inn.

Eventuelt, eller i tillegg, burde det kanskje vært en spørsmålstegn-knapp der, som linket til relevant del av hjelp/info-teksten jeg skal forfatte. Den som ellers åpnes via en Help/Info-knapp nederst i appen.

Løses ved å skyve den litt til høyre?

Nå leter appen etter verdier langt opp i milliardene (uten at den er treig av den grunn tydeligvis). Vi må vel sette en eller annen øvre grense for N^? 100.000 ble diskutert som en akseptabel grense.

Relatert:
Problem-vektoren 1,3. Hvorfor gir den nå N/A for Zippin, selv om den leter etter superhøye verdier? Tidligere ga den jo N^ = ca. 650000 for den vektoren, som var feil, og vi fant ikke ut hvorfor.

Skulle vært N/A.

Når man trykker på + for å lage nytt effort, bør man slippe å trykke i den hvite boksen for å få lov til å taste inn tall. Man bør automatisk være i skrive-modus. Da unngår man også at appen først beregner output for verdien 0 i det nye effortet, som jo er litt merkelig, spesielt siden den da ofte vil bli grønn, inntil verdi er tastet inn.

Hver nye effort er nå tom (har ikke verdien 0) inntil man skriver inn en verdi. Bortsett fra effort 2, som automatisk er 0. Faktisk regner appen ut output som om e2=0 etter at du har skrevet inn fangst i e1, samme hvor i appen du trykker (for eksempel kan det hende du trykker "New group" etter å ha fylt inn data under e1. Per nå beregnes likevel output og summary som om e2 var 0). Output bør ikke beregnes før data er tastet inn for e2, og e2 bør være tom før data tastes inn.

Den enkleste måten å løse dette på må vel være at e2 simpelthen ikke eksisterer før brukeren oppretter den ved å trykke "+"? Om noen da mener at funksjonen til "+"-knappen blir mindre tydelig (jeg er usikker; per nå er det i alle fall tydelig fordi man har e1,e2,+ , som tydelig indikerer at man skal fortsette tallrekken), kan man evt. ha teksten "New effort" like over "+"-tegnet.