Lunar Power



Team

Rutu Samai, Matt Lewis, Eleanor Lewis, Tommy Dillon , Kelsi Damme

Project

February 2019 - Present
CSC 308 - Software Engineering
Design any application with approximately 4k lines of code using some Java.

My Role

Product Manager + UX Designer

  • Wrote Use Cases, User Stories, Functional Requirements
  • Prioritized design choices using AHP (Analytical Hierarchy Process) and CBAM(Concerns-Based Adoption Model) charts
  • Made class diagrams - Singleton, Entity Class Boundary, etc
  • Listed features, bugs, and pivots as issues on GitHub
  • Compiled final 20 page report and pitched to a 30 person class

Introduction

Overview

Lunar Power is an Android application designed to automate everyday tasks* performed on smart* devices. Tasks* can be completed at a scheduled time, when the user falls asleep (sleep mode), or during periods of low power consumption (sustainability mode).

Keywords

  • Smart- a smart appliance is one with access to the internet that can be remotely operated through internet connection.
  • Task - an executable that a device can perform.
  • Task History - A list of executed tasks* sorted by date- newest to oldest. It displays whether a task* was successfully executed or the error it ran into.

Stack

  • Language: Java
  • IDE: Eclipse
  • Storage: Oracle DataBase

User Research

Related Systems

Google Home - Speaker with Voice Assistant and Mobile Application

Pros
  • Easily compatible with all Google and Android devices
  • Conversational voice assistant
  • Use of high-quality and efficient Google Knowledge Graphs
  • Ability to recognize and differentiate multiple voices
Cons
  • Lack of privacy because Google is always listening to you
  • Must be plugged in at all times
  • Lack of control buttons on the device
  • Can’t send messages or emails

Lockitron - Smart* Door lock with Mobile Application

Pros
  • Allows multiple users + temporary guests
  • Can trigger actions from anywhere in the world
  • Unlocks by scheduled times, by proximity, or mobile widget
Cons
  • Only connects to the Lockitron door locks
  • Has several bugs with bluetooth pairing
  • Needs Bridge device to lock away from home

User Stories

  1. As a user, I want my audiobook to pause when I fall asleep, so that I can continue listening later.
  2. As a user, I want to schedule tasks* in advance, so that I can avoid doing the task* manually.
  3. As a user, I want to view my task history*, so that I know which tasks* executed successfully or ran into errors.
  4. As a user, I want to edit the device permissions, so that I can limit the application’s access to my device data and restrict its behavior.
  5. As a user, I want to view a list of compatible devices, so that I know which of my devices can be connected.
  6. As a user, I want an application that can make my roomba vacuum only when I’m asleep, so that I won’t get distracted when I’m awake.
  7. As a user, I want to run smart* home appliances at night, so that I can reduce my home’s energy consumption.
  8. As a user, I want to update my PC at night, so that I can avoid wasting time during the workday.
  9. As a user, I want my smart* home lights to turn off when I fall asleep, so that I can avoid getting up to turn off my lights.
  10. As a user, I want to receive a notification when a task* has been completed, for assurance that the task* actually happened.
  11. As a user, I only want to receive notifications during the day, so I’m not disturbed when I’m asleep.
  12. As a user, I want to receive error notifications, so that I know what went wrong when a task* failed to execute.
  13. As a user, I want my account on the cloud, so that I can access my task history* from any online device.
  14. As a user, I want to connect my devices over wifi, so that I don’t have to be near the device to connect it.
  15. As a user, I want the display to have a night mode, so that the screen isn’t hard to read at night.

Functional Requirements

  1. The system shall track when users fall asleep via the user’s smartwatch.
  2. The system shall detect and pair with user’s personal devices through wifi.
  3. The system shall execute scheduled tasks* for that day on the target device upon detecting that the user is asleep.
  4. The system shall send the user a notification each time a task* is executed.
  5. The system shall allow users to select a time and date for a task* to execute.
  6. The system shall be capable of launching updates and virus scans on standard Windows machines.
  7. The system shall provide a home screen displaying the user’s task* calendar.
  8. The system shall provide a list of compatible smart* devices.
  9. The system shall provide search capability through task history* by device, date, and task*.
  10. The system shall provide the completion status of previously ran device tasks* within the task history*.
  11. The system shall provide timestamps for the time each task* began and the time each task* was completed.
  12. The system shall provide a list of tasks* that can be executed for each paired device.
  13. The system shall provide an option to run device tasks* during periods of low, grid-wide electricity usage.
  14. The system shall store user’s data in a cloud database.
  15. The system shall provide a “configure smart* watch” feature within settings.

Storyboard

1st Draft Whiteboarding

Final UI



Class Diagrams

Use Case Diagram



Entity Class Boundary Diagram



Factory Pattern Diagram



Singleton Diagram





Sequence Diagrams

Add Task



Connect Device



Edit Task



View Current Schedule



View Task History





Design Choices

Analytical Hierarchy Process - Prioritizing Tasks

The process was scoring the requirements on a scale of 1/9 - 9 on the following factors:
Value: How important/urgent and valuable is this feature to implement in my application?
Cost: How much time and resources will building this feature require?


1 means row and column have equal value 5 means row is strongly more than column
9 means row is extremely more than column
1/5 means column is strongly more than row
1/5 means column is strongly more than row

For example, in the YELLOW box, we see that Schedule Tasks in advance is strongly more valuable than Add new tasks because users will want a single task to run in advance before adding new ones. Users may not have a smartwatch to enable the Sleep Mode, so they would want to preset times to execute tasks.

