1

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Possible enhancements to Recorder 6 - please contribute your ideas

We may have a small amount of funding available to make some enhancements to Recorder 6 functionality in the next version we release (which we hope to begin to develop around November this year). Due to the limited amount of funds we have, we need to ensure that any changes we make have greatest benefit to the recording community, and in particular, that the changes made make a demonstrable difference to the efficiency of data collation.

We need users to help prioritise and also add to the list of suggested improvements that have been contributed so far (see uploaded excel file 'Suggested Improvements to Recorder 6 software' here http://forums.nbn.org.uk/uploads.php for details).

Which changes would save you the most time when managing your data?

It might be easier to group some suggestions together, e.g.

Improvements to the Import Wizard
1.    Improve performance when importing large files
2.    Have a facility to match species to ‘all preferred lists’
3.    Improve flexibility when importing location information
4.    Make analysing import rejects easier.
5.    Additional fields for import, e.g. sample reference.

Batch Operations and Exporting
1.    Provide a facility whereby you can select and update multiple records, e.g. add determinations, change dates, recorders etc. ensuring that these changes are cascaded to all appropriate levels and do not create any invalid data.
2.    Provide a facility to select and check multiple records in the database, to ensure that any existing data does not break the validation rules, and similarly for this checking to be available when exporting data.
3.    Make exporting more granular, flexible and consistent, so that the user can choose whether to include zero abundances, invalid data etc., or to export location information or recorder information only without occurrences etc.

Support multiple databases within one system

1.    So that large surveys can be separated out into separate ‘NBN’ databases
2.    Could also allow the use of a ‘test’ database.

Please feel free to expand on/discuss any of the above, or suggest something new.

Your input greatly appreciated,

Many thanks,

Sarah

Sarah Shaw
Biodiversity Information Assistant
JNCC

Sarah Shaw
Biodiversity Information Assistant
JNCC

2

Re: Possible enhancements to Recorder 6 - please contribute your ideas

I'm surprised no-one has responded to this yet. Guess I'll be the first to take the plunge. I'll divide our main work areas that make use of Recorder into categories: data input, data management and data output.

1. Data input
The vast majority of our data comes in through the import wizard and so performance improvements are always welcome. Here are some specific improvements I'd like to see:

1.1 The Import Wizard

1.1.1 General performance improvements, although for most imports, performance is pretty good. For large imports (10k rows and up), performance can be quite slow.

1.1.2 At the species matching stage it would save lots of time being able to search across preferred checklists.

1.1.3 Although not a time-saver as such, there are often times when the columns types we can currently import aren't sufficient. For example, we often need to import a Location Name in addition to, or instead of, a Location. Maximising the number of columns that can be imported could potentially save bags of time if the only alternative is to enter data manually, or make changes manually.

1.2 Recording Cards

1.2.1 Need to be able to remove items from recording cards

1.2.2 Need to be able to filter and dynamically search the list of species in the recording card in order to narrow the possibilities

1.2.3 Need to be able to add the species group as a column and filter on this

1.2.4 Option (or button) to automatically populate the Recorder with the currently logged in user

1.2.5 Option (or button) to automatically populate the date with the current date

1.3 Enter a Species Record...

1.3.1 See points 1.2.4 and 1.2.5

1.4 General improvements

1.4.1 When searching for a taxon, make the most likely choice appear first, i.e., make sub-species appear below species instead of vice-versa as is the current situation.

1.4.2 Don't start searching for taxa until 3 characters have been typed (currently it's 2)

1.5 Dictionaries

1.5.1 Currently the dictionaries are very unweildy, particularly the means of choosing particular checklists and searching across them. Provide an improved way of browsing the dictionaries and allow for searching across dictionaries.

2. Data Management

2.1 Verifying data

2.1.1 At present it's a very fiddly process marking an occurrence as invalid (or other determinations). The process could be much simplified if there were a simple menu available that provided these options "mark as invalid", "mark as verified", "mark as needs confirmation".

2.1.2 Allow for colour coding of invalid (and other determinations) data.

2.2 Batch updates

2.2.1 Data should be batch updateable including marking records as invalid (or other determinations), updating dates, recorders, grid refs, etc.

2.2.2 Data should be editable from within report wizard grids. Columns and selections should be updateable as a batch and determinations should be possible.

2.2.3 Data should be batch movable to other surveys or categories (see 2.3)

2.2.4 User should be able to multi-select items in order to copy/paste them

