Standardising CQS followup functionality

[krisgesling]

Is your feature request related to a problem? Please describe. Whilst adding GUI's to each of the default CQS enabled Skills it became very clear that they each have slightly different functionality and follow up abilities.

Most users don't know they are talking to the Wikipedia Skill or DuckDuckGo Skill - they are asking Mycroft a question.

Describe the solution you'd like To provide a consistent and intuitive experience we should try to provide a consistent feature set when asking general questions.

• Wikipedia supports request for more information by voice as it has a whole article it can read from.
• Wolfram supports emailing the user the information source.
• DuckDuckGo and Wikipedia both have methods for disambiguation but it's not consistent and needs review.

If a specific Skill cannot support some function for whatever reason, it should at least say that. The current behaviour is that it just won't trigger anything eg:

• "Hey Mycroft, who is the president of the united states?"
• Wikipedia answers
• "Hey Mycroft, tell me more"
• Wikipedia Skill reads more
• "Hey Mycroft, who is the current president?"
• Wolfram answers
• "Hey Mycroft, tell me more"
• No intent is triggered - likely falls back to unknown

Questions

• Should these be baked into the Common Query Framework in some way? eg default methods that report they don't have any more info which can be overridden by each Skill to return actual new info.
• Should a short answer from Wolfram follow up with more detail from Wikipedia?

[krisgesling]

Relevant comments from Jarbas in Chat:

i wouldnt bake them into the framework

i use this in regular intents, no reason to be framework exclusive in all my skills where i do it i take advantage of adapt context, if there is no more info i remove it and "tell me more" triggers nothing at all. if baked into the framework i lose this kind of control the implementation is very skill specific, in many skills it wont make sense, in every skill it will have something different, ie, it might need several api calls, forcing this into the framework might also force a lot of stuff to be done at "the wrong time". where wrong means doing stuff at search step without skill being selected, or doing it after selection and introducing unneeded latency, or even spaghettifying code to force a one liner to be async with events

obviously will depend on the final implementation, none of these are actual barriers, just considerations