18540
Reporter: feedback bot
Type: Feedback
Summary: Pyxine cocoes
Description: Can you please indicate why the taxon of this is fuzzy?
Status: Reopened
Created: 2016-06-18 23:55:17.815
Updated: 2016-06-21 14:49:25.517
Author: cgendreau
Created: 2016-06-20 10:22:15.406
Updated: 2016-06-20 10:22:15.406
Provided: Pyxine cocoes (Sw.) Nyl.
Backbone: Pyxine cocoës (Sw.) Nyl.
There is a fuzzy match because of the e vs ë.
Closing, no contact provided.
Author: rdmpage
Created: 2016-06-21 09:31:53.75
Updated: 2016-06-21 09:31:53.75
Maybe this could be interpreted as a plea for the interface to explain why the match is flagged as fuzzy. In other words, something like Google's "did you mean?" - Pyxine cocoes is interpreted as Pyxine coco_ë_s
If one user is asking for clarification I suspect many other will similarly be helped if GBIF makes it explicit what it is doing here by providing information for the user over and above "fuzzy matching"
Author: cgendreau
Created: 2016-06-21 09:37:09.67
Updated: 2016-06-21 09:37:09.67
Indeed, I'm re-opening the issue for the UI team.
Thanks Rod.
Author: trobertson@gbif.org
Created: 2016-06-21 09:38:08.721
Updated: 2016-06-21 09:43:26.876
Hi [~rdmpage]
Please see attached how this is expected to be displayed in the reworking of the GBIF.org interface. We would be interested in feedback on that (CC [~hoefft] ) but can we keep this issue specifically on the topic of the taxon fuzzy issue.
Please note: This is not yet public, but we are working towards a minimum first set of functionality to show publicly as fast as we can, and that styling is not final.
Author: rdmpage
Created: 2016-06-21 10:45:43.469
Updated: 2016-06-21 10:45:43.469
My initial reaction is "yuck" Is this the default view? It's cumbersome, full of stuff I don't necessarily need to see by default, why is the dataset provider given such prominence (I don't care as much about the provider as the individual record). The current portal isn't perfect, but it's MICH better at telling me what I need to know. The screen shot might make sense as a "detail" view but not as the default.
Do you guys watch "Silicon Valley"? The latest episode should be required watching: http://www.nytimes.com/2016/06/19/arts/television/silicon-valley-season-3-episode-9-recap.html?_r=0
OK, after calming down a little, I think what this view needs is a lot more information at the top. When I use GBIF I want to see things such as catalogue number, collector, associated sequences, etc., so I'd recommend adding these to the summary at the top. Don't dumb it down, tell us everything GBIF knows, then give me all the gory details of interpretation below.
Author: trobertson@gbif.org
Created: 2016-06-21 12:05:16.542
Updated: 2016-06-21 12:05:16.542
Thanks Rod. There are some useful comments in there.
Author: hoefft
Created: 2016-06-21 12:33:16.375
Updated: 2016-06-21 12:33:16.375
Good morning Rod. The sun is shining here.
??The current portal isn't perfect, but it's MICH better at telling me what I need to know.??
I do not know what you are looking for, but I would love to know where the current version serves your needs better.
I’ve attached a couple of screenshots. Two of them show the same record in the current version and the new (with the caveat that things might change). The pictures is cropped at the screen size our users most often have.
The current version shows: id, event date, species name, dataset name, issues, locality and half a map.
The new version shows: event date, species name, continent, country, basis of record, type (if type specimen), dataset name, publisher name, taxonomy, last modification date of record, date of last sync with original source, full map, coordinate accuracy (as circle on map) and reference to original record (if provided which it isn’t in this case).
Besides that it separates issues into info, warning and errors. And it provides a direct way to give feedback to the publisher.
That is quite a bit more in “the top”. That said the top is a undefined size in these days of responsive web design. Just take the screenshot from the mobile view.
I like your idea of showing catalogNo, collection code etc in the top. But only in cases where it is of interest. And I would say that it isn’t the case for many records (iNaturalist records for example). It is however relevant for museum specimens.
Likewise showing data related to sampling would make sense in cases where the occurrence is part of a sampling event. There are many special cases like this, where showing more/other data would be relevant - much of that data is currently of so varied quality and format though, that it is difficult to bring to the top in a useful way. But it would be interesting and useful extensions. But as basis info, i would say that the current focus on what, where, when + issues, type and provenance is the most important and stable.
I imagine the implementation order like this:
1) information we always have and that is useful to most (the version you see)
2) deducing extra info of interest on record basis (your ideas are very much welcomed here)
3) customisable views.
??My initial reaction is "yuck" Is this the default view???
No it is not the default view. It is however very similar to the default. The verbatim tab has been removed and been replaced with a diagnostics view that shows the interpreted and the verbatim/original side by side along with remarks about the transformation (if any). The table view present much more data in less space and follow the (for many) familiar grouping used in DarwinCore.
Ive attached the default view for an occurrence of Schizobranchia insignia Bush, 1905
Author: rdmpage
Created: 2016-06-21 14:01:19.646
Updated: 2016-06-21 14:01:19.646
Thanks [~hoefft] for the screenshots. My initial reaction was partly because the example being discussed lacks a lot of the fields that make for a more interesting view (e.g., the map). That, coupled with Tim's big screenshot made me freak out a little ;) The examples with maps look nice, especially the responsive resizing.
I'd really like to see as much specimen-related detail appear "above the fold". While some (most?) users may just want to see a dot on a map for a species, people like me care about the actual specimen being plotted, so I want museum catalog numbers, identifiers, collector numbers (handy when looking at plant specimens), anything which helps me figure out what the actual specimen is.
Have you explored putting a media thumbnail "above the fold" as well? Especially for observations from iNaturalist, having a thumbnail in the top panel makes the record look richer and more interesting.
Thanks for responding, and for the screenshots, although we may have ignored [~trobertson@gbif.org]'s plea to keep on the topic of fuzzy matching...
Author: hoefft
Created: 2016-06-21 14:49:25.517
Updated: 2016-06-21 14:49:25.517
Media thumbnails: I have considered that - and completely agree that it is a good idea. But it hasn't been implemented yet. Audio haven't been properly incorporated yet either.
I'm not at all against putting more in the top, but there is already a lot of information and I'm afraid to drown the most sought for info. That is why I'm thinking along the lines of some smarts deciding on additional information dependent on the record in question. Specimens as you mention seems like a group that could get special treatment. Holo types etc possibly also. Sample based occurrences another group. And as a last resort the option to customise.
There is a lot of ideas for how we could improve this page further. The map alone could provide more information than simply the location. Some of the ideas are captured here: https://github.com/gbif/portal16/issues/7 . For now we only use Github for issues as an experiment while developing - so please keep using Jira :)
So many ideas for what could be improved, but I already find that the redesign is a fair step forward. No doubt it warrants another iteration, but there is currently pages that is worse of and needs doing foremost - such as all the pages that we haven't implemented at all yet.
The main improvements of the occurrence page is - as I see them: More readable header. More info in the top. Coordinate uncertainty shown. Better diagnostics tools (this issue is an example of that need) by splitting issues into severity and mapping them explicitly to the fields they relate to. All terms and extensions is shown. And a clear channel for giving data feedback (though it is by no means perfect either, but simply the better way for now).
Thanks