2.3 Managing "Sets" of Data

2.3.1 There needs to be a level in the hierarcy above the survey in order to help categorise data

2.3.2 The user should be able to include/exclude these categories globally within Recorder, so that, for instance, data in an excluded category wouldn't appear in reports or exports.

I'll post the rest (data output) in a couple of days (I'm out of the office all day Wednesday). If anyone has any comments of suggestions regarding the above, please do chip in, particularly in regards to what you might consider to be priorities.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

3

Re: Possible enhancements to Recorder 6 - please contribute your ideas

I would see the tool for detection and management of duplicate records as the most important improvement on the list.

This wouldn't initially save me time, as I wouldn't even try doing this "by hand" across the whole database, but in the longer term this would reduce the time spent chasing up duplicates that I notice and edit on an ad hoc basis.

I would also like to see the addtional "Dataset" category in the Survey hierarchy (2.3.1 in Charles' list)

Gordon

Gordon Barker
Biological Survey Data Manager
National Trust

4

Re: Possible enhancements to Recorder 6 - please contribute your ideas

I've asked for a formal response to Sarah's posting from the NBN's Data Tools and Standards group who are meeting on 25th September.
JNCC's Recorder team are represented on this group and a number of proposals (mainly from myself, acting on behalf of the NSS steering group) are currently tabled which impact on Recorder development. Oliver Grafton has prepared a summary of NBN's contributions to the area as a whole to date. Outcomes may affect the JNCC budget for Recorder enhancement if we're lucky enough to persuade people with purses.
I suspect part of the cause of the delay in responding to this is that we are in the traditional holiday month, Mandy was just going on hols and Trevor is in Mull (or somewhere)

5

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Gordon/Charles
Can you say more about the dataset level in the hierarchy. I had been thinking about this but was thinking along the lines of a number of separate databases in the background rather than yet another level in the hierarchy. eg. there would be a test database (messing about with) and a live one and for orgs like BRC a separate database for molluscs, plants etc. If the issue is mainly around access etc could this not be dealt with through a survey level attribute?
Steve

6

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Steve: separate databases are fine, but it should be clarified how the might best be implemented. The purpose for a new level above surveys would be to:

a) Enable more efficient organisation of data
b) To allow sets of data (many surveys) to be excluded/included from reports, exports, etc. on an as needed basis

To give you a use case, we sometimes receive data from other LRCs in order to carry out cross-border, or regional, projects. This data needs to fit with our existing data (for reporting) and thus wouldn't ideally be put into a completely separate database (it would need to be integrated with our core db). But with the current survey structure, these data get "mixed in" with our core Sussex data, which causes long term problems (lots of locations and recorders we don't want or need) and are hard to get rid of.

Another use case is that we need to exclude a set of about 10 surveys from all exports. Currently there is no practical way to do this unless we export surveys individually. If were were able to dump these surveys into a "folder" that enabled reporting, but excluded exporting, that would be ideal. Each "folder" or category would have a set of access controls that would enable/disable, for example, exporting, reporting, data entry.

I suppose that separate databases could be used to implement this with a facility in Recorder could turn them on and off and apply the access controls. The key is to be able to cleanly integrate and separate multiple datasets on an as-needed basis.

Gordon: good point regarding duplicates. I way to detect and manage them would indeed be a great time saver. Like you, we simply ignore them for now in the absence of any practical way of dealing with them. This also relates to items 2.1.1 and 2.2.1 in my list; once duplicates were detected, we'd need a way of (batch) marking them as invalid quickly and easily.

I would also add to this a way of detecting and managing invalid data. Currently, the only way to detect invalid data is to export it, then re-import it, which is a huge time waster.

Here are some points regarding reporting:

3. Reporting and Output

3.1 Geospatial reporting

3.1.1 Currently, a lot of time is wasted exporting data into GIS, converting it into grids, then reporting against those grids using polygons. The fact that Recorder places points in the bottom-left corner of a grid square means that it cannot reliably be used to do geospatial reporting, thus necessitating the use of a GIS.

3.2 Report Wizard

The report wizard has come a long way, but still needs further improvements in order to save time doing tasks which should be unnecessary

3.2.1 When saving a report, also save the order of the columns. Rearranging the columns consumes a lot of time.

3.2.2 Enable exporting to GIS formats, such as SHP and TAB. Also allow exporting as NBN Gateway style grids, in addition to points

