We designed and printed our team shirt to wear on STePS day
And print our poster for STePS
We set up a website to show a live “Number of Focus minutes of all our users”, and use an iPad to display it during STePS.
During STePS, we have to give 100 “How the app works” speeches, really wear me out afterwards. I had my first experience as a exhibitor at STePS.
Although our team didn’t win, CS3216 final project has brought me two things more than that. First is my teammates. They are the best I can ask for even though we didn’t win. I learnt a lot from them, and working with them is really joyful. Second I get to experience full life cycle of a product (from design, implementation to publishing and marketing). I hope to start it all over again, and this time, I am confident I will do much better (hopefully in CS3217).
In this week, we have gone into the final stage of the app and start marketing our marketing plan.
We started off purchasing a Google play account and publish a beta version of the app, as well as setting up our Facebook page. After we published our beta version and ask as many of our friends to download and use as possible, we received tons of feedbacks from them. Most of the feedbacks are actually good idea and we have implemented them. For example, our music feature originally will use tracks from users’ phone local storage. However, most users now do not store music tracks on their phones (they often stream music online). So we include our own Mindful Music into the app itself. We also find the problem explaining how the app work to the users. Although there is a tutorial session when you first install the app, most frequently asked question I got from my friends was “How the it work”. As we put the button label “Start Training”, most of them do not know that after setting the timer, you can go and do whatever you want to focus on (studying, sleeping, eating and so on), they were expecting the app to show them something for them to train. Also one lesson we learnt that many users actually don’t read our tutorial (LOL), even though they are extremely short. I learnt two lessons from this incidence. First we should release our beta version earlier and ask for feedbacks from our close friends. As developers, sometimes we cannot know what the users need as good as users themselves. In our case, feedbacks from them are very constructive and valuable ways of improvement we can consider for our app. Second, we should focus more on the UX rather than UI. I often found myself looking to make the UI as beautiful and catchy as possible without considering much about the UX. As a result, in our consultation with Su Yuen, she was completely lost in our app. We try to fix it by adding a one-time tutorial in the app, but many users neglected this and found the app confusing. We should have consult users (a random friend) about our app at a very early stage to see if he understand the app flow, and based on his feedback to design a UI that is intuitive to users.
We also decided on using stickers, posters and Facebook posts for marketing.
Cutting these stickers is a pain >.<“, luckily we managed to borrow a paper cutter so that it can be done in a few hours. We pasted the stickers in common studying areas around NUS. Unfortunately the best place to paste them is in the library, but we don’t have permission to do that so … we can’t.
Aside from stickers, we also have posters with catchy phrase to get the attention of reader and motivate them to take a look at our app.
This week, our aim is to settle part of the UI as we are having consultation with Su Yuen on Tuesday. However, the challenge and social mode was not done yet so I and Yuchuan continue to work to complete it, while Van and Derek focusing on polishing the UI.
We started off by having a meeting and decide what UI element need to be improved, compiled it into a list, then each member can refer to that list and work. In the mean time, I try to get the functionality of the challenge mode up.
While doing the challenge mode, I came across many interesting problem. Challenge mode will display a list of challenges in which the user participate in. This will be fetch from our server. Initially I want to store this list in the database so that it can serve the user faster and work offline. However, a lot of foreseen problems arise in this approach. First, when should I fetch data from the server? Should the data be fetched when user access the challenge page (this will make no difference with fetching data directly without storing as we need to make API call and wait for response), or should the data be fetched periodically (this may affect performance even if the user does not use challenge at all, and the data on challenge page is not real time). Second, if I was to store data in the database, how should I update them with new information. After asking around, I found that the correct way to do this is to attach an last_update time-stamp when sending a request to the server, and the server will return only the record that was changed. Then we have to update these records one by one in the database. However, this approach is not very applicable to our app as the challenge data will definitely changed (as the challenge involve multiple players). Hence, after consider the good and bad of storing data locally, I decide that we will not store it on the phone and the data will be fetch directly from server on the page load itself. This simplify the problem dramatically. But it will result in longer page load and higher data usage.
On the other hand, I try to help my teammates doing UI. Doing front end takes dramatic longer time than we expect. Hence, we have to reschedule the meeting with Su Yuen to Friday instead of Tuesday so that we have more to show on the consultation. During the consultation, we have some trouble building the app so Su Yuen have to wait for us quite some time. During the consultation, Su Yuen gave us a lot of questions about the UX flow of the app. I truly learned on that day the differences between UI and UX. Su Yuen get lost in the app as she did not understand how it work and did not know what to do. I realize a big problem: I have never truly put myself as a fresh user. I understand the app well because I am the app developer, but to the users who have not read anything about the app, it is not intuitive to look at the UI and understand what to do. On today meeting with Bjorn, he also briefly told us on how to study the user use case, follow that and design a UI that make sense to fresh new user. So our next mission is not to implement something that looks cool into the app, but to refine the UI so that the app flow is natural and intuitive.
After two week getting started with Android, I understand the basic workflow as well as simple transition between activities in an Android app. Now comes the interesting story between Activity and Fragment in Android.
When I first started on Android, a lot of tutorial mention about Fragment is the new style but I did not understand the idea of Fragment at that time. Activity is nice, I can make a view and put logic code inside a java class and move around from Activities to Activities, I feel I am fine with it. The need for Fragment arises when I started to implement the Bottom Navigation bar. The problem comes when you want to reuse an element across multiple activity without duplicating code (both logic and view). One example is the Bottom Navigation bar. It doesn’t make sense to just add the code for Navigation bar on every activity, and have it re-rendered in the app. I google and read about this, and I choose to use Fragment. The idea here is that you have one big activity where you put the Toolbar (the top bar) and the Bottom Navigation bar, and everything else is Fragment to hold the content of a specific page in the app. So all the previous pages has already been implemented using Activity, with this approach, I would have to convert all of them into Fragment. But I just leave them like that first, I implement two new pages as Fragment and use the above tactics, hoping to achieve a cleaner app. We shall see how this goes.
The next big thing is I also started to integrating API call to our back end in the Android app using Retrofit library. This takes a while to get things up. We need to create model and use Gson to parse JSON into Java object. And we need to set up retrofit to attach our access-token into API calls for authentication with jwt. After that things went smoothly. I really love Retrofit, highly recommend if you are looking for a library to do API call in Android. With it, making request and parsing response is an ease.