Master the art of managing your restaurant online

Tips, tutorials and data to help you make the most of Ordr.in’s restaurant tools.

Hacking the dining experience

Posted by David
 

Ordr.in is psyched to participate in FoodTech Connect's Hack Dining this weekend. We shared these thoughts with them. Reposted here.

__

In the old days hungry diners like me had relatively few places to learn about restaurants and low expectations for the experience when we sat down. Not that we thought the food would be blah or the service indifferent, but that, more or less, you sit down and follow the script as given. Want sauce on the side? You are one of those kinds of people. Most of us stayed in line.

Today tons of information- from Yelp reviews to health department scores- focus our attention on small differences between restaurants.

There is a yawning gap between a diner’s information and a restaurant’s. This is where the dining experience needs to be hacked.

I choose my restaurant based on many factors- location, cuisine, price. Am I eating alone on the road or close to home with my kids? Looking for someplace familiar or new? As a rule of thumb I will eat in a specific restaurant about every six weeks. All those other meals? Your experience didn’t align with my interests.

The restaurant on the other hand, is standing in line next to all the others, hoping to get picked like a 4th grader in gym class. A restaurant menu changes seasonally, if that. Customers change by the hour.

The ultimate hack is unlocking data to create a service experience that is about me, the customer, not what the chef and manager dreamed up before opening for business.  The more you know about what I want in the moment I want it, the more orders you’ll get from me.  A huge opportunity for your bottom line.

I’m not suggesting overhauling your menu for each customer every day. I am thinking about all the ways you interact with a customer- the email newsletter, social media, how well you understand my order history to remind me of what I love about you. Maybe the food too. Find me where I am online and let me order- don’t force me to come to you.

This kind of hack would make me happy and dine with you more often. All those extra orders will flow to your bottom line. We should all get behind this. And start hacking.

 

Ordr.interns + 1: Building a Swift API Library

Posted by David
 

[Our ordr.interns and part time dev (who was an intern last summer) were just at the beginning of some projects and after Apple announced Swift, we were all reading the Swift book. It occurred to me that best way to learn is by doing - and so three days of madness ensued. And to be clear, by doing I mean them doing and me watching. --felix]

The future is here! You can now write code to order food directly from your iOS apps...in Swift! The Ordr.interns built an alpha Swift API wrapper and it is now available for everyone to use.

 

The story

As we began to settle in to our second week as interns, David and Felix suddenly called us aside for a mysterious meeting. They asked how we would feel about dropping everything we were working on to make a wrapper for the Ordr.in API in Swift, the new language that Apple released last week for iOS development. After a few minutes of discussion, we excitedly jumped right into getting started. It’s not every day that you get to dive into working on the bleeding edge of technology - last week at Ordr.in, we did exactly this. Building quickly was necessary in order to get a head start on being relevant in the rapidly growing community forming around the new language. With the buzz around Swift exploding, we had our work cut out for us if we wanted to finish this in time to keep up with the hype (especially with experienced iOS developers already implementing games like Flappy Bird in Swift). We had three days to build the wrapper to support the entire Ordr.in API, and we gladly worked hard to get shit done.

 

Our experiences with Swift

The three of us had absolutely no experience with iOS development prior to this project. We had to go through the hoops of learning a new language in a new environment (Xcode) with no resources other than the language specs and Google. We had three days to do this, so we plunged headfirst into hacking on the API wrapper figuring things out as we progressed. Little by little, the nuances of the language revealed themselves to us in the form of errors that we deduced how to fix. We picked up on subtleties such as arguments being immutable inside the body of a function. This is a clever move on the part of the language’s designers because changing the values of function parameters inside of a function could potentially cause unexpected side effects. The fact that parameters are immutable by default forces the developer to follow better practices.

 

We all come from a Python and JavaScript background, so it was great to see patterns that reminded us of these languages. Allowing function arguments to have default values like in Python was great, and we were also able to pass around callback functions like in JavaScript. Optional parameters are also allowed, which gives us the ability to write more generalized code for making API requests. With this comes the concept of “unwrapping” variables, which may cause some seemingly obscure compiler errors if you are not in the right mindset while getting used to Swift. We thought that it was an interesting choice to require names for all function arguments except for the first one, when calling a function. This was weirdly annoying for us at first as we were making a library that was not very iOS specific, but this pattern makes more sense in the domain of building iOS apps.

 

