Codex
(UXPROD-833)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Codex |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Charlotte Whitt |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | crossrmapps, erm, metadatamanagement | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||
| Epic Link: | Codex | ||||||||||||
| Analysis Estimate: | Medium < 5 days | ||||||||||||
| Analysis Estimator: | Charlotte Whitt | ||||||||||||
| Front End Estimate: | Large < 10 days | ||||||||||||
| Front End Estimator: | Mike Taylor | ||||||||||||
| Front-End Confidence factor: | Low | ||||||||||||
| Back End Estimate: | Large < 10 days | ||||||||||||
| Back End Estimator: | Ian Ibbotson (Use this one) | ||||||||||||
| Development Team: | Prokopovych | ||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R4 | ||||||||||||
| Rank: Chicago (MVP Sum 2020): | R4 | ||||||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||
| Rank: GBV (MVP Sum 2020): | R1 | ||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R3 | ||||||||||||
| Rank: TAMU (MVP Jan 2021): | R2 | ||||||||||||
| Rank: U of AL (MVP Oct 2020): | R2 | ||||||||||||
| Description |
|
This feature was created before the ERM subgroup was formed. This may eventually become a feature or set of stories related to 589 Do we have any plans for expanding the Codex Search beyond the present two sources (Inventory and EBSCO KB), eg. GoKB for v1? We need to avoid allowing the design and specifiction of the Codex to be too dominated by the two sources we happen to have right now. If we can add a at least one more source, then the use case for Codex Search will be more evident for SMEs and testers, and we can ensure both the UX and implementation won't get any surprises down the line. |
| Comments |
| Comment by Mike Taylor [ 02/Mar/18 ] |
|
I am 100% on board with "We need to avoid allowing the design and specification of the Codex to be too dominated by the two sources we happen to have right now. If we can add a at least one more source, then the use case for Codex Search will be more evident for SMEs and testers, and we can ensure both the UX and implementation won't get any surprises down the line." But my understanding had been that we were not planning to do this for v1. If we did so it, it would be a non-trivial bit of work, involving new UX elements and their implementation down the stack through stripes-components, stripes-smart-components and ui-users. But I think it's important work. Also, the back-end component would be entirely dependent on what the additional resource (or resources) to be integrated was. |
| Comment by Mike Taylor [ 02/Mar/18 ] |
|
On the UI side, the complication is that having two Codex sources of the same kind ("KB") introduces a new notion into the mix, and we'd need UX work, which would then of course need to be realised in the UI. Would we want the ability to select "all sources of type KB", for example? If not – if we just treat it as an opaque third source, with no classification of sources – then it's much simpler to handle. |
| Comment by Cate Boerema (Inactive) [ 04/Apr/18 ] |
|
I think Owen Stephens seems like the natural PO for this feature. Owen, if that doesn't make sense, let me know. |
| Comment by Khalilah Gambrell [ 30/May/18 ] |
|
Owen Stephens - I think we should discuss how the work done for mod-kb-ebsco ties into this effort. And also my only concern with codex at this time is there is no way to search for packages and it does not provide any titles in the context of a package. |
| Comment by Mike Taylor [ 30/May/18 ] |
|
As I understand it, the absence of support for packages is not limited to the Codex, but comes from the fact that they are not recognised in Inventory either – isn't that right? If so, then there's probably not much point putting too much effort into them on the Codex side before that's fixed. |
| Comment by Charlotte Whitt [ 30/May/18 ] |
|
Mike Taylor - Packages in Inventory is definitely considered |
| Comment by Cate Boerema (Inactive) [ 10/Jun/18 ] |
|
Owen Stephens, I know that as part of your ERM project you will be working to integrate GoKB. Given that, I would like to keep this old feature with your work. Not sure where it belongs specifically so I just put it with Agreements (
|
| Comment by Holly Mistlebauer [ 20/Jun/18 ] |
|
In the gap analysis Chicago indicated that they need this feature within the first quarter of their "go live" date: |
| Comment by Owen Stephens [ 20/Jun/18 ] |
|
"all of the functionality available currently for EBSCO KB" would be an eHoldings question I think Khalilah Gambrell |
| Comment by Khalilah Gambrell [ 20/Jun/18 ] |
|
Holly Mistlebauer - My guess is Charlotte outlined this feature to support the Codex. There is another feature that pertains to integration of KB providers to support eholdings and ERM (https://folio-org.atlassian.net/browse/UXPROD-166). It might be helpful to breakdown the feature into multiple features represent integration per KB provider for prioritization |
| Comment by Cate Boerema (Inactive) [ 25/Jul/18 ] |
|
Per discussion with Owen Stephens, the ERM features will interact with multiple KBs (GOKb and EPKB to start), but that capability is included in the (other) ERM features Owen created. This feature was originally created by Charlotte (perhaps based on something in the v1 roadmap). Based on the description here and the people who estimated it (Mike Taylor and Ian Ibbotson (Use this one)), this feature seems to be about incorporating GoKB into the Codex app. This is a worthwhile endeavor, but not in scope for Owen. Charlotte Whitt, I am turning this back over to you and putting in the Codex epic. I am also renaming this, as the current feature name (Allow the integration of multiple knowledgebases for e.g. reference cataloging. Some will support holdings such as EPKB) is confusing. If I am misunderstanding the intended purpose of this feature, please let me know. I don't want to change the name of the feature in such a way that it no longer represents what was estimated. Thanks! |
| Comment by Cate Boerema (Inactive) [ 25/Jul/18 ] |
|
If everyone is okay with the changes I've made to the title and epic of this issue, I think the next step is to follow up with Chalmers to see if they really need GOKb integrated into the Codex for go-live if it will be integrated into ERM. |
| Comment by Charlotte Whitt [ 25/Jul/18 ] |
|
Cate Boerema - okay. I'll reach out to Chalmers. Both Theodor and Lisa is away on vacation this week. But as soon one of them are back, I'll talk to them about Chalmers expectations. |
| Comment by Mike Taylor [ 25/Jul/18 ] |
|
Cate Boerema, you wrote "(GOKb and EPKB to start)". Is EPKB the same thing as the ESSCO KB we've been using up till now (and usually abbreviating EKB)? |
| Comment by Khalilah Gambrell [ 25/Jul/18 ] |
|
Mike Taylor - Yes EPKB is the same as EBSCO KB. We should probably stick with EBSCO KB for Folio purposes. Charlotte Whitt, I scheduled a meeting with Theodor for 7/31. Do you want to be a part of that meeting? |
| Comment by Cate Boerema (Inactive) [ 25/Jul/18 ] |
|
Sorry - will use "EBSCO KB" from now on! |
| Comment by Charlotte Whitt [ 25/Jul/18 ] |
|
> I scheduled a meeting with Theodor for 7/31. Do you want to be a part of that meeting? |
| Comment by Charlotte Whitt [ 31/Jul/18 ] |
|
Follow-up: |
| Comment by Owen Stephens [ 25/Jan/19 ] |
|
My feeling is that we’ve now gone past this in terms of the ERM work, and that as a feature it is probably a bit broad to be useful going forward - as we probably want to look at integration of specific knowledgebases rather than just generally allow for integration We already have: https://folio-org.atlassian.net/browse/UXPROD-589 (GOKb integration) as well as work under way to ensure eHoldings title-packages or packages can relate to Agreements, Licenses, POLs etc. Unless there are objections I'll close this as "won't do" with a comment that we need to describe specific integrations where required |
| Comment by Charlotte Whitt [ 25/Jan/19 ] |
|
Hi Owen Stephens - as we discussed on Slack, this UXPROD is from the original roadmap spreadsheet by Hkaplanian, and the ERM work has moved in a new direction, and things have changed since the initial roadmap was defined. |
| Comment by Hkaplanian [ 25/Jan/19 ] |
|
IS the assumption that the eHoldings app can handle KBs outside of GOKb for libraries that want a direct connection to KB data? This is specifically about references and not copying or importing records which is very different from
|
| Comment by Owen Stephens [ 25/Jan/19 ] |
|
Hkaplanian the assumption is that eHoldings app can handle KBs that support the necessary API(s) to interact with eHoldings. In terms of the rankings from early adopters presumably they are looking for specific integrations rather than a general ability? Wouldn't expressing those requirements give us a clearer set of priorities to work towards? I'm just not clear on the value of having this open as an issue - how will we know when it is complete? |
| Comment by Hkaplanian [ 25/Jan/19 ] |
|
Owen Stephens, I can live with that. Lets close it. |
| Comment by Cate Boerema (Inactive) [ 22/Mar/19 ] |
|
Removing all but the essential features from the Q2 2019 Core Functional team backlog. After we've run the estimates through the cap plan, we may find we can pull in more. |
| Comment by Cate Boerema (Inactive) [ 09/Apr/19 ] |
|
Switching the resolution from done to won't do so this doesn't clutter up our reports. See comments from Owen and Harry above for why this issue was closed. |