Interactive Prototype Recreativity

Alex Constant

Angela Liu

Shahaf Nuriel

Janette Siu

David Swanson

Our team’s goal is to make users more comfortable in their creative skills. People frequently suffer from creative blocks, during which they struggle to find inspiration to produce a creative work. Other people do not feel wholly confident in their creative abilities and may simply need more practice being creative. The current applications which support these users do not feature a fun way to share creativity and collaborate productively.

Task 1: Sharing Content (simple)

Jane wishes to bolster her creativity. A friend of hers told her about the Recreativity application. She really likes games where the participants work together to connect ideas, so she would like to try it out. She plays a round of the game, in which she produces a creative work and submits it for viewing by others.

Task 2: Finding Inspiration (medium)

Jim has a hard time viewing the world around him in a creative way. He is working on a project where he has to make a logo for a theoretical company. Tim desires to examine the creative connections that others have made in Recreativity in order to inspire him and increase his own creative output.

Task 3: Exchanging Feedback (complex)

James is an artist by profession. His art teachers always gave him useful feedback, and responding to this feedback helped make him the artist he is today. He likes to give back by helping budding artists realize their full potential by providing feedback. He uses Recreativity to star submissions that he likes to help encourage other artists to be creative.

Revised Interface Design

We learned a lot as a result of our usability tests. The usability tests highlighted three main results we wanted to mold Recreativity into. One was the need for the integration of a social aspect of Recreativity, so using the app to share a flow with a friend and only making a closed social circle engaged in a game. Second was using stars to represent earning points in the game, or gamifying Recreativity. Last was seeing how a flow evolved and being able to navigate that easily.

Easier to differentiate Can easily star a submission, More buttons when submit,

from flows, can click on can navigate top menu bar so can send to friend, look

any image presented, look at prompt again, and

search bar can be easily submit; also tries to help

used correct word

The following features highlighted in red boxes were not implemented in our UI at this stage:

Commenting, flag a comment, Progress bars for how far Uploading other types of

and the ability to delete your into the flow media beyond text

own comment

Upon opening the app or selecting

“Play” from the main menu (in the

upper right corner), the user is

presented with brief instructions,

followed by the prompt. The user

can tap the icon at the bottom of

the screen, or play in the top menu,

which allows them to compose a

response. (In this prototype, this

response can only be textual.) The

user can then submit their work, and

share their work with friends.



Task 2: Finding Inspiration

When the user selects “Explore”

from the main menu, they are

initially presented with multiple

randomly-selected flows, which the user is able to search by entering a query in the text box and selecting a magnifying glass icon

Task 3: Exchanging Feedback

The user can access a flow through

“Explore” in the main menu; after the

user has selected a flow, they can quickly

and easily contribute feedback to a

given piece of content by pressing the

star button to vote for that submission.

Comments for submissions will be

implemented in a later prototype

Prototype Overview
Tools:
We used primarily four tools in creating our prototype: Andorid’s software development kit (SDK), Eclipse, Intel hamx, and online tutorials.
The Android SDK was essential to getting our project done. Not only was it extremely helpful on how to create an application, but it also allow us to emulate our application. Through the SDK we were also able to drag-and-drop application details without necessarily having to build the entire application. The only setback to Android’s SDK was that its help features are not obvious, and Android programing is different from most of teams programming experience.
Eclipse was critical to this project running the Android SDK, and also giving our team a familiar coding environment to organize files and complete code. One of our issues with Eclipse is that it has many features that are not very compatible with the SDK, keeping backups of deleted files, which means the emulator often uses stale data when rendering.
Intel hamx’s purpose is to speed up the Android SDK emulator. The issue with this tool is that is was laden with bugs and threw a lot of confusing errors after installing. Only one person in the team got it to work after several tries.
Lastly, we used online tutorials to help us code the Android application in eclipse. This helped a lot because tutorials online meant access to the information for all team members, and the ability to skim content for code parcels. The issue with the tutorials was that there were not enough relevant tutorials. At times the tutorials were unclear or assumed too much prior knowledge.
We did have an Android phone available to us for testing the application during this process. Due to the emulator, the phone was rarely used.

Implemented user interface (UI) :
The recreativity application was implemented for Android devices. Our initial page is playing the game from there you can navigate to the flow you are working on to star other submission or look at other flows to star their submissions. What is good about this UI is that you can search the flows, navigate between the flows, and the display of different flows to explore. The menu bar has also been redesigned so that navigation is less layered, and the game is more straightforward. We also added new buttons to the submission page so that you can look at what you are responding to, send your prompt to a friend, and submit your work.

A decision we made about our implemented UI was that we were only going to allow text responses for the interactive prototype. This was mostly because the size of images that could be imported could potentially get distorted with our current display features as well as be too big to display on our canvas. Additionally, hard coding the flows means only a few flows could be shown, making the storing process for responses to and comments on flows nonexistent.