zendesk / linksf Goto Github PK

• Data representation for facilities and services
• Querying support
• UI for picking hours

Description

The search link doesn't do anything right now; we should hide it.

http://cl.ly/image/3x190f3n3C0j

We'd like a nicer design for the filter page that will be broken out from the list page.

So either the filtering has to be hoisted up into the query (possible?), or we have to be willing to go back for more data if none is retrieved.

@osheroff will host link-sf.com on Amazon S3.

Resources can have multiple services associated with them. Add a UI in the admin page to be able to add more than one service.

google doc: https://docs.google.com/spreadsheet/ccc?key=0AkkJeKqc-HDpdE5INXRRYVdMVmd5ay15dm5LZEdPLWc#gid=0

We need this fixture data to:

1. build the user frontend
2. build the admin frontend
3. act as a reference for the Parse backend

The end result should (probably?) look like a json array of objects that look like the schema:

name:        string
addr:        string
description: string
phone:       string
hours:       object
notes:       string
geopoint:    geo
demos:       []
services:    []

Need to figure out a way for everyone to deploy. Right now only Ben and Ken can deploy.

Stealing this from Yelp:

Yelp has a textual description of the current query right under the nav bar. That would be good to have.

Right now the per-service hours is treated like a free-text field.

Some examples:

"Tues-Thurs 11:30am-1:30pm"
"Tues 5:30pm until food runs out"
"Thurs 1:30pm"
"Sat 12pm-3pm"

Other services don't have any recorded hours at all (value is null).

We need to do two things:

1. Decide on a consistent format
2. Update our current service hour data to fit this format

Service hours will probably need to be optional. The selected format should be designed around making the following as simple:

1. editing from UI
2. detecting 'is open now'

Blocked by #17.

In general there hasn't been a final decision how we're going to calculate if a facility is open or not. There will likely be three states - 'open', 'closed', and 'unknown' state when we lack hours information or the information does not give us a conclusive measurement. The indicator in the facility view should read from the isOpen() function on the Facility model.

Retrieving coordinates via navigator.geolocation.getCurrentLocation is unpredictable. If a 'near' query is made, we should defer firing the query to Parse until we receive coordinates.

We currently make the request to Parse immediately instead of waiting for the callback that contains the coordinates.

ref: https://developer.mozilla.org/en-US/docs/WebAPI/Using_geolocation

When the landing page query submits, we want to include a search by name in our Parse query.

This is one of the final blockers for handing the admin UI over to the Tenderloin Tech Lab team. Marking as high priority.

Blocked by #16.

The facility model has a function isOpen already. The behavior will probably look something like this:

// the facility has hours information and we can calculate that it's open:
facility.isOpen(); // => 'open'

// the facility has hours information and we can calculate that it's closed:
facility.isOpen(); // => 'closed'

// the facility has hours information but we can't calculate if it's open or closed:
facility.isOpen(); // => 'unknown'

// the facility does not have hours information:
facility.isOpen(); // => 'unknown'

For consumption in #18.

are we doing infinite scroll?

map, basic styling, pull data in

The menu should provide two options:

1. get directions from current location
2. get directions from a user-provided location

Note that this issue only concerns displaying the menu, not implementation of either retrieval option.

@stevenyan thoughts? UI inclinations?

@bEElz1 has provided an updated mockup for the Link SF homepage. From the mockup below, we first want to implement the following:

1. New UI chrome
2. New category buttons
3. New category icons

Exclude for now:

1. The "near" search
2. The Search button.

@shajith let's add an "all" option here instead of making users unselect "men" or "women"

A blocker for beginning concurrent working threads is deciding on a schema to build against.

Individual services rendered at each facility commonly has its own hours, notes, and supported demographics. We whiteboarded and decided on having two first class objects in our data model- facility and service.

Our schema will probably look something like this:

facility has many services
service belongs to facility

facility:
  id: integer
  name: string
  addr: string
  description: string
  phone: string
  hours: object (derived from aggregate services)
  notes: string
  geopoint: geo
  demographics: array (derived from aggregate services)
  category: array (derived from aggregate services)

service:
  id: integer
  facility_id: id
  name: string
  description: string
  hours: object
  notes: string
  demographics: array
  category: string

Resolution of this issue is contingent on having fixture json which we'll need to translate from the original google spreadsheet.

Description

Design a nicer hours input UI for the admin UI that enforces consistency for our hours formatting.

@bEElz1 can you take a look at a resource page that we have today and produce a design inline with the homepage look/feel? Reference #39 .

Key items:

• Navigation bar at the top
• Resource name
• Hours
• Demographic allowed
• Provided services
• map
• clickable phone number
• Directions link (invokes Google Maps UI)
• Information section

suggested: http://stackoverflow.com/questions/1608548/how-to-trigger-a-phone-call-when-clicking-a-link-in-a-web-page-on-mobile-phone

Description

In addition to changing the filter from the list view, the initial query should be done from a landing page.

UX/UI

See below.

Acceptance criteria

1. This should be the landing page of going to link-sf.com
2. Tapping on any of the buttons should render a search result that filters results by housing, food, medical, technology, or hygiene.

Test site working on an iOS simulator as a smoke test.

We can only make location-based queries that use the current location from navigator.geolocation. We want to support making queries using arbitrary locations (with the intention of allowing the user to input a starting location).

This is an investigation task. Priority of implementation depends on required effort. This can be considered complete when we have evaluated our options and have some idea of required effort.

Description

@osheroff has apparently started on an admin UI. Expose this UI so we can prioritize additional work against what is editable on the resource listing.

As a web browser, I want to be able to see more results.

As a mario, the princess is still in the other goddamn castle.

Description

The filter UI is currently using basic form elements:
http://cl.ly/image/3K2F3a0d1E0u

Update the filter UI to have more tappable pill-style buttons

UX/UI

http://cl.ly/image/0V0J0q3e2d2y

Acceptance criteria

1. Tapping each text string (e.g. "Name" or "Distance") should highlight the pill
2. Tapping "Cancel" should close the filter without running a filter query
3. Tapping "Find" should filter the results by the selected search criteria.

Right now only the facility name is linkified - we should be able to tap anywhere in the list item element and be routed properly.

Right now it seems to render the page scrolled down to the map (roughly). Try it on your phone to repro.

We need better icons for the categories:

Housing
Hygiene
Food
Medical
Technology

We're using (glyphicons halflings from bootstrap)[http://glyphicons.com/] but we don't have a suitable icon for food or hygiene- I don't think using a shopping cart is a good idea.

The full-size icons provide decent-looking icons for all the categories above, but we'd have to do the sprite calculations ourselves and possibly resize.

@bEElz1 Any ideas? you mentioned there were some other options here. Thanks!

Description

Right now we have a placeholder, "pretend these are hours for the moment". Render proper business hours.

http://cl.ly/image/1k41050F2g2e

Depends on

#16

The filter dropdown should instead be a separate full-screen page.

Designed in #47

TTL would like an 'About' page accessible from the landing page. We don't have any content to go there yet, so just add their contact info available from the TTL website for now and we'll loop back with them about it later.

We should also ask Tiffany what Zendesk information/branding we'd like on that page, if any.

If you scroll through a listing and your thumb happens to catch the map, the scrolling will stop and the map will scroll instead. @roseleaf can we lock scrolling of the map? The main use case of showing the map is just to give some context to the location of the resource anyway.

• Phone call link
• Directions link

do it!

We used to have this, but forgot about it in the filtering UI redesign.

We should add a 'back' button to the list page that takes the user back to the landing page.

User testing feedback showed that many testers missed the filter button entirely, we should make it more prominent.

We don't need this to expand - we can just have the per-service notes all visible and have users scroll.