COGS 187A-Week 8: The Implementation Hustle

Author: Kathy Vo

Team Members: Jake Browne, Wesley Chan, Chris Korkos, Pargat Singh

Let it be known that all members were present this week.

As the day of the shark tank presentation get closer each day, it was time to make the transition from hi-fi prototypes to implementation. While there is the benefit of being allowed for a Wizard-Of-Oz type of implementation, that did not mean we were going to slack off during this process. While we should never stick strictly to one idea, it was important to advance the process and finalize every detail before proceeding to full on implementation, as we aimed to do. The goals of this week were to finalize our hi-fi prototypes and organize front-end and back-end implementation.

Guiding Questions for the Wack Panther

How can we implement heavy amounts of information for users to easily understand different parts of a player (availability, level, etc) without risking design?

What are the main features that require immediate attention for implementation? Which ones can we freely ignore?

Reviewing Hi-Fi Prototypes

As this week marked the end of prototypes and the beginning of real implementation, it was necessary for our group to review each screen of our app and make any last edits before proceeding. During recent meetings, there had been confusion over certain aspects in some screens, so this provided a good time to gather all our thoughts together and pinpoint where the confusion originated.

During the prototype review, we also finalized how each part would be implemented throug Android Studio, especially for the Create Raid Form. For example, if you had to input a raid type, is text-based for the user or do we provide them pre-made options? If you pressed the menu bar, does it slide right or dissolve? These were the questions we addresse during prototype review, which spanned over all three days with some side conversations about XML assignments (to be addressed later).

The Struggles for Availability

Although it may seem like a small component to spend so much time on, one of the biggest issue we addressed was the display of one’s availability. The whole point of this app was to find people who not only shared the same views on raids, but also had similar availabilities to do so. From previous testing, users hated our initial Google-inspired calendar. Hence, we played with several variations.

Wesley introduced the group to an app called Calendly, which provided time slots for people to match up their schedule for meetings. This made us think whether we wanted to show the user’s time or whether it matches up the viewer’s availabilities. In other words, if X was viewing Y’s profile, it would say “you have 9 matching time slots on Wednesday.” Due to the complex nature of both coding implementation and the numerous variations in providing time (someone could be free all day vs. something who only has hour chunks of times through the week), this idea was scrapped.

Because it was taking so much time, we wondered if we should just give up and provide a text-based viewing of availability on profiles. People had varying forms of free time to play, and this was the easiest way to accomodate for that. We agreed that this would be our last resort.

Finally, we agreed on a grid-version of availability on the profile. This provided both a quick way to organize and visual heavy information usually associated with scheduling.

Key changes were made from this review:

1. We would throw out any indications of whether raids were present within certain days or not. It was too lengthy of a conversation that wasn’t necessary when many users during testing flipped through all days anyway.
2. Add a Notification Option in the Menu bar so users know whether their raid requests were accepted or asked for. We discussed what clicking each notification would allow the user to do (i.e. if you tapped on a notification that says “StarLord wants to join your raid Vault of Glass at 10am,” it would provide options to view StarLord’s profile, accept/reject, and message StarLord).

Aesthetics

Throughout the prototype review, we also discussed the visual aesthetics for our app. As we aimed for a sci-fi look, we agreed to move from a soft blue palette to a cyan-based one. While we loved the brightness, we had to be careful overdoing it as it could easily become too bright and dizzy to look at. In general, the goal for aesthetics was to keep it sleep and bright without making the app look like it belonged in a TRON movie (TRON Legacy was amazing by the way).

XML Screen Implementation

Very early on on the advice of Pargat, our lead coder, we had decided on implementing our app through Android Studio. Beside learning how to use Design View on Android Studio, we assigned certain aspects of the app screens accordingly to each member of the team. For the sake of time, we decided to hardcode dummy users and populate existing raids.

We prioritized certain screens that were most important to showcase for the shark tank presentation. The ones that weren’t necessary were the Friend List, Settings (self-explanatory as we only planned for a “Change Email/Password” option), and the Tutorial (we’re demonstrating at the shak tank anyway).

With this plan in mind, we begin our implementation over the weekend and throughout Thanksgiving.