Development of Native Android & iOS Wiki Resource for Writers
OBJECTIVE & OVERVIEW
A running gag in the writing community is that authors regularly find themselves clearing their browser history to cover their more unconventional searches.
”Why are you Googling 'How to hide a body'?"
"It's for a novel I'm writing--I swear!"
I wanted to provide writers with a safe place to browse and gather resources, a place where they can search for the most obscure and controversial topics without fear of reprisal, while also offering a single-source citation for their work.
The challenge was two-fold. One challenge was to design two separate native apps--one for iOS and one for Android--while maintaining a cohesive function and appearance between the two versions. The other challenge was to create an app that functions similarly to Wikipedia while offering a more tailored experience to writers that they're not able to find elsewhere.
I researched common design patterns, paying particular attention to the iOS Human Interface and the Android Material Design specs. My focus was on patterns for gathering input, data management, navigation, and onboarding. Navigation was of particular importance from a design perspective, as that's where the most noticeable changes are between the two platforms. I completed four iterative prototypes, reviewed by my peers, before I settled on a set of screens for each app that were both cohesive and logically functional for the user.
LEARNING FROM OTHERS
I spent the most time with this project in the research and development stage, relying heavily on Google and YouTube, focusing my searches on "app walkthroughs", "apps for iOS", and "apps for Android." It was equal parts grueling and gratifying to sift through the mountains of data as I built my design reference archive. Both Dribbble and Behance proved to be reliable and regularly-visited sources of inspiration and knowledge as I narrowed down the basic elements for my designs. Wikipedia was certainly a major influence for my app, and I took many pages of notes regarding features that were beneficial as well as those that felt unnecessary for my particular concept.
Before I began the design process, I reached out to fellow authors and writers (since they're the target audience) to share with them the idea that I had for the app, as well as to get their perspective on features that they might find beneficial. The participants for my interviews consisted of one published novelist, a seasoned blogger, and two writers who are both working on their first manuscript. With the premise of the app in mind, and with the clarification that there are no wrong answers, I asked the following questions:
What is your main source of reference when conducting research? (And do you prefer digital or physical resources?)
Do you have any concerns in regards to privacy when conducting a digital search?
Are there any resources that you wish were more readily available? Please cite specific examples.
What is the most challenging aspect of conducting your own research?
How important is providing citations for your research, and why?
If you have a preferred digital resource app or website, please list your favorite feature(s) of the app, and your least favorite feature(s).
How important is the visual interface of the app to your general search?
To no one's surprise, both Wikipedia and general Google searches reigned supreme as a source of reference. Only one of the participants expressed concerns over privacy in regards to his searches, and he chalked that up to the eccentric nature of his queries. Dictionaries and thesauruses also topped the chart for reference material, and both digital and physical seemed to hold equal weight.
One user indicated that Google Translate was accessed regularly for her writing, and another expressed interest in a feature that could coach the user in regards to regional dialects.
All said and done, my participants provided me with a wealth of information regarding the desired features of a resource app, as well as a few features that could potentially be skipped.
This user flow came together a lot more smoothly than previous flows. I spent more time studying the proper usage of flow elements, and my final flow chart was clear and logically arranged. I started the flow diagram with three unique tasks to be completed for the app, each one inspired by the results of the author interviews: searching for an article, submitting new content (as a verified user), and translating dialogue into a specific dialect or jargon (this last idea conceived during the author interviews).
I then created paper low-fidelity wireframes for each of the three use cases within the user flow, and of those, I created a version for both Human and Material Design, ensuring that they adhered to their respective guidelines.
I did a rapid prototype for the first round of user testing, just to see if I was on the right track. To do this, I contacted six new users from my Slack groups; three of them were Android users, and three of them iPhone users. As an iPhone user, myself, the feedback from the Android users was of particular benefit. Basic app usability was at the heart of this test, so I didn't feel the need to isolate the test subjects to just authors or writers. I assembled the prototypes using InVision, then invited my users to test a single user flow using their respective mobile device.
Once the feedback was received, reviewed and compared, I began the transfer from paper wireframes to digital using Sketch.
SOUNDS & PHYSICAL FEEDBACK
For the next iteration, I considered how the user might respond to haptic feedback, touch, and sound. Did they enter the wrong password when logging into their account? Perhaps they'll receive a warning buzz, accompanied by a subtle vibration. Has their content been successfully submitted for review? A simple "ding" could alert them to their success. The prototypes I submitted to my peers were not sophisticated enough to include such feedback, but I did annotate the features accordingly. Based on the responses, most of the indicated sensory feedback would be acceptable for this app, as long as I also include a setting that allows the user to turn off the sounds and vibration, should they prefer not to use that feature (that was the only major concern shared by my users).
Since this app is a tool to be used by writers, selecting the proper fonts was just as important as selecting the accent colors. Users of this app will no doubt already be familiar with e-readers and other digital encyclopedic sources. As such, a traditional sans serif font was the obvious choice. And with that in mind, sticking with the default native fonts for each respective app made the most sense.
The users shouldn't require a manual to use the app, especially an app designed as a learning resource. The beauty of this particular app is in its simplicity; the user will intuitively know how to search for a new article, save it to their projects folder, or even translate a phrase because all of these features have been designed to emulate features and apps that the user is already familiar with. The one bit of instruction that I included was the onboarding screens, which are simple illustrations of users engaged in the basic tasks featured within the app.
UI & STYLE GUIDE
Referring back to both the results of the rapid prototyping and the results of the author interviews, I decided to avoid adding features or elements that were overtly "trendy", instead, relying on tried-and-true patterns for my app's main navigation and functionality. Users will be coming to this app for the information it provides, not the sparklers and fancy stickers. In regards to the orange color scheme, I chose that based on other popular writing and information apps: Apple's Books, Wattpad, and Thesaurus (from the Dictionary.com app), to name a few. The orange color scheme evokes a sense of knowledge, determination, creativity, and success. It's less severe than red, but not quite as playful as yellow, giving the user the feeling of informal professionalism.
As I neared the final iteration of the UI, I decided to present my participating users with a more polished and refined prototype. With fully realized native prototypes for both iOS and Android, I reached out to both sets of users: those from my author interviews and those from the rapid prototype session. Each set of users had a different piece of the early puzzle, and each had their own expectations for the resulting app. I asked them to complete the three tasks originally conceived for the user flows, and then recorded and compared the results.
The users were not required to test both the iOS and Android prototypes; I instructed them to choose the platform they used most regularly. However, each one of my 8 participants chose to test both of the prototypes, indicating curiosity regarding how the two versions compared both in both function and visual interface. And this suited me just fine. I actually received feedback from at least four of the users who preferred certain aspects of the iOS functionality over the Android (regarding the Dialect Coach feature). As such, for the final iteration, I was able to make adjustments to the Android version to allow for similar functionality as the iOS version, while remaining true to the Material Design standards.