19lmyers / cse110-w21-group14 Goto Github PK

Description:

Since we are automating the pomodoro cycle, we need to be able to automatically add in long breaks after every 4 pomos

This means we want to implement a visual cue for users to track pomos completed.

Checklist:

The implementation should:

• Easily seen and easily understandable
  • Is there a logical way to add a counter without explicitly labeling it "Pomos done"?
• Be portable to smaller screens
  • If adding the counter to the side, need to figure out a way to have it move correctly when resizing the window.
• Not complicate design too much
  • Keep it simple.

To prepare for presentations, we want to write additional unit tests for every section of our app.

This will make sure our app runs smoothly and doesn't break! :)

Unit Tests

splash screen

• enter button closes splash screen

timer text

• timer text displays pomo time
• timer text displays short break time
• timer text displays long break time
• timer text starts time
• timer text updates time
• timer text ends timer
• ignores start timer if already running
• ignores start timer text if already running
• ignores set timer text if already running
• timer text displays negative time

timer buttons

• start button starts timer
• end button pauses timer and triggers confirmation

sounds

• plays button sound when settings button clicked
• plays button sound when close button clicked
• plays timer complete sound when pomo ends
• sets sound to beginning if already playing

There are many ways to implement some sort of way to notify the user of what task they are currently working on. While the most obvious way to do this is a task list, consider the development time and whether the user truly needs something so comprehensive. An alternative could be an editable text box that serves truly functional purpose - all it does it allow the user to track what task they're doing right now (see Momentum's focus feature, which allows the user to type in their focus and check if off once it's complete to get a "congrats" message).

Checklist:

• Brainstorm task possibilities
• Implement task functionality

Overarching Decisions - we will eventually capture these as an ADR in markdown (/specs/adrs will contain an individual document per major decision. There will be some initial ones that have to do with general project plan and approach, but more may be added as the project goes on. The main point of this capture is to explain why choices are made. As brainstorming may have your team settle on choices quickly capturing them in a document may be better than just mental consensus)

Description

In order to keep everyone on the same page and help teammates understand what every one is going through, we've decided to do daily standups through Miro.

Checklist

Create a miro template for daily standups that is:

• Easy to look at
• Works asynchronously
• Fun
• Quick and Fast
  • Should take less than 5 minutes to fill out

System Diagrams - we will eventually capture how your app will be decomposed in C4 diagram, event modeling diagram, or UML form

Interface Design Documents - we will initially capture "fat marker design" later extended with wireframes and high fidelity prototypes (/specs/interface/rough, /specs/interface/wireframes, /specs/interface/highfidelity; These directories may contain single or multitude of documents)

Checklist:

• Complete rough design
• Complete wireframe (low-fidelity)
• Complete high-fidelity design

Description:

Implement settings. Should include:

Checklist:

• Decide on which settings we want to include for the Prototype
• Review coding standards and commenting standards
• Use the event modeling diagram from Miro to guide code organization!
  • Feel free to send a message if you don't understand anything or want anything explained!

Suggested code from Justin:

• Read settings
• Have button initiate custom event settingsChanged containing what has been changed
• Add event listener to timer app to update based on custom event

After pushing:

• Create a pull request!
• Link the pull request to this issue
• Move this issue to "Pending Review"

Description

In order to make sure our timer can run correctly, we need to test it thoroughly!

This is really important!

It's going to be these test cases that ensure the most important part of our timer doesn't break.

Unit Tests

timer app

• creates a new timer
• when timer begins, start progress bar
• when timer runs out, stop progress bar
• when timer ends early, clear progress bar
• wait 5 seconds before ending pomo
• warns before leaving app

pomo cycle

• schedules short break after pomo
• schedules pomo after short break
• schedules long break after 4 cycles
• schedules pomo after long break

Unit Tests:

progress bar

• starts progress bar at pomo
• starts progress bar at short break
• starts progress bar at long break
• ignores start progress bar if already running
• updates progress bar
• stops progress bar
• clears progress bar
• progress bar text changes from short break to long break

