Open jrmerz opened 5 years ago
jrmerz
commented
5 years ago The one item that we also discussed was the Genre of the item. This is something that is currently not included in the overview, eg. We have previously had a discussion about this:
https://github.com/UCDavisLibrary/dams/issues/29
Where I suggested that we might use prodocutontology as a method for identifing the Genre of an item. This covers a big swath, maybe too big.
wrenaria
commented
5 years ago Here's what I am currently thinking for the DAMS item editing interface. Passing this off to @EricNebeker to investigate implementation requirements to make it work.
When users are logged in, there will be an edit icon (pencil) next to the "Item Data" section title. Anything adminy like this in the interface will use a teal color (#008EAA) to differentiate it from normal DAMS functions.
Clicking the edit icon switches the applicable fields into editing view. The teal color carries over here -- Any labels for items that are editable are denoted in teal, changing the content display either to open fields used for freeform text input, or fixed boxes containing any items that involve controlled vocabulary (creator, publisher, subject) coupled with typeahead searching.
Since some markup is allowed in Description field, I'd like this to link to a pop-up or page about what is allowed. I don't actually know what is allowed, so I haven't created that piece yet.
For subject, since we only accept fixed vocabulary, if a search returns no results, we just suggest trying again.
For Publisher and Creator, we use both fixed taxonomy and custom entry. Typeahead shows a few possible matches, but also offers custom entry. If possible, give highest relevance priority to names already associated with collections first to help speed up entry across multiple items / promote consistency within a given collection.
Since we're using a mix of linked and custom data, it's not clear to me how this information is managed on the backend. Once that is figured out, I can design screens for inputting or managing custom entries.
Any questions, concerns, whatever else, just let me know!
EricNebeker
commented
5 years ago @jrmerz @wrenaria This a tool for selecting FASTIDs with auto-suggest. It could potentially be integrated into the interface. http://experimental.worldcat.org/fast/assignfast/
EricNebeker
commented
5 years ago @jrmerz @wrenaria We should consider making Date, Title, and Description editable as well. In addition, if a field is not already present in the metadata (for example, no creator is listed) can that field be added?
EricNebeker
commented
5 years ago @jrmerz @wrenaria Can you give me a little more detail on what information you need from me for this?
wrenaria
commented
5 years ago @jrmerz @wrenaria We should consider making Date, Title, and Description editable as well. In addition, if a field is not already present in the metadata (for example, no creator is listed) can that field be added?
Originally when I mocked up DAMS, I had those things included in item data as well as in the blue section (sort of an at a glance info for casual viewer vs in depth info for power user). That didn't seem to translate over when it reached coding phase. I'm all for making it happen now.
Mock-up example from the past:
As far as fields not already filled in, is there a fixed number of field options possible or are they more organic depending on need? If the type of fields available are fixed, then I say they should become visible when you enter editing mode but outside of editing mode are hidden from the viewer. The order of field placement should remain standardized as well to create consistency/avoid confusing when editing the form.
EricNebeker
commented
5 years ago I have no objection to these suggestions. I think we can come up with a pretty comprehensive list of fields that should be editable in the UI.
From: Kimmy H notifications@github.com Reply-To: UCDavisLibrary/fin-server reply@reply.github.com Date: Wednesday, May 1, 2019 at 3:12 PM To: UCDavisLibrary/fin-server fin-server@noreply.github.com Cc: Eric A Nebeker eanebeker@ucdavis.edu, Assign assign@noreply.github.com Subject: Re: [UCDavisLibrary/fin-server] Record Metadata Editor - UI (#121)
@jrmerzhttps://github.com/jrmerz @wrenariahttps://github.com/wrenaria We should consider making Date, Title, and Description editable as well. In addition, if a field is not already present in the metadata (for example, no creator is listed) can that field be added?
Originally when I mocked up DAMS, I had those things included in item data as well as in the blue section (sort of an at a glance info for casual viewer vs in depth info for power user). That didn't seem to translate over when it reached coding phase. I'm all for making it happen now.
Mock-up example from the past: [Image removed by sender. DAMS-Item View]https://user-images.githubusercontent.com/17831969/57045476-8c4c2880-6c22-11e9-9fc5-8d2e69eccaf5.jpg
As far as fields not already filled in, is there a fixed number of field options possible or are they more organic depending on need? If the type of fields available are fixed, then I say they should become visible when you enter editing mode but outside of editing mode are hidden from the viewer. The order of field placement should remain standardized as well to create consistency/avoid confusing when editing the form.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/UCDavisLibrary/fin-server/issues/121#issuecomment-488455069, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIL4DMGZZLDV3Z5RTRKC5N3PTIISNANCNFSM4GSHPTAQ.
NeilWeingarten
commented
3 years ago Assigned wont fix label - may reopen if 3rd party shows interest, or if future OS work shows a needs for this.
We would like admins to be able to edit a records metadata from the fin client. The backend still needs to be flushed out and will be a bit complicated. To get the ball rolling we are going to design the front end UI for the following properties:
Metadata Properties