Dining work

[rosslebeau]

Just adding this as a point for correspondence and reference for the Dining module work.

[intrepidtong]

@rosslebeau Good Call.

@justinanderson I'm pasting all the questions in my email here as this might be a better place for them

iPhone

• Single Dining Hall Screen: What is the expected experience when the user rotates devices to compare venues? In the current app a daily view with different dining halls in columns is presented. We were unable to find any design/mockups/direction in the documentation.

iPad

• Dining hall home screen navigation bar: do we support “swiping to next week”? The wireframes seem to indicate that we do not. Just wanted to make sure. In addition, if there is not swiping, do weeks always start with Monday?
• The wireframes seem to suggest the dining hall home screen should support portrait mode, by shrinking down to 3 columns. What happens to the weekly navigation selector in portrait mode, does it just shrink to fit the screen width?
• When a user is in map view (viewing other dining options) and then taps on “Dining Halls”, does the app return to dining hall home screen, or remain in map view and show dining halls on the map? The wireframes indicate that dining halls can only presented on the home screen, not on a map. Just wanted to double-check.
• Map View: are the pins tappable? i.e A user should be able to access pop over by either tapping on the dining option on the last pane, or tapping on the pin, correct?
• Map View: want us to take a stab at designing the map pins?

[samvoigt]

@justinanderson We're going to have to do some refactoring so that we can re-use components for the iPad version. Our preference when doing this is to do a quick re-build the data model so that it leverages restkit, is more properly integrated with the new view controllers, and better mirrors the webservices, like we did for events and shuttles. However, this would result in users losing any venues they've currently favorited. Thoughts?

[justinanderson]

@samvoigt It should be possible to preserve favorited venues across data model changes. I'm ok with switching it to RestKit, just be aware of what you're getting yourselves into with the landscape comparison screen if your data model changes require modifying that view controller.

[samvoigt]

@justinanderson sounds good... I looked at the comparison screen, and I think we'll be ok there... famous last words, of course...

[justinanderson]

@samvoigt For a good time, load it up in Xcode 6 and do 3D view debugging on that screen. It has so many layers of scrollviews.

[justinanderson]

@intrepidtong @MIT-Mobile/intrepid-devs

iPhone

• What is the expected experience when the user rotates devices to compare venues?

That should be left as is for now. We should come back to it later when there is more time.

The expected behavior is that it should show a scrolling collection view of all menus from all venues for all meals that we have data for, allowing the user to swipe between meals in a continously paging scroll view. The current implementation is a big mess both from a view hierarchy and from a data standpoint, but it's functional enough to leave as is.

iPad

• Dining hall home screen navigation bar: do we support “swiping to next week”? ... do weeks always start with Monday?

Our data source only ever provides the current week's meals, so even on Sunday we can't say what tomorrow's Monday will offer. In the longer term we should be getting more data, but for this, that's the best we get. And yes, it's always Monday to Sunday with these menus. And always the same meals each day: breakfast/lunch/dinner on weekdays and brunch/dinner on weekends.

• What happens to the weekly navigation selector in portrait mode, does it just shrink to fit the screen width?

That's correct, Dining should support a portrait orientation. The intention is to have flexible whitespace between each day so that they all fit on screen in any orientation.

• The wireframes indicate that dining halls can only presented on the home screen, not on a map. Just wanted to double-check.

That's correct. Dining Halls only show as a collection view on the iPad.

• Map View: are the pins tappable? i.e A user should be able to access pop over by either tapping on the dining option on the last pane, or tapping on the pin, correct?

Yes, the pins are tappable as well.

• Map View: want us to take a stab at designing the map pins?

Sure. We'll want to use the same numbered pins here in Dining as well as in Maps, Events, and Tours. Jason took a stab at the pins earlier, but those are all too close to Google Maps-style pins for my taste. I would prefer something closer to classic map pins like Apple uses, with a ball and needle, as that minimizes how much around the point of interest is obscured by the pin.

[justinanderson]

@MIT-Mobile/intrepid-devs Are you in need of sample data, or does that fake data already in the repo meet your needs?

[samvoigt]

@justinanderson Is there any way we could get the mobile-dev webservice to return sample data that has the dates adjusted for the current week (i.e. it would reset the dates in the dummy data to be for the current actual week each monday)?

[justinanderson]

@samvoigt I'll look into it. Should be pretty straightforward.

[justinanderson]

@samvoigt That should be working on the dev server now: http://mobile-dev.mit.edu/apis/dining/.

[samvoigt]

Awesome thanks so much!

[loganwright]

@justinanderson

I'm running into some problems displaying the HTML properly in the "Retail Info Screen" because of the differing HTML formats.

Added Top WhiteSpace Some include a <br> tag, or a <div></div> tag, or a <p></p> at the top which adds additional whitespace that is difficult to predict. (about 30-35% seem to have some sort of added white spacer). This makes accurate placement from restaurant to restaurant awkward.

Can these tags be removed on the backend?

There's also a lot of general formatting issues such as having a closing html tag as the first text in the HTML description. Everything is currently displaying properly (aside from whitespace), but its difficult to account for all of the possible edge cases and I just wanted to make sure you were aware.

Best,

Logan

[justinanderson]

@LoganWright I'll see what we can do. Looks like that's only happening on the production server at the moment.

[loganwright]

@justinanderson - Thanks!

[justinanderson]

@LoganWright I've got a temporary fix in place on the dev server now. I copy pasted the venues from production into the fake data we're providing on dev and then put some filters in before it gets sent off. It'll be about a week before we have that in production, but let me know if I missed anything.

[loganwright]

@justinanderson - Looks great on my end!

[rosslebeau]

@justinanderson Didn't see anything in the docs about this: For the iPad dining hall screen, do you want the main collectionview to be paged and swipable? e.g. you are looking at dinner on the 28th, swipe the middle of the view to the left to page to see breakfast on the 29th?

[justinanderson]

@rosslebeau No page swiping or animation when changing meals in iPad Dining. But we do want page swiping for iPhone meals.

[rosslebeau]

@justinanderson Just making the iPad's meal selector view (in the nav bar) and I'm grabbing all the meals for each venue and ordering them by date, since the OrderedSet of meals doesn't give context between venues. One thing I noticed is that a certain venue has a meal without a date. It's technically listed as optional in the docs, but without a date I can't know where to place it in regards to the other meals.

I could hard-code the meal names but I preferred doing it this way to be as robust as the API allows for.

[justinanderson]

@rosslebeau I haven't seen any meals without dates, but there are occasionally meals without times. It happens sometimes because we merge meal hours and menus from two different sources, and one is filled in by people who often put meals under breakfast instead of brunch.

The app was supposed to handle that gracefully by merging the two, but I see that it actually just drops meals without a date. It probably makes more sense to resolve this server-side, so I'll update the dummy data on mobile-dev to not have that issue and make the live server merge instances of breakfast and brunch into the appropriate meal.

[rosslebeau]

@justinanderson ah I was unclear, I am using the "start_time" as a comparator. Simmons appears to have a breakfast without one.

Ok thanks

[justinanderson]

@rosslebeau The test data should have times for every meal now, and no days with both breakfast and brunch.

[samvoigt]

@justinanderson In the main dining call, are we always going to get back announcements and links, or will there be a case where we just have venues? I'm assuming always, because the API doesn't list them as optional, but right now there aren't any links coming back, so I just wanted to confirm... Additionally, could you provide some links in the test data for testing purposes? Thanks!

[justinanderson]

@samvoigt Whoops, sorry about that. It's in the test data now.

[samvoigt]

@justinanderson Will meals from the webservice come down in order (i.e. breakfast will be first in the array of meals, followed by lunch, followed by dinner), or should we enforce order locally on our side based on timestamp (in the old version, the meals were ordered based on name and not time)? Thanks!

[justinanderson]

@samvoigt You should enforce the sort order of meals yourself.

[samvoigt]

@justinanderson How do you want this to look when multiple filters have been selected:

Should it go: icon, text, icon, text or: icon, icon, icon, text, text, text, or some other way? The current version just shows icons without any text. Thanks!

[justinanderson]

@samvoigt

• One item: icon and text
• Two or more: just icons

[transitmark]

@samvoigt @rosslebeau

It's not completely correct but could you do something like this for fixing the dates and times?

https://github.com/MIT-Mobile/MIT-Mobile-for-iPhone/tree/3.6/ipad-dining-mark-dates

(edit: it needs a little more error checking but it's a rough idea)

[samvoigt]

@justinanderson for the retail venue descriptions that had trailing whitespace, it looks like that was mostly server-side. For example, the Jerusalem Cafe Food Truck description has a bunch of extra random HTML on it. I'll clean it up as best I can for entries that don't have extra HTML, but parsing on our side is tricky (there's already some code in there to remove some crufty HTML, but obviously not all of it).

[justinanderson]

@samvoigt don't worry about cleaning up HTML app-side. Better to have it come across correctly in the first place. We'll tweak that server-side.

[rosslebeau]

@justinanderson I cannot reproduce the strange ipad meal selector view bugs we encountered on friday. I have tried test server, prod server, and switching between the two. Sam has fixed the date issues and I've made some changes to the meal selector as well, which I believe would have fixed the problem anyway. Just letting you know, if you can reproduce these sometime when you are testing (after we've gotten this week's fixes in), please let me know so I can take a look at it ASAP.

[justinanderson]

@rosslebeau I can't reproduce that weird collection of meals either. I imagine that's because the menus changed this week.

[samvoigt]

@justinanderson For the building names for the Dining Retail Venues, where should we be pulling these names from? e.g. we'll get a room number which we can map to W20, but where do we get Stratton Student Center from?

[justinanderson]

@samvoigt From the same /apis/maps/places/ list as the Maps module. Ideally, there would be one shared data model for that info across the app, so Maps, Dining, or another module could fetch that data once and cache it in core data, and then subsequent queries for place info would happen locally without a need for more network calls. That data will be needed for the Building Services module as well.

[rosslebeau]

@justinanderson re: rotation, I'm pretty confident I've found a way to reliably forward the "supportedInterfaceOrientation" calls to the appropriate viewcontroller. It seems that if you unselect an option in the xcodeproj file, allowing that option in the top VC will not work; however, if you select ALL options in the xcodeproj file, disallowing certain options in the top VC does work.

At any rate, I think we should probably hold off on this until after the hamburger/navbar stuff is complete, but its good to know that we should be able to do any customization you want per module/VC.