Wildcard: Spreadsheet-Driven Customization of Web Applications

Spreadsheet-Driven Customization is a great way to enable non-technical users to customize and configure software.

I used that technique for a one-off Java application back in 2011. The Java application did not do any live synchronization with the spreadsheet like Wildcard does. It just read the spreadsheet at application start-up to get configuration data needed to drive the application logic.

Spreadsheet-driven customization allowed the application's users to edit the spreadsheet to grow and maintain the dataset that drove the application logic.

I would not be surprised if others have done something similar before me.

Thanks! "View source mindset" is a nice word for what we're trying to promote with this project.

Brittle site-specific logic is indeed a challenge. So far we've started with the simplest thing possible of programmers manually writing scraping code, so we can focus on how the system works once you have the data available. That has been enough to test the system out and build lots of useful modifications ourselves.

I think eventually some degree of automation will be an important way to help end users use this tool with any website. The "wrapper induction" problem has been well studied and there are lots of working solutions for end-user web scraping, so I expect to be able to integrate some of that work.

We're also interested in a community of shared scrapers, but as you point out there are security considerations. I'm considering trying central code review from the project to approve new site adapters and make sure they aren't doing anything obviously malicious. Another solution could be carefully restricting the expressivity of our scraping system (eg only specify CSS selectors, no arbitrary code) but I doubt that would be sufficient for all cases. Would appreciate any suggestions here.

Yes, you're right! In practice, though, we're finding that many useful customizations can fit into that framework. For example, the Expedia demo in the paper shows a "1 row table" to represent an input form. It's worth thinking about how many different things people use spreadsheets for...

I think another useful analogy for thinking about abstract data representations is text streams in UNIX. It turns out many types of data can be represented as newline-delimited text, which enables you to use a suite of generic tools with that data. Inevitably, some data doesn't fit into that format, but it's perhaps surprising how much does.

It’s not really true that we have custom front-ends because they are best for the user. Consider the example of AirBnB in the article and the fact that in 2012 they stopped allowing ranking by price: one has to assume that if a feature has been absent for eight years there’s no intention to reimplement it (presumably because it behooves the company to have it absent). I’m guessing that AirBnB knows/believes that the absence of this feature leads users to choose slightly more expensive properties and this generates more income. The spreadsheet intercept allows the user to regain control.

nice, this would be very useful in enterprise/internal facing apps, where the users are 'power users' who already know and know the app on a day-to-day basis.