Mashing Texts is a SSHRC RDI funded project that has prototyped a recombinant research environment for document management, large-scale linguistic research, and cultural analysis. In addition to the best-of-show design documents, a working Mashing Texts prototype exists in the form of JiTR (Just in Time Research).
The rise in accessible information that has accompanied the arrival of the Internet has presented new challenges in harnessing this data. This phenomenon is commonly called "information overload", referring to the difficulty for an individual to process such large amounts of information using current means. The Mashing Texts project seeks to simplify this task by adopting principles of online mashups. It is in doing this that Mashing Texts looks to combine both the creation and exploration of resources into a single, cohesive system.
This is the original Mashing Texts proposal, headed by Geoffrey Rockwell in 2007. It outlines the fundamental principals and goals of the project. PDF download.
Though the JiTR prototype is in active development, the primary product of the project is conceptual, as we explore new hypotheses for addressing the problems with exploration of resources.
In this project, we have adapted the Personas and Scenarios model in order to develop with a heavy user focus. The Personas and Scenarios model is a design strategy in which realistic composite users are created ("personas") and the design of the product centres around their needs and uses ("scenarios"). This model essentially asks: "If the end purpose is functionality for users, why not begin the process by thinking about users?".
Personas are imagined possible users that "act as stand-ins for real users" (Calabria). Certainly, an imagined user cannot match the complexities of a real personality. The strength in this approach, however, is that the design team is actively striving to consider users with depth at a development period much earlier than when user tests can be conducted. Even at times where early user studies are possible, using personas allows a team to smoothe over the unique and unrepresentative quirks that individual users may have.
Once three to six personas are created, they are prioritized into primary and secondary users. The users that are seen to be the most important to the team become the primary users, and their needs in turn assist in prioritizing design choices. In other words, later design choices can be considered through the lens of whether they would benefit the primary users.
The Personas and Scenarios model does not need to be used exclusively, and can be combined with other design techniques. In the Mashing Texts process, there was an interplay between scenarios and wireframes. Three different design philosophies were wireframed, based on the needs of the primary personas, and organized in the order of their scenarios. This allowed side-by-side discussion, following through the scenarios step-by-step and considering which of the three wireframes served each particular task best.
Mashing Texts Personas
These are the scenarios that were used to guide Mashing Texts design.
Primary Persona - Kate
Independent Researcher
Kate is using JiTR to track Fair Trade news in Costa Rica, as part of a book that she is collaborating on. She’s not well-versed in computers, but competent in figuring them out. Most notable about Kate’s experience is the ability to organize large data sets easily, and call them back up even easier. She loves taggs and collection sharing.
Scenario 1 - "The Collection Scenario"
Kate creates a shared collection and runs some processes to automatically populate it. When she receives new items, she cleans them up and keeps them organized through tagging.
Kate is following media reports on coffee growers as part of a book that she is co-authoring.
In this scenario, she:
Creates a shared repository with her collaborating colleagues
Sets up a web spider to poll her common sources, automatically
Is emailed when there are new items
Labels items according to category
Cleans the imported items
Adds her older research by uploading it as files
Shares a public repository link with her other colleagues. People at the public link have the lowest access, and their notes are retained by the system until they can be reviewed.
Prints a summary report with metadata and her notes
Scenario 2 - "The Just-in-Time Scenario"
Kate is following a media sub-issue that has just developed, about a tax conflict that coffee farmers are in with the government.
In this scenario, Kate:
Uses labels to track the sub-issue without starting a new repository
Adds notes analyzing each article. Later, she also more detailed notes for the broader label.
Runs “Count Words” on chronologically organized list (of just the one label). Forms a hypothesis based on the sparklines provided by the tool.
Receives notification when revisions are made on notes by her colleagues
Scenario 3 - "The Wrap-Up Scenario"
Kate's book is nearly complete, but she needs James' foreword. She send James an invite to add his text to the collection, the organizes it and exports by chapter.
Before Kate can send a transcript to the publisher, she needs the foreword that James is writing.
In this scenario, Kate:
Sends a limited collaborator invite to James
Organizes the finalized chapters in custom order (rather that alphabetically, chronologically, etc.)
Persona
Cheryl is a contributing editor for the Orlando Project. Her daily routine involves interaction with a number of entries and needs to accomplish encoding quickly and effectively.
She is quite familiar with the reference sources drawn upon to obtain biographical information, with online and print primary sources used to write critical materials, and also with the conventions employed by the project for encoding this material.
Cheryl has in the past experienced roadblocks in the production process arising from lost emails, overwritten versions of documents and time wasted trying to track down reference sources lost or misreferenced during the writing process.
Scenario 1 - "The Editorial Scenario"
Cheryl logs in to do a variety of small editorial tasks, checking and correcting documents, updating statuses, and communicating to her contributors.
In this scenario, Cheryl:
Logs in, and is updated on her projects through the notes panel and generated reports
Opens a document in edit mode, automatically locking it. Status indicators show the completed stages of the project.
Responds to notes, marking them as read
Edits a date. She inadvertently inserts an extra digit, and the system warns her about it.
Corrects the faulty date value and saves the new version
Changes the authoring status to "finished"
Attaches a note to it for Ian. He will see this in his Dashboard.
Previews the display of the document using a project stylesheet
Scenario 2
In this scenario, Cheryl:
Creates a new document on Pauline Johnson for Ian, using a bibliography template
Adds a editorial ticket for PJ in the Authority Lists panel
Finds another document to point to the PJ document by consulting the shared research bibliography
Sends a message to Ian
Scenario 3 - "The Workflow Management Scenario"
Cheryl creates a new workflow for a new document type, starting from templates. She then starts using the workflow with a new document, that she assignments to another person.
In this scenario,Cheryl:
Defines a new workflow to manage the creation of a new type of document.
Chooses the basic entry schematic from the DEEP workflow editor templates.
Chooses a document template, automatically triggering an email notification.
Sets up messages for the person to whom the entry is assigned, the assignee's immediate supervisor and the system administrator when a new XXX document is created
Sets the workflow endpoint as the the bibliographic entry workflow.
Validates the logic of the workflow.
Saves the document type, automatically making it available for all relevant users.
Secondary Persona - Ian
Ian has just become a contributor with the Orlando Project. He's still unfamiliar with the system, but eager to learn.
Scenario 1 - "The First Time Visit"
Ian signs up for JiTR and logs in for the first time. He watches an instructional video to understand the system, and then reads some additional documentation.
In this scenario, Ian:
Checks out a “tutorial” repository that already exists in his new account
Scenario 2 - "The Creation Scenario"
Ian receives instructions from Cheryl on a new entry. He begins to collect materials for it and add them to JiTR.
In this scenario, Ian:
Logs into DEEP and Sees a new message from Cheryl about Rita Joe, which he tags saves to his research log.
Sees that he has a new entry assigned to him and opens it.
Follows a link noted by Cheryl and adds it to the collection.(collection? tag?)
Tidies (automatically) the collected webpage.
Browses the Dictionary of Canadian Biography Online and collects materials relevant to his topic.
He inputs the metadata manually, attached to a correct bibliographical citation. He marks this as requiring double checking.
Saves his entry, validating it against the XML stylesheet. The status of the Rita Joe entry is changed to "in process" and a notification is automatically generated and dispatched to the supervisory editor.
Responds to Cheryl's note.
Secondary Persona - Sidney
English Grad Student
Sidney uses JiTR to research temperance in the writing of Victorian women. He’s grown up around computers, and is comfortable around them.
Most notable about Sidney’s experience is the push-pull power of the API, allowing him to pull in information from Orlando and send it into Mandala and TAPoR, all within the interface.
Scenario 1 - "The Bibliography Scenario"
Sidney browses Orlando through JiTR, adding book records as items to his collection. He then creates a dynamic "bibliography" item that includes all the other items.
Sidney is creating a bibliography of works to consult related to his research. He's interested in Orlando because has the information on upbringing and social circumstances that he hopes to connect.
In this scenario, Sidney:
Imports book metadata as name/value tags (i.e. "year:1850")
Combines all the book items into a dynamic item
Scenario 2 - "The Analytical Scenario"
Sidney tries to explore different way of understanding his data by connecting his collection to TAPoR and later to the Mandala browser.
Sidney has read the books in his bibliography and wants to consider the bigger picture.
In this scenario, Sidney:
MT operates through two over-arching two principles: items and collections. Items are the individual texts that are kept in the system; these can be original texts or ones added by the user. These items are kept in collections, the repositories that bind all the items of a single topic. Items are never shared between collections, as all relationships are intended to be represented within the collection.
Important to the organization of collections are tags and notes. Tags allow natural language categorization of items, offering organizational flexibility beyond the standard set of metadata. Notes are text memos that can be attached to both items and collections. If they are attached to shared items or collections, then they can be used for communicative purposes.
The final fundamental of the MT design is processes. This is the name given to actions that can be run on collections and items; a process is when the computer "does stuff". As the API is a vital part of Mashing Texts, the system needs to support built-in (native) process and third-party processes similarly.
Dashboard
Upon logging into their account, a user arrives at a dashboard summarizing the most recent activity related to their account. A similar dashboard is shown at the main screen of a collection, though only summarizing events related to the selected collection.
The dashboard shows the most recent items, notes, and processes, 'most recent' referring both to modifications of these entities or creation of new ones. These are displayed module-like, with sections cleanly compartmentalized. From the dashboard a user can either go directly to entity's page –by clicking on that item, note or process– or expand to a larger list view by clicking on the compartment header. "Most Recent Items", for example, will exists in a summarized and possibly truncated state on the dashboard, but by clicking the title, a user will go to a full-page, chronologically organized list of all items. This allows a user to freely browse the history of their account, particularly useful for users with lots of activity or who have not logged in for a considerable time.
Notes
Notes are a minimal annotation and communication tool. They consist of a message and optional message title. Also included are three types of system data: datestamp, author, and location. Mashing Texts also remembers a flag of read / unread status, which does not exist in the note's metadata per se but nonetheless rounds out the six parts of a note that are seen by a user.
The minimalism of the system is because the notes system does not intend to replace email. Rather, it more closely follows metaphor of a Post-it message stuck onto the page of a book. The datestamp allows Mashing Texts to offer chronology functionality, and the author is remembered for the ease of users with shared collections. Finally, the location is a part of the note architecture within MT. From the system's view, notes exists similar to items. While items are bundled in collections, notes are kept together in their own special list. Rather than existing as a part of an item, notes exist in their own realm with their relationship specified in their metadata. A note, then, can be attached to a number of different entities. It can have a collection, item, or even a user as its "location". Each of these entities has a section that gathers all notes attached to them. Notes can be seen by anybody who has access to what they are attached to. If an item is shared between two users, both users will see its notes.
Navigation
The design of Mashing Texts is based closely on common application design practices, moreso than on website design mainstays. Resultant features include a full-page dynamic design and a navigation gently reliant on familiarity. There are two primary navigation areas: a top navigation bar and a sidebar. The navigation bar is the permanent navigation: it consists of drop-down menus with static, consistent choices. The top options offer links to the primary start pages (i.e. Home, Collections, Tools, Notes) while their drop-downs offer quick access to popular actions (e.g. create new collection, write note). The far right of the navigation bar holds another form of navigation that is constant: the search bar.
In contrast to the top bar, the sidebar offers contextual navigation: options that are directly related to the page that is in view at the time. These include the actions from the dropdown menu featured more prominently, as well as lower priority actions and actions that can only be applied to specified entities. For example, being in a collection list screen, the sidebar would show general collection actions (e.g. create new collection) as well as specific collection actions (e.g. create report, sort collection by...). The sidebar is not purely reserved for actions, and also can include regular navigation if the context requires; one such example is a jump to option that lists and links to all the items on a list screen.
Item Screen
The item editing screen is split up into two parts: the document and metadata. Most basically, an item has the primary content, a title, author, date, and source (i.e. how the item was created or gathered).
List Screen
The primary collection browsing state is the list view, a collection of entities represented as list objects. The list screen is used for all lists, regardless of what it is viewing. The sidebar of any list screen has a "sort by" option, for changing the display priorities of the list. There is also a "jump to" option, which functions as a sort of linked table of contents, quickly jumping the page to the location of a list item. This helps avoid excessive pagination by making more items on a page manageable.
List objects generally show abbreviated versions of what they represent. Long notes and items are truncated to the size of the list objects box, and only the most important item metadata is shown. A number of features are included in order to make lists more comfortable for a user to browse and process information. The first is that list objects are collapsible into small slips, a features which helps manage screen space and, for some users, can be adopted into one's reading flow by hiding items when they're no longer needed. Another feature is that list objects can include basic editing functionality, such as title and tag editing.
API
The API is an vital part of Mashing Texts. It allows third-party developers to create tools that interact with the data from a user's account. While external tools are possible through the API, the primary emphasis is on allowing developers to add processes to be used within the Mashing Texts environment. This approach, popularized recently by APIs such as Facebook Platform, allow tools to be added that augment the website from within. This is done with an API that offers connection points within the interface. A tool that translates an item, for example, could add an item to the processes menu of individual items.
(Insert mockup of adding process to item)
To augment a user's account, a user will need to approve a tool to do so. They will be able to do so in the processes directory, which will serve the additional purpose of simplifying and encouraging discover of processes. The native JiTR processes will exist similar to third-party processes, developed using the same features of the public API, but will be activated by default.
>
The working Mashing Texts prototype is JiTR. It helps its user collect online texts into one place, then organize and process them.
JiTR streamlines the research process, so you can concentrate on what's important.
JiTR can be used at http://ra.tapor.ualberta.ca/~jitr/. To request an account or report bugs, email Geoffrey Rockwell at geoffrey.rockwell (at) ualberta (dot) ca.
>
Crane, Gregory. "What Do You Do with a Million Books?" D-Lib Magazine. Vol. 12,
No. 3, March 2006. <www.dlib.org/dlib/march06/crane/03crane.html>.
Frischer, Bernie et al. "Report on Summit Accomplishments." Summit on Digital Tools for the Humanities. Institute for Advanced
Technology in the Humanities, University of Virginia. May 2006. <http://www.iath.virginia.edu/dtsummit>.
Personas and Scenarios
Calabria, Tina. "An introduction to personas and how to create them", <http://www.steptwo.com.au/papers/kmc_personas/>.
The minimalism of the system is because the notes system does not intend to replace email. Rather, it more closely follows metaphor of a Post-it message stuck onto the page of a book. The datestamp allows Mashing Texts to offer chronology functionality, and the author is remembered for the ease of users with shared collections. Finally, the location is a part of the note architecture within MT. From the system's view, notes exists similar to items. While items are bundled in collections, notes are kept together in their own special list. Rather than existing as a part of an item, notes exist in their own realm with their relationship specified in their metadata. A note, then, can be attached to a number of different entities. It can have a collection, item, or even a user as its "location". Each of these entities has a section that gathers all notes attached to them. Notes can be seen by anybody who has access to what they are attached to. If an item is shared between two users, both users will see its notes.
> 
