Well well well…

Well the hiatus ended back in early July and aside from some work-related travel (your solo developer has a day job), nights and weekends have been poured into freshening up the codebase before the actual, yes-it-is-happening launch.

Couple cool updates:

  • PostgreSQL 9.4 is just about released, many good things added to this already-excellent database
  • jQuery Mobile 1.4.3 and jQuery 1.11.1 released, getting a bit faster and a bit better
  • Front end templates migrated from genshi to chameleon… this improves page rendering speed and presses ahead with a better-supported template engine
  • Pyramid 1.5 series with its new features
  • The list continues…

This has meant a bit of porting and moving things around, and in fact the architecture of the controller layer of the code got a major scrubbing over the last couple of weeks.

The eventual call for early-adopter types to try this out will be going out soon once all of this dust settles. One thing is for sure, this project is about as long overdue as any such project should be allowed to be, but if everything works as designed (after the inevitable bug-fixing iterative rounds), it’s possible that this will have been worth the wait.

Schedule Slip Means Time For More Features!

The headline is a quote from someone in marketing when I was in engineering at some unnamed company, and I remember thinking how insane that was.

Now that I’m in marketing and engineering and QA and any of the other hats you can name are perched upon my head, I have to say it’s not far from the truth, in certain circumstances.

So the FoodTruckYP web app is delayed, it’s late, it has slipped. That’s a fact, no denying it. However, this has allowed for some good things to occur as development continues:

Most notably, there has been time for some unit test coding and of course time to fix the things that were found. This resulted in some re-architecting of the main database schema and the addition of some slower-changing cache ideas.

There’s a new logo idea that I’ll be trying out in the other 24 hours/day, which will hopefully find its way onto Food Trucks and other mobile food vendor rigs all over. It does involve QR codes…

I found a cool javascript library called Reveal.js that enables simple slide shows embedded in web pages. There’s a lot to explain here with this new tool concept for business development and market intelligence gathering and customer engagement, and nobody wants to read long emails or web pages about all of this. Simple slide presentations look promising.

As has already been mentioned time and time again, there was a house fire and a move to Las Vegas, so time has been spent on those things. That move to Vegas has included re-engaging with a mobile food community in a new city, which has been educational. In telling and re-telling the story of this project and its history and direction I’ve learned a bit about simplifying the descriptions and I’ve also received some different feedback from a community operating in a completely different place… I should travel more as this gets out and see what others have to say!

So yes, I’ve taken the time that has been passing more and more quickly to recode some things, adopt the latest Creative Commons Attribution 4.0 International License for site content, I’m looking at Ink responsive email templates from Zurb to make email notifications appealing across email clients, and as always there are new and better versions of the tools included in FoodTruckYP that I’ve been able to integrate (or been able to plan to), not the least of which is a major update to JQuery Mobile (1.4 RC1 is out now, too early for prime time).

I’m very excited to have this project see the light of day and, more importantly, see more mobile food customers and vendors and hosts get together because of it. It’s been a long and tricky road with hazards mentioned and not, and going it alone has been amongst the biggest challenges, but it will all have been worth it…

The road to FoodTruckYP 1.0

What a trip this has been. About 18 months at this point, and much has been learned along the way…

First of all, this project is not dead. It may seem like it disappeared off the radar, but in fact it was dormant for a bit while its sole developer and chief cook and bottle-washer (hence self-referred-to as “we”), Dan Hugo , has been on quite a journey away from a computer. But it’s still on.

Along the way a few others “food truck apps” have launched, which was both disheartening and encouraging. They are all okay, and anything that helps our small business owners on wheels reach their customers could be a good thing. The time to deploy FoodTruckYP into this ecosystem is upon us, though, and we’ll see if this little experiment yields fruit or not.

