Disable choosing an image, video or audio

What is the general goal of the feature?
Optionally prevent from selecting an existing image, audio or video file to answer a question.

What are some example use cases for this feature?
To discourage fabrication of results where this may be an issue.

What can you contribute to making this feature a reality?
I can contribute code.

Fantastic!

For image and video types, we recently had a discussion about the appearance names and came to some agreement here on the appearance name camera. @Snvssh4a2017 you were asking about this recently, does adding an appearance named camera that means the "choose" button isn't shown work for you? If that works for both of you then I think it's ready to implement.

For audio, we need to agree on an appearance name. I think by analogy recorder might make sense?

Ok. What about an appearance that represents a facet of camera, video, audio. Ie "nochoose", or "newonly".

This kind of conversation should happen here on the forum moving forward but we're still getting used to it so it started on GitHub. You'll see that the additional requirement for specifying a particular camera with no chooser (front or rear) led to the triplet camera, camera-front and camera-rear. We weren't considering audio at the time.

no-choose/no-picker is probably not ideal because clients can offer users the opportunity to choose/pick an photo app so that becomes confusing. Note also that enumerators who have permissions to install apps to their devices could use that feature to cheat so it's important to lock that down as well.

Perhaps new could work for all media and new-front and new-rear for pictures/video? Ah naming, the hardest problem in computer science! :laughing:

Are we now considering all of the widgets or data types that this could apply to? I think whatever we pick for visual media should combine with the annotate appearance.

@martijnr @Grzesiek2010 @Snvssh4a2017 what do you think?

Edit: removed only from names because @yanokwa is right that we already came up with some compelling reasons not to use the word.

If we are trying to protect against fabrication, we have to own that capture pipeline. We can't rely on external apps to capture audio, video, and pictures and ask implementers to lock down their devices.

I like camera and microphone and camcorder. Or whatever people call them in HTML5 land. I could also go for capture-{audio, video, image} or new-{picture, sound, video}.

Looks like I confused things. Since this is an appearance on an existing data type, all we need is a modifier. In that case, new (and new-front/rear) seems reasonable. Sounds like dropping the "only" was also mentioned on the GH issue.

As far as owning the pipeline, that's likely out of scope for this particular feature (but I think we should do it!)

I know this is a large and ongoing conversation, but is there any way we can imagine doing this without growing appearance yet further? At the very least, we should carefully define must/should/may/must not specs for these things, as far as appearance overlaps with behaviour and in many cases with semantics.

As I understand it, appearance is taken to be an entirely optional client hint. But as the list of appearance-based features grows, there grows a greater reliance upon matrices like the xlsform reftable to verify what works where and why. Certainly for anybody relying upon this appearance feature, it would seem to them to be a behavioural requirement.

@yanokwa. I agree I would have thought modifiers are the way to go. If we just had an appearance of "new" then that could be defined as preventing selection of previously collected data. That could then be combined with front/rear/audio/video etc.

I noticed a while back that there were quite a few places in the widgets code where it uses .equals() to check for an appearance. Given that it is reasonable to have more than one appearance then these should probably be replaced with .contains().

@issa I'm not sure if I really get the issue you are raising with growing appearance however supporting a minimal set of values which can be combined seems reasonable to me. Any that are not relevant to a widget would just be ignored. So the set for media could be:

image
video
audio
front
back (default)
new
existing
annotate

1 Like

I think it's a good set.

@issa I totally understand where you're coming from and agree that we should be really mindful of when appearances are and aren't appropriate. In this case, I don't see any great alternatives. For any of these media types, the type declared on the bind is binary. The control they use is all upload and it's a combination of mediatype and appearance that determines how they are displayed to the user. Given this existing setup, do you see any good alternatives?

I agree that we have to communicate much more clearly what appearances are and how they are treated by clients (Collect, Enketo, etc). We could say something like "Unknown appearances are ignored and the expected kind of data is still captured. If a certain appearance is important for your data collection, you should make sure that it is supported by all of the versions of ODK Collect or other clients that you use." We should also document the versions at which different appearances started being supported.

@Neil_Penman, you are absolutely correct about Collect being inconsistent in how it identifies appearances. That's something we should rectify for consistency. I don't think it has any effect on behavior currently, though.

I don't quite understand the list of appearances you have included. Currently, audio and video do not support any appearances. images by default can be picked from a camera app (either front or back camera) or the file system. They additionally support these appearances:

  • annotate
  • draw
  • signature

We need to introduce the following appearances:

  • hides the button to choose pictures but lets users take pictures from either camera
  • hides the button to choose videos but lets users take video from either camera
  • hides the button to choose audio
  • hides the button to choose pictures and only lets the user use the front camera
  • hides the button to choose pictures and only lets the user use the rear camera

Ideally this could be addressed with three new appearances since the first three in the list above are the same applied to different mediatypes.

1 Like

@LN Can we begin to consider a more rigorous standards-ratification process which culminates in extension properties being added to the orx: XML namespace? (Or if that's infeasible politically, a new odk: namespace.)

Cool. When we have an agreed an agreed approach. I will review the code
to see if it can be made to fit.

1 Like

I started a conversation here about spec change processes. I think the important thing is to start having conversations in one place because they're a bit scattered at the moment.

@issa, that post links to some conversations about namespacing but I don't think they say anything explicit about appearances. Appearances can be client-specific and are passed through by some form generators like pyxform (though not Build). There was some conversation about it and the conclusion was that they're loose by nature and that exposing namespaces to users would add some complexity without clear benefit.

@Neil_Penman annoying to be blocked on this, I know! Imprecise or ill-considered naming has been a problem in the past and I imagine there will be more decisions like this to be made so it's probably best to take a little time to make sure all the right voices are heard before a decision is made.

No problem. As long as the final decision on naming is implemented via one
or more settings in appearance then the code is ready to go. Otherwise I
will reassess the approach.

1 Like

The idea was to prevent a user from using previous data collected while proceeding to collect new data, in such a case the proposal is only to hide the choose button and let the user capture images or videos with either front or rear camera, then the case for audio the user is let to record at that particular time. @Neil_Penman

You can use an appearance of "nochoose" in fieldTask with a Smap server to hide the choose button for image, video and audio. If this is critical for you and you can't wait for the collect implementation you can register to use Smap at https://sg.smap.com.au

Hi Neil
Any updates on this?

Thank you,
Andrea

Hi Andrea,

Not that I have heard. I presume it is still being discussed as a potential update to the xforms spec. @LN may know the status.

regards

Neil

Indeed. Making progress on proposed spec changes and specifically these appearance names was discussed briefly in the last @TAB call.

The latest proposal is to add the following appearances:

new
Combines with image, audio or video types to require that the media be captured rather than selected from previously captured files. For example, in Collect, the "Choose Image", "Choose Sound", "Choose Video" buttons would be removed. Can combine with image appearance annotate.

new-front
Combines with the image type to require that the image be captured from the front-facing camera. Can combine with image appearance annotate.

new-rear
Combines with the image type to require that the image be captured from the rear-facing camera. Can combine with image appearance annotate.

To move forward with these we should get approval from a few organizations and no binding -1 votes (from TSC or PMC members).

2 Likes

Thank you Hélène for the update!