3 ms·

The app looks good, but from the video I think, wow it would take me a long time to put in an order. I was a bartender at a downtown Chicago restaurant using A

The app looks good, but from the video I think, wow it would take me a long time to put in an order. I was a bartender at a downtown Chicago restaurant using Aloha for more than a year. Aloha is not pretty, but it's really fast. I don't want to scroll, or click into menus and tabs to then go find an order. Just put my tables in front of me as soon as I'm logged in. Trying to give constructive criticism here, so please don't take this the wrong way. Speed is everything. I almost feel like I can login to Aloha (all I have to do is type my server #), and then enter in an order for a table before I've even finished finding my name and typing in the password into your "server selection dial". Passwords are really not that important at the server level. What I am going to do, go change someone else's check? Speed. Think raw speed. How FEW clicks can I get from login to item entry. It's not about how logically organized it is. I don't want a magical experience, I want a flawless and fast experience, so that I can get back to the 500 things I have to do to service my customers. My 2 cents.

vandalizeit 15y ago
I second this. If you have ever waited tables or tended a bar, you know that speed is everything. A fast illogical system is better than a well organized system that requires several actions to get a result. You can front load the work an illogical system requires when you aren't busy, by memorizing the location of menu items, etc.
refulgentis 15y ago
This is true...one of the UI things that keeps me up at night is how to optimize that login screen. Passwords are actually important to me because of that, and I'm not sure servers IDs are really a great idea, they just seem insecure to me (the restaurant I worked at constantly was broken because servers would figure out the manager ones) and introduce a whole host of validation issues that would be frustrating to deal with in this distributed system. We'll have to look at speed a bit more - at the restaurants we've tested at, my experience once it was just pure frustration for a server at first, but after 3 or 4 shifts they settled back down into normal speed for order entry, and it ended up being a win overall because the discoverability of stuff was faster. That being said, I know we definitely have room to improve. Thanks for your feedback, it's nice to hear from someone else who worked at a restaurant, especially one that was busy and relied on the speed of its POS more than one in Buffalo may have.
- pbreit 15y ago
  If you're going to ask for feedback, you should take it! Here's a professional explaining that you don't have to worry so much about the login. A 2-4 digit code will do. Password-protect the manager login if you want, but not the servers'. This should not be keeping you up at night. What should be keeping you up at night is the ordering experience. This is where users are going to spend 99% of their time. It needs to be flawless and ultra-refined for speed and accuracy. The cascading screens and tiny "Done" buttons are not going to cut it for heavy use. Finally, you are going to need to be careful about getting feedback during a 15 minute demo. There is a grand canyon of difference between using a POS all day every day versus once for 15 minutes.
  - christopherslee 15y ago
    Sorry, didn't see these replies. But I just wanted to add, that at our busy bar, the manager's IDs were passworded. Actually, I assume they were passworded. I do not that for certain functions, the managers had a mechanism to go in a delete items or change price/add discounts etc. I'm not sure of what scenario you could commonly avoid by passwording the server ID. Maybe messing around with other server's checks happens at other restaurants (but then I assume they have a slew of other problems.) We did however have situations where I would need to enter alternate server IDs for different things. What comes to mind is that we had an ID for bar comps so that we could keep track of inventory. Perhaps discoverability makes sense in certain restaurant scenarios. At our sushi restaurant/bar, I don't know that I ever had to "discover" something?
  - christopherslee 15y ago
    Sorry, didn't see these replies. But I just wanted to add, that at our busy bar, the manager's IDs were passworded. Actually, I assume they were passworded. I do not that for certain functions, the managers had a mechanism to go in a delete items or change price/add discounts etc. I'm not sure of what scenario you could commonly avoid by passwording the server ID. Maybe messing around with other server's checks happens at other restaurants (but then I assume they have a slew of other problems.) We did however have situations where I would need to enter alternate server IDs for different things. What comes to mind is that we had an ID for bar comps so that we could keep track of inventory. Perhaps discoverability makes sense in certain restaurant scenarios. At our sushi restaurant/bar, I don't know that I ever had to "discover" something?

vandalizeit 15y ago

I second this. If you have ever waited tables or tended a bar, you know that speed is everything. A fast illogical system is better than a well organized system that requires several actions to get a result. You can front load the work an illogical system requires when you aren't busy, by memorizing the location of menu items, etc.

refulgentis 15y ago

This is true...one of the UI things that keeps me up at night is how to optimize that login screen. Passwords are actually important to me because of that, and I'm not sure servers IDs are really a great idea, they just seem insecure to me (the restaurant I worked at constantly was broken because servers would figure out the manager ones) and introduce a whole host of validation issues that would be frustrating to deal with in this distributed system. We'll have to look at speed a bit more - at the restaurants we've tested at, my experience once it was just pure frustration for a server at first, but after 3 or 4 shifts they settled back down into normal speed for order entry, and it ended up being a win overall because the discoverability of stuff was faster. That being said, I know we definitely have room to improve. Thanks for your feedback, it's nice to hear from someone else who worked at a restaurant, especially one that was busy and relied on the speed of its POS more than one in Buffalo may have.

pbreit 15y ago
If you're going to ask for feedback, you should take it! Here's a professional explaining that you don't have to worry so much about the login. A 2-4 digit code will do. Password-protect the manager login if you want, but not the servers'. This should not be keeping you up at night. What should be keeping you up at night is the ordering experience. This is where users are going to spend 99% of their time. It needs to be flawless and ultra-refined for speed and accuracy. The cascading screens and tiny "Done" buttons are not going to cut it for heavy use. Finally, you are going to need to be careful about getting feedback during a 15 minute demo. There is a grand canyon of difference between using a POS all day every day versus once for 15 minutes.
- christopherslee 15y ago
  Sorry, didn't see these replies. But I just wanted to add, that at our busy bar, the manager's IDs were passworded. Actually, I assume they were passworded. I do not that for certain functions, the managers had a mechanism to go in a delete items or change price/add discounts etc. I'm not sure of what scenario you could commonly avoid by passwording the server ID. Maybe messing around with other server's checks happens at other restaurants (but then I assume they have a slew of other problems.) We did however have situations where I would need to enter alternate server IDs for different things. What comes to mind is that we had an ID for bar comps so that we could keep track of inventory. Perhaps discoverability makes sense in certain restaurant scenarios. At our sushi restaurant/bar, I don't know that I ever had to "discover" something?
- christopherslee 15y ago
  Sorry, didn't see these replies. But I just wanted to add, that at our busy bar, the manager's IDs were passworded. Actually, I assume they were passworded. I do not that for certain functions, the managers had a mechanism to go in a delete items or change price/add discounts etc. I'm not sure of what scenario you could commonly avoid by passwording the server ID. Maybe messing around with other server's checks happens at other restaurants (but then I assume they have a slew of other problems.) We did however have situations where I would need to enter alternate server IDs for different things. What comes to mind is that we had an ID for bar comps so that we could keep track of inventory. Perhaps discoverability makes sense in certain restaurant scenarios. At our sushi restaurant/bar, I don't know that I ever had to "discover" something?