And of course, as all of this time passed all of the components that make up the FoodTruckYP web app have matured that much more. There’s a more comprehensive list on the site itself (in the About section), but a few of the recent version moves include

  • Pyramid 1.4.5 python web framework, we started a few versions back and it works great. It’s not Django, which is good and bad. We’ll go with Good.
  • PostgreSQL version 9.3 was just released with a whole bunch of new stuff. We started with version 9.1…
  • JQuery Mobile version 1.3.2 is out and 1.4.0 is on the way… we started with version 1.0/1.1 to deploy a mobile-first web app that works on as many devices as possible without installing anything!
  • Leaflet 0.6.4 is great for deploying maps on your website, we started with 0.4.5 after embedding google maps moved to second choice.

And there’s more of course. Plenty of stuff has gone into making this project happen, much from other developers by way of these and other projects and products and services, and of course insights and other forms of support from many people near and far.

The main thing that has made this project more of an undertaking than may have been perceived initially, is the desire to address both problems faced by any mobile vendor, whether its food or otherwise. And to do it in a way that is straightforward and appealing… well we (I mean I) hope we are getting that part right.

And finally, from day 1 the goal has been to push this data that we collect and construct out to the masses. I jokingly say that I would rather people go visit a food truck (or food cart, trailer, etc) than visit this website. By publishing using standards like ics for calendar data, kml and geojson for map data, rss for updates, by pushing data automatically to services like twitter and facebook, and by exposing our data to services like IFTTT, we’re hoping to make it easier than ever to book and locate your favorite mobile food vendors wherever they may be, today, tomorrow, next week, and whenever you’d like to invite them over…

Thanks for your continued interest, we’re looking forward to launching our 0.9.0beta site this week, about 18 months later than initially planned…

A shot of the FoodTruckYP git source repository in a late frame of a gource rendering.

A shot of the FoodTruckYP git source repository in a late frame of a gource rendering.

The Real Countdown

One of the most challenging journey’s I’ve embarked on is reaching a waypoint. Finally! Despite various trials and some tribulations (or vice versa?), the FoodTruckYP project is coming up on a real 0.9.0 beta release.

What could that possibly mean?

The project was “feature complete” a while back. Sort of. The problem with an engineer running a self-specified project is, every day there’s some new facet that wasn’t accounted for, some new feature that seems essential, some existing feature that is now insufficient or just plain wrong, and so on. On top of everything else, there is and probably always will be a “it’s not quite done yet” feel from the developer side.

As I’ve told various food truck owners, it would be like handing some food out the window that you know is undercooked, or maybe not seasoned correctly, made with bread from a bakery other than the usual one, or some variation of “I’m not happy with this, but here it is.” Not to say that I’m not actually happy with where this project is today. Would I be happier if I wasn’t 210+ days later than the flip release date I had originally announced (April 2, 2012) ? Maybe, though I would have been much happier to have reached this point about 110 days in, rather than being distracted with other projects and associated headaches and, well, distractions.

But here it is. My friend Sean (mentioned in the About section) has been testing out some UI and data consistency stuff, had to debug some of the JQuery Mobile Ajax page loading stuff, I rolled in JQM 1.2.0 with pop-ups to fit more stuff on the small screen, trying to make the workflow as easy and obvious as possible, and of course there’s initial support for booking… which means over time our busy Mobile Food Vendors can spend less time typing and mis-typing addresses into twitter and fielding phone calls and emails in search of the next lunch stop or event and spend more time actually doing what they set out to do. That is, as it happens, the goal of this project…

I’m headed off to work on a food truck at lunch time (Someone somewhere asserted some doubt that food truck directory developers have or had worked on food trucks, but I’m doing it more and more and the experience has been invaluable, even after talking to 50+ owners and tons of customers and… eh, you know that rundown by now).

Okay, so more debugging and some integration today, watch that YPFoodTruck twitter account to see if anything is actually working, cross your fingers. Now go eat. At a food truck!

Interesting Times

Some good news, and some possibly-bad news.

First the good news:

I’ve had a couple of discussions lately, as recently as today, about pushing “live” mobile food vendor location and schedule information to press entities. Non-trivial ones. I’ve been saying this for a while, that a big piece of this value proposition is the ability to spread the word far and wide, rather than keeping the data in a silo (inside an app or otherwise). Publishing everything under Creative Commons Commercial Attribution makes it easy to re-publish data without encumbering that data with “ownerous” terms (see what I did there?), while publishing in standard formats (ical/ics, kml, rss, schema.org, etc, along with whatever might make sense like json for widgets) makes the actual re-publishing of this data easier (not always easy, but easier. But I hope it becomes easy once we’re all set).

Now, the bad news:

As late as this project is, and with as much distraction as has been encountered (some necessary, some as part of the long-tail view that ftyp is a part of, and some completely unnecessary), your solo developer is in a bit of a financial pickle. This is nothing new for mobile food vendors… there’s always a time now and then when the revenues aren’t quite up to the costs, the question is how to get through. If you believe in your product and your customers believe in you, it ends up working out in the end.

The question is, will the mobile food folks that form the focus of this effort believe in this? That is the $N question.

Stay tuned…

Another final stretch…

A solo software development project will always take far longer than anticipated. If the solo person is an engineer, double that again.

In my travels I’ve run into the challenge of trying to book events, be they small school events or a former workplace, where the person involved eventually threw up their hands and went with “normal catering.” Too many variables, to many options. The paradox of choice?

The final feature that has pushed FoodTruckYP well beyond reasonably late and firmly into uppercase LATE is the core ability to book events, where an Event is any location that will host a truck at any time. Yes, a single truck for lunch once ever is an Event just as a 50-truck mega-rally every Tuesday at an amphitheater is an event.

The UI has been a challenge since I am not a UI designer by any stretch. Forget about the UX, I predict that will need work from the moment it hits the air. But initially, with only a small number of vendors to get things started, they will be booking themselves into locations for events, which makes for yet another challenge… how to deal with the transition from self-booked events to host-booked events. That is still something I’m not looking forward to.

In the mean time, I took some feedback from some initial sign-up experiences and made the path to normal-sign-up a bit more obvious. I was initially not going to have the typical email address verification loop in there, and in fact I was going to use email addresses as usernames, but both of those things are problematic… individuals will use their vendor email address even though that isn’t really the intention of a personal account, and then there’s still an expectation of a verification email, as I was informed more than once. So there is DKIM all setup and ready to go, and plain text+ html MIME email seems to work just fine.

This is just as well, because email notifications of some sort will enter the picture soon enough, email from FoodTruckYP should work and should be greeted with warmth and happiness anyway, may as well get that connection going immediately.

But what will email notifications do? Initially we’re supporting vendor signups, and then very soon after organizer signups (those are the people booking vendors for Events). Clearly if you’re a vendor and someone wants to book you, you want to hear about it, so email notifications are a must. Similarly, the cancellation market, and in short order the real implementation of the MarketPlace will make use of notifications… so email, fully supported.

I was looking at Amazon’s SNS for more generalized notification services, that is not off the table. But email is fair, it’s supported everywhere and works across mobile devices (everybody has a smart phone, right?) and other computers, they can be forwarded and whatnot, so in the end they work better than text and other point-to-point messages. But support for those forms might also be desirable, that we’ll find out.

Leaflet has come a long, long way since I first looked at it way back in March (and in fact, there were a lot of things I looked at way back in March… it seems like a lifetime ago), so integration of that mapping tool for the public-facing front end is in the cards. Since initial roll-out will have no vendors in the directory, the public-facing front end will lag by a couple of days so we have some volume of different vendors (and their logos) to check for size and whatnot, with maps and public profile pages. And various other things.

Anyway, it had been a while since I posted an entry here. Much has gone on, including non-food-truck-related food poisoning and a horrible case of writer’s block, to slow the final descent to stall speed on final, but I think we’re okay. The big test will be how real the support is for this effort in the silicon valley food truck community with which I’ve been in such close communication. The great unknown, when the rubber meets the road, so to speak.

A re-cap is in order of features, especially given the serious re-architecting that went on, some things are going to have to get shuffled out of v0.9 and into v1.0 (aka about two weeks after?) and some things will come online in between (like fuzzy search… not much to search for on day 0 but soon after, if all works out).

Stay tuned…

Pre-release pivots…

Probably not a great idea, but here’s what’s up:

The ability to have others schedule mobile food vendors is a convenience at least, and a new form of business at most. It seemed worth it to delay the already-delayed release a bit more to make sure there was infrastructure in place to enable this.

What am I talking about?

The initial architecture for schedules was vendor-centric, in that there was a presumption that the schedule for a given food truck or tent or whatever was managed by the owner or some other responsible person. Period. Events were to be an add-on at some point afterward once the initial release started to garner some attention and sign-ups.

However, as I believe I mentioned, “Do we have to enter our own schedules?” was a point raised by one or two owners and it made me think for a moment about what that really meant. Events, as a separate notion, would require mobile food owners to coordinate their scheduling efforts with the efforts of event hosts, and then there would be the question of whether the event host was actually using FoodTruckYP in any way to organize and advertise vendor attendance at the event… basically, it seemed like a bit of chaos on the horizon.

So the pivot is this: everything is an Event. An event happens at a Venue. It can have multiple recurring schedules (Recurrence), and each actual occurrence is a Timeslot. Each Timeslot can then have associated with it, zero or more mobile food vendors for a Stop.

Zero or more?

A timeslot can be visualized as a line item in an agenda or on a calendar for a particular date and time, and they exist in the future. Where before the design implied that any timeslot in the future had a mobile food vendor associated with it (since the vendor was scheduling it for themselves), now anyone organizing a a recurring event can have unbooked timeslots in the future. Not rocket science, but an important change in The Way it Works.

Operating in a self-scheduling mode, the workflow goes something like this: 1. Create an event at a venue. 2. Add a recurring schedule 3. All of the future timeslots automatically have the self-scheduling vendor booked there and then.

But now supposed I want to schedule weekly lunch stops at my workplace two days/week.

  1. Create my event for my venue (my workplace), call it something like “Lunch at FTYP”
  2. Create weekly recurrences for, say, Monday and Wednesday.
  3. For each timeslot in the future, request some number of mobile food vendors to attend
  4. When vendors accept invitations, make a final booking selection
  5. The Stop for a particular Timeslot is now booked and appears in all of the usual spots.

The sounds tedious… that’s 8 timeslots a month to schedule! That’s a lot of inviting and accepting and booking. So here’s what comes next (as in, it’s supported in the architecture but not yet implemented):

  1. Create my event, WITH additional information like estimated attendance, pre-payment terms…
  2. Create my recurring schedules
  3. Make timeslots available in the Marketplace
  4. Interested mobile vendors can request participation
  5. Make final booking selections
  6. The stops are booked, published in the usual places

Subtle, but the event at a given location on specified dates is something that can be matched up against mobile food vendors operating in the area, and if their schedule is available in the FoodTruckYP database, it can be presented to avoid double-booking. Because events in the marketplace are specified with attendance estimates, pre-payment terms, fee requirements, and anything else that might be useful, the vendors can make a determination based on their own business requirements.

In the end, the goal is to enable this marketplace where recurring (and individual, non-recurring) events can be published like location-based “want ads,” and when they are accepted and booked, have these schedules automatically publish for customers (employees or others at the venue location, or customers nearby… subject to local zoning codes and laws of course) to find and discover.

If this works out, discovering, finding, contacting, scheduling, and booking mobile food will hopefully become easier so that anyone can do it… this will, hopefully, result in more business and better margins for mobile food vendors, and that’s what this whole project is for.

Last Addition

After the feature debacle with Dreamhost, M5Hosting.com is the new home of FoodTruckYP.com and it looks like they are even more nerdy than I needed. That’s a good thing.

While demonstrating the public profile pages to MattyD of House of Siam on Wheels, I heard something from him that I’ve heard more than once… “Do we have to enter our schedules ourselves?”

First response, “Well, people do need to find you,” but the I thought about it for a moment, and it’s actually not always true that mobile food vendors should enter their own schedules in this tool that is FoodTruckYP. So, the booking feature is going to be implemented in the back end in order to make unified schedule entry ready sooner rather than later.