Hurdles we went through when getting started

Online resources like Stack Overflow were relatively barren because the language was literally one day old. The Swift docs that Apple provided were comprehensive, but did not really touch on anything specific to Xcode, Objective-C or iOS. Although these can be found elsewhere, we spent a lot of time wrestling with problems in this domain. Xcode would spontaneously debug our program even with no breakpoints. When we would make HTTP requests, the execution would hang and the message “lldb” would display, representing the debugger prompt. This was solved by configuring Xcode to not debug executables. We also found it extremely annoying that Xcode displays a clickable error symbol right on top of where breakpoints are set. It was frustratingly easy to accidentally set a breakpoint by misclicking next to an error prompt. Learning how to manipulate the Xcode environment effectively was actually harder than picking up the language itself. This speaks to both how easy it is to pick up Swift with prior coding experience as well as how clunky Xcode can be if you are unfamiliar with it.

We spent a while trying to figure out the best way to package our API for other developers. We’re aware of Cocoapods, the dependency manager for Objective C, but we were unsure of its compatibility with Swift. In the end, we decided to just include instructions on how to import our code manually. While Swift code can usually be dragged and dropped for ready use, our API requires an extra installation step because of the Objective C code that is mixed in. One note: import statements are not necessary for Swift code contained in the same target.

 

Setting the standards

Swift is a language that does not have any accepted standards or best practices yet. When trying to look for examples of what other people have done before, there was very little to find. We found very few open source projects to base ideas off of, although we did learn about how HTTP requests work in Swift via an open sourced framework we found called Agent, written only hours before we started working on the wrapper. The open source community around Swift is sure to grow immensely in the coming days or weeks, but there is still so much room for discussion. Given that our project is open sourced, we hope to help other prospective Swift developers who may not have many examples available to work off of. We are glad to be part of the earliest group of Swift programmers, and look forward to seeing where the language and its community will go in the near future!

 

Our impressions of Swift

Sam: I personally haven’t written code in a typed or compiled language in a while (too many fancy scripting languages #hipster). It was both enjoyable, yet slightly annoying, to get back into that mindset. Swift is obviously more fun to write than something like Java because of all the similarities it shares with my preferred languages, and because Apple really tried hard to make it more accessible/developer friendly. I liked that it was not super verbose (unless you compare it to Python), and that we could work quickly in it. Including variable types in function arguments promotes more self documenting code, which is something I highly value. I think most of its quirkiness came from the fact that we had no idea what we were doing at first, but I would say Swift does exactly what Apple intended it to do by lowering the barrier of entry for iOS dev. I can see myself hacking in Swift again if I ever want to make a quick iOS app.

 

Eric: After skimming through the Swift docs, I was intrigued by how different it was from my preferred languages (JS, Python, C). I was excited to try it out and play around with new features like optionals which I haven’t worked with before. Unfortunately, many of the problems we ran into during development were related to XCode and the way it sets up projects. The actual programming involved was fairly trivial and I wasn’t able to play around with the language as much as I’d liked. That said, Swift (not XCode), has left a good impression on me and I hope to use it more in the future!

 

Polina: It’s been a relatively long time since I jumped onto a previously unfamiliar to me language, so the challenge of diving head-first into unexplored syntax and rules was refreshing. The lack of explicit standards and examples, beyond the simple textbook samples that the docs gave, brought an extra level of enjoyment. Speaking of the documentation, it is rather complete and covers most questions one would have about Swift, which makes it possible to quickly jump into the coding. That being said, Swift has its hidden peculiarities (as mentioned above), although it’s fully possible that they were inherited from Objective C - the primary language of iOS development up to this point.

 

 

Food Ordering on the Yelp Platform with Ordr.in

Posted by David

Ordr.in’s mission is to improve the ways restaurants and consumers engage and transact. Powering new food ordering experience is our passion. That is why we are so excited to partner with Yelp to help expand food ordering on their Platform. 

On average 132M people each month use Yelp to connect with great local businesses. Now, in more cities from more restaurants, they can complete their search with a transaction without leaving Yelp.com or Yelp’s mobile apps. A win for consumers, restaurants, Yelp and, of course, Ordr.in.

Ordr.in open APIs are used by developers and publishers of all kinds  to build food ordering experiences that drive business results. If you can dream it, you can build it with our APIs. The Yelp integration is a classic example of what Ordr.in is all about. We are thrilled to work with Yelp. 

If you are curious about what you can do with Ordr.in, check out our developer portal, see what’s in our app gallery and reach out to brainstorm. And if you are a restaurant that wants to take orders from Yelp and all of our partners, register or reach out for more info. 

Yay Yelp! Yay Ordr.in!

Ordr.in joins AirPair's API Partner program. W00T!

Posted by David

More and more we hear from individuals that have great ideas but not the skills or bandwidth to build the food ordering app of their dreams. Over time we’ve collected a short list of developers and agencies that know our platform well. Today it's getting even easier to find help for Ordr.in development.

 

Today we joined the AirPair API Partner program, which helps connect technical experts quickly and painlessly with those in need. AirPair will help our users solve issues faster and unlock the full capabilities of the Ordr.in platform.

 

  • Gargoyle: Based in NYC, the Gargoyle team is expert in mobile app development. These guys get. Stuff. Done.
  • Five Minutes: With offices in NYC and Croatia, Five Minutes offers a wide range of design and development services.
  • Fueled: A premier mobile strategy, design and development shop, they’ve worked with an amazing array of brands and startups.
  • SourceFuse: With office in India, the UK and the US, this tech development shop literally works around the clock.

 

If you care about doing more faster, check out AirPair and our experts.

App Spotlight: Pizza The App

Posted by David
 

Pizza The App is an app for ordering pizza at the tap of a button. It makes ordering a pizza delivery as easy as ordering a Lyft or Uber. You create your pizza, and we route your order to our network of hand-picked local pizzerias.

 

What inspired you to create this app?

We were hungry in our kitchen late one night! We were like, “there should be a button for ordering pizza!”

 

What was the hardest moment building it?

We’ve got work cut out, so maybe our hardest moment is ahead of us :)

