Adding columns-1 as appearance option

[Tyler_Depke]

1. What is the issue? Please be detailed.

Using ODK Collect, I have a select_one question with media (audio/image) and no text in the label column of the answers. I often use no-buttons columns-n as an appearance for many selects questions. In the past I’ve intentionally only used square images because I know this will make the answers display consistently like a gridview in a photo albums app.

For my new scenario, I need images to be very large and fill the entire screen. I also will have horizontal and vertical images. Ideally a horizontal image would have its long side fill the screen horizontally and a vertical image would have its short side fill the screen horizontally. Even with square images, I would like photos to fill the screen entirely, but I’m not seeing this as an option. Based on current options, to me the most logical appearance would be no-buttons columns-1, however, this behaves exactly like no-buttons because columns-1 doesn’t look like it exists. Is there a different appearance that would make this happen?

I’m proposing that columns-1, which according to the docs, doesn’t currently exist as an option, be added as I imagine this would be a quick fix and it would be more consistent with current behavior.

If images were small and didn’t have enough pixels to fill the screen, based on current behavior I would imagine they would show up as left aligned. It would look nicer if they were center aligned but this is a very minor issue and left aligned is more consistent with current behavior.

2. What steps can we take to reproduce this issue?

Create a selects question with images in the choices and no text in the labels. Put the following in the appearance columns:

no-buttons

no-buttons columns-1

Both of these show the same behavior, when I would expect the columns-1 to behave more like columns-2, etc.

no-buttons columns-2 is closest to what I’m looking for but looking for a single column.

3. What have you tried to fix the issue?

See Screenshots below.

4. Upload any forms or screenshots you can share publicly below.

Below is a group of choices that all have square images and the appearance column is shown in the text of the question above the images.

Below is a group of images that are horizontal and vertical and some answers don’t have any images yet.

[Aly_Blenkin]

@Tyler_Depke, have you explored https://docs.getodk.org/form-styling/#big-image? I don’t think that addresses your problem completely, but I’m curious if it helps.

[ahblake]

Big-image isn't able to be combined with no-buttons though is it? But it would be possible with a basic label value that's not too obtrusive i guess

[Tyler_Depke]

Haha, I always debate whether or not I should include certain details in my original description because there are many things that don’t seem relevant, but alas they become relevant. Based on my tests, I’m not convinved that the fact that I’m using a choice filter or multilingual form are issues, but here are those details:

I’m using a multilingual form with audio as well so when a user taps the image with the no-buttons columns-n appearance, the image is selected and the audio plays. This is the behavior that I’d like.

I’m also using a choice filter like this:

selected(username, ${username}) and
level='0' and
(${q3_place0} = '' or selected(places1, ${q3_place0})) and
(${s_task_q} = '' or
selected(${s_task_q}, '24_q4') or
selected(${s_task_q}, '25_q1') or
selected(${s_task_q}, '25_q2') or
selected(${s_task_q}, '25_q3') or
selected(${s_task_q}, '25_q4')
) and
(${s_task_priority} = '' or selected(${s_task_priority}, priority))

which I’m not sure how much that is affecting things but saw that choice filters might break big-image displays in Collect.

I just tried a column like big-image::English (en) but this doesn’t display images in the responses when appearance is blank or with columns-n or with no-buttons columns-n

I’m actually not getting any images to display using big-imagefor any of the tests I’ve done. the docs have this only in the survey sheet, not in the choices sheet, but it sounds like @ahblake has used this extensively for choices, is that right @ahblake? Also, do you know if multilingual forms and/or audio works with big-image ?

I deleted all the multilingual columns from my form for testing purposes and stuck with these three columns. Note there is not actually an image column and ONLY big-image. No images show up. I removed all the choice filters to be sure and get these same results:

label	audio	big-image

So it looks like big-image isn’t being recognized in the choices sheet at all. Again when I changed the column from big-image to just image, below shows the results I’m getting. When I have two identical columns except one header is big-image and the other is image I also get the identical results below, which to me confirms that in my case, big-image in the choices sheet isn’t working at all.

label	audio	big-image	image

label	audio	image

[Tyler_Depke]

I hunted down what I think might be the change that is needed here in the original source code in the AbstractSelectListAdapter.java

line 181 changed from >1 to >=1

Original

noButtonsItem.setUpNoButtonsItem(imageFile, getChoiceText(index), getErrorMsg(imageFile), numColumns > 1);

New

noButtonsItem.setUpNoButtonsItem(imageFile, getChoiceText(index), getErrorMsg(imageFile), numColumns >= 1);

Edit:
I made a Pull request here: https://github.com/getodk/collect/pull/6872

The post below shows screenshots with this code change.

[Tyler_Depke]

Screenshots from tablet after code change (ABOVE)

Screenshots from phone after code change (BELOW)

[ahblake]

@Tyler_Depke

I’m actually not getting any images to display using big-imagefor any of the tests I’ve done. the docs have this only in the survey sheet, not in the choices sheet, but it sounds like @ahblake has used this extensively for choices, is that right @ahblake? Also, do you know if multilingual forms and/or audio works with big-image ?

