Create MVP wireframes

[slifty]

We should create a set of wireframes to ensure alignment on MVP functionality. The high level functionality is as follows:

MVP Android application that allows the user to:

• Register a new “book” to scan.
• Edit book metadata (e.g. title, author, ISBN, etc).
• Take a picture of book pages in sequential order and run OCR on that page. This process
  will likely require page de-warping in order to ensure OCR accuracy.
• Export both a text-based PDF and a Unicode text file of the book pages to the Android
  documents (or export through another similarly convenient means).
• Re-start a previously started book scan that has not yet completed.

This MVP does NOT allow the user to:

• Scan multiple books in parallel (e.g. start scanning one book and stop part way).
• Manually edit the text of an OCR’d page book.
• View a history of their book scans.
• Upload scanned books to third party services directly.

The final wireframes should be stored in the repository in a docs/ directory

[slifty]

Here is a first stab at some wireframes. This goes a little beyond the MVP specification by including a carousel that shows pages that have been scanned so far, rendering their scan status, and allowing the user to delete pages.

I would consider that functionality almost-critical-but-technically-not-MVP. The goal would be to create everything EXCEPT the carousel (and delete) features first, adding the carousel in the second iteration.

Nevertheless, feedback on all of the above is welcome.
BookLiberator20200203v1.pdf

[kfogel]

Dan this is great, thank you. The carousel idea is perfect -- I would never have thought of it, but now I can't imagine it any other way.

Feedback / thoughts / questions:

• p2: "Scan" instead of "Take Picture" (I toyed with "Liberate", but, really, let's not be too cute)

• p3: "Redo" or "Rescan" instead of "Delete"? (Assuming I'm interpreting the meaning correctly... The idea is that any page can be rescanned, right? And that the decision to rescan a given page can be made at any time -- i.e., even if you're many pages ahead by then, you could go back and redo a page?)

• p4: Obviously we'll want more fields, but these three look good to start with.

• p5: When we ask "Did it look good?", we're referring to the export, right? In other words, there's an implied other screen between p4 and p5, in which someone looks at the resultant PDF or text export and evaluates it, and then goes to p5?

[slifty]

Thank you for the feedback! Regarding specific words we can easily tweak that kind of wording even after implementation as well.

"Redo" or "Rescan" instead of "Delete"?

Great feedback because that implies different functionality than delete. I think that is a fine idea. I will similarly plan to implement that as a "round 2" feature.

p4: Obviously we'll want more fields, but these three look good to start with.

For sure; what is the path to identifying all of the fields we want? Happy to have that be an issue that gets opened after MVP as well, just don't want to lose the concept.

p5: When we ask "Did it look good?", we're referring to the export, right?

Yes, however according to these wireframes that validation would occur outside of the app (e.g. there would not be a screen between p4 and p5, but rather the user would be instructed to manually check the exported files). <-- this is a more clunky user flow, but appropriate for an MVP since the user is still able to perform the task of validation.

On another note: one concern I have with these wireframes is the challenge of reordering pages. Delete was a way to get rid of an out of place page (we may still want to allow for deleting IN ADDITION to redo / rescan). I imagine we may eventually want the ability to "insert" as well as the ability to "move" a page some day, to account for the use case where a user accidentally skipped a page and didn't realize until the end of the book scan process.

I would like to add that concept of re-ordering as another post-MVP feature (no point in adding code for re-ordering until after we can do a scan to begin with!)

I'll do another iteration of the wireframes now with all of this in mind!

[kfogel]

Everything you say above sounds good to me. For MVP, I'll try to focus on feedback that represents a substantive change of direction, not things like wording or whatnot that can easily be tweaked at any time. Agreed re re-ordering/inserting being important but also post-MVP.