https://canvas.ucsd.edu/courses/21783/assignments/259323

Project Roadmap - we will capture a roadmap of how the product will evolve both here in the quarter as well as ideas of how it might grow beyond the time we have with (/specs/roadmap.md)

Currently, new URLs will show the filename (i.e. website.com/app.html) instead of a cleaner URL (i.e. website.com/app). There's a method to do this through HTTP redirects; explore a method to do this for our pomodoro app.

Local storage should get previous settings and the number of pomodoros completed so far if they have been stored. It should automatically update when one of the settings change. This should be implemented as a final feature to ensure consistency. Inspired by Lab6 (Shop).

In preparation for presentations and deployment in the final week, we're going to spend the last week tying up any loose strings and polishing up any unrefined code.

Description:

Since we are using a step progress bar, we'd like to be able to implement the functionality so it'd reach each point based on the timer.

Checklist:

• HTML setup is completed
• Timer functionality is implemented
• Check HTML formatting of progress bar supports step progress bar
• Implement step progress bar
• Initiate pull request to request for code reviews.
• Attach pull request to this issue.

Description

Now that we've done away with the idea of having concrete pairs, we might want to rediscuss how we're going to approach branching during development, testing, and pipeline modifications.

Checklist

• Discuss possible ways of branching
• Form a concrete branching standard
• Write ADR

Description

The base HTML file will be the structure for the entire document. Unlike other parts of the app (functionality/style), this needs to be finalized as soon as possible.

Checklist

Create HTML for...

• Splash page
• Timer app
• Settings
• Finalize skeleton

In preparation for presentations, we're going to need to tidy up our github and organize it in a way that is presentable to the class.

The organization should reflect our process and be easy to understand at a glance.

https://canvas.ucsd.edu/courses/21783/assignments/277675

Description:

In order to prepare for our first merges and inevitable git conflicts, we need a couple of you to read up on git. This is to make sure that no problems arise and our deployment goes as smooth as possible.

Checklist:

• If you're completely new to git:
  • Start by reading chapter 2
• If you're familiar with git basics (undoing things, tagging, setting up a repo, recording change to repo, aliases):
  • Read chapter 3 here and chapter 5 here
• Then, read up on github

Make sure if you skip the basics, you are comfortable explaining any of the listed topics to the entire group

• Be prepared to explain to members who don't understand

Modify the rules in the JSLint config file so that code linting works properly. Base it off of the coding conventions in our ADR.

• Probably should be done together during the code documentation meeting

Description:

Checklist:

Description

Timer functionality is vital to the innate functionality of the Pomodoro app. Use the timer-test branch and other JS files as a reference in this implementation.

Checklist

• Implement timer start functionality
• Implement timer stop/reset functionality

With the minimum viable product complete, we need to refactor and document the codebase to ensure it's clean.

Plan: Begin separating each class in main.js into its own components file, and update index.html accordingly with the new component. The goal is to make sure each component is individually controlled. Note that an underscore before a method indicates that the method is private. Below are the specifications for each component:

TimerApp

Do this last and keep in main.js, as it is not a web component.
The primary controller. Handles big events in timer by calling on its child components at the right times.

• constructor(): creates a reference to all other components, initialize settings, create event listeners as needed
• handleStart(): handle start of timer
• handleEnd(early): handle end of timer depending on if it was ended early. Sets page title back to Pomodoro.
• handlePause(): handle pause of timer
• handleContinue(): handle continuation of timer
• cyclePhase(): cycle to next phase and return next phase
• resetPomodoros(): reset number of pomodoros completed
• playSound(): play sound for buttons
• playComplete(): play sound for completing a pomodoro or break
• confirmEnd(): create confirmation dialog for ending a pomodoro before timer expires
• confirmReset(): create confirmation dialog for resetting all pomodoros

TimerText

