jthrilly
commented
6 years ago external data is always local?
No, external data can be remote but this will be handled by a loader of some kind that will fetch the data and return once it is available. For now we can assume it will be local (embedded in the protocol file).
What is “filter” in the protocol?
I think I included filter by mistake, as we don’t have this functionality at present. It was on the roadmap, but has been dropped for now. I've removed it.
fuzzy search: preference for library or not?
No preference here. The only requirement is that this cannot be a web service, since we need the app to be able to function offline.
- if not, algorithm requirements?
I don’t have a good technical answer for this, just a “common sense” one. We want to be able to fudge the matching, so that things like the presence or absence of spaces, or minor miss-spellings still provide matches.
“fuzziness” setting:
Again, I did not have a technical specification in mind when thinking about this. Perhaps it could be a binary value so it is either enabled or not, with whatever we think is the best fuzzy matching functionality included
Field to Display?
- need new config opt.?
- ...Or use first match prop? Or show all matching props in a line...?This is a tricky question. The “variable registry” is supposed to define the display variable to be used when rendering a node of a given type. However, this external data doesn’t contain a node type, and nor does the main component configuration specify a global node type, since each prompt can theoretically import and create nodes of different types. I think we will need a couple of new configuration options.
At the prompt level, let's bring in a creates property, with a string value equal to the node type that will be created. We can assume that this node type is defined in the variable registry.
Then let's introduce two other properties:
displayLabel, allowing the user to specify the node property to be used as the primary label.- and
displayProperties, an array of other properties to be printed in the auto complete results.
For example:
let prompt = {
"id": "7cl",
"creates": "friend",
"displayLabel": "nickname",
"displayProperties": ["first_name", "last_name", "school_year"],
"text": "Which classmates would you also think of as friends?",
"additionalAttributes": { // Added to the node object when it is added to the main interview network
"special_category": 46,
"close_friend": true
},
"dataSource": "schoolPupils", // Key corresponding to external data section of the protocol file.
"autoCompleteOptions": { // Configurable per prompt, but with sane defaults TBD.
"fuzzyness": 5, // Can we control the level of fuzzy matching?
"matchProperties": ['nickname', 'name'], // Properties to apply matching to
"sortOrder": {
"nickname": "DESC"
},
}
}
If those options are not provided, we dan default to using the first property that isn't called ID, and the next three properties.
sortOrder:
- Should be an array for defined behavior
- I would expect “best first” rather than defined sort?
- example: type “mar...” => “lamar” comes before “marco”.
- Is optional?
Yes, I think you are absolutely right. Let's leave this out. It applies more to Rebeccas interface.
TODO: research best way to customize the UI of a redux form field...
Speak with Steve about this.
internationalization / unicode? We will need to support UTF-8 character entry, yes.
browser/device support requirements? Requirements are the same as for the software in general. Namely, touch optimized but supporting keyboard and mouse. Windows and Mac (using Electron), iOS and Android (using Cordova). Two aspect ratios (4:3 and 21:9). Refer to the mockups to see examples of how the interfaces will adapt.
bryfox
Purpose
There are situations where we want to limit the scope of new node creation to a predefined list. This is typically the case when when we know the boundaries of the network we are interested in, as for example in a classroom, or organizational setting.
Depending on the number of nodes the user is able to choose between, different interfaces are appropriate.
The autocomplete interface is designed for situations where there are too many possible nodes to display either in a side panel, or a node list.
It is important to remember that nodes might not always represent "people". They could represent other actors, such as places, or even medical conditions.
Functionality
This interface should:
Configuration
Sample Data
https://gist.github.com/jthrilly/3c44635576d423d58710b4b3c72542b2
UI Mockups
Incoming.
Sub-tasks