In the third post, I gave an insight into the story of the Text Analyzer Platform using the ‘User Story Mapping’ methodology. This is the second post in the first Build-Measure-Learn cycle to build a Minimum Viable Product. It comprises of the decomposition of the major user task ‘Storing Text Files’. We are now going to look at this part of Anton’s story in more detail. It reveals some important properties of the Text Analyzer Platform (TAP).
Breaking down the Major Task ‘Storing text files’
The first draft of the user story map for the Text Analyzer Platform involves three major tasks. One of them is ‘Storing text files’. If a major user task is too big for immediate implementation; I have to refine it. I have to break it down into smaller subtasks and details in the user interface. This is consistent with the third step of the user story mapping process, which is called “Explore” (see [Patton2014]). The next picture shows the result of breaking down the major user task ‘Storing Text Files’.
When talking about storing a text file we must also think about the retrieval of the data. Thinking about the two aspects storage and retrieval I found the following new user stories:
- Importing text files
- Viewing documents
- Adding annotations to text sections
- Searching the document database
- Check for doublets and newer document versions
- Web crawler for downloading content as text file and direct import
It is easy to identify the user story to start with. Logically a text file has to be stored before anyone can access the text. Let us refine Anton’s story.
The Story of ‘Storing Text Files’
Anton found a free introduction to NoSQL databases in the internet. He was able to download a legal copy of the article in PDF format on his computer. For his analysis process, he wants to import the article into the Text Analyzer Platform (TAP).
He logins into the system and navigates to the file upload dialog. There he starts the upload dialog and selects the text file containing the article. The text file will be read by the TAP importer and the text will be imported as a document. The resulting document will be stored in a database.
During the import, the system checks for doublets or newer versions of an existing document. In case of a doublet candidate, the user may cancel the import or nevertheless import the text file.
After the import, the user who has imported the file can view the text. There is a viewer for the text. The viewer displays just the content, the plain text. It does not show any formatting.
In the document viewer, the user can see existing annotations for the text; also, he can create new annotations. The user can add an annotation to a certain text passage, a section, chapter or the whole document.
The system offers different search options in order to find a text file. The user may find a text file by its name, or he uses the import date as criteria or an annotation associated to the document.
An alternative way to get documents imported to the system is to use some kind of web crawler. A web crawler can directly import text into the system. Which renders the step of saving as a local file as unnecessary.
What is next?
In the next post of this cycle of the Build-Measure-Learn feedback loop, I will describe the user story of importing a text file. In future posts of an upcoming cycle, I will also deal with the other stories.
[Patton2014] Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product (1st edn, O’Reilly Media 2014)