AT Beta Test: Week Two
Accession Records & Linking Name and Subject Records
[Note: Comments have been pasted from submitted reports without editing. The unedited version in the current rough sequence meets the needs of the AT Project Team and should be intelligible to most interested readers.]
Color key:
Fixed
Needs to be investigated
Existing JIRA issue
Proposed JIRA issue
Respondents:18
Bugs reported and not yet validated or fixed:
Numeration contains no options/data.
We are unable to delete a child or sibling withou entering some kind of infromation into the record. This is frustrating if you have the habit of adding a sibling when you want a child.
This is a bug and will be fixed
Can't save. Duplicate error bug. Bug report sent.
I also had a problem when I tried to add the immediate source of acquisition note to one finding aid. When I tried clicking okay the duplicate record error message came back.
Dragging and dropping components a bit odd in the following ways:
1) if a drag doesn't actually drop, the text goes away from the screen, but the data are still there;
2) horizontal bar that indicates where drop will go disappears sometimes -- not clear why (is the drop not allowed at that point? is it a bug?)
3) I can manage to switch the components of the lowest level easily, but not in either direction all the time. It is not clear how one drags a component to be the "first" component under its parent. I have done this by dragging up so that it is the second component, and then draging the first one down below it.
4) Similary, I have managed to swith the order of series by making the second series a child of the first series, then draging the second series to the parent; but straightforward switching does not seem possible. There may be a bug here. But there is certainly a need for better documentation about this process. It’s not completely intuitive.
Drag and drop needs to be reworked to be consistent and adhere to normal UI guidelines
when adding a subject to a resource, after linking a subject, the entire list gets highlighted
I can’t get this to happen. We need more details
When entering in a new location while in the "manage locations" part of a resource record, once I enter the new location, the new coordinates show up in the filter and then it freezes temporarily
This is due to the size of the list of locations in BETATEST (There are more than 15,000) and it takes the filter a moment to work.
LOVE the wrap in tag feature in the resources notes! What about adding a normal= for persname, subject, geogname, genreform, etc? While working on wrapping a tag, I minimized the AT and then tried to get back in, but it was frozen
We need to look at the issues of minimizing and then maximizing the application on windows
We also need a final list of tags and attributes supported by wrap in tag, along with where it is to be applied
When adding subjects from the list the whole list was high-lighted, so I had to click somewhere else to get rid of the high-lighting and then to choose my subject again.
Had some difficulty creating additional parts of a Multi-part note. The first paragraph was entered with no problem. After pasting text for second or third paragraphs, got a Validation Error: "To save the record, please fix the following errors: ArchDescription Note. Note Content is mandatory." Had to Cancel, go back and Add Part.., then select Text. The pasted text then reappeared and I was able to save successfully
In the tree, if you enter a child under a series and call it a subseries, and then change your mind and decide it is a sibling, so you go in and change the level to series, it still appears in the tree as a child (e.g. "under" the series entry).
You need to use drag and drop to move the node. Changing the level designation will not move it.
In the tree view if you move <c>s around and want to put it at the very end of the list, it gets deleted instead (also happened to me when I put it in one of the mid-levels--just disappeared)
This is a bug that will be addressed when revamping drag and drop as described above
I think I remember Brad saying the resource module would have an undo. When I did something and realized it was a mistake, I couldn't undo. So I got smart and decided to "cancel." When I got back in, it had saved my mistake. So cancelling doesn't really cancel, or more exactly, what does cancelling do? Presumably the OK button was chosen at some point. Otherwise…???
If you create a child element in the resource view and then delete that child before entering any data, the data for all items in that nested sequence will be deleted. For example, if I create a file within a series and do not enter the required data, and then delete the file, all of the data for the series and the collection will be deleted. This may cascade to the other series within the collection, but the validation error that pops up prevented me from viewing other series to see if the data was lost in all branches of the tree.
You CAN cancel the data entry and resume from the last saved version, but any new changes will be lost.
This sounds like a bug. We will investigate and define the problem
Inheriting locations -- We created instances that recorded both box and folder container data. When a box was assigned a location, instances inherited the correct location. However, when additional instances were created AFTER the location was assigned to the box, those instances did not seem to inherit the location.
This needs to be fixed
Notable issues:
To date, this has been the most complicated assignment, but very helpful in evaluating the way we maintain our records. I have a few general comments that may be answeed in our next assignments. Under resource type there is not an option indication when the collection or records are primarily graphic. These terms broadly cover, but I wonder if there is vocabulary that would be more specific. I would like to see donor information on the accession record. Notes may be used to indicate the dominant material type of a collection. Donor information can now be linked to accession records.
Do you envision the name and subject sources ultimately as a shared database for all users or would these only be local? The name and subject records are implementation specific. They can be shared by the repositories using the same implementation of the AT. The records, esp. names, are designed to be contributatble to an EAC or MADS database. Developing such a database is a community responsibility, and it is has not yet happened, probably due to the immaturity of those standards.
Is there a way to select a default language or, alternately, to ensure that English appears at the top of the menu when you type "eng" into the screen? When you do that, you wind up with Middle English, which is likely not the first choice for most repositories. This can be done using the default value configuration tool.
When creating name authorities, I found that only a certain number of characters--usually fewer than the name included--were displayed. Is this because there is a limit on the number of characters able to be displayed?
There are character limits for each of the fields. They will be published with the data dictionary.
I am experiencing the same problem with adding names and subjects as we had previously: When I tried to enter a new name as subject, the program didn't allow me to add it because it said it was a duplicate record. At first, it seemed not to be creating the record, but apparently in some cases it actually did create the record the first time I got the duplicate record report.
I think that certain information is being recorded at least twice in the "resources" section. For example, I think that there are two or three places to record processing information. I see that the info on the basic information tab can indicate the status of processing ("processing in progress" or "processing complete" for example) while the info on the finding aid data tab would provide the <processinfo> and <revisiondesc> information. Then why also have "finding aid status"? This may be largely a documentation / default labeling problem. The “repository processing note” on the basic description tab is an internal note for a repository to use any way it wants to. The other fields mentioned here are actually output with the finding aid.
Speaking from the perspective of one who does a lot of box-folder lists, I wonder how easy it will be to do a lot of data entry quickly, using the instances and file levels. This concern will be addressed more fully in phase 2.
It is complicated to "undo" a parent-child relationship, but it is possible. Dragging and dropping is weird. For example, until one creates a child for a compontent, that component cannot be a "parent" and therefore other components cannot be dragged into it as children. So, if one needs to move a set of children from one parent to another, one first needs to create a child under the intended parent before one can drag the other children and drop them at the right parent. Needs to be explained in documentation. (No actual human children were harmed in the creation of this comment.)
Data entry is cumbersome. Lots of mousing, clicking, opening new windows, selecting from drop-down, clicking, closing, re-opening, etc. We were able to input 13 resources, but only by spending many more than 4 hours on the project each of the two weeks.
We have a lot more information about our boxes -- for example, box types (record cartons, half document boxes, legal-size document boxes, legal half-document boxes, etc.). We also don't see how to display more box information. For example, there is no screen where we can see the control number of the resource, the boxes related to the resource, and the locations of the boxes all together. Perhaps this will be possible with reporting? But it is useful information to see for assigning box locations as well.
We see no place to put a barcode for a box, or other container-level ID (container info in an instance is not the same thing). Do you plan to have functionality for managing containers? Assigning the locations of containers would be desirable through this means.
I'm not sure where to put the more odd kinds of extents. For example, I want to say things like "2 photographs" or "1 volume" or "1 v. ([365] p.)" as an extent sometimes. In EAD we map this to <physdesc<extent>. This may very well be what "container summary" is meant to do at the item level, and perhaps this should be renamed? Perhaps if I just knew where the AT maps data it would answer this question. (See note about documentation.) It’s becoming clear that our extent expression is not as robust as people might want it. It should probably follow the principle in MARC with $3 materials and then their extent.
Folder titles are often identical to names, a linked, newly created name pre-populated with the data in the unittitle would be a big time saver. This is an interesting point. Unfortunately, it is not always the case that a name linked to a file / item level component is always the title for that component. And the linked name asserts a different type of relationship. This is a place where redundant data entry might be necessary. But it can be less onerous with sticky data and adherence to good multi-level description.
The gray backgrounds in the text boxes are confusing--makes it seem like you cannot type anything in there. Maybe reserve gray boxes for text boxes where you must pull up a dialog to be able to enter information
This is only a problem on windows (and maybe linux). I am looking for a fix.
Container summary - how would you enter "1.3 linear ft. and 6 oversize volumes" Would you duplicate the 1.3 linear ft. in the container summary or just type "and 6 oversize volumes" (in other words, do these two fields merge?) It is designed that the extent is used for a statement of how much space is occupied by the resource being described and container summary is a list of the number and type of containers occupying that space. Thus, for the question above, let’s assume 6 oversize volumes equals 1 linear foot. The extent statement would be 2.3 linear feet and the container summary could be 1 records carton, 1 archives box, and 6 oversize volumes.
When you are entering a component description record, it is misleading to have the buttons on the bottom. When I am finished writing a component, I want to click okay and go to the next one, but I get pushed out of the entire resource. A set of buttons for each component might be useful
Are the "next" "previous" buttons actually useful? I think it just adds more clutter. Someone looking for something is more likely to exit out of a record and look for it on the main screen
If I accidentally create a sibling/child and then want to delete it, it still prompts me for the required elements and will not let me continue unless I exit out of the entire resource record
See above
The Bentley creates separate MARC records for visual materials and mixed materials (ie. access points and scope/content different while admin history/bio usually remains the same)--how will the toolkit handle this--would you be able to export a MARC XML record on the series level? MARC export in V. 1.0 is designed to be supported only at the resource level and not at any component level.
Managing locations takes a long time to load
One problem I had was with the multi-part note. Since I had several preliminary descriptions hat I wanted to work later on, but the moment I checked the multi-part box - all information from the note field was gone and I had to re-type it into 'text' part. If I understand correctly, this identifies an interesting problem, that of transforming a note to a multi-part note. How might that be done without requiring entering the data again?
If you uncheck the box the info will still be there and you can copy and paste.
1. The extent field, using linear or cubic feet, is mandatory. However, this type of a measurement is not acceptable for single item collections, such as a diary or a folder. Not acceptable in what respects? Certainly a diary can be expressed as occupying a segment of a foot. The point of the extent statement is also to allow for a cumulative statement for a repository’s entire collection. Thus a diary might be expressed as. .25 linear feet and the container summary might be 1 diary. If exent allows for expressions such as 1 diary, 1 volume, 1 sheet, then cumulative extent is not possible.
2. Is there any way to have extent fields added for other types of mixed materials? Right now, the only place to list tapes, video, oversize, etc. in the container field. We would have no way of generating reports later of how many tapes there are, or oversize things there are, in a collection. The question of how many things of a type can probably be handled by the instance record.
3. I remain confused about how to add names to records. When I'm in a description record, at the collection level, should I add Jane Smith three times as a creator, source, and subject? The “should” speaks to repository policy. The AT enables the name to be linked as a creator, as a source, or as a subject. Some names can utilize all three functions, some won’t. The repository needs to decide what it wants in its output documents.
4. Will the names and subjects added in the collection level record appear in the finding aid as the added entries? If so, will we have any control over their output? In the finding aid, we have a note (just a p tag) at the beginning of the list which describes the added entries. We also separate the added entries into author and subject categories. Names linked as creators will go to the <origination> tag and 1xx / 7xx, while names linked as subjects will go to <controlledaccess> and 6xx. There is no provision for a “head” in the EAD but this could be done post output via a style sheet or manual addition.
not sure if already reported this: in the locations can it sort by number regardless of the number of "places?" E.g., right now it sorts shelf 1 shelf 10, shelf 2, shelf 20, etc. I'd like to see 1,2,3,4,5, before 10.
This would require splitting the field into 2 parts one for the alpha part and one for the numeric.
In resources "tree," icons confusing. The icon for something with sub-levels in it is a folder, otherwise it is a dot. But this is confusing to view, since in some cases <c>s at the same level will have different icons. For example, Agnes Mongan has 3 series--right now there are things described under I and II but not III. So the icons for I and II are folders and IOII is a dot. I am using labels (e.g., "SERIES") in the title, but if I understand AT correctly whaty I should be doing is using the "component unique identifier" for e.g. "SERIES I." So that emans that when I see the tree, I wills ee some things ("Personal and Biogr" and "Corr") with folder icons and others (Writings) with dots when really they are at the same level. This is confusing. And will get more confusing as granularity of description deepens. Can users configure the tree so, e.g. something with "series" in the unique ID always gets a folde ricon, and something with a "subseries" ID gets somethign else? Or maybe color-coded folders or something?