3.2.3 Improve the filters; allow for filtering by taxon group and other filter items that might be missing (could do with some input from others on this - Darwyn?). Also improve the filter dialog to allow for selecting from terms lists. For example, if we are to filter on designation, allow for the designation(s) to be selected from a list. Currently it is very difficult to select by designation because the precise wording of the designation has to be typed in. Things like recorders, locations, designations, measurements, etc. should be selectable from a list.

3.2.4 Allow for an occurrence to be invalidated/verified from the report wizard output table (see 2.1.1)

3.2.5 Allow for editing of values in-place (see 2.2.2)

3.2.6 Improve reporting on designation; the current solution is flawed as many people have noted. Providing a concatenated list of designations (or perhaps designation kind would be a suitable addition/alternative) in one cell would be one solution, as would adding designation columns dynamically; i.e., if a taxon is returned in a report and it has xyz designation, append an xyz column and a boolean TRUE value to the row.

3.3 Exporting

3.3.1 Improve the export filters so that they are as flexible as the report wizard. It is currently impossible the export with anything like the level of granularity needed with the current export filter facility. Perhaps link export filters to report wizard saved reports, complete with their improved filtering (3.2.3).

3.3.2 Filter exports through the validation library and provide a means of fixing invalid data quickly and easily (see 3.3.3 below).

These next two should really go in the data management section, but I'll put them here for now:

3.3.3 Provide facility for detecting and managing invalid data, and provide a simple interface for fixing the invalid data

3.3.4 Provide a facility for analysing import rejects; provide a report to send back to the data custodian so they can fix the problems.

I've personally spend days and days worth of man hours wrangling with these last two. Finding invalid data is a large part of the task, but then once they are found, it can be very time consuming fixing those same data. For instance, if a set of records are somehow outside the date range of their survey, the date must be changed in at least THREE places, and usually more if there are multiple occurrences under one sample (one date change for each taxon determination). The changes must also be made in a particular order. The process is very prone to error and is quite excruciating if a lot of these changes have to be made. I spend over a day recently updating about 50 records in this fashion. With the added ability to batch process items (in this case, batch change the determination dates), it would have taken perhaps half an hour.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

7

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Another point I have been thinking about: an XML Reports style means of specifying a custom recording card/recording form complete with definable terms lists that apply to just those forms. So, for example, I would be able to define a form/card suitable for a specific survey. It would contain just the fields and measurements required and would be a big time saver in both pure entry performance (the data keyer could key faster), but also training (much easier to train someone to enter data into a specially designed form) and also in later validation (a specially designed for would generate less errors).

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

8

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Darwin,
Just to pick up your point re. the standards and tools group. That group does not explicitely steer the Recorder work plan or developments. The decisions around this are made by the Recorder steering group. The standards and tools group acts as a voice but the voices through this forum (at least in relation to Recorder) are at least as strong if not stronger. The decisions in relation to the enhancements will be made relatively soon so if you have ideas or things you want to raise / add to what has already been proposed my advice would definitely be to contribute them to this discussion strand.
Steve

9

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Who is on the Recorder steering group and what range of interests (e.g. Local Records Centres, users of LRC data products, National Schemes & Societies) do they represent ?
Darwyn

10

Re: Possible enhancements to Recorder 6 - please contribute your ideas

wilkin_s wrote:

Gordon/Charles
Can you say more about the dataset level in the hierarchy. I had been thinking about this but was thinking along the lines of a number of separate databases in the background rather than yet another level in the hierarchy. eg. there would be a test database (messing about with) and a live one and for orgs like BRC a separate database for molluscs, plants etc. If the issue is mainly around access etc could this not be dealt with through a survey level attribute?
Steve

Steve,

My issue with this is that without a higher level in the hierarchy, the number of Surveys in the hierarchy becomes unmanageable and it becomes hard to locate records within the hierarchy. This becomes more of a problem if I start accepting imports from other people's Recorder systems and then can't edit the Survey names to fit them into a consistent filing system. Effectively I am already using the Survey level as this top level, partly because this was how transferred data from R3 came back to us. This means there are no items of the true Survey type, as it should be used, causing the mess to be at the Event level.

I would suggest that although the system is capable of holding a large number of records, the hierarchy for organising them may not have taken account the needs of dealing with these large amounts of data. There is also the possibility that I have not thought of a much more obvious solution to this problem that everyone else is already using.

Probably a good idea to start a new thread on this if anyone wants to reply so we don't hijack Sarah's topic.

Gordon

Gordon Barker
Biological Survey Data Manager
National Trust

11

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Probably no need to create a new thread Gordon.

Instead of a new level above surveys (which I suspect may be tricky), I suggest a facility to add "tags" (or labels or categories or flags) to surveys? The surveys should then be able to be quickly filtered and viewed by specifying one or more tags. The benefit of tags over a traditional hierarchy is that multiple tags can be applied to one survey whereas in a hierarchy, there can only be one parent. Here's a use case:

I have several surveys containing bird data and I want to categorise them. Some of these surveys are from Kent and some from Sussex. With a hierarchy, do I put them under my "Birds" node, or do I put them under "Kent" and "Sussex" nodes? My options are limited and neither is ideal. However, if I were able to tag my surveys, I could apply all of them with "Birds" and could also apply "Kent" and "Sussex" to the appropriate ones. Point being, each survey could have multiple categories. It's actually much, much simpler than it sounds. Check out Del.icio.us for a great example of tagging in action. Here's a list of all of the bookmarks on there tagged with both "birds" and "sussex".

The key to making tags work is to allow for very easy filtering and viewing. I would suggest a list of tags somewhere on screen that one could click on to filter the list and also a dynamic input field that allows for the entry of multiple tags (like Del.icio.us), e.g., enter "birds+sussex" would list all surveys tagged with "birds" and "sussex".

Expanding on this some more, individual tags should also have properties that would enable/restrict reporting, exporting, editing, etc. The export routines could be enhanced to enable exporting of one or more tags as could the report wizard.

Is all of that ramble clear, or does it need some more explaining?

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

12

Re: Possible enhancements to Recorder 6 - please contribute your ideas

In her post on 22/08/07 Sarah included exporting location information or recorder information only, without occurrences, as one of the suggested enhancements but this facility already exists. Are users unhappy with the current facilities for doing exports for multiple locations, etc.? Users were able to do this in Recorder 2002 using rucksacks: create a rucksack containing the locations/people/documents to be exported; open it, then use Tools - Export data...  to export the items in the rucksack with or without sub-sites or observations – see the Help: Index – Export – Rucksack in Recorder 2002 and Recorder 6. If creating a rucksack in Recorder seems to be too time consuming the necessary codes can be added more quickly using Access.

Sally Rankin, JNCC Recorder Approved Expert
E-mail: s.rankin@btinternet.com
Telephone: 01491 578633
Mobile: 07941 207687

13

Re: Possible enhancements to Recorder 6 - please contribute your ideas

The rucksack export facilities are fine up to a point Sally. Is your question in response to a particular point I or someone else made? Where rucksacks don't help is in filtering data. If, for example, I want to export all bird data, but NOT those data from a particular set of surveys; there's currently no easy way to do this. If items were able to be designated as EXCLUSIVE in a rucksack, that would be a very useful feature. That is, by placing a location or species or recorder (etc.) in rucksack and marking it as "excluded" it would then be excluded from reports, exports, etc.

While on the subject, my point 2.2.4 (User should be able to multi-select items in order to copy/paste them) would be a useful, timesaving addition for working with rucksacks. I could select several items at once by Ctrl-clicking them (like working with files in Explorer), then drag them into the rucksack in one move.

Another useful timesaving feature would be a right-click menu option along the lines of "send to current rucksack". So I could right-click on a location and select "send to rucksack". This is much easier than dragging and dropping in many instances as the rucksack window is usually obscured by other windows.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

14

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Hi

Following on from the thread here on Admin areas - http://forums.nbn.org.uk/viewtopic.php?id=413 I think it is worthwhile adding the following to the list:

Increased interoperability (for want of a better word :)) of the Locations hierarchy and Admin areas dictionary. To be able to automatically assign (with the click of a button) multiple admin areas to a location, derived from it's position in the locations hierarchy. In addition, to be able to select a number of admin areas and create their equivalent locations (in appropriate hierarchy) by clicking on a button.

Hope that makes sense.

Not sure where this would fit in within your list Charles? Dictionaries? Management of "sets" of data?

Best wishes,

Sarah

Sarah Shaw
Biodiversity Information Assistant
JNCC

Sarah Shaw
Biodiversity Information Assistant
JNCC

15

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Charles

