Features & Information Design
The way an app’s data is constructed and stored can severely bias the design of an app. The way data is connected might make some aspects of an app very easy to create and others a complete nightmare.
MongoDB can handle small sets of flat data easily, and that’s exactly the type of data we’re looking at.
To determine the data model, I’ll create user stories to describe what features will be available to users. Remember that every ‘user’ is actually an author, each with their own writing styles and needs, and each author works on their collection of stories called ‘novels.’
– can write and switch between multiple novels
– can read their novel in a full-page novel view
– can only see their own novels
– sign up and login with email/password, facebook, or twitter API
– write paragraphs inside novels
– earn achievements for completing a stories
– can see when their story was created, how much time is left, Nano progress, including check a story’s word count, how many words are left, or each session’s date, time and word count
– track writing speed / word rate per session over the entire process
– can continue writing their story, in which the words get combined into the story
– can see word count for the current session
– can add or edit a title for a novel
– can read and copy their novels
– can edit their previous sessions
– can delete previous sessions
– can delete their novels
– can copy their novel to the clipboard
– can edit their preferences / settings, such as interface, color theme etc.
– can change their email, reset password, change their username, and delete their accounts (after a stern warning all their data will be gone)
– can bookmark a paragraph or session
– can set a word goal for a session
– can view a word counter for a session (can also hide the counter)
– can view a progress bar towards completion of session
– can earn achievements for challenges
– can add paragraphs into segments
– can add paragraphs and segments into chapters
– can add paragraphs, segments, and chapters into novels
– can edit their novels — note that once authors edit their novels, they will have ended their initial challenge
– can edit paragraphs seamlessly, like in a word processor
– can move, group and regroup paragraphs inside segments, chapters, and novels
– can create and swap out versions or alternate scenes of the same text
– can move, group and regroup paragraphs and segments inside chapters and novels
– can move, group and regroup paragraphs, segments, and chapters inside novels
– can share their novel, or parts of their novel, for others to read, either privately with a password, or publicly. Can also unshare novels
– can create revisions, or alternate paths for their novel
– can add keywords
– can add keyword categories (e.g. villain: Jack)
– can add notes to keywords, paragraphs, segments, chapters, and novels
– can search for notes, keywords, and phrases
– can see an overview of their novel, with keywords and notes overlaid
– can track all keywords and their occurrences
We can see that information will be closely tied to author accounts. Authors will have pieces of writing under their name. Each piece of writing (for example, a sentence) should be recognized as an atomic piece of writing, that users can tag, move around, end edit. What I meant by “write paragraphs inside novels” is that every paragraph is considered to be part of a novel, and all the text written for a novel is uniquely a property of that novel.
NanoWrito Data Model
Previously, NanoWrito created a “story” collection, with each session’s writing stored in a data object that represented each writing section. Each session’s content array was essentially a large array of text. This worked for NanoWrito, as I never had any plans to expand on its functionality, but storing a simple array of text without options for additional metadata will limit what you can do with the text in the future.
– Account Info
– User Settings
– Created Date
– Last Modified
—– Novel Type
–– Is Nano Winner?
––– Session ID
––– Session Date (word count, time stamp, etc.)
––– Session Options
NovelMonkey Data Model
I’d like to have finer control over the content authors generate, so I can support features like categorization, tagging, editing, shifting, grouping and creating alternate content, and revisions, I will need to plan for something much more flexible. Each atomic piece of writing will be called a paragraph — the end of a paragraph is denoted by a new line — and these paragraphs can either stand alone or be strung together into a collection called a sequence. A collection of sequences would be a chapter, and a collection of chapters would be a novel. Each layer of this word-cake simply provides a way of categorizing and organizing paragraphs.
Note that I don’t handle each sentence as a separate data object — it might be too atomic for my purposes. Instead, each sentence within a paragraph could be broken up into an object or an array within the paragraph object.
The following way of tracking paragraphs adds a small amount of overhead, as I’m letting novels track paragraph IDs instead of just storing plain text into an object. These benefits should be realized later, as it disconnects written text from its context.
Phase 1 Data Model
— Account Info
– User Settings:
– Created Date
–– Novel Type
–– Is Nano Winner?
–– Word Count
–– Word Count Goal
–– Last Modified
–– Created Date
–– Session Word Count
–– Paragraph IDs (array of paragraph reference IDs)
– Created Date
– Reference IDs
–– Created Date
This data model gives me enough flexibility for the future, and also allows me to recycle some of the code from NanoWrito. It also allows authors to track progress in various ways, as every piece of data has a time stamp attached. Meteor’s DDP tends to only send data through the top-level data field. This means that if paragraph was a part of a novel, adding a new sentence to a paragraph, all the paragraphs of the novel be sent each time the novel is updated, which would be very inefficient for a large-scale application. By separating paragraphs into its own collection, we won’t need to send as much data back and forth. On the flip side, we would still want to make one single call to the database to retrieve all the paragraphs related to a novel (instead of looking up each individual paragraph reference ID and making a separate database call for each paragraph found), so we store the reference ID to improve retrieval speed. These hacks are necessary to both reduce the amount of data sent back and forth, and reduce the number of database calls. I think. I’m still pretty new at this. More information can be found at Meteor’s Schema Design portion.