This is just as important for any other piece of software as it is for games. A clear understanding of the software's goals and the different interactions that will take place between the user and software will be a vast help in keeping the software usable. This project is the last one in which we'll explicitly cover the design that states what the software needs to do.
Because this app has only a few features, the design will stay fairly simple.
- Start by explaining the overall function:
TranslationBuddy will provide translations of short phrases and words from English into Japanese, and preserve a history of translations that have been previously obtained so that they can be viewed again.
- Specify the user experience along the principal interaction path (how the user is expected to use the software most often):
When the app opens, an editable text field is displayed above a tab bar with two options: Translate and History . Translate is the current option. When the text field is selected, the device's native text entry facility appears; when it is dismissed, the view pans to the right-hand side to reveal a list of the entered text and the translation below it. The tabs remain visible so that the user can return to enter or select another translation easily. The result display is also topped with a bar that includes a Back button to return to whatever selection method opened the results screen.
- Explain the user experience along any other interaction paths (there is only one in this case):
The History tab button reveals a table of previous English sentences that have been entered. This list can be scrolled up and down to reveal parts that don't fit on the screen. Tapping a sentence will reveal the translation of that sentence much as if it had been just entered in the Translate view.
- Finally, explain any other non-functional requirements; that is, details that might be possible to change without completely upsetting the chosen solution:
Translations will be obtained from the Microsoft Translator API. Because this service has limited access, the app will store received translations with the sentences that produced them to avoid needlessly repeating requests.
We've outlined what tasks the app will perform and summarized the interface elements that will implement those tasks. We've specified a couple of what project managers call non-functional requirements, specifications about how things will be done, and the parameters that operations will be performed within, such as which engine will provide the translations and that it must conserve the service subscription. These requirements could be changed without stopping the app from doing its job, but they might have other side-effects, such as damaging the app's business model, if it had one.