I wasn't in favour of the tag approach, but now I think I understand it a bit better I see how it could work. It would need some sort of filter, possibly drop-down list, on the appropriate page. Would you see this as being an option for Event/Sample as well?

I still prefer the extra top level of the hierarchy as I think it would be simpler to use and would cause less work to deal with existing data.

Overall it probably depends which solution would be easier to implement.

Gordon

Gordon Barker
Biological Survey Data Manager
National Trust

16

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Sarah: I'd put this in the 'management' section, but it also applies equally to the 'data entry' section (for when entering Locations)

Gordon: the beauty of tags is that they can be implemented to mirror a folder-like structure. Have a look at the this screenshot from my Google Reader. Note how the RXWildlife weblog is present in both in both the GIS and Wildlife 'folders'. This is because in Google Reader you apply tags to individual feeds; each tag then appears as a folder. It's visually the same as a folder structure, but with the benefit of being able to place the same item in multiple places.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

17

Re: Possible enhancements to Recorder 6 - please contribute your ideas

1. GIS
All Local Records Centres require GIS to deliver site-based services. At the same time, Recorder offers a good structure within the data model to record, report (to some extent) and provide analyses (e.g. for LDF) as part of our suite of services.
The mapping functionality within Recorder (Hannah Betts called it a mapping tool as distinct from a GIS) is inadequate for the vast majority of GIS-based services which an LRC is required to deliver.
The concept of the incorporation of a sophisticated GIS within Recorder has been criticised by many purely by reference to the original decision to use a cheap GIS in order to keep costs down. LRC partners have paid for this decision several times over and still remain interested in better integration of GIS with Recorder; and still possibly prepared to pay for it.
The degree to which such an integration might occur is debatable but some small steps may be made towards this simply by acknowledging the need to have some form of link between a Location and an externally managed polygon.
What we are looking for as a first step is an unambiguous field on the General tab of the Locations used purely to store the unique polygon identifier key (e.g. POLYGON_KEY); that key to have been derived from some other external GIS.
[We currently have to use File Code but it is highly unsatisfactory as it fails to display all of a Recorder-style 16 digit code and external to our LRC may be used for other purposes - as the Help menu states "Optional. Any user-specific file code can be entered here"]

18

Re: Possible enhancements to Recorder 6 - please contribute your ideas

2. MapMate
The absence of a built-in Recorder/MapMate data exchange mechanism which will permit easy movement of records between the two systems is long overdue. The longer that this is not addressed, the more harm this does to the biological recording community as a whole.
[Please avoid giving the reasons for the situation in any response to this posting]

19

Re: Possible enhancements to Recorder 6 - please contribute your ideas

3. Metadata
If I send my Myriapod records today to the NBN Gateway and fill in my "Specify Metadata", I'm told that the information is provided within the export file to other users. Tomorrow I'll be sending Amphibian records and I'll have to change many things in the "Specify Metadata" box. I've now lost all record of my Myriapod metadata from the previous day.
Can we have a Print button to save a record of each metadata batch.

20 (edited by Darwyn Sumner (LERC) 06-09-2007 14:15:25)

Re: Possible enhancements to Recorder 6 - please contribute your ideas