I have only used big-image for monolingual forms and without audio so far, but I have used it against choices extensively with column type appearances and filtering, including entity lists. With the caveat that you are somehow getting the filenames into your main form to trigger upload. You need an image column to accompany it, can be the same or different file.

While the columns-1 mod seems like it does what you want - have you tried various image widths for your image files, as this will display differently without columns appearance - but it will also vary by device / orientation.

[Tyler_Depke]

Unfortunately, it is VERY rare that I don’t need audio in addition to images, so perhaps that is the problem? I’m always testing with an audio and image column and also multi-lingual.

So, you are saying there are no issues with using image and/or big-image for entity lists and external CSVs without any other media columns using columns-n and a choice filter? I recently learned that external CSV choice lists cannot have multilingual columns (there’s a workaround I think using search() function), which I think is also a limitation for entities, so I wonder if all of these limitations are related.

[ahblake]

@Tyler_Depke

So, you are saying there are no issues with using image and/or big-image for entity lists and external CSVs without any other media columns using columns-n and a choice filter?

I have to recant my earlier statement, I was convinced I had a form working this way, but opened it to check and saw that for simplicity, as I need to include the filenames in the form anyway, the entity list with the filenames is queried into the form and spilled into the choice sheet.... sorry!

I whipped up a very quick form with select from choice/csv/entity, with/without appearance/filters and ... yeah... problems. I'll build out a bunch of permutations as a test form to show what does/doesn't work.

[seadowg]

@Tyler_Depke just wanted to confirm: you’re using images that are smaller than the screen width here right? If so, is there a reason you can’t use bigger images? It looks like to me that images will fill the column if they’re large enough.

no-buttons columns-n seems to also stretch smaller images to fit the column width if they’re smaller, but that might actually be a bug given that doesn’t happen when using just columns-n

[Tyler_Depke]

@seadowg

It looks like to me that images will fill the column if they’re large enough.

Are you only talking about only when using columns-1 no-buttons appearance specifically?

My images tend to be slightly smaller than the screen size of a phone. You can see on the tablet of the screenshots that I put up that some of the images on the tablet in the horizontal position look a little blurry. Some of my images used for this sort of thing are populated from the API of another app and so I'm not looking at the dimensions of each image before I put them in. The two most important things for me in all of this is that the images are large enough to see not just the overall image but that when looking at the image, the user can see where this is specifically AND what is going on/details inside the image, as well as that the user can scroll through a list of about 10-20 large images quickly without needing open other previews/tabs/windows/etc. to view each image.

[seadowg]

@Tyler_Depke

Are you only talking about only when using columns-1 no-buttons appearance specifically?

The default (empty) appearance, no-buttons and columns-n all behave that way: the images are shown “as-is” unless they are bigger than the horizontal space they’re given, and then their scaled down. The only time images are stretched horizontally to fit the space is when using no-buttons and columns-n together. You can see from the docs that neither columns-n or no-buttons are designed to stretch images.

All that said, the value you’re getting from the magic combination of the two appearances is pretty obvious: you’re able to take images that are smaller or of different sizes and show them as a uniformly sized group. My preference would be to introduce a specific appearance for that behaviour and remove it from the no-buttons and columns-n combination, but that could break how a bunch of existing forms are displayed. We also want to make sure that Collect and Web Forms are aligned here so that form designers know what to expect from these appearances.

My images tend to be slightly smaller than the screen size of a phone. You can see on the tablet of the screenshots that I put up that some of the images on the tablet in the horizontal position look a little blurry. Some of my images used for this sort of thing are populated from the API of another app and so I'm not looking at the dimensions of each image before I put them in.

Would a temporary solution for you be to use larger source images or just scale the images up before using them in the form? I know it’s more work and potentially creates larger form sizes, but it’ll get you the layout you want without any updates to Collect.

[Tyler_Depke]

I see what you're saying now, I didn't realize that this magic combination was the only one that was stretching images.

@seadowg

you be to use larger source images or just scale the images up before using them in the form? I know it’s more work and potentially creates larger form sizes, but it’ll get you the layout you want without any updates to Collect.

Unfortunately due to poor internet, larger image size/any data transfer is the exact opposite way I'm wanting to go, but the stretched images are not at all a concern for me since in most cases the stretching will be minimal since the resolution is near the size of the device(s) being used.

Yesterday I was in the field testing stuff and was stuck for a few hours with a very spotty connection and when it was working it was topping out at about 10-20KB/s download speeds. For the past month the best reliable connection "in the office" I have downloads at about 70KB/s and upload speeds are slower.

[ahblake]

This is off topic, but have you experimented with aggressive image compression?

You can drop jpeg quality a long way before the image is unusable, often a higher resolution and lower quality image can be smaller and more useful than a low res high quality.

Try converting to q=20% ish and see how it goes. It will start to posterise but can be surprisingly good

And if you use pngs, try converting to png8 to drop colour depth.

[Tyler_Depke]

For the main thing I was wanting to use this for, my images are being populated/compressed by another app and retreived via an API so I have less control over their sizes/compression.