USSD isn't available everywhere, so we need an SMS-only interface as well.
General design
The SMS-only flow will use three shortcodes, denoted here as 9454 (WIKI), 94540 and 945450.
-> User sends search query ("SOME TEXT") to 9454.
<- User receives list of search results from 94540.
-> User sends result selection ("1") to 94540.
<- User receives list of article sections from 94540.
-> User sends section selection ("1") to 94540.
<- User receives article content from 945400.
-> (optional, recurring) User replies to 945400 to request further content.
<- User receives further article content, if any, from 945400.
Billing considerations
This isn't really relevant to the code, but it's worth tracking anyway.
9454 would ideally be zero-rated, because we like promoting free access to information.
94540 really should be zero-rated if possible, because it's just an implementation detail in the search flow.
945400 can be zero-rated, but it's optional and presents a possible revenue stream for operators, etc.
Modifications
If three shortcodes are unavailable, the above flow can be modified in the following ways:
Longcodes
If three shortcodes are unavailable, 94540 and 945400 could easily be longcodes instead. These will only be receiving replies, but it's important that we're able to differentiate between them. 9454 should ideally be a shortcode, since that's inbound-only.
Fewer shortcodes
NOTE: This probably isn't going to be implemented in this ticket.
If three shortcodes (or a shortcode and two longcodes) are unavailable, 94540 may be combined with either 9454 or 945400. Aside from the tradeoffs below, there are potential billing considerations.
In the first case, we remove the ability to cancel a search early and start again with another query unless we try to detect the difference between a menu selection and a search query. (Note that "1" is a valid search query, though.)
In the second case, it becomes harder to share the "more content" reply code with the USSD flow and general state management becomes more complex.
USSD isn't available everywhere, so we need an SMS-only interface as well.
General design
The SMS-only flow will use three shortcodes, denoted here as
9454(WIKI),94540and945450.9454. <- User receives list of search results from94540.94540. <- User receives list of article sections from94540.94540. <- User receives article content from945400.945400to request further content. <- User receives further article content, if any, from945400.Billing considerations
This isn't really relevant to the code, but it's worth tracking anyway.
9454would ideally be zero-rated, because we like promoting free access to information.94540really should be zero-rated if possible, because it's just an implementation detail in the search flow.945400can be zero-rated, but it's optional and presents a possible revenue stream for operators, etc.Modifications
If three shortcodes are unavailable, the above flow can be modified in the following ways:
Longcodes
If three shortcodes are unavailable,
94540and945400could easily be longcodes instead. These will only be receiving replies, but it's important that we're able to differentiate between them.9454should ideally be a shortcode, since that's inbound-only.Fewer shortcodes
NOTE: This probably isn't going to be implemented in this ticket.
If three shortcodes (or a shortcode and two longcodes) are unavailable,
94540may be combined with either9454or945400. Aside from the tradeoffs below, there are potential billing considerations.In the first case, we remove the ability to cancel a search early and start again with another query unless we try to detect the difference between a menu selection and a search query. (Note that "1" is a valid search query, though.)
In the second case, it becomes harder to share the "more content" reply code with the USSD flow and general state management becomes more complex.