Results

From this numeric heavy analysis, the chart shows that the most high priority requirement is 1) Pause Audio Media, 2) View History, 3) Schedule Tasks in advance, 4) Add new tasks.
Though this gave me a great idea of what requirements to tackle first, the method has its flaws:

  • Requirements aren't directly comparable or independent
  • It's difficult to stay consistent with scoring and comparisons
  • Hard to quantify differences

From this numeric heavy analysis, the chart shows that the most high priority requirement is 1) Pause Audio Media, 2) View History, 3) Schedule Tasks in advance, 4) Add new tasks. As I analyzed the results, it made sense, as the Pause Audio Media would be the first task we program and thus allowing simple functionality to the MVP application.



Concerns-Based Adoption Model

Goal: Decide which device, smartwatch, and data storage option to work on first, in order to make a Minimum Viable Product.

I chose the following metrics because I found them appropriate to our design decision needs. Each metric has a different weight for each design decision based on relevance.
  • Security -Whether the device itself is secure and if we can keep our interactions with the device controlled.
  • Maintainability -How often the device get updated or a new generation is released, thus needing to change our code to match any new deprecations or additions.
  • Commonality -How common these devices are used and owned by our target customer so that we allow maximum usage.
  • Interoperability -The ability of computer systems or software to exchange and make use of information on different platforms and environments.
  • Reliability -How often these devices have bugs, crashes and how easy it is to retrieve information, documentation, and customer support.
The ratings are on a scale from [-1, +1], higher being better
The risk for each alternative was on a scale from [0,1], 1 being the most risky
The benefit score is an equation = (weighted average of the metrics’ rating) x ( |Risk - 1|
Desirability = Benefit/Cost
Results

The CBAM recommended we pursue the Amazon Smart Plug, Letscom Fitness Tracker, and Oracle Database. These options agreed with our predictions because The Amazon smart plug is a fair common, cost-effective device and the API seemed friendly to work with. The other smartwatches are costly and have high security barriers and my teammates were familiar and eager to learn Oracle DB.
Overall, the cons to an algorithmic approach to design decisions are that it’s unrealistic to fairly rank qualitative factors with numbers, so we must always use our human judgement calls, using the CBAM as a tool.



Reflection + Takeaways

Overall

Coding isn’t always the hardest part of a project. This was my first time taking 2+ months to thoroughly research and scope out a project before coding a single line. Looking back, I can’t imagine how I jumped into projects without these steps because they were integral to our fundamental understanding of the problem and best alotting time and playing to our team’s strengths.
Due to the course structure, each team member made their version of a storyboard individually, then we were allowed to collaborate. This technique allowed us to think creatively on our own, rather than piling on ideas with tunnel vision, and have a diverse set of ideas; however, it was a challenge to merge everyone’s.
Defining the goals, MVP features, and vocabulary of a large scaled project is an ITERATIVE, sometimes frustrating process.

When each of us first walked through our storyboard, it seemed like we were building completely different apps.


After combining our individual user stories and functional requirements, we spent 5 hours stepping through each member’s version and how we could combine the promising components of each. But in the following meeting, we almost completing scrapped it and started over. I didn’t expect finalizing this to take so long, but the challenge was making requirements not overlap, not showing implementation (ex. click button that triggers a database query), and being precise with any time periods or numbers.

Nomenclature

Our individual versions had a wide range of nomenclature and quite unique user journeys. In my version 1, I used the word “skills” instead of “tasks” and the user would create a “cycle” for each day composed of skills. Although, we pivoted because it seemed tedious to create an ordered list each day. It’s more practical and familiar to have a calendar setting.
Additionally, my v1 had “logs” to display the status of each skill executed, but my teammate pointed out that “logs” and “skills” were very developer oriented nomenclature, which isn’t inclusive. Developers know from their IDEs or similar that logs are the summary of all actions completed and errors. Amazon Alexa skills are a familiar concept and developers know it’s an executable task, usually paired with a device.
After several whiteboard sessions and asking random users in the library to walk through our screens and talking out loud, we decided on the final nomenclature and sequence of steps that was most intuitive.

Android App and Dark Mode

This was my first time designing an Android and dark mode app. As a primarily Apple user, I hadn’t explored much of Material design.

Material design has imaginative thought, careful emotion, and refreshing logic behind it.


There are so many amazing resources and videos about the philosophy and it values the user’s learning curve and needs. Material Design makes sure the user knows their power via clear feedback and emphasis on motion design. This is the main difference, compared to flat design in iOS which has significant discoverability and the user must guess and memorize design patterns.
My research of 30+ Android and Dark mode apps (Twitter Dark, Spotify, etc) was impactful and a visual way to understand the common flows and feedback icons, like the back button and common complimentary colors. ||Dark mode is not just inverting colors. It makes you wonder what’s essential and what’s not. As a beginner, it’s tricky to do in material design, which usually shows shadows and depth, even on black backgrounds. I could’t have done it without the Sketch template on Material Design and materialdesign.io.

Team

This team was incredibly driven and had a growth-mindset. Even when we scrapped entire designs, we didn’t take the easy way out. We meticulously investigated why a certain method isn’t working or why we’re not on the same page and solved the problems. From our Petra dinner nomming on falafels, to stress-eating Thai food and working till 4:30 AM in the library the night before the presentation, we trusted and helped one another learn various concepts and complete deliverables. I’m very grateful for this dynamic group and I’m looking forward to coding the app in the next couple of months with them.