FoodTruckYP

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

Sat, 24 Nov 2012 23:15:29 -0800

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

The Real Countdown

Thu, 08 Nov 2012 10:38:48 -0800

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

Sun, 30 Sep 2012 18:27:16 -0700

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...

Wed, 05 Sep 2012 00:02:08 -0700

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...

Mon, 06 Aug 2012 11:44:13 -0700

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.

Create my event for my venue (my workplace), call it something like “Lunch at FTYP”
Create weekly recurrences for, say, Monday and Wednesday.
For each timeslot in the future, request some number of mobile food vendors to attend
When vendors accept invitations, make a final booking selection
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):

Create my event, WITH additional information like estimated attendance, pre-payment terms…
Create my recurring schedules
Make timeslots available in the Marketplace
Interested mobile vendors can request participation
Make final booking selections
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

Sat, 14 Jul 2012 11:02:11 -0700

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

Thu, 05 Jul 2012 03:16:16 -0700

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…

Release Plans for v0.9b

Thu, 14 Jun 2012 15:14:20 -0700

Found a few bugs in the version on the little tiny test server that have been fixed, a few things are still lingering, a few things that really should be properly finished off for this first roll-out will be, and then we’ll release it into the wild

Along the way I’ve bounced back and forth on how I’d like to monetize this exactly. The general plan is, it’s a nominally-priced service for mobile food vendors to help engage their customers. The presumption is that there is value not only in automating some of what is in use now (the FoodTruckYP Robot tweeting schedules is one component of that, the upcoming Facebook App is another), but also in the “modern technological approach” taken for some of the features FoodTruckYP.com offers. The KML map files, the calendar sync (that may or may not be in 0.9, but it is a 1.0 feature for sure), the menu items and per-timeslot menus, etc etc etc.

Initially I was hoping to get some early adopters to sort of flush out some of the workflows, make sure things made sense, that they operate according to some field intuition (I’ve learned a lot from speaking with owners, but there’s nothing like being in those shoes yourself), and in exchange I wanted to offer a deep discount, lifetime subs, etc. That, however, is completely impractical, because owners are not software QA people… they have no background in testing new products and services in that way, so it’s unreasonable to ask them to. They have no such time.

Instead of that approach, it looks like I’ll take the input I’ve received so far, package it up into this version 0.9 of which I speak, call it a “Beta” release, and wait for the issue reports. There will still be introductory rates and whatnot— these are not get-rich rates, these are defray-server-costs AND support-future-development rates— and once we leave beta I’ll make it a normal rate (which, as I’ve mentioned, should be right around $25/month or so, with 1-year price break).

So, here’s what happens next…

Getting a server. The current server, a SliceHost virtual server now owned by RackSpace, is not bad at $20/month. However, the heavy use of database for the backend, along with bandwidth requirements that go along with giving away data (in case you’ve forgotten, we’re going to take all of this data the vendors pay us to deal with, store it and organize it in a database, then turn around and not-sell it… we’re giving it away to anyone who want to know or talk about mobile food!). We may yet return to Rackspace, they are a fine company with many substantial offerings.

Why not Amazon? Well, didn’t say that exactly, but I’m not prepared to roll out a new service when I have no real experience with EC2. If it makes sense to use S3 for map markers and logo icons and whatnot, that is entirely different and that could happen. The back end is architected so that every asset can be “somewhere,” making it relatively easy to push the graphical elements (and other statics) out to more convenient places than the main server(s).

Dreamhost will be the first real home of FoodTruckYP.com. Not only was it founded by people who went to the same college I did (Harvey Mudd College, in fact), but they are reasonably-priced and offer unmetered bandwidth… this means that initially it will be painless on the billing side to give away all the data we have, whether it’s one YPFoodTruck schedule or 3000 mobile food vendor shedules, maps, calendars, and profiles. The question along the way between 1 fake food truck and 3000 real vendors is, how much more server and resources (and maybe people) will we need?

That is a question I look forward to answering.

One of the things I like about mobile food vendors is their entrepreneurialism, and the thing I like about their business is that it’s on the move This project as many similarities… the version that will follow the roll-out will already have been under development, and the one after that will start soon… in other words, this is a moving target as much as any of my clients will be, and as much as any of their customers are, and as much as any mobile food vendors are to those looking for them.