The timer text that counts down from 25:00. This timer inherently doesn't automatically start or stop itself. Like a countdown timer that ticks forever (almost like a pomodoro timer), this timer can be started, stopped, and set to a particular time.

• constructor(): creates timer-text with initial time of 25:00 (or testing time).
• start(): start timer and begin updating text and page title
• stop(): stop timer
• _update(): update timer status, text, and page title.
• setTime(time): set the pomodoro time to passed in time (seconds). Timer must be stopped to set time.
• get timeString(): Get the current time as a string (eg. 25:00, 10:06, 05:04, etc)

TimerButton

The timer button that runs the app. Already a component.

• constructor(): creates timer-button with START as initial text.
• set buttonText(text): sets the button's text.
• set buttonAction(action): sets function to call when button is pressed. Note: testing is needed to see if this works. If it does properly call functions, we can do the same for other components such as ConfirmDialog.

TimerInfo

Deprecated. Rather than holding TimerInfoSessions and TimerInfoProgress, just remove it in favor of the two components below.

TimerSessions

The indicator for the number of timer sessions. Currently pending on whether it should hold the current number of sessions.

• constructor(): Initializes timer-sessions
• set sessionsText(sessions): Sets the number of sessions.

TimerProgress

The progress bar for the timer and already a component. Similar to TimerText in functionality: it can start, stop, update, be set, etc.

• constructor(): creates timer-progress and sets properties
• start(phase): starts progress bar based on the given phase. Only one bar can run at a given time.
• _update(): updates running progress bar.
• stop(): stops running progress bar.
• set pomodoroTime(time): set the pomodoro time passed on (seconds). Timer must be stopped to set time.
• set breakTime(time): set the break time passed on (seconds). Timer must be stopped to set time.
• set breakText(text): set the break text passed in.
• clearPomodoroProgress(): clears pomodoro progress bar.
• clearBreakProgress(): clears break progress bar. Note: may be able to be merged with above method to create general clear() function if both are always used together.
• set pomodoroDot(complete): sets completion status of pomodoro (first) dot.
• set breakDot(complete): sets completion status of break (second) dot.
• set doneDot(complete): sets completion status of done (third) dot.

TimerSettings

Handles the settings page and dispatches events indicating updates and resets.

• constructor(): creates timer-settings and adds event listeners.
• syncSetting(updated, toUpdate): Updates corresponding number/slider when slider/number is updated.
• openSettings(): Open settings dialog.
• closeSettings(): Close settings dialog.
• updateSettings(): Dispatch settingsChanged event with new settings to TimerApp.

TimerSplash

The initial splash screen.

• constructor(): creates timer-splash screen.
• close(): close and remove splash screen (make sure to account for event listeners before calling Node.remove())

ConfirmDialog

A generic confirmation dialog.
-constructor(): Initializes the confirmation dialog based on the existing template.

TaskList

TODO

Document code:

• Start after refactoring
• JSDoc for all classes, properties, and functions
• Comments in large, hard-to-understand code blocks

Checklist:

• Refactor main.js
• Document code

Description:

In order to help us focus on javascript implementation, we want some basic css styling to declutter the website so people can focus on making their respective components functional.

Checklist:

• HTML File is set up.
• Elements are spaced out logically to allow for js implementation
• Basic coloration of elements.
• Immediately start pull request for review
• Attach pull request to this issue.

Description

Since we are going to be using github as our primary workflow manager, we need to restructure our repo a little bit.

Our github file structure probably doesn't need much tweaking, but the most important part is that it is organized so team members will use it in a meaningful manner.

We basically just need to make it our own.

Checklist:

• First: Read up on GitHub if not already familiar with it
  • https://git-scm.com/book/en/v2 (book version, long but in depth)
  • https://learngitbranching.js.org/

Organize folders in a way that is:

• Meaningful
  • Each folder must have a purpose and be aptly named to describe what it should contain.
    • For example /specs/ contains all forms of documentation that set standards for our project
• Easy to use
  • When we need to find a specific file, we should be able to find it quickly