4. File Plan Identifiers
If you've never wasted a piece of paper by printing out something unnecessary from your computer then you're probably entitled to claim that the "paper-free office" is real.
The rest of us have to handle paper documents. I'm surrounded by fourteen 4 drawer cabinets and about 30' of shelving full of this stuff now. All of them relating to biological records. Very few of them ever likely to be turned into an electronic format so that I can link them into the "external references" bit of Recorder. But I do need to link them into all sorts of places in Recorder (supporting evidence, audit trails, validation, verification, etc.)
Our paperwork has a proper filing system (see Six Steps to Better Files by the U.S. Environmental Protection Agency's National Records Management Program for a wonderfully concise and commonsense approach to all this) and it generates File Plan Identifiers (commonly termed FilePlanIDs) to identify documents right down to individual bits of paper. These same FilePlanIDs may also be found in electronic document management systems designed for managing paper documents (see National Archives website and your local friendly Records Office)
I would like several FilePlanID fields on all "Sources" tabs, with room for a textual description

21

Re: Possible enhancements to Recorder 6 - please contribute your ideas

I agree with the need for a POLYGON_KEY or perhaps better a FEATURE_KEY (a feature in a GIS can have multiple polygons); but they're effectively the same thing. Regarding GIS integration with Recorder, I would prefer to see the ability to query Recorder data directly in ArcGIS (and MapInfo) rather than integrating more GIS functionality into Recorder. I suspect it would be a less expensive, more powerful, more flexible implementation. If GIS functionality were brought into Recorder, I suspect it would be very expensive to develop and would also be sub-standard and relatively inflexible when compared to the tools we're already used to in a 'proper' GIS. What are the advantages of having extended GIS functionality in Recorder vs. extended Recorder functionality within a GIS?

Something like ArcGIS (I don't know about MapInfo, but I suspect it's similar) can be easily extended with add-ons and scripts so that's one option for better integration. There are also a slew of open source GIS projects running that could also be made use of. I suppose it depends on what you want to do. For us, we'd simply like to be able to plot data properly (using a grid rather than points) and use the various spatial querying and select tools available in ArcGIS and also be able to link site polygons in the GIS with location data (and thus species data) in Recorder.

Totally agree with regards to MapMate interoperability. We waste a LOT of time jumping through hoops trying to deal with MapMate data.

Regarding metadata, that's a very good point and something that never occurred to me before. Some sort of log or database table that provided a persistent store for the metadata would be useful.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

22 (edited by Darwyn Sumner (LERC) 07-09-2007 09:52:24)

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Thanks for expanding a little on those topics.
I suspect it would be very useful to all of us GIS users to have this as a separate topic (next to Web Services at the top) so that we can more easily share our experiences.
I'm a MapInfo user (cost ~£200 to charities & Wildlife Trusts) but from conversations around the country I suspect that ArcInfo is better at the sort of integration that Chris refers to.

23

Re: Possible enhancements to Recorder 6 - please contribute your ideas

From the perspective of a records centre that doesn't use Recorder but does use MapMate I would also welcome a better solution to the problem of data exchange between the two packages.

Martin

Martin Harvey
Buckinghamshire and Milton Keynes Environmental Records Centre

Martin Harvey
Biological Records Centre
CEH Wallingford

24

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Most definitely agreed Martin.

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

25

Re: Possible enhancements to Recorder 6 - please contribute your ideas

Some improvements to Recorder 6 required by LWIC - some of these have already been covered by others and reinforce the need for them:

1. Ability to tag surveys to allow groupings. 

2. Currently species aggregates are given an identical name to a species (e.g. Pipistrellus pipistrellus is used for both the s.s. species and the s.l. aggregate).  John Tweddle’s request to recording schemes for aggregate species names was sensible as a means of carefully distinguishing them from species when inputting records – currently the inability to distinguish the names in R6 is going to undermine this. Sarah Shaw suggested including the taxon rank field with the species name and as long as this is available everywhere in R6 where species need to be selected or reported this should get around the problem.

3. There is a need to attach various national and local details to species. If this is to be most effective the data needs to be attached to the preferred species name and there needs to be a mechanism so that if the preferred species name changes then the details 'follow' it. It would also be useful to view all of the designations/statuses relating to a species.  This can be done in the taxon dictionaries but it is not a simple listing and it would be better if this was available in the taxon details area (accessed via Edit Taxon Details). Currently this area does not list any of the national designations even when an appropriate checklist is selected.

4. The species designations are currently a bit of a mess! Many species have multiple status/designations some of which might now be obsolete or have been updated (e.g. vascular plant red list). In general we need to provide data based only on current designations.  There needs to be a way of determining which designations are currently applicable and one part of this is to ensure that the Date_to field in the Taxon_Designations table is kept up to date. This would provide a flag that would allow obsolete designations to be excluded.  We usually need to provide reports that list designations at different levels (e.g. international, Scottish) and the ability to concatenate all designations at each level is needed. A report with full designation names is cumbersome and it would be useful to have standardly assigned abbreviations for each designation e.g. W5 = Wildlife and Countryside Act schedule 5 or EN = IUCN Endangered.  (Reports then just need to include a key that spells out the codes)

5. The report wizard needs to have the ability to list all fields.  The report wizard also doesn’t have a single abundance field but has separate fields for every abundance type – again a method of concatenating the input data into a single field is needed.

6. We have a need for a validation report that lists all of the fields that data has been input into, allows corrections to be made and finally automatically 'ticks' the check box of all records in that batch once the double-checking against the original data is complete. (I have this system set up using Access queries but it would be far preferable if it was integral to Recorder).

Bob Saville
Lothian Wildlife Information Centre Biodiversity Data Officer