Once the server is up and running, the software installed (You can read the About page on the site, the core system is Linux, PostgreSQL 9.1, Apache 2, python 2.7, pyramid framework, a whole mess of python libraries for twitter, google, template rendering, time calculations, graphical image resizing, etc, and some initial use of redis (caching and work queue, or maybe in the opposite order) and some initial checks are run, we’ll put up YPFoodTruck as a tester truck, add some schedule entries, and have the robot start tweeting. Those astute among you may notice that, the rest can watch for a directed tweet or facebook or email message (you will still get first crack at it), and then we’ll either try to spread the word proactively, or we’ll see if viral takes it aloft. There are Share buttons and Facebook and Twitter buttons there so maybe this social networking thing will work out for us….

Okay, back to work.

Alpha Test about to begin...

Tue, 05 Jun 2012 17:24:31 -0700

So far there has been a grand total of 1.5 people testing out the web app, and a couple of bugs have been found.

Show stoppers preventing roll-out for alpha test

Re-schedule bug, sometimes schedules get munged a bit (this seems to be identified, a solid fix is in the works)
Front end maps. These are actually not totally working because of the lack of KML NetworkLink support in the google maps api. It’s obviously a priority, need to read the markers with an appended BBOX parameter.
Place adder. I don’t like the way this works, I have a better version, need to get it all in there.

There are a couple of other things, but these are the ones that bother me enough to not have people trying this out because they will be issues (obvious the map has to work, that’s a no-brainer).

I’ve also been dressing up some of the UI (on the admin stuff as well) so it is slightly more visually appealing.

If you’ve read this far, you have my congratulations!

I’m going to send some alpha invites for free testing. Free for both of us! That is, I was initially planning to ask for early sign-up money in a special promotional arrangement, which would cover real launch costs (mostly a suitable server, the current platform is great for testing but not sufficient for real use) and which would be a tangible value assignment. Free stuff tends to not get as much attention as something you’ve plunked down some money for.

But then it occurred to me, there would be a tremendous amount of value in getting maybe 5-10 owners to give it a try on the current server and point out any glaring errors or omissions. This will only take a few minutes for the big things, maybe a couple of days of messing with it, rescheduling something, etc.

The goal is to do this some time in the week of Jun 4, likely toward the end of it but I’d love it to be earlier than that.

I think this will have been worth the wait. But I’m sure I’ll hear about it if it isn’t…

Today we are feature complete!

Wed, 30 May 2012 22:12:00 -0700

For the 0.9beta release, the plans were these.

Schedules
- Recurring
- One-off
- Transparent cancellation (people can see when timeslots have been cancelled to avoid “You’re usually here” confusion)
Locations
- Explicit location with draggable map marker
- Nicknames for easy descriptive naming of unnamed places
Maps
- KML as the preferred transport format
- Javascript-based website map
- Google Maps website support
- Google Maps Native app support for mobile
- Markers are twitter icons for now (ie vendor logos at 54x54 pixels)
Profile pages
- Vendor pages with logo (downloaded from twitter automatically), contact info, timeslot schedule
- Place pages showing timeslots for that place as well as nearby places, to help discovery
- Timeslot pages, one vendor, one place, one time, one set of menu items (menu support is slated for 1.0, but item support is in)
- All external profile pages are permalinked with UUIDs, bookmarkable, sharable, LIkeable, tweetable, all have OpenGraph and Schema.org metadata embedded.
Short url
- Automatically assigned business name, twitter handle, facebook handle.
- Other names are possible, no set rules as yet
- Disambiguation page addresses duplicate handles
Twitter robot
- OAuth posting support for twitter accounts
- Twitter robot posts well-formed time and address information, as well as geotag of the timeslot destination, prior to the timeslot, automatically.

We are currently testing this stuff out to make sure the twitter robot doesn’t go posting weight loss links [actually, that won’t ever happen, just joking]

Coming up next

Fuzzy search (vendors and menus)
Search filters on food components (IS and HAS tags)
Facebook app
Facebook opengraph verb to enable timeline Map view
Website widgets (your schedule exported to your website)
User logins for follows, etc
Search heat maps
Maps of future timeslots
ical export
Events (profile pages for events with profile links to vendors automatically)
More?

Remember, every single piece of output from this website can be freely re-displayed, re-published and re-used for commercial and non-commercial purposes, all we ask is that it remain intact (don’t go editing anything such that people don’t trust the data, etc) and that you tell people where it came from. Otherwise, our job is to promote mobile food vendors, and whatever we can do to accomplish that goal is in our purview.

I think some people think 10 weeks of hard-core development time is too long. To that I have no answer.

To those who have been supportive along the way, and whom I hope will continue to be supportive as we roll this out, I thank you for your patience, and I look forward to changing the way customers find you. And customers, finding out which foodtrucks are where tomorrow and the day after is one of our goals, I think we’re almost there.

It's been running...

Fri, 25 May 2012 14:34:34 -0700

So for the curious, FoodTruckYP has actually been up and running for “public site tests” much like one might take a new food truck off external power and let it run self-contained while you make some food and drink and whatnot.

Guess what. We found some bugs here and there. That’s what that’s for.

Couple things got sorted out:

Cookies, SSL, and logging in and out seem to work properly when switching between https and http versions of the site
The twitter robot login stuff seems to work (OAuth is not my favorite thing in the world, as it turns out)
Grabbing twitter images, there’s a small issue with blocked access to profiles when we grab the profile icon (this enables cross-branding easily without having to go find that image file when signing up from your mobile device).
Short URLs… after some pondering, the short url is to be composed of the business name, the twitter handle, the facebook name, and the company name in url-friendly form (in other words, if the business name is “this is a food truck” then we would support “this-is-a-food-truck” and “thisisafoodtruck” which are basically identical. We lowercase-shift and punctuation-remove the shortened url part anyway.
Found a DST issue that was just plain dumb. For the curious, we’ve gone with storing non-naive timestamps localized to UTC, along with the timezone (not the offset!. This way we can always account for DST and present localized times, but we can treat everything as UTC internally for things like the FoodTruckYP Robot to go wandering through timeslots and whatnot. Well, generating timeslots based on a recurrence rule that crossed over a DST boundary left the stored UTC timestamp off by that delta. Freshman mistake, really.
Added titles for schedules and timeslots. This will make more sense in context.
We’re going to support a cool thing that I will go into more detail about later, but let’s just say it’s icon-related.
On the fence about whether OpenGraph meta headers should be a show-stopper for 0.9. I say no, can add them as we start getting some schedule data in. These will be most interesting, though, when people decide to share a timeslot on Facebook. Basically, each timeslot (that is, a mobile food vendor at a location during a window of time) will have a universally-unique URL to a page that can be shared, bookmarked, tweeted, and liked on Facebook. The Open Graph headers will make that work better for the Facebook part. This goes for business profile pages as well.
Place pages… for now we’re only going to support display of food trucks that have indicated that they are at a particular place (venue) as well as those who are nearby. In other words, we’re aiming for discovery of nearby food trucks and carts. If this is not what people want we can tune things down to show only the vendors specifically at a place.
Those are list-based considerations. When viewing a map, the map edges are a natural and visually-clear search boundary.
Added support for geohash-based searches (in fact, that’s how generation of Place page lists work for the moment) so that it should be pretty easy to make an RSS feed or similar by trimming letters off of a geohash key. Experimental.
Right now we have Menu Item support all good, but we still need to implement Menu Support. In other words, if somebody has 50 menu items, we don’t have the Menu grouping feature implemented yet. Well, not in the UI…
Fuzzy Search works nicely, but still need to have the index writer running off on its own. We’re starting with Whoosh, for the curious, and the index writer isn’t thread safe. Weighing the use of the Async wrapper or just having a periodic indexer job run through updates. The goal here is to make all mobile food vendors findable by misspelled names (that’s for you, O Mi Ninja, nay Oh My Ninja, nay OMiNinja… and there are many others with similar non-obvious names). This will also apply to menu items and places as we get some input records.

There’s probably more. Pondering whether KML should be the publication format of choice. Sure, GeoRSS works as well and is basically a subset, but KML already supports timestamps and timespans, in addition to precise location information. Embedding a structured PostalAddress is easy… would others consume such data? Or are we just looking at Google Earth and Google Maps to consume these? (Well, we’re going to use the KML output for display on our maps, too…)

That’s all for the moment. It’s taken a while to get here, but things are really, really coming together now. Pretty exciting, actually.

The final countdown

Sun, 20 May 2012 17:02:25 -0700

There’s always something that crops up or otherwise makes itself known, that stops the final bits from coming together. The list of things that qualify has dwindled, and so we are approaching the release of FoodTruckYP 0.9 beta.

No, really.

It’s actually been up and running, a non-truck-owner has gone through the vendor signup process and found a few things that didn’t function as expected, a couple of typos that turned into bugs, and one or two things that need to be tweaked for clarity. It’s been tremendously useful, because after speaking to so many mobile food vendors, and after being immersed in this for so many weeks, I have lost some objectivity that comes from that lack of familiarity. So unleashing this on one person has been a good thing.

That thing that was confusing

One of the features of FoodTruckYP that I like is the ability to place a mobile food vendor on a map at a precise location. It makes the challenge of location clarification around and behind buildings or other obstructions at least surmountable (if people are willing to look for the information, it will be available). My approach was to collect these locations ahead of time, so that when it came time to create schedule entries, there would be a list of locations already selected and already marked up with parking locations. It did occur to me that entering locations during a new schedule entry would be sensible, but it didn’t seem to me to be a major difference.

Well, apparently it is, because the end result was “it doesn’t matter if we we can enter them before or during, either way…” which, in fact, means that both are needed. The ability to enter a stand-alone location, and the ability to enter a new location when creating a new schedule entry. The final blow was that it wasn’t intuitively obvious not to have location entry within schedule entry, so my testing friend suggested that I should have it written somewhere to choose locations, then enter schedules. In fact, I had it listed in two places… not a bad thing to know, that intuition trumps written instructions. So that is a little extra code for tonight.

Additional data views and such

The bare minimum for FoodTruckYP would be to display mobile food vendor schedules that are correct. Of course.

Many conversations with employees at companies that host food trucks or other mobile food vendors have shown that knowing the schedule for a location is just as useful to the customers, and as important to the vendor (if a truck shows up in your parking lot and nobody knows it’s there, does it make any money?). So a list of trucks that will appear at a place at a time, that’s sort of obvious.

But sometimes there are other places nearby that also host mobile food vendors. Or maybe the precise address wasn’t clear so that technically vendors will be at different places, when in reality they are at the same place, or close enough. So now we view at or near a place. That’s pretty easy, too.

Mobile food vendors are interested in expanding their markets, so over some interval we’ll be able to figure out where mobile food vendors are hosted. Sort of like finding all Starbucks, they just appear on a map… once we know which places host mobile food vendors, we can make some guesses about whether a particular area is saturated, or whether there might be room for additional hosting locations. And we can also see where there aren’t so many hosting locations, and decide why this might be.

Now let’s look at cancellations. Sometimes a vendor has to cancel for last-minute circumstantial changes. Equipment failure, confusion or miscommunication over a timeslot, mutliple bookings, etc. The cancellation might also come from the hosting side. Either way, there are circumstances where unmatched locations and vendors might not know about each other… so that is another view on data to expose for consideration.

Add to this search metrics… not individual metrics, that isn’t so interesting, but rather where people are looking at mobile food vendors. Are they looking where vendors are, or where they aren’t?

Add regional regulations for keep-out zones and other limitations on location.

And so on, and so on.

Open Search? Open Graph? KML? ICS?

Making our data available in any format that can be used is the goal.

What will people use?

Oh yeah… widgets, is JSON sufficient? XML?

Back to work

Blogging is a great diversion… too great.

Pretty Much...

Fri, 11 May 2012 16:42:47 -0700

I’ve suggested that things move faster and faster as web app details come together, and this is true. Or it has been.

I mentioned previously that since I’m horribly late at this point, that I’m adding some additional features that I was going to roll out over time… time that has since gone by anyway, so why not? Horrible violation of the software engineering best practices that we tell project managers we should follow.

I’ve had a chance over the last few days to convince myself through detailed discussions with some mobile food vendors, that getting to know the environment, the workflow, the view of the gem from many sides, through the eyes of the vendors themselves, event organizers, and customers (mobile food fan customers and newbies alike), that this was the way to do it. How do people find trucks and carts now, how could it be easier, and how can my customers, the mobile food vendors, accomplish this in a way that makes sense but isn’t too vague, too taxing, or overly complicated.

Well?

The overly-complicated part remains to be seen, I’ve made a good effort to do the right thing automatically, and while there are likely some options that will have to be added for what exactly is the right thing sometimes, I think I’m pretty close.

Case in point, the first image that will appear on the site for your business will come from Twitter. Why? Because… some mobile devices don’t allow image uploads, almost all mobile food vendors have a twitter account, and there is a twitter api that returns the original image uploaded plus 3 square sizes. Piece of cake!

So my initial plan was to have those images download behind the scenes once the business owner saves the Twitter Handle for a particular account. But that’s not really obvious, it’s not intuitive, and it leaves questions like did this happen? and how can I re-do this? and I didn’t want that to happen, now what?.

I just added an Images view with an option to download from a specified Twitter Handle that may not even be the one associated with the business. Why? Who knows, it could happen. The default value is a Twitter Handle supplied in the business profile, if there is one supplied, and then the Twitter handle from whence the images were grabbed is saved separately and shown as the source handle later for re-downloads… end of the day, business branding is obvious and easy, no need to find the image file on a desktop computer, no need to size it, it’s done.

Not to say that there won’t be other options, like uploading a separate photo of the truck so we can do the trading cards views (did I mention that? Hmmm…), and of course menu item images… those will be less-simple, since iPhones and maybe some other devices still don’t want to let you upload files from your device. Maybe email an image? We’ll see.

As I’m writing this, there is one thing I want to make work better, namely the Place editor. Then I will upload this mess to the server, test a few things like SSL redirects for the right directories and the secure setting on the auth header, run through a few iterations of creating and editing an account or two, some schedules, etc, and then… tweet to my followers @FoodTruckYP that they can come by and have a look.

Then, to fire up @FoodTruckYPRobo and see if anybody notices.

The order of what happens next is TBD.

Fix bugs (this is probably first, last, and always)
Add owners/managers/employees to businesses (not too hard)
Event Organizer support (non-trivial, the back-end is done barring anything I missed)
Menus per business/timeslot (non-trivial, back-end is done, yadda yadda)
Facebook app (shouldn’t be hard, but there are a couple of unknowns)
Search engine (starting with whoosh most likely, then on to xapian?)
User accounts with follow/like/etc.

Things that I have to integrate, but which have already been tested as components

KML file generation
KML NetworkLink file integration
ICS file generation
GeoRSS/RSS file generation

And, of course, anything else that comes to mind. The market analytics stuff will come as traffic builds so there will be some meaning.

I’d like to look at a Bayesian classifier to create a simple recommendation engine for menu items (and thus the trucks that purvey them), based on the item tags assigned by the chefs/cooks/owners. This might be going overboard, but it might be interesting to generate a list of vendors on a recommendation axis in addition to a distance axis.

I’m actually pretty excited about the KML feature… the ability to use Google Maps (and hopefully Google Earth, and hopefully Apple’s new tools in iOS 6) to natively or at least more-optimally view mobile vendor location data as a layer on top of the other feature layers provided by GMaps is pretty neat. You’ll see what I mean.

Okay, I think we’re really actually coming to the big event, and the follow-on stuff is further along than it would have been had I rushed, so maybe this is all working out nicely. ‘Tis the season for mobile food, hopefully I’m just in time and not just too late.

Thanks for reading, and if you’re among the few then I also thank you for your support.

Violating the rules of software engineering

Thu, 10 May 2012 11:51:22 -0700

In all of my years as a software engineer, programmer, white-box tester, etc, I have always found this statement and those like it to be silly:

Since we’re late, we have time to add more features.

I can’t even remember how many times I’ve heard marketing folks try to take a schedule slip as just such an opportunity, as if there wasn’t enough to do scrambling around trying to get something out the door less-late!

So I say this as sheepishly as I can in writing: since FoodTruckYP is so late at this point, I’ve added some features.

I was going to add the features over time, but one of the reasons this project has been delayed is to try to make sure the data in the back-end (the database that stores mobile vendor info, locations, schedules, and so on) was thought-out well enough to have these extra features added on over time. Afterall, the developer staff of one can’t go breaking things left and right trying to add a new feature here or there. Well, I guess that could happen, but why build that into the plan if it can be avoided?

Some assumptions I had made early on, which were sort of embedded into the data design, had to be modified slightly. These were the wrong assumptions and the changes:

All schedules are recurring, even if they recur once. But later, I settled on the fact that a schedule for a vendor is the intersection of location and vendor. In other words, a schedule is a list of dates and times when a given mobile vendor will be at a given place. This made the one-off scheme incompatible with the always-recurring scheme. Now, there is explicit support for a one-off schedule entry that is not related in any way to a recurring schedule (literally, the schedule_id is NULL).
Event schedules and Vendor schedules should be maintained separately and be linked in a meeting-invitation style interaction. This was cumbersome and lead to too much room for confusion, especially if there were individual schedule entries (which I now refer to as timeslots) that were actually for events. Basically the vendor timeslot is the final resolution of who, what, when, and where. For the super-nerdy, then, a vendor timeslot has a schedule_id and an event_id, if both are NULL it’s a one-off event, or schedule_id points to a recurring schedule recurrence rule entry, or event_id points to a specific event timeslot instance.

That seems like a lot of thought going into this. A mobile food vendor said something to me the other day, though, which summarizes why this is important:

Some people thought I was out for late night and started tweeting and messaging me when I wasn’t there.

In other words, the tools that vendor was using to reach customers displayed something that lead them to believe there was a late night (around midnight) outing when there was not… best efforts to avoid this are at work here.

As for more features, given this extra time I’ve had… no, but seriously, the features that will either come out now or quite rapidly now that the back-end is sorted out are:

Menu items. Menu items are individual items from a menu, of course. But each will have a page, each will have a facebook button on it, a picture (from the vendor… they own there brand on ftyp), and so on, and will exist even if the item itself is no more. For example, the SJ Taco Festival of Innovation had some unique taco formations that may not see the light of day again from some vendors, yet they could live on as menu items for posterity.
Menus. These are a collection of menu items. With a twist. Once you have your menu items available en masse, constructing a menu is a few checkboxes away. So then, constructing a menu for any given timeslot is also a few checkboxes away. Thus, menus as a collection of 1 or more menu items can vary per timeslot… it sounds complicated, but if you vary your menu for different days or locations, or have a menu for large events that is a subset of your normal menu, you know what I’m saying here.
Event organizers as entities. One of the core components of the data is the mobile business, with schedules and such all wrapped around the vendors. The obvious thing to do was to make event organizers the same, structurally, as vendors, so that as far as we’re concerned in the database, an event can be organized by a company, a specific mobile business unit, or an event organizing entity.

On the front end, there are a few bonus features that have fallen out as a result of this delay:

Calendar formats. Generating .ics files is trivial, the question is whether anyone will know what to do with them. End of the day, you’ll be able to directly add timeslots for places and trucks and events to your icalendar-friendly calendar (works so far with Google Calendar, .ics is an interoperability standard so it should work like magic…)
KML output. If you like using Google Maps in native form on your mobile device, or if you like to be able to add a KML layer to your desktop web maps client, or maybe you want to view mobile food vendors in Google Earth… generating KML output for mobile food vendor locations is a piece of cake.

I think that’s enough rambling for today… back to work, all these features aren’t worth a lick if you can’t play with them. Now go eat something.

End-to-End Site Functions for Test

Wed, 02 May 2012 09:17:59 -0700

Just a quick update… internally, these features work, which mean that last 20% should only take about… well, I’m not going to predict any times anymore:

Vendor signup
Add company
Add business(es) - the Who… trucks, carts, etc
Add place - these are Where the businesses conduct their business
Add schedule - the When
Edit above
Display public-facing profile pages for a business, place.

That last one is, for all practical purposes, the reason for this entire project.

In other words, that last item shows anyone looking for mobile food vendors:

Which vendors will be in a particular place over time (say, the next 7-14 days)
Which places a particular vendor will be at over time (again, maybe 7-14 days)

So, end of the day, if someone finds a truck at their workplace, or when visiting some other workplace, or wherever they find one, if that truck will be there according to a schedule, they can visit the profile page for that place and see when any trucks will be there, and/or visit the profile page for the truck and find out where else they will be and when.

Similarly, if someone hears about a cart from a friend or in a review or wherever, a mobile profile page for that cart can be found showing contact info, twitter and facebook names, and that upcoming schedule for the next week or two.

Bonus

I don’t know if I mentioned this, but we also have the ftyp.co domain name.

While urls for FoodTruckYP.com are nerdy and cumbersome (every public object has a UUID assigned to it, making them always-reachable even if the name of a vendor changes, etc), we still want it to be easy for anyone to direct their friends and customers to a FoodTruckYP.com page of information.

So far we’re supporting these:

ftyp.co/@FoodTruckYP
ftyp.co/tw/FoodTruckYP
ftyp.co/fb/FoodTruckYP

That first one relies on inclusion of the ‘@’ in the twitter handle… we could be persuaded to treat even ftyp.co/FoodTruckYP as though it were a twitter handle, but with less certainty. The point, though, is that if a customer already follows you on twitter, it’s that simple to find your mobile profile page on FoodTruckYP.com, and that easy to find you. (I’m speaking to vendors at the moment).

So there it is. Much of the FoodTruckYP.com project is functioning as designed (I may have said this yesterday, more works daily at this point), there are some bugs to fix, but otherwise it’s coming together only a little behind schedule (I prefer to think of it as “early for the next version”).

Thanks for your support, back to work.

28 Days Later...

Mon, 30 Apr 2012 10:56:45 -0700

Much code is working.

Had a great design review with Maria from Whisk on Wheels to go over some of the workflow for schedules as well as organizational stuff for menus, and a few useful tidbits from Nancy of OMiNinja about event scheduling.

I’ve seen a few more cases of confusion over location when trucks or an event with trucks are not so visible from the street. I’m not totally confident in the placement editor when selecting a schedule location so I’m a little stuck there, though that has also been the thing I’ve been showing around to folks. It works well when it works right, and I think it will be one of the cooler features.

Watch this space… I’ve been playing with it as a local web app, it’s looking pretty okay. Not so beautiful, I’m not so aesthetic a web designer (in other words, I am not at all), but it’s working as designed…

Three Weeks Late?!?

Mon, 23 Apr 2012 15:45:14 -0700

By now I suspect that some are doubting what has become to me (the lone developer of FoodTruckYP.com) a moral imperative, but rest assured, it is coming together nicely.

These three weeks have been highly-educational in two specific areas.

First, Events are Important

Well of course they are, but here in the South Bay Area (Silicon Valley, San Jose, whatever), there have been a few events in the last week or two that were under-promoted and, thus, under-attended. Most recently were events on Earth Day 2012, where the inclusion of Food Trucks was apparently a bullet item. Another was an event held right in front of the San Jose Mercury Newspaper headquarters, featuring an RV and ATV exhibition and a “Food Truck Rally.” This is the local paper, which is really the only local paper anywhere near its size, so you would imagine whatever they placed in their print and online copy to promote this, it would be useful to their readership…

In all of these and other cases, event details, locations and participants are sometimes left to chance. That is, someone who is not familiar with a location may not know where a casual reference is pointing, and certainly someone who is not already familiar with individual food trucks might have no idea what “babaloo” and “twisted chill” might be [I’ll do what they did and let those stand on their own, with no links or other details at all…]

The take-home lesson, make events and the mobile food vendors at them as easy to find and as clearly described as possible. This was always in the plan, but it has moved up in importance and modified a bit to enable three different attendance models

Ad-Hoc, where there might be little oversight on who attends (not none, just not strictly-enforced). These might be charity events.
Peer-Organized, are events where one or more mobile vendors take the lead role(s), collect fees, promote the event, etc. Some charity events fall into this category, as well as some smaller public events (the events I mentioned above fell into this category).
Professionally-Organized, where there is an active, possibly-separate but certainly focused business group or entity that manages which vendors are to appear at particular events, possibly multiple events under the same organizational name, and so on.

Event publishing will be an early feature after roll-out…

Make it Easy

Today was the planned roll-out for a minimally-functional demo platform, to show where this is and where it’s going to some local mobile food vendors. However, I made a tough decision early this morning, to make the schedule features easier to use and more focused. As I’ve spoken with more and more mobile vendors and customers, it has become clear that knowing where the vendors will be (especially at lunch time…) is pretty important. Leaving it to chance is not good for anyone, nor is not-communicating last-minute changes.

Most mobile food vendors are getting the hang of social engagement tools to reach out to their customers… making sure they know when there are equipment failures, delays due to traffic, when items are sold out, and so on, these are important. Nobody likes to make a trip out to an empty spot for lunch, when there should have been a favorite [or even NEW] truck or cart…

The FoodTruckYP Robot — which now has its own twitter account, [http://twitter.com/FoodTruckYPRobo] — will be able to send out status update messages based on intra-day changes.

Facebook App

One more thing… some love Facebook, others not so much, but it is used by many for locating mobile food vendors. The plan for version 1.1 is to implement a Schedule app that can be embedded in your Facebook page to show the exact same schedule, location, and status information as appears in twitter and on FoodTruckYP. That is, right after initial roll-out, the FB app will be in testing.

Later I’ll mention the widget feature for the mobile vendor website, but this blog post is already too long…

Events...

Thu, 19 Apr 2012 19:58:58 -0700

Not even done with this first roll-out, I’m keeping one eye on the next features, which will include support for events.

Before I go there, here’s how I view a “schedule” versus an “event.”

Schedule

A schedule is managed by a mobile vendor. That is, if it up to the vendor to declare a date and time and a place and then eventually end up there.

To support this, FoodTruckYP enables schedules to be added and edited as recurring calendar items, and each individual entry can be marked as canceled, etc. In other words, free reign, the idea being we keep the customers and the vendors on the same page.

Event

An event is managed by someone else. That someone else may be a mobile vendor, may be an event organizer or coordinator, or it may be someone who has taken on that latter role but who isn’t really an event coordinator.

More specifically, here are the usage scenarios:

A formal, promoted, pay-to-participate event organized and executed by some entity that oversees who is invited, who attends, who is late, gross receipt percentages, etc.
A less-formal fund-raiser event or similar, sometimes organized by a coordinator, other times coordinated in a more-or-less ad-hoc fashion, perhaps by one or more of the participating vendors.
A periodic event in an company parking lot or similar, where the event is coordinated by an office manager or other individuals who are not necessarily focused on mobile food vendors.

All of these events are presumed to be recurring, though they may not be.

We assume for events that the final decision as to which vendors are invited and will attend is not up to the vendor, but up to the vendor and the coordinator(s) of the event (and possibly not in that order).

What Then?

At the end of the day, the goal is to make sure mobile customers (even if they’re at work, at some point they get to stand up and venture forth to locate and patronize mobile food vendors) can find their favorites as well as vendors in the area, and sometimes those vendors are serving lunch or dinner at a periodic company parking lot location, other times at a mid-day promotional event for recreational vehicles, other times at a formally-organized lunch or dinner gathering in a nearby (or not-so-nearby) venue.

As long as the events are accessible to the public (not private, and ideally not requiring paid admission, though we’re making that a 3-way distinction), they should appear right along side individual schedule items, and that’s are approach.

One of interesting things to note here, though… except for the first case, where there is a formal, organized effort to coordinate and oversee gatherings (surely there are some near you, in my case we have MVBL Feast, Edgewood Eats, Off the Grid, Eat StreEat, and others), these events are sometimes under-represented in media and online in general because often there is no website setup as a landing spot for them.

The typical approach seems to be to place mentions on Facebook pages, have the participating trucks do the same, have them tweet, and then hope for the best.

One of the goals, then, is to make that work better, while enabling ad-hoc and more formalized events to be coordinated and promoted by those who may not have the time, the inclination (office managers, we love you, but you’re not focused on promoting the vendors…), or perhaps any idea what to do.

It’s on the list…

Almost. No, really

Wed, 18 Apr 2012 12:52:29 -0700

The past few days have seen development accelerating, which is sort of exciting. And tiring.

Location location location

I’ve mentioned this before, all mobile food vendors already know this, there is one simple fact in this arena: Your customers must know where you are and when. That’s the core business we’re pursuing here.

So yesterday, when I walked over to Raytheon in Sunnyvale where one of my personal favorite food trucks was to be, it was not parked in its usual spot. A spot that is visible from the street and from a nearby major intersection, in fact. Luckily, I had heard that the people working at Raytheon had asked food trucks to park closer to their building, which means parking away from the intersection, tucked behind another building. Hidden from view!

Had I not known that this might be the case, I may have turned on my heels and wandered to a food establishment more firmly fixed to the ground. But things hadn’t gotten that bad…

I also took some time to visit a weekly high school fundraiser event in Union City, following the imprecise directions given me by one of the vendors. Those directions got me close, and since this was a large high school campus (Logan High School in Union City, CA) I had some looking to do . Turns out, the event is visible from one major street, but not the street that runs through the campus area… had I not been 100% certain that the event was taking place, I may have become frustrated, I may even have made a left turn instead of a right turn and missed the event completely as I reached the main thoroughfare that leads back to the freeway.

These and many other examples of imprecise address and verbal directions to where mobile food vendors are conducting their business! Add to this the number of times incomplete addresses are posted on Twitter for “locals” to guess with implied detail, the number of times an address isn’t actually known… with more and more customers carrying GPS-enabled mobile devices on their persons or in their cars (or both), there’s no reason to not have a precise location available that leads your customers to you where you are open for business.

Clearly I’m speaking to vendors in that paragraph, but customers, you should be able to find these trucks and carts without having to hunt around. Hide and Seek is a fine game, but not for lunch. Not for most.

Now that there is a UI in place to enable vendors to add places and parking locations, so that not only can I find your venue using normal mapping tools (by searching for a location address), but I can also see on a map (or within Twitter or elsewhere) precisely where you will be parked. This could also work at a large, multi-vendor event where you may want to indicate to your customers that you’re around the corner or on the south side or next to a building… again, we have these devices in our pockets, we can take advantage of them!

Quality Assurance

We’re about to start some QA on some new features and roll out the soft launch so that others can play. The YPFoodTruck will start wandering around in cyberspace very very soon (famous last words again) so you’ll be able to see how this works out. Then we’ll get going on the Facebook app…

Thanks for following this development cycle, this is going to be a cool service, definitely looking forward to seeing it help our mobile food vendors and their customers find each other on a regular basis!

Two Weeks Late, What's Up?

Sun, 15 Apr 2012 19:06:00 -0700

Tomorrow will mark 2 full weeks since the line-in-the-sand release date of April 2, 2012 for FoodTruckYP.com.

What has that gotten us?

More Realistic Scheduling

As mention in two previous posts, there are some things about publishing the schedule of a moving target, for the consumption of mobile consumers, that can be a challenge. The “Edgewood Eats” scenario was a good one to learn from, it reversed my thinking on how far out to publish schedule items. This, unfortunately, will be something to look at closely in the early days to make sure I’ve re-thought this through. On the surface it’s not a huge departure from the initial design, but marking those future, changed instances when the base schedule entity changes is important, it needs to work intuitively (just because it works “correctly” doesn’t mean it makes sense to the users of this site…)

Maps maps maps

The ability to place the nearly-exact location of a mobile food vendor’s spot of deployment onto a map is important. I’ve mentioned it before, there can be buildings in the way, there can be a large, expansive campus or other obstructions that obscure a location, or it may be that the vendor just isn’t there for the scheduled time… how do you find something that isn’t there when you aren’t sure where to look?

There will still be a couple of geo-related things to look at. The vendor record we store includes a service radius, we’ll need to make sure that some searches properly include vendors where the search and service radii overlap sufficiently. That likely means a little bit of slack. The finer point is the problem of county and city permits and licenses and other such things that aren’t so easily captured in a single radius parameter, but we’ll get there if that is needed.

Finally, there’s the street view feature… let’s just say that sometimes it’s useful, or interesting, or maybe fun, to see your favorite truck or cart in Google’s Street View. Well, that sorta works…

Under the Hood

A couple of design decisions were re-thought as far as how some data is stored, all of the data that can be updated by more than one person has a simple locking mechanism in place so that, say, two different people aren’t trying to modify the status of a particular vendor when they’re running late or just opening.

There is also a history log in place, so that when a user makes a change (and in this case, we’re calling signed-in vendors and their employees users while in the future users will be anyone) the change is tied to that user id, timestamped, and a before-and-after record is captured so that the change could be rolled back, or shown explicitly. The rollback feature hasn’t been implemented yet, that will be soon (you want this to get launched, right?).

Twitter Connection

This shouldn’t have taken as long as it did, but connecting a vendor account to their Twitter account seems to work as expected. What was the pain? On the backend, example code is written assuming a continuous, statefull set of OAuth 1.0a transactions, and only very subtly is it mentioned that some information from the original request may need to be saved in a stateless http transaction flow. In other words, I was scratching my head for a couple of hours one day thinking that both of the server-side wrappers I was trying were doing something wrong, turns out I wasn’t saving some state.

Subscription Model

My original thinking was this, that the early-adopters of FoodTruckYP.com’s services would always get the best price on a monthly or annual subscription basis, including same or more-slowly-increasing pricing if subscription prices do need to go up in the future.

Then I had a discussion with a very-well-known truck owner at the San Jose Taco Festival of Innovation on April 14, 2012, and while I thought I was going super-cheap for the early adopters, the “free” question came up.

Hmmm.

My initial early adopter pricing was going to be $10/month, $100/year.

After a few people have asked the question about a free version of the service, and after yesterday, I’ve given it a lot of thought. My guess is, this is so weird an application that I’ve been developing in the context of what’s available now, and I have such unusual plans for the use of the data (this is not ad-driven, I want anyone to have access to all of this data, even competitors), maybe setting a price is too unnerving.

On the other hand, some people have been excited at how low the price is.

I’ve reached this conclusion: During the roll-out period, those who want to contribute to the founding of this new service as early adopters may do so. They will be marked as such in the database, in perpetuity. Those early adopters will always get the best services available, including access to new features, best support, etc.

However, there will be no compulsory subscription fees during the early days of FoodTruckYP.com. Free users will have access to all of the roll-out services and will not be penalized for not contributing financially as early adopters.

Crazy? Maybe. I guess we’ll find out together!