-
Notifications
You must be signed in to change notification settings - Fork 1
All Meeting Notes
Top > Bottom
:Recent > Oldest
Past 2 weeks
- Matt did some UI testing and added design issues to the repo
- Chuck shared API env vars so we can tie up the UI to the API
- DSW call - they shared that they have collected venue data, we should be able to just add this to our DB, so we don't need to do any coordinating with the venues
Remaining work
- Organize remaining task cards better
- Complete Rewards page and intro page copy
- Tie up API to APIService in the UI
- Add password to login
- Basic Signup email template, and make sure signup works via UI (still needs to be tied to API)
Testing (once API is attached)
- Test if geofence marks locations as visited (if it routes to "you discovered x" page, it works)
Status
- Location
- Ability to check in (still working on validation)
- Insert an address - Google geolocation services API injects the coordinates for us
- Need to get with ben to build a UI for the venue managers to manage their location
Looking at the front end and creating data models that the UI will expect from the back end
Link to Data Models Spreadsheet
- User
- Venue
- Prizes?
Other notes
- Will use Rails Administrate to easily manipulate db (this thing's awesome 🎉)
- Jacob used this geofencing JS snippet on Northwoods app, should work for us
-
Andy update - No pushes, off next 2 weeks
-
Mapbox stuff - Paul is very frustrated and making no progress
- Chris / Jacob will take a look too
-
Back End - No updates
- Chuck has admin rights on repo, but he says he's still on board
-
Available to Work
- Drey
- Jacob
- Chuck? Reach out to him on monday
- People update
- Tracy is leaving :(
- Andy is allocated to DSW engagement
- Drey is on board!
- Jacob is bench in early june
- Paul going 100% Synchrony in June
- Back End
- Jacob is taking it
- Needs to handle
- Add + Query User
- Add + Query Venues
- Update and Query Visited Venues for a user
Front End
- Map on mobile - Paul
- Venue Detail - Visited State - Drey
- Onboarding Screens - ?
- Lots of Dev! first phases of...
- Header complete - Andy
- About complete - Andy
- Map placed - Paul
- Venue list - Andy
- Rewards placeholder - Andy
- Venue api - Chuck/Tracy
- No updates on design but the whole foundation of the app is complete
- Prizes?
- Lets make prizes just progressive additional entries into a contest
ToDo:
- Venue Detail view - Andy
- Mapbox mobile location, use location in a component - Paul
- Geofencing - Jacob
- Record a Venue's Geocoordinates to db - Tracy + Jacob
- Detect whether we are in a fence - Jacob
- Back end - CRUD Venues - Tracy
- Back End - Create user, set/reset password - Tracy
- Back End - What venues each user has visited - Tracy
- Design - Ben
- Should be able to start dev work from these designs
- Starting a project, so need to have someone else own design
- Components Ready to build:
- Landing
- Map + Locations List + Banners
- "You're at" check in modal
- Venue Detail + You checked in here banner
- Rewards menu slideout
- About the App slideout
- What's left to Design
- Collect location + email UIs
- You just unlocked a reward! UI
- Who's taking what
- Header - Andy
- Info page - Andy
- Venue List - Jacob
- Owning Design - Ben
- Prioritizing
- Venue list
- Venue Detail
- Map
- Geofencing
- Map with locations
- Saving to database
Back End Contingency Plan
- Chuck is moving so he can’t teach Go and BE dev at the same time reasonably
- Contingency plan: Rails
- Everyone has been given access to Rails repo for stuff we’ll need
- Postgres
- BCrypt
- Chuck will doc out APIs with user stories and acceptance criteria
- No code progress
- Design - Ben created artboards for each screen we'll need, allowing anyone to pick one up and design them
- Jacob RIP? :(
- Tracy wants to pick up the back end stories. Work with Chuck on his progress
Jobs TODO:
- Venue list placeholder - Chris
- Map - Paul
- Tabs - Andy (hold until tab design decisions are made, POC Ben)
- Design updates (Kyle, Ben)
- Starting to play with some visual directions
- Components we build now should not be opinionated at all on the design side - just make em work, clean up later
- Dev Update (Jacob, Andy, Paul, Chris)
- ❗️ Jacob - No progress on tabs - blocker: client work
- ✅ Andy - Header, burger menu merged in - completed
- 🔄 Paul - Map, finishing up unit tests - blocker: webgl in unit tests
- ❗️ Chris - No progress on Venue list placeholder - blocker: client work
- Jobs To Do
- Tabs - Jacob
- Venue List - Chris
- Layout
- SCSS variables
- DSW Folks did not attend
- Ben made great progress on Low-Fi designs
- Focuses on Venues Visited and Venues Remaining
- Still needs:
- Reward/Congrats msgs
- Milestones for # of visits
- Accounts
- Caching data
- We only really need their email once they hit a certain number of locations
-
NOTE:
- We should ask if there are special events (band at 7pm, talk at 6:30pm, etc) -
DECIDE
- If DSW decides this is a two-day event, do we persist the location data, or start the count over on the second day? - Go Repo
- Chuck is playing with the logistics of a monorepo
- Wants to prevent unnecessary builds by detecting which end (front/back) a commit is changing, so we only kick off a build and deploy on that end
- Still playing with it
-
Still need
Landing page for a desktop site
Jobs to Do
- Begin lo-fi components
-
IMPORTANT
: Make sure to link up with other devs before starting to develop the layout of the page - Tabs -
OWNER
: Jacob - Header -
OWNER
: Andy - Map placeholder -
OWNER
: Paul - Venue List placeholder -
OWNER
: Chris - Drop color palette into SCSS variables
-
- Design
- Venue Detail
- Signup
- Landing page for desktop
-
IMPORTANT
- Next meeting (March 6) will include DSW team! Prepare questions! - Re-Deciding feature set for CRAWL
- No need for Sched API Integration
- Need user accounts
- Need admin portal for venues
- Geofencing for locations (require user location services)
- Keep record of locations visited
- Instagram integration to see live photos of venues and encourage engagement (swag if you tag #companyDSW)
- Design team working on low-fi designs
- WHY: When this is delivered, the dev team can build low-fi components! Design and dev can then work in parallel
- Friday 2/22, Chuck leading beginning of API development
- Reviewing completed work
- Andy added Heroku deployment
- Jacob added Docker
Notes
-
DECISION:
New meeting time 1pm Wednesday - better for building momentum and separates the overlap with Team Mercury -
First Wireframes
- These are high level to give front-end a direction. Development should not aim for pixel-for-pixel as these designs WILL change
- Vague components
- Nav bar w hamburger menu
- Venues tab, events tab
- Map
- List (venues, events)
- Venue detail, event detail
- NOTE: Denver Startup Week has a Startup CRAWL within it. Is our app for crawl or for week?
- CRAWL
- Idea: Social media sharing, whatever company has most photo uploads with #somehashtag wins, this should nudge the companies to incentivize the visitors to upload (swag, etc)
- We can pull insta pics into the app
- SOD
- Ask Chuck for his progress on back end
- Jobs To Do
- NOTE: This week is thin on responsibilities. These items are not immediate.
- Set up front-end containers based on wireframes
- Get Chuck's back-end repo integrated
- Questions
- How are people going to get here?
- When will users get context into what it's for? Before visit or on first visit?
- Will we allow users to build their personal schedule / Crawl?
- Would this require user accounts? Probably.
- Where will this live?
- Seems like the best spot would be within the main DSW site, but how would that work?
- Do we gamify with a raffle or contest?
- Do attendees sign in to something on the DSW website, and if so should we piggy back on that?
- How many sign ins do attendees and venue admins have?
- Do we have any constraints when it comes to mobile gestures? How would those translate to desktop?
Venue info
- Name
- Distance?
- Chuck - Apiary
- Used to document API
- https://app.apiary.io/stmbl/editor (requires invite, ping chuck if you don't have one)
- Using route parameters to execute actions, rather than putting verbs into the api endpoint name (see apiary docs for details)
- Automatically -pulls routes from- and -pushes docs to- master in our github repo
- Decision: Monorepo
- Front and back end will be hosted in the main repo
- Requires docker config for project
- Jacob's PR
- Configs are set up in
package.json
-
package.json
-
vue > css > loaderOptions > sass > data
- This config always imports
styles.scss
into every scss file - Removes the need to import variables etc. into every single scss file
- This config always imports
-
- Adds End-to-End tests
- We can add end-to-end tests after a section is stable / feature complete
- Adds Unit tests
- we should shoot for 100% coverage on unit tests
- Router - Generated by CLI, gives us lazy loading :)
- Observables -
- Jacob is playing with them
- We probably won't use the full potential of observables, but we will get good practice
-
'@/'
notation on ts imports- Gives you access to the
src/
level
- Gives you access to the
-
.vscode
directory- Will suggest extensions that Jacob has tested and work
- Configs are set up in
Jobs
- Chuck - Leading the charge on setting up back-end boilerplate
- Jacob - taking Docker Monorepo setup
- Paul
- Figure out solution for github notifications
- Create Decisions manifest
- Design
- Meeting Thursday to complete wireframes
Retro
- Pros
- Happy with how we're using github
- Improve
- Git flow (pure) sucks with github - Use modified version
- Just use branch naming, and then merge dev into master at stable release points
- Decisions should be tracked in github Issues
- Create a decisions manifest - wiki
- Github discussion notifications on issues sucks - Paul figure out a solution here
- Git flow (pure) sucks with github - Use modified version
Notes and Discussion Items
-
Ben put some rudimentary wireframes together!
-
Is there value in showing the map for the Events view?
-
Check map constraints; if someone scrolls away, can we reset the map?
Using Google Maps API- think this will allow area constraint or map resetting. (Which approach is better from a UX perspective?)
-
We will need to design admin pages.
-
Orient new users. (Use a cookie?) Are we doing a raffle again? We'll need to let people know they can sign up and what that means. (If they need to sign up, only ask for necessary info- name, and maybe email?) Let users know that they should go to basecamp to check in and get started. Don't require that they sit through a lot of screens in case people have already done this. Maybe provide an option to show check in on the map and navigate to it (but only if the user initiates)
-
Only venues will have ability to edit information in the app.
-
Would it be beneficial to include admin links in the app? (link for venues to edit their logo, image, etc and/or link to edit event details in sched)
-
Decrease clicks by having map still navigable on venue detail pages.
-
What do we do about parts of Dev Week that aren't talks? Can we take the Basecamp category and present that information differently?
-
What happens if a company gives a talks at a venue that's not another space? Can we distinguish venues and companies? Can we sort by companies giving talks?
NO. API does not provide variables for Company, just Venue. This means:
- We will not be able to sort view by organization giving the talks
- We can work around this by putting in a general search in case people want to see talks by particular companies (or on specific topics, for that matter) so long as the information is input in Sched
-
Mobile first! Consider how this scales up, though.
Let's start development!
- 2-2:10 - Overview of Wiki
- :10-:15 - Review Feature Set
- :15-:40 - Prioritize Features
- Core delivery - What's required in Stumbl to be a usable app if we only get 50% done?
- Ideal delivery - What's a "full product"?
- Stretch delivery - What would we add if we finish early?
- :40-3:00 - Choose February owners
Notes
- Reviewed Wiki and Phases of Production
- Prioritized Features into Core (C), Full Product (F), and Stretch (S)
- Probably need to adjust phases of delivery to accommodate
- Chose Points of Contact (POC) for upcoming work (See Phases of Production to see who's assigned)