You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 11, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
and945450
.9454
.<- User receives list of search results from
94540
.94540
.<- User receives list of article sections from
94540
.94540
.<- User receives article content from
945400
.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
and945400
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 either9454
or945400
. 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.
The text was updated successfully, but these errors were encountered: