Separate Facet for tags applied via coding on batches

[AdamS]

I would say that this is the most urgent addition I can think of for the following reasons.

 

Currently when our clients review the documents via the 'Review' tab and apply their coding, the resulting hits appear mixed in with the regular tags Facet, this is fine when you have a very simple case with no other tags.

 

However this is rarely the case as most of my matters require me to perform some pre tagging and scoping to setup the batches, in some cases there are hundreds of tags along with family tag sets etc. 

 

Once my client finished their review and they want to create export sets it becomes very difficult when viewing the tag sets to quickly isolate the tags that are related to the batches. This is compounded when they have multiple reviews going on and they want to create exports at different stages of the review.

 

Currently to create an export I have to first isolate the tags by user, then ensuring batches and tags are showing in the preview window, sort by tags and then manually scroll through and apply a new tag to all the relevant items and create an export set from those tags.

 

If we are talking about 4000 items then this can be a slow process.

 

Everything up to that point is brilliant, simple and fast so that last stage I think needs to be just as simple and fast, ideally so our clients can create the export package without needing further assistance.

 

To that end I would propose the following:

• A new facet called 'Review Code Tags' be created which is where the tags used for coding appear, completely separate from the other tags which were applied via the 'Search' tab
• This 'Review Code Tags' to be mirrored as it's own separate 'tab' up next to Search and Review in the top right corner. This will give us the ability to show or hide that tab based on user privileges we can setup.
• The 'Review Code Tags' tab would be laid out identical to the 'Review Tab' in that I mean you can see each batch with the same details as the Review tab with a few small differences, namely:

1. The coding fields appear on the right hand side of the screen and all tags have a 'show/hide' option which you need to select for each tag
2. When you 'explore' any of the batches you only see those items which correspond to the tags you selected in the previous step
3. The coding fields on the right remain visible so you can change on the fly and what you view will change dynamically as they are changed
4. Like the main 'Review' tab you can select all the batches or a selection of batches, however unlike the 'Review' tab we need to be able to display all items in a single batch/window
5. The coding fields on the right hand side will also need to have the ability to select individual users or all users who applied the tags
6. Lastly once all the relevant tagged items are selected and displayed the option to 'create export' needs to be available somewhere.

 

I suspect that would be quite a lengthy process to implement but I can't overstate how much I think it's needed, however as a short term (and hopefully simple) addition I would offer that simply having a separate Facet for Review Coded Tags would be a huge step in the right direction.

[ŁukaszBachman]

Hi Adam,

 

Please forgive me, but this looks complicated. I had to go back and re-read the entire post few times and I think I still fail to see what exactly we are solving here. I understand that mixing standard tags and the ones used for coding can be problematic and we could figure out something to address this better. But the proposed 'Review Code Tags' seems to try to pack everything (joining batches, reviewing, filtering by tags, filtering by users) in one UI that mimics standard review UI. Isn't that mixing ideas of Quality Assurance and exporting together? Surely it wouldn't be allowed for all users, but nevertheless that feature would require a lot of expert knowledge to be used correctly.

 

 

Currently to create an export I have to first isolate the tags by user, then ensuring batches and tags are showing in the preview window, sort by tags and then manually scroll through and apply a new tag to all the relevant items and create an export set from those tags.

 

Can you help me to get to the bottom of this by making a step backward and explaining the original issues with exporting? It seems to me that you are doing a QA here too, but I'd like to know more about it.

[AdamS]

I may have had too much coffee at that point quickly and easily isolating those items my clients deem relevant, based on the coding tags was the central issue here. Everything else just evolved from my crazy thought process that followed.

 

Currently it's difficult to quickly isolate items based on the review coding 'tags' that our clients apply. 

 

I would break down a proposed solution like this.

Currently we set up the coding tags via the 'Search' tab by creating new tags in the 'tags' facet, then we follow through with the coding layout etc.

 

I would like to see a new facet in the 'Search' tab called 'Coding Tags' (or similar) and this is where we create the coding tags which will be used in the batch reviews.

 

This will also simplify the coding layout creation as when you go to create the layout you will only be able to see tags that you have created in the 'Code tags' facet rather than the many other normal 'tags' which may exist, this will also make it super easy to identify items my clients have coded as relevant, and to create the relevant batches for export or for further review.

 

I should point out that this has become particularly relevant for me as the vast majority of my cases the number of tags usually run quite high. I could go back and delete some of my setup tags at a later date, but my practice has been to keep these where ever possible as it allows me to duplicate searches and findings at a later date if I need to back track at any point.

[ŁukaszBachman]

Yes, that's closer to solution that I would have in my mind. I am just wondering if we should be separating this entirely (so coding wouldn't use tags at all, it would rather be more similar to assigning custodians) which implies that changing tags in Previewer won't affect coding decision (and vice versa). Or maybe simply offer an alternative where "Coding Tags" facet would list those tags which are also used in Coding Layouts (for easier querying). Both have ins and outs. What do you think?

[AdamS]

Either would work, I think it might come down to which is easiest for you to implement.