Up until now, vendor schedules and events were two different pieces of data and there was some weird glue between them to merge an external schedule (an event booking) with the schedule for a vendor. But it all becomes clear when any schedule and any event are made the same thing. This slight redesign also makes it far easier to implement seasonal schedules for events (for example, a summer event that happens weekly and then switches to monthly or bi-weekly in the cooler months), but it also makes it easy for one organizer to schedule any number of vendors for a particular window of time (a timeslot), whether the organizer is a mobile vendor scheduling themselves, or a business scheduling weekly lunches for their employees with different vendors at different times.

So my second response to MattyD would be, “not always.”

This approach also makes the Event Page easier to create, which will make better promotional tools for vendors appearing at events where long tweets or facebook posts aren’t always practical or detailed enough. For example, each event page would contain profile links for all of the participating vendors automatically, whether the event is “Huge Truck Rally” or “Weekly Lunch at Acme.”

This change in the back end will likely be mostly transparent in the front end initially (famous last words), until event booking is integrated in. This enables schedule entry by vendors initially, until we catch on, so to speak.

Steeping

Took a little break before launch to work on an educational project, which was good and highly educational for your FoodTruckYP developer!

While the notion of FoodTruckYP.com was conceived some time late in 2011, hard coding began in mid March 2012 and continued daily at a break-neck pace as a solo project, which meant the specs, architecture, and all testing were going on inside one head, with one keyboard and one developmental pathway.

The time away, allowing the code and architecture to steep a bit, was good, because a few limitations and issues came to light. No, this wasn’t back-burnered so much as simply moved down in priority (there’s a slight difference… trust me), but now it’s back at #0.

Also in there was the launch of that educational prototype project, unleashed onto 30 high school students, and it didn’t do so bad. But it did show one important thing, that users find problems immediately and it’s important to this developer to be able to react to those findings, so some of this delay has revolved around preparing for the inevitable bug and feature issues (which are desired, of course).

I’ve also been struck during the last few weeks by more than one comment about the work designed in to the process on the part of the mobile food vendors… “do we have to enter our schedules?” Well, actually, no. However, if schedules are entered, then the Twitter Robot will tweet schedules, future scheduled stops will be shown in profiles, and in general your customers will know where you will be in the future, not to mention the fact that entering a schedule once that recurs means that some of these things will happen automatically for each of the recurring events, for that one schedule entry effort. In other words, the idea is to reduce work while simultaneously increasing utility, but we haven’t quite figured out how to guess correctly at a mobile food vendor’s schedule… getting it right still includes that little bit of effort, for which there is (hopefully) substantial reward. Or more succinctly, there is high ROI for schedule entry time investment.

Also along the way there has been a little bit of re-thinking on the way Events will be incorporated into FoodTruckYP… this is a vendor-centric service, so that Events are not the primary promotional goal… if anything, events are a location container to make it easier for multiple vendors to schedule stops, since the stop time and place are set by an event schedule externally. Yadda yadda yadda, at the end of the day events are just stops with an organizer. But there’s a goal to abstract any externally-scheduled stop to extend FoodTruckYP into the workplace booking arena, while still remaining vendor-centric. Not a show-stopper, but it’s something to ponder, because it will be a feature rolled out very soon after version 0.9 is launched onto the world.

Finally, a very small number of vendors have signed up to the very-early morass of code that has been running on our feeble public server and we’ve received zero feedback. That is a little disconcerting, but hopefully the “real” code will draw more attention and feedback. As I’ve chanted time and time again, we’re trying to make this easy, and with the help of our vendor-users, we want to then make it easier again. Letting customers know where a moving vendor is is something that can be done just barely, or effectively, and at the end of the day the results can be measured in business and customer engagements… do customers find the vendor(s) they set out to find, and do the vendors (and the customers) benefit as a result?

That’s what’s going on behind the scenes, under the covers so to speak. Stay tuned…

Development notes, feature commentary, issue discussion area, and general repository of information about our mobile food directory

twitter.com/FoodTruckYP

view archive



Ask anything