Request: need notes in scriblio (new work flow)

[paul.n]

To assist in our goal of less material handling, we'll need a good way for the scanner to communicate issues with the physical book to the remote republisher. A good way to do that would be to allow notes to be taken during image loop.

Here's how it could possibly work (Jude's ideas):

   * The notes could be stored in the "notes" field of the meta.xml
   * This is written via modify_xml when a book is finished scanning
   * When a book is opened for republishing, we can display anything in the notes field of the meta.xml

Interface:

   * In scriblio, there's a button that does two things: 1) exposes a text entry box where scanners can store notes 2) let's scribe know to modify the xml.
   * In republisher, the operator sees a pop-up when opening the book, detailing what notes the scanner provided. These notes should also be referenceable later in the session. I think a link from the "more options" menu, as well as the normal display of notes on the checkin-readiness screen, makes sense.

Other thoughts/considerations:

   * The person republishing may need to add more notes or edit existing ones. Any notes made by the republisher probably need to override the existing notes on the site.

[danh (danh-archive)]

paul.n wrote:
> Public bug reported:
>
> To assist in our goal of less material handling, we'll need a good way
> for the scanner to communicate issues with the physical book to the
> remote republisher. A good way to do that would be to allow notes to be
> taken during image loop.
>
> Here's how it could possibly work (Jude's ideas):
>
> * The notes could be stored in the "notes" field of the meta.xml
> * This is written via modify_xml when a book is finished scanning
> * When a book is opened for republishing, we can display anything in the notes field of the meta.xml
>
> Interface:
>
> * In scriblio, there's a button that does two things: 1) exposes a text entry box where scanners can store notes 2) let's scribe know to modify the xml.
> * In republisher, the operator sees a pop-up when opening the book, detailing what notes the scanner provided. These notes should also be referenceable later in the session. I think a link from the "more options" menu, as well as the normal display of notes on the checkin-readiness screen, makes sense.
>
> Other thoughts/considerations:
>
> * The person republishing may need to add more notes or edit existing
> ones. Any notes made by the republisher probably need to override the
> existing notes on the site.
>

Do we need this added to the *_meta.xml?

I think that would make it exposed on the details page.

Could we just store it in a text file in the book directory (and if
we want to preserve it, we could arrange for it to go up with
the orig_jp2 and scandata files)?

Also --- do we need a button in scriblio?

Could we just let the user type in the currently blank
white area to the side?

dan

[paul.n (paul-n)]

I think the idea was just to build off what we already currently do.
Right now, operators have a free form text block for notes in
republisher and those notes do end up in meta.xml, for better or worse.

Now that you mention it, there's probably two classes of notes:

1) patron facing notes
2) internal notes

patron facing notes should probably be broad, predetermined statements,
perhaps chosen from a list.
there was some discussion about plugging in some pre-determined, common,
notes - perhaps a checklist in Republisher. Tom did some work on this...
internal notes should be free form.

the internal notes, like you say, could probably just be saved with the
book directory...
but we still need the patron facing notes. in other words, it looks like
we only have one method of note taking which we're trying to use to
serve two purposes.

----

the idea for the button was to act as a signal to actually run a
modify_xml, otherwise i'm not sure how we'd know to modify it (since you
don't want "notes=(null)" to be run).

----

So I guess it's a question of scope. Maybe we really do want to rebuild
notes once and for all? But the initial request was more to facilitate
the internal communication -- so I think you may be right that just
saving the internal notes in the book directory, and accessing them
somehow in republisher is the best way.
Then, as a separate project, we can fix the patron facing notes.

Paul

On 1/7/11 8:48 AM, danh wrote:
> paul.n wrote:
>> Public bug reported:
>>
>> To assist in our goal of less material handling, we'll need a good way
>> for the scanner to communicate issues with the physical book to the
>> remote republisher. A good way to do that would be to allow notes to be
>> taken during image loop.
>>
>> Here's how it could possibly work (Jude's ideas):
>>
>> * The notes could be stored in the "notes" field of the meta.xml
>> * This is written via modify_xml when a book is finished scanning
>> * When a book is opened for republishing, we can display anything in the notes field of the meta.xml
>>
>> Interface:
>>
>> * In scriblio, there's a button that does two things: 1) exposes a text entry box where scanners can store notes 2) let's scribe know to modify the xml.
>> * In republisher, the operator sees a pop-up when opening the book, detailing what notes the scanner provided. These notes should also be referenceable later in the session. I think a link from the "more options" menu, as well as the normal display of notes on the checkin-readiness screen, makes sense.
>>
>> Other thoughts/considerations:
>>
>> * The person republishing may need to add more notes or edit existing
>> ones. Any notes made by the republisher probably need to override the
>> existing notes on the site.
>>
> Do we need this added to the *_meta.xml?
>
> I think that would make it exposed on the details page.
>
> Could we just store it in a text file in the book directory (and if
> we want to preserve it, we could arrange for it to go up with
> the orig_jp2 and scandata files)?
>
> Also --- do we need a button in scriblio?
>
> Could we just let the user type in the currently blank
> white area to the side?
>
>...

[Hank Bromley (hank-archive)]

Another possibility for "internal" notes is to use a distinct element in meta.xml (other than <notes>), and then not display that element on details pages. We already have a mechanism for skipping display of designated elements. That won't securely hide the information, but it will prevent casual observers from being exposed to it - you'll have to go looking for it (download meta.xml, or view the details page with output=json) in order to see it.

Also, we have some experience with attaching (patron-facing) <notes> from a pre-formed list. The ufilm workflow at one time included that feature (and may still).