This is true.

This feels wrong. If you’re going to ask for my name only for asking sake then it shouldn’t be there in the first place. I suggest that if it’ll remain, you could use it to address the user in future replies (it’ll create some sort of bonding).

Finally, if there is a way you could tell that the user doesn’t want to supply a name, you can add a fun twist to it and call the person J. Doe (J could be Jack or Jane that’s why I left it as “J.”)

Cheers :thumbsup:


It’s not for asking sake. It can be used to address the user in future bonding, like you said, as the bot gets more conversational powers.


I’d be happy to contribute/look at how we can make the data more structured for easy discovery for the bot.
The blog might be a bit of a stretch for the bot - unless it’s Alexa/Siri


Bot is neat AF for an MVP! People keep obsessing over the wrong things. This is a major breakthrough in my opinion. EDL has been sitting on a mountain of data and they can now monetize (in a way that is probably not optimal as food delivery companies are dropping like flies) but provides great UX to the gallery. I see this happening in hotels almost immediately. Hotels even need it more.

@timigod and @Nosaaaa My little contribution to the bug list. If you can’t find an option, take the person back to a nice question like “would you need more help?”


Can you explain this




I’m glad you like. My thoughts exactly.

I’ll add your thoughts to the bug list…


Great stuff. Few points (which you may be integrating on the back end already)…

@Nosaaaa Seeing as you guys have reviewed restaurants AND their food, it’ll be great to get some recommendations on specific food items.

For example, if I typed “I want sandwiches” or even just “Sandwiches”, the bot can show me (in your preferential order) a list of places where I can get good sandwiches. Same goes for steak, salad, seafood and all.

These food items are from places you have visited already, so you’ll have the data and it shouldn’t be that arduous of a task to get the list of items together. I might be wrong.

Even better, the bot can ask “What would you like to eat?”, then have options of food categories/items like “Chinese, Thai, American, Nigerian, Russian, Pizza, Burgers, Jollof Rice, Plantain, etc…”

Like I said, this is something you might be working on already, so yeah, that’s that.


This is great, you guys will go far


It being a blog (although I don’t know which platform you’re using) could mean that data discovery might be difficult for the bot. I presume it is drawing data from a database from which it can make connections easily.
This might sound crude - connecting the bot to a “web crawler” of some sort that acts as an intermediary; sorting and parsing data to a database/program (Disclaimer: I’m not a programmer)


that’s interesting. something to consider. for the bot, we’ve been collecting our data manually (with each restaurant visit) for a while now so it was easy to whip out the data when building the database for the bot


this will probably come in a future version. it’s something we considered, but both parties decided it was best to start out simple


Neat idea!


Need not be. Decouple the bot from the platform. Make the conversation independent of platform. The bot should only take in a message, parse, generate response and send. The bot should not know where the message came from and where the response is going to. It should be stateless (response is generated based solely on the input to the bot. You can easily achieve that by sending back the entire message tree to the bot to get a new response.). Then, write minimal codes to expose your bot to the different platforms: web, mobile app, fb, twitter, etc.


In essence, a REST API which is then utilised on different platforms, right?


Yes, REST could be used especially if you want the bot to live in a different process. There is also the option of the bot co-existing in the same process as the platform-dependent (presumably stateful) components of the system. In such setup, the bot could be a class/module that exposes a minimal set of apis. For his scenario, the important thing is to isolate the bot from the platform-dependent codes.


Great stuff guys.

Also, side concept suggestion (which I designed and wanted to email you guys last year but forgot)… can you make your emails conversational like EDB?

As in, can I read your emails like I’m reading a screenshot of a conversation from iMessage or Telegram or whatever bubble chat interface you like?

I just thought it will be interesting. I was going to make a template for folks who send emails like yours so they can implement (maybe i’ll still do that).

Apart from that, I have no complaints. So a voice bot next right? like Alexa hehe.


What emails? The ones readers send?


The ones you send.

Random screenshot below (although seems you’ve moved this to the blog).


it’s not really “moved” to the blog. we used to send out blog posts, as they went up, to our subscribers. don’t really know how to make the blog posts more bot-like, if that’s what you’re asking.

as for making it look like an iMessage screenshot, that’s not really what we want to do. might be a bit “too much”