Skip to content
This repository has been archived by the owner on Oct 11, 2022. It is now read-only.

SMS-only interface #16

Open
jerith opened this issue Aug 23, 2012 · 0 comments
Open

SMS-only interface #16

jerith opened this issue Aug 23, 2012 · 0 comments

Comments

@jerith
Copy link
Member

jerith commented Aug 23, 2012

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.

  1. -> User sends search query ("SOME TEXT") to 9454.
    <- User receives list of search results from 94540.
  2. -> User sends result selection ("1") to 94540.
    <- User receives list of article sections from 94540.
  3. -> User sends section selection ("1") to 94540.
    <- User receives article content from 945400.
  4. -> (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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant