BiologicalRecordsCentre / iRecord

Repository to store and track enhancements, issues and tasks regarding the iRecord website.
http://irecord.org.uk
2 stars 1 forks source link

Add activity name to source column for app #88

Closed charlesroper closed 2 years ago

charlesroper commented 8 years ago

When adding records associated with an activity and using the app, the source column should display "iRecord | App | Activity Name". Currently, it only displays "iRecord | App".

/cc @kazlauskis

johnvanbreda commented 8 years ago

I don't think this is an app specific thing - the source column doesn't show the activity name for any records entered via the web interface either.

DavidRoy commented 8 years ago

In principle this is a good idea but given that activities can have long names, i have concerns about the length of the text string - being unwieldy in 'Explore' reports for example. For the iRecord - explore reports, perhaps we should adopt the coding (+ hover-over) approach that is used for the verification grid? I suspect the general user is not that interested in sources of records

charlesroper commented 8 years ago

I'd say it's more helpful to activity administrators (and participants) where the records come from a number of sources. Having the data in the grid means we can filter and sort. Point taken about the length. Could we truncate if over a given limit? Or use an activity code?

Example screenshot of FSC Cuckoos activity: 2016-09-06_10h25_27

DavidRoy commented 8 years ago

Having the information coded in the grid would allow filtering (via filter setup) and sorting but perhaps not so easily. Truncation might be difficult to automate and ensure that source text is unique. Here is how the codes are implemented in the verification grid, and what I propose should be replicated in other explore reports: image

charlesroper commented 8 years ago

Ah, I've not looked at verification for a while and didn't realise it did that. That looks like a good compromise to me (with the hover tooltip).

DavidRoy commented 8 years ago

Great. Is that ok for you John?

JimBacon commented 8 years ago

A possible alternative that crossed my mind is whether you might use the responsive tables capability to include extra information for which there is not sufficient screen width to display. capture

kazlauskis commented 8 years ago

As an idea for long table cell entries you can easily trim the text with a bit of CSS:

overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;

You can see that in blue here (I have placed it on a new line though): screen shot 2016-09-07 at 09 35 30

johnvanbreda commented 8 years ago

Hi @kazlauskis, thanks for the idea. I'm not sure how this works in terns of interaction with the way the browser resizes the cells though. If I try it on my own laptop in both Chrome and Safari, then when I resize the window to the point where the data will no longer fit in the cells, the browser prefers to allow the table to overflow its container rather than shrink the cell causing an overlap. This even occurs when the table is max-width 100%.

kazlauskis commented 8 years ago

screen shot 2016-09-07 at 11 33 28

Like that? I am not sure how the percent works in this case, but you can use specific width with td's

td {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
max-width: 50px;
}

screen shot 2016-09-07 at 12 03 28

johnvanbreda commented 8 years ago

Yes, I've now realised that max-width works, though there are still 2 problems:

kitenetter commented 2 years ago

Activity names now included in downloads and are coded on the verify page. Closing.