Hide the card's payload

[djechelon]

In a screenshot I attached for PR #427 you can see a green pass. It is a QR code made by a looooooooooooooooooooong code.

I'd prefer to display the QR code as widest as possible, and nobody really cares about what's written in it if it's small to scan.

In the screenshot, you can see the pass doesn't take full screen width, which should be prioritary for this kind of applications.

Supermarkets barcodes are short enough to be displayed on full width on any screen

[djechelon]

[TheLastProject]

The barcode isn't pushed up due to the text, it is just set to use up about 50% of the screen: https://github.com/TheLastProject/Catima/blob/e3bec085df5fd65e935c58617eb5fd2749b96e86/app/src/main/res/layout/loyalty_card_view_layout.xml#L37

Though I suppose QR codes, being more square, should use different logic indeed.

[TheLastProject]

Hmm, actually, I'm not certain how to properly solve this. I disagree with hiding the payload by default though.

[djechelon]

Or...... give the payload less visibility?
Hide by default and make it appear on ellipsis?

Think about it as a user.
I don't think you normally own more than 1 card per shop.
If you use Catima to hold cards for yourself and children, you may want to label them differently "Card Alice", "Card Bob".

And for the case of eu green pass, the payload is long enough to be......... useless for daily use?

What do you exactly disagree about hiding the payload? Can I learn more about your opinion?

Thanks.

[TheLastProject]

In most situations showing the payload is very useful. I've had several cases where I was at stores and the scanner of the person at the counter was failing and they went "Let me just type it manually". If we hide the payload, we break this surprisingly common thing.

In this specific case the payload is too long to be useful, but it doesn't get more space because it is more text, the font is just made smaller.

Many barcode types actually become harder to scan if you make them too big, QR codes are the rare exception.

Maybe editing #428 (comment) to use 0.75 or so if the code type is square (like QR codes are) but... that means adding additional inconsistency.

QR codes need some tweaking anyway (see #329 (comment)) because there is too much white space around it.

So, I'm having trouble seeing any improvement without downsides.

[djechelon]

Nope, sometimes I type faster than my brain.

From a design point of view, each code type has its own characteristics and size requirements. Now, I don't recall all, but for best readability it could be useful to use all available width (constraint 1).

Barcodes, if I recall correctly, can be stretched, QR codes require to be square (constraint 2), so they must use less width if not enough height is available: consider screen rotation and different screen sizes.

My idea was to define different sizing logic for each kind of code

[djechelon]

Ok we are writing simultaneously. I agree with you. If your code is like my lottery code ZGQ3425V it's enough to type it manually.

Some stores, in fact, are still equipped with laser barcode readers that do not support LCD/LED screens. Modern supermarkets in my area employ camera readers.

Your statement is correct, we also agree that if the payload is too long it's not that useful

Many barcode types actually become harder to scan if you make them too big, QR codes are the rare exception.

Hmm, yea, that's the vertical bar codes. I find it frustrating to scan big codes with the supermarket self-scanner. These codes need another constraint: absolute (centimetres) max size perhaps? I mean if you install Catima on a 10inches tablet (who wants to show this to the checkout?) you're struck again.

That is the part I sometimes hate with Android layout system

[tbertels]

Catima vs Stocard:

Catima

Stocard

Clearly, the text could be smaller for QR codes while still being very legible.

[TheLastProject]

Okay, that comparison makes a very good point! Thank you @tbertels.

So I guess the best way would be to use layout_constraintGuide_percent 0.5 for barcodes and layout_constraintGuide_percent 0.75 or so for square codes.

Seems like something a beginner can pick up :)

[ankittiwari101]

Hii..I am interested in taking up this issue.

Could you quickly get me upto speed on what needs to be done and Activity(s) where I should focus??

[TheLastProject]

I think all we need is for https://github.com/TheLastProject/Catima/blob/e3bec085df5fd65e935c58617eb5fd2749b96e86/app/src/main/res/layout/loyalty_card_view_layout.xml#L37 to be 0.75 for square ("2D") barcodes, but 0.5 for regular barcodes.

So, somewhere we should store which barcode types this affects. I think the CatimaBarcode class makes most sense to add that to. Maybe adding a new "isSquare" function that returns true for square barcodes (like QR codes) but false for non-square ones (like EAN-8) and then base the size of layout_constraintGuide_percent in LoyaltyCardViewActivity on that.

May need some tweaking to find the perfect values, so if you don't feel 0.75 is correct please add screenshots to show why another number would be better :)