• Compatible with development process
• Finally: Write ADR for repo organization!

We also need to establish a way to use github as our primary workflow manager. This means setting up the backlog, issues + labels, and figuring out a way to organize them.

Backlog functionality:

• Create system for workflow using github
• Fix projects tab
• Update tasks and assignees
• Finally: Write ADR for work flow

User Centered Thinking Documents - we will produce personas, user stories, and potentially use cases. (/specs/users will contain this but user stories chosen will also be represented as issues to work on)

Checklist:

• Create personas
• Create user stories
• Create use cases

Look into timer implementation in JavaScript and create a basic prototype.

Description

In order to save ourselves from headaches later on and to keep our code uniform and easy to read, we need to establish coding conventions this week.

Checklist:

• Establish meeting time to discuss coding conventions
• Research into the coding standards used at current organizations
• Discuss and explore possible ideas
• Write ADR on what is decided on

Look into local storage, its capabilities, and how it may be applicable to the Pomodoro timer.

When a pomodoro is complete, a sound should play to alert the user's attention. The sound is up to you, but try to keep within the theme. Implementation should be similar to the Car Horn lab, but plays once the timer end (i.e. TimerApp's handleEnd()).

Description:

Our event modeling diagram currently does not visually break down our flow to show what aspects of our web app is affected by each command.

We should update our event modeling diagram to display command effects on functions. This will make task formation and task execution much easier.

Checklist:

• Update UIs on Miro to match latest flow implementation on Figma
• Create sections for the main functions of the timer app (Settings, Progress Bar, Sessions Tracking, and Timer)
• Rewrite event modeling diagram to include these categories (use store/state category)
  • Refer to an example or the event modeling website if help is needed.
• Update us in #workupdates!

Description:

In order to maintain code readability and document generation, we need to set concrete commenting standards. This will make reading peer code much easier too!

Checklist

• Read up on JSDocs
• Think about document generation and what is necessary for our project
• Come up with suggested conventions and write them in an ADR
• Present them at next meeting
• Finish writing ADR

Description

Refactor CSS

Checklist

• Change Figma prototype to use resizable spacing
  • Currently the prototype is using absolute spacing and padding. We need to update this so that it can be used on both mobile and desktop.
• Label prototypes with new relative units
  • Now that the prototype is using relative units, label elements (such as buttons and fonts) with relative sizes if possible.
  • This will make styling a LOT easier in week 8
• Read up on basic CSS if little prior knowledge (or ask someone with more experience for suggestions on variable conventions!)
• Create universal css variables for usage in Week 8 styling.

Currently, our app uses an alert() style notification for its end/reset confirmations. Create a dialog that allows the notification to pop up in the app (the timer should still keep running, however).

<dialog> will work, but watch out for compatibility issues in browsers

Unit Tests:

confirmation cards

• confirmation ends pomo session- [x] continues timer after cancel
• ignores continue timer if timer already running

https://canvas.ucsd.edu/courses/21783/assignments/259323

Project Pitch - we will produce a project pitch that will be presented to your team mentor for sign-off. We will use the ideas from Shape Up to guide this process. Teams looking to get ahead are advised to read this book now.

Unit Tests

settings

• settings button opens settings
• close button closes settings
• save button triggers update
• save button updates settings
• error thrown when pomo text input outside of range
• error thrown when pomo length text input outside of range
• error thrown when short break text input outside of range
• error thrown when long break text input outside of range
• pomo text input changes slider pomo value
• pomo slider input changes pomo text value
• pomo length text input changes slider pomo length value
• pomo slider input changes pomo text value
• short break text input changes slider short break value
• short break slider input changes short break text value
• long break text input changes slider long break value
• long break slider input changes long break text value

Implement a warning right before the user closes the window (eg. Are you sure you want to leave this page?) so that the user doesn't accidentally close the tab unexpectedly.

There's likely a way to alert or ask for confirmation from the user in the same style as alert() (don't make new HTML elements, just use what's built-in to JS).