My Visit: Hours

[staticmade]

Update hours to :

• Monday 10AM - 5PM
• Tuesday Closed
• Wednesday 10AM - 5PM
• Thursday 10AM - 8PM
• Friday 10AM - 5PM
• Saturday 10AM - 5PM
• Sunday Noon - 5PM

[RubenSandwich]

@staticmade I'll update these, but considering that this is gonna change in the future I think we should have an API endpoint that provides the hours. Though maybe that should wait till the app is fully updated.

[workergnome]

I agree on both counts—I think that describing that endpoint would be a worthwhile task, though maybe out of scope for what you've agreed to do.

The medium-term answer would be to pick a URL and hang a static JSON file out at that URL that returns the data, but that can be a next-step.

[RubenSandwich]

@workergnome That sounds like a good plan. I'll just update the hard coded times for now.

[RubenSandwich]

I changed the view slightly:

Old:

New:

If this does not work then please send me some Mockups and I'll work off those.

[staticmade]

That looks good. Can you add some top padding above the "Monday, Wednesday, Friday and Saturday" text and change Tuesday's "0am to 0am" to "Closed"?

Thanks! On Tue, Sep 29, 2015 at 3:42 AM Ruben Niculcea notifications@github.com wrote:

I changed the view slightly:

Old: [image: Old Hours View] https://camo.githubusercontent.com/dcd551d4b867ba295d0161863ebb2c0ce208c118/687474703a2f2f727562656e6e69632e636f6d2f7374617469632f696d672f4f6c64486f7572732e706e67

New: [image: New Hours View] https://camo.githubusercontent.com/938b259334b552cb77d0a1a9d64d7193d770eecb/687474703a2f2f727562656e6e69632e636f6d2f7374617469632f696d672f4e6577486f7572732e706e67

If this does not work then please send me some Mockups and I'll work off those.

— Reply to this email directly or view it on GitHub https://github.com/cmoa/cmoa-app-ios/issues/2#issuecomment-143975072.

[workergnome]

If I were to provide data that looked like:

{
  "@context": "http://schema.org",
  "@type": "Organization",
  "url": "http://www.cmoa.org",
  "foundingDate": "1895",
  "sameAs": "https://en.wikipedia.org/wiki/Carnegie_Museum_of_Art",
  "contactPoint" : {
    "@type" : "ContactPoint",
    "telephone" : "+1-412-622-3131",
    "contactType" : "customer service"
  },
 "name": "Carnegie Museum of Art",
 "logo": "http://www.cmoa.org/logos/images/PNG/CMA_LogoType_Vertical_Black.png",
  "location": {
    "@type": "Museum",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Pittsburgh",
      "addressRegion": "PA",
      "postalCode": "15213",
      "streetAddress": "4400 Forbes Ave"
    },
    "openingHours": ["Mo,We,Fr,Sa 10:00-17:00", "Th 10:00-20:00", "Su 12:00-17:00"]
  }
}

How much work would it be to integrate that? It's schema.org format.

If we wanted to be fancy, we could use https://schema.org/OpeningHoursSpecification, but that might be over-complicated—or might be more specific.

(Not a huge priority, and not a requirement)

[RubenSandwich]

@staticmade Yup that's a bug. Good catch Jeffery, I'll fix that now.

@workergnome The only problem I have with that format is the time format makes it difficult to parse. (We use the time to determine if the museum is currently open, etc.) I searched for a schema.org format parser and wasn't able to find one for Objective C/Swift, do you know if that time format is known by another name? I could write a parser for it, but I'd rather not and I think that is beyond the scope of this project.

I did some initial work on making the code more dynamic based on this data structure: (But I'm not married to it)

[{open: true, opens: 12, closes: 17},
 {open: true, opens: 10, closes: 17},
 {open: false, opens: 0, closes: 0},
 ...
]

The one other thing we have to worry about when dynamically loading the hours is how we want to structure the presentation. Currently we group all the similar times together, but which times are similar is currently hard coded in, I'm guessing we are gonna want to do that in the future?

[workergnome]

Hmm. I totally agree that the schema.org format is unfriendly. I think that it's trying to encapsulate reoccurring data, and it causes problems for data consumption. (It's quite nice for data entry, though.)

In trying to imagine a API endpoint that's more reusable for this, I would assume that you would pass in:

• The ID of the location that you want the hours for (warhol, CMOA, CMNH, Science center.)
• An array of dates for which you'd like the hours.

and you'd get back an array of those dates, with the hours.

{
   "@context": "http://schema.org",
   "@type": "Museum",
  "name": "Carnegie Museum of Art",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "validFrom": "2015-10-1",
      "validThrough": "2015-10-1",
      "opens": "10:00:00-5:00",
      "closes": "17:00:00-5:00",
      "dayOfWeek": "http://purl.org/goodrelations/v1#Monday"
    },
    {
      "@type": "OpeningHoursSpecification",
      "validFrom": "2015-10-2",
      "validThrough": "2015-10-2",
      "opens": null,
      "closes": null,
      "dayOfWeek": "http://purl.org/goodrelations/v1#Tuesday"
    },
    {
      "@type": "OpeningHoursSpecification",
      "validFrom": "2015-10-3",
      "validThrough": "2015-10-3",
      "opens": "10:00:00-5:00",
      "closes": "17:00:00-5:00",
      "dayOfWeek": "http://purl.org/goodrelations/v1#Wednesday"
    },
    {
      "@type": "OpeningHoursSpecification",
      "validFrom": "2015-10-4",
      "validThrough": "2015-10-4",
      "opens": "10:00:00-5:00",
      "closes": "20:00:00-5:00",
      "dayOfWeek": "http://purl.org/goodrelations/v1#Thursday"
    },
    {
      "@type": "OpeningHoursSpecification",
      "validFrom": "2015-10-5",
      "validThrough": "2015-10-5",
      "opens": "10:00:00-5:00",
      "closes": "17:00:00-5:00",
      "dayOfWeek": "http://purl.org/goodrelations/v1#Friday"
    }
  ]
}

(I'm working hard to have all data returned from the theoretical API be JSON-LD, which is more work but will help future-proof what we're doing.)

Not 100% sure how best to represent periods where it's not open—thinking about nulls, but not married to them.

I think it's important to return the time-zone: it lets us translate this information into timezones per-user. (We have visitors from out of state, and I could see that being useful for "Is it open now".

Again, this is mostly an exercise in thinking through this stuff, and trying to give you a heads-up where I'm coming from. No need at all to implement this—hardcoded values are fine in this version, particularly since this API doesn't exist.

[workergnome]

Regarding the grouping—personally, I'm not sure that it's more obvious to the user than just having an explicit box for each day. I could potentially see grouping if there were regular patterns, but given that there are only two consecutive days that have the same hours, I think it's confusing to group them.

But I realize that takes more space, so I'm comfortable with the current solution in the interim.

[RubenSandwich]

Yeah, it seems that the OpeningHoursSpecification is strangely silent about what to do if it is closed. I too would rather avoid null and suggest leaving out the offending date. The problem with this approach however is that you need the keep track of the query to completely make sense of the response, which I don't like either. It really is a pick your poison type of situation, as the spec is silent. May I ask why you are keep going back to the schema.org format? (I'm just wondering what the motivation is.)

I do agree that a box for each day is easier to quickly glance and gain the information, but less elegant and more screen real estate especially on a mobile device. Perhaps fiddling with a new way to present the information might be helpful.

[workergnome]

RE: box layout

I'm open to suggestions for improvements to this, but no need to extend your scope at this point. I'm sure we're going to take a good look at this and have much better ideas once you're around in person, and a quick fix now is all we need.

RE: schema.org

Mostly, I'm looking for an existing ontology for the information, and the http://www.heppnetz.de/projects/goodrelations/ schema seems to be the most broadly-supported one. We could define our own schema, but in general I'd prefer to leverage other people's work—slightly more code, perhaps, but the documentation exists already.

The only other thing I've seen is http://openinghours.io/openinghours.pdf, but it doesn't seem broadly used, and it requires iCal data.

I'm opposed to leaving out the date—the ambiguity of "did I not ask for it or does it not exist" is worse than trying to parse a null value. The other, probably worse option I've thought of is to have a 0-second duration between open and closed, but that's even more messy. Conceptually, it also violates the open-world assumption, and I'd prefer to build these APIs using that assumption. We just have too much uncertainty in too many of our data-sets to rely on missing information to indicate falsity.

One solution that we could try, if we wanted to simplify, would be to add in our own property to the result that indicates if it's open of closed at all on that date—not opposed to that. We could also return the date, but have no "opens/closes" properties.

Aside

I realize that this is sort of noodly, but I'm thinking through and trying to prove that we can use JSON-LD and existing ontologies as valid, workable API responses. It could turn out that I'm wrong, and that the conceptual load required is too large to make it work.

[RubenSandwich]

@staticmade How about something like this for the spacing of new first cell: (This is a mockup.)

The time no longer sits at the same location across each cell, but it does fix the top spacing issue.

[staticmade]

Looks good. Thanks!

[workergnome]

How hard would it be to throw a rule between the map and the list?

[RubenSandwich]

@workergnome What do you mean by a rule?

[workergnome]

Sorry—a darker horizontal line, like the one above the map

[RubenSandwich]

Not too difficult just a quick subclass and an additional layer added.

[RubenSandwich]

Alright added the dividing line and fixed the placement of the title and subtitle of the top cell.

[staticmade]

This view looks great. Issue closed.