One of our ongoing challenges is being as reliable as possible, so we never have to turn down a customer who’s in the mood for some ‘zza. We have a network of hand-picked, highly rated pizzerias, and we’ve built a fallback system so that if a restaurant is closed or non-responsive, we route your order to another awesome local pizzeria. Ordr.in has been instrumental here.

We call our software stack PaaS (Pizza as a Service) - read the blog post!

 

How did it evolve (if at all!) from how you thought of it at the beginning to what you've launched?

It’s gotten even simpler - fewer screens, faster loading, less input needed from the user. We’re having fun seeing how far we can push this, how easy & fun we can make it to order a pizza.

 

What's next for the app?

We are super focused on pizza. It’s a food people love - it’s popular, delicious, shareable, and open late.

We’re constantly listening to users to find ways of making the experience even easier, more reliable, and more widespread.

 

What technologies and APIs did you use?

Besides Ordr.in, we’ve had a great relationship with Stripe, Google, Twilio, Heroku, Sendgrid, and GitHub. PizzaTheApp would not exist if not for these awesome services! This is the problem Google founder Sergey Brin wanted to solve in the 90’s, but was too difficult then so they did Google instead :)

 

How can people check out the app or get in touch if they want to find out more?

Want pizza? Visit --> PizzaTheApp.com

Find us on Snapchat/Twitter: @PizzaTheApp

Email: pepperoni@pizzatheapp.com

Announcing the Windows 8 and Windows Phone SDK!

Posted by David

Many a startup has been more harmed than helped by working with large brands. But when Microsoft offered to work with Ordr.in we jumped at the chance. The result of this partnership is an SDK and reference food ordering app for Windows 8 and Windows Phone. We are thrilled and you should be, too.

Ordr.in’s mission is to power new and innovative ways for restaurants and consumers to engage and transact. Windows 8 and Phone offer unique user experiences. Developing for them unlocks imagination. We are excited to see the developer community rise to the occasion.

Many thanks to our excellent friends at Microsoft, especially EIR Tereza Nemessanyi and developer Steve Maier. These guys and their colleagues really know how to get things done with startups.

Happy hacking!