Easy interface to bulk add labels to a set of pages

[tpendragon]

No description provided.

[jpstroop]

My understanding (avoiding Gherkin):

• pages are generally numbered 1 - n (n = number of pages) OR
• leaves are foliated 1a - nb OR 1r - nv (n = number of leaves, r = recto, v = verso)
• sometimes the front of a leaf is not qualified (e.g. 1, 1r)
• front and end matter might be numbered with Roman numerals (i, ii...) or labeled as "[fly leaf i]" etc.
• supplied or corrected numbers should be bracketed

It would be helpful to be able to choose:

• a pattern based on the variables above:
  • unit label ("p.", "f.", "fly leaf")
  • a start number (n)
  • a method ("paginate" or "foliate")
  • a numeral system ("Arabic", "Roman") Can guess this.
  • a front-side qualifier if foliating (e.g. "r", "a", "obverse", null, whatever)
  • a back-side qualifier if foliating (e.g. "v", "b", "reverse", whatever)
  • an option to bracket the label or not ("[1a]", "[1b]")
• a start image
• an end image

and say "Go!"

At which point the label form box for each image would be filled in, counting up appropriately:

unit_label="" start_number=1 method="paginate" front_side_qualifier="" back_side_qualifier="" bracket=false	unit_label="" start_number=1 method="foliate" front_side_qualifier="a" back_side_qualifier="b" bracket=false	unit_label="f. " start_number=1 method="foliate" front_side_qualifier="" back_side_qualifier="v" bracket=false	unit_label="" start_number="i" method="paginate front_side_qualifier="" back_side_qualifier="" bracket=true
1	1a	f. 1	[i]
2	1b	f. 1v	[ii]
3	2a	f. 2	[iii]
4	2b	f. 2v	[iv]

There are always going to be exceptions - repeated or missing folio numbers, labeled plates, alternate versions of images, etc., and being able to stop, start, and override by typing in the form box, will be necessary.

[jpstroop]

@joycebcat, see above. Thoughts?

[jpstroop]

Relevant conversation from Slack:

tpendragon [3:31 PM]
This feels like proper complicated business logic.

jpstroop [3:32 PM]
It convinces me that reordering, paging, and structural MD should be separate interfaces

tpendragon [3:32 PM]
Can this bulk edit interface not handle exceptions, and we say “if there’s an exception, fix it in the reorder interface”?

escowles [3:33 PM]
i wonder if we know how common various permutations are -- e.g., what % could be handled by just [1,2,..., N] and [1r, 1v, ...Nv] or whatever?

jpstroop [3:34 PM]
The problems generally surface w/ covers and front matter

jpstroop [3:34 PM]
looks in the PUDL..

escowles [3:35 PM]
i'm thinking of about five different UIs for this and wondering how many patterns we need to support

escowles [3:35 PM]
or maybe you could just enter the first one or two page numbers, and then click a button at the end of the pages you wanted to auto-number and it would auto-guess the pattern and auto-number through that page?

jpstroop [3:36 PM]
that’s definitely more spreadsheet like

escowles [3:37 PM]
and is that good? i know a lot of people who love their spreadsheets

jpstroop [3:38 PM]
It might be…but it feels like it could become a pretty complicated UI

escowles [3:38 PM]
guessing the pattern could get messy for sure

jpstroop [3:40 PM]
I was thinking that each image gets a number that is just its index position in the DOM, and then there’s a form (maybe it’s statically positioned in the left margin?) that lets the user basically fill out the stuff mentioned in the issue.

tpendragon [3:41 PM]
That was my thought too.

tpendragon [3:42 PM]
Just a simple form that provides more options if you need it (IE - “front side qualifier” shows up if necessary)

escowles [3:44 PM]
and then you select and end page somehow?

jpstroop [3:44 PM]
you’d use the index # from the DOM

tpendragon [3:44 PM]
Ehh

jpstroop [3:44 PM]
no?

tpendragon [3:44 PM]
There should probably be some sort of click/drag interface at some point.

tpendragon [3:44 PM]
But maybe the index # is good as a starting point.

jpstroop [3:44 PM]
oh, that might be cool

escowles [3:45 PM]
click/drag seems like it would be nice

jpstroop [3:45 PM]
I was thinking the static positioning of the form would solve that

jpstroop [3:45 PM]
brings the form to the image, rather than the image to the form

escowles [3:54 PM]
yes, it seems pretty reasonable -- there's a million options for the UI, but the basic numbering functionality is well spelled out

[jpstroop]

It looks like ec6 has generators. This seems like a perfect application.

[jpstroop]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*

[jpstroop]

Implementation: https://github.com/jpstroop/page_label_generator

[joycebcat]

@jpstroop Yes, this idea of choosing a start image and end image, choosing a pattern and saying "go" would be great. With the ability to manually override by overtyping a value, it would cover most things quite well. Really nasty things might end up being almost all manual override. If we have roman numerals, 1,2,3... and 1r,1v,2r... that would cover the majority of objects.

[jpstroop]

@joycebcat thanks! I spent a little time on the algorithm over the weekend, and this seems possible. We also had a chat about it late last week (look in the #plum channel on Slack, or see the bit I cut and pasted above), and have a few ideas around what the interface might look like. Do you have any strong opinions or see something in your mind's eye that we should consider? No worries if you don't or don't have time; we can just mock something up and go from there.

[joycebcat]

@jpstroop Would be happy to look at what the interface might look like, but don't see anything in the above that looks like an interface.

[jpstroop]

Sorry I was just referring to this discussion, no mockups yet.

[joycebcat]

@jpstroop Oh, yeah. That is sounding OK. We can work reasonably well within a range of possibilities, the key factor is being able in some fashion to auto-populate based on a pattern.