- Model changes reflecting web service
- Facebook Login
- Activity spinners throughout the app
- New organisation info screen replacing map screen
- UX Issues
- Skip login
- Outstanding bug fixes
Facebook login is mostly ready to go on the iOS side, barring FITUser model changes.
- New model changes for FITUser
facebook_id
gender
age_range
- ...
- New route:
/oauth/token
- Params:
facebook_access_token
(this is already wired up) - Returns:
access_token
- This route will have to integrate with Facebook to obtain (and ideally update) users.
- Params:
Skipping login is the means to continue into the app anonymously. This has been shown to affect conversions, as many people want to see value before they give away their data (and we have no onboarding screen to prove ourselves).
To acheive this:
- Add button to login screen to skip
- Logs the user in with the anonymous user
[email protected]
- Check for anon users and restrict / update the UI in the following views:
- Account view
- Favourites view
- Event schedule view (as we check for passes)
- On booking button pressed
- Check for anon user
- If anon:
- Bring up login screen
- Log user in
- Show payment screen / show alert saying you need to login (if login fails)
- Else proceed as normal
It's frustrating to not know when the app is loading data in the background. The UI gets confusing and data can appear out of date or disappear before your eyes. Note that we don't want spinners everywhere right now. For example, the account section works fine from the cache, and only needs a network update to 'check' if the cache needs updating. Spinner's here would just slow down the experience.
Spinners should only show during the first load of data for that screen (after a period of time). Once downloaded, the cache is up-to-date (although another check does still happen). For example, if I load an events schedule, I'd want to see spinners once for each day.
To achieve this:
- Add spinners to:
- Venue list table view (each day needs a spinner)
- Event schedule table view (each day needs a spinner)
The model changes affect the app significantly. This is because the entity relationships are used frequently throughout the app.
To achieve this:
- Update API model:
- FITAPIUser
- FITAPIOrganisation
- FITAPIEvent
- FITAPIVenue
- Update Realm model attributes:
- FITUser
- FITOrganisation
- FITEvent
- FITVenue
- Update Realm model relationships
- TBD
- Add Realm migration for old app users
- Observe every view and change where needed
- Add stacking to map view
- Event schedule now needs organisation as well as venue
- It needs this to say 'get me events at this venue for this organisation'
- Venue view now shows organisations and their associated venues, rather than just venues
I need the model changes to be in-place on the webservice side before I can begin this part. I don't foresee the need for any new routes just yet.
Allows users to make more informed decisions without leaving the app and potentially booking elsewhere.
To achieve:
- Modify event cell to include fitter rating, a longer textual description and a calorie count
- Add new Organisation / venue hybrid page containing:
- Organisation info
- Name
- Description
- Cancelation policy
- Instagram feed
- Venue info
- Address (w/ link to map)
- Amenities available
- Organisation info
New attributes are needed on several model objects:
Organisation:
- Description
- Cancelation policy
- List of Instragram images w/ metadata such as username
Venue:
- Showers
- Towels
- Yoga mat
- Cycling shoes
- Trainers
- Lockers
Event:
- Calories
- Fitter rating
- Kit requirements
The dashboard needs to have the ability to add all of the above data, most of which will be done manually.
All of the above data needs to be found on the organisations websites and input into the system via the dashboard.
To change:
- Swap around 'Login' and 'Create account' buttons
- Map view needs to show all venues
- Class count should take availability into consideration.