support custom data types in drop-down and multiple-choice lists

[josteinaj]

From @ghost on April 13, 2014 0:29

From josteinaj@gmail.com on June 20, 2013 16:02:54

We have discussed custom XSD datatypes, and they are becoming more relevant as we start implementing support for TTS.

The Web UI should be ready for this.

Custom XSD Datatypes: http://code.google.com/p/daisy-pipeline/wiki/ScriptMetadataCleanup#Custom_XSD_Data_Types

Original issue: http://code.google.com/p/daisy-pipeline/issues/detail?id=331

Copied from original issue: daisy/pipeline-issues#331

[josteinaj]

From @bertfrees on February 13, 2015 14:8

see https://github.com/daisy/pipeline-framework/pull/84

[josteinaj]

This issue as well; there are no current script that uses this feature. It would be easier to implement if there was a script that had a default value.

@bertfrees I think I'll wait with this until we have a script that uses this feature.

@usama49 if you have time, maybe we could have a look at adding a typed value to the scripts? (alternatively @bertfrees if you want to do it that's fine as well)

[josteinaj]

see: snaekobbi/issues#19 and snaekobbi/issues#20

[bertfrees]

I had planned to work on this a bit in this sprint but didn't have enough time. I only got to https://github.com/daisy/pipeline-clientlib-java/pull/10. I'll see if I can get a bit further with clientlib-java and then possibly webui and maybe you can pick up again when you're back.

Pipeline v1.9.8 supports datatypes by the way.

[josteinaj]

Ok, cool. Yes, I'll look at it when I get back now that 1.9.8 has support for it.

[josteinaj]

maybe also related: snaekobbi/pipeline-mod-braille#61

[josteinaj]

While the DP2 engine v1.9.8 itself seems to support datatypes, the modules (scripts) themselves which declares and provides the actualy datatypes needs to generate the osgi service declarations for the datatypes based on the XML catalogs so that they are recognized by the DP2 engine. And to do that, they need to have the 1.4-SNAPSHOT version of org.daisy.pipeline.modules.modules-parent released which includes an update to the XSLT that generates the osgi service declarations.

So we should have v1.4 of modules-parent released before we can start using the datatypes. I don't know if releasing modules-parent v1.4 would cause any problems when using other modules build with modules-parent v1.3 simultaneously. If so, we could alternatively declare the osgi service declarations manually while we wait for that to be released (I'm doing that in the nordic epub migrator already for other reasons).

@bertfrees wdyt? release modules-parent or manually declare the osgi service declarations?

[bertfrees]

I have another idea. I was planning to add more custom stuff to braille-modules-parent (e.g. in order to define some resources declared in catalog.xml as braille CSS files so that we can dynamically list the available CSS files in the user interface). So we could simply copy the new stuff from modules-parent to braille-modules-parent for now.

[josteinaj]

Ok, cool.

[josteinaj]

So I just added support for dropdown lists.

For when sequence="true" I've left the string widget as a fallback since I'm not sure how best to render a "sequence of enums" input widget. In the title of this issue a "multiple-choice list" is mentioned, but I'm not sure how best to implement that. If we don't see a big need for such a widget maybe it's safe to close this issue?

[bertfrees]

sequence="true" how is that possible for options? I'm sorry I think I may have asked before but I forgot.

I can think of a way to render a "sequence of enums" widget, however I can't immediately think of a use case, so you shouldn't bother.

I don't know what we meant with a multiple-choice list. Maybe a list of radio buttons? In that case it would just be an equivalent for a drop-down list.

[josteinaj]

We support sequence options in DP2 mainly so that we can provide a list of non-XML files as input to scripts. DP2 sends them to the script as a space separated list. I think you can change the separator character by setting the px:separator attribute on p:option (no consequence for the web api clients, happens internally when dp2 serializes the option values for use by the script).

Yeah I can think of ways to render it as well, I'm just not sure if they are good ways. You could for instance have a add/remove button which repeats the widget so you can select multiple values. Or you can render the <select> as a list instead of a dropdown so that you can select multiple values by holding down CTRL, but I'm not convinced that it's a good thing usability-wise. We could do something similar to the sequence input file widget, but I don't really like that widget either.

Yeah, radio buttons. We could use radio buttons instead of a drop-down, I wasn't sure what was best. Hmm, maybe it could be radio buttons for non-sequence, and checkboxes for sequence? Do you think we would encounter enums with like 100+ possible values? That would probably not look nice, but I suppose enums typically have less than 10 possible values?

[bertfrees]

I just wouldn't support sequences for now (except for files), but if you want to support it I would do something generic, like a button for repeating the widget. Check boxes instead of radio buttons when something is a sequence is specific to enumerations so you won't be able to use it for anything else, and also it doesn't support ordering.

Radio buttons can indeed be a bit more user friendly than a drop-down list, but only if the number of values is limited. Maybe use radio buttons for up to 3 or 4 possible values, drop-down lists for anything above that?

[bertfrees]

Windows guidelines: https://msdn.microsoft.com/en-us/library/windows/desktop/dn742436.aspx: radio buttons for 2-7 values

[josteinaj]

Interesting, thanks for the link. Very interesting and concrete guidelines there.

I googled Googles guidelines and they don't suggest a number on it but rather states:

• Use radio buttons [...] if you think that the user needs to see all available options side-by-side.
• Otherwise, consider a dropdown, which uses less space than displaying all options.

The Windows guidelines you linked also has some other more or less fuzzy notes in addition the the "hard" 2-7 suggestion:

• Use radio buttons on wizard pages to make the alternatives clear, even if a check box is otherwise acceptable.
• Use radio buttons if you have enough screen space and the options are important enough to be a good use of that screen space. Otherwise, use a check box or drop-down list.
• Use a check box if there other check boxes on the page.
• Consider a drop-down list if there are other drop-down lists on the page.

I think I would avoid the "2-7" rule simply because the form is dynamically generated, and whether it should be a radio button or a dropdown depends on whether there are other radio buttons and dropdowns in the form. If some options are radio buttons and some options are dropdowns it might be appear a bit inconsistent.

I'm leaning towards simply always using radio buttons for enums because that makes it simple to add descriptions (as we're discussing in daisy/pipeline-mod-braille#72).

[bertfrees]

OK let's try that, we can always go back to drop-down lists for some options later if it takes too much space.