A request web app?

[Nakatomi]

The other week I put request slips into a venue where I'm pretty much hidden away. They were an incredible success - I was inundated with bits of paper & I felt the element of interaction at the venue went up a good few notches. However, little bits of paper are annoying & handwriting can be hard to read.

I originally considered making a device app for clients/guests to make requests, but I only have Android devices at home & any app thing would need a web backend anyway so I've boshed a thing together on my own Virtual Private Server using PHP,MySQL & Ajax.

How does it work? Well, ahead of the event or on the day the app administrator (i.e. me) logs in & creates an event 'key'. This key is (at the moment) only valid on one day but can roll over by a globally configurable amount. The URL & key need to be displayed somewhere at the venue for this to work of course!

The admin can see & edit all requests made by clients for any of the event keys previously generated. They can be marked as 'played', or 'will play' ('played' can be shown on the customer facing side) - 'will play' is for the DJ's own reference).

What does the client see?

The customer facing end is a basic login page:


then a list of any requests made so far, along with buttons to add a new request or log out. :




Adding a request, the end user sees this:



And this, if their submission is successful:



The showing of existing requests is set by the administrator & is optional. In the case of the list not being shown, the user is only shown a count of requests made so far.


I've trapped everything out that I can think of.. xss, mysql injection & HTML code insertion.. and all user input on the customer facing side is error checked (certain fields can't be blank or too long). I've also included flooding protection (which of course is configurable):


CSS styling is still a bit up in the air & it looks best on mobile devices.. apart from the admin end which at the moment is suited to bigger screens only.



It can't give the end user any choices based upon an existing music database - I don't want that available on the night.. crazy requests can be bad enough without people seeing what I haven't got around to pruning yet.

The flooding protection is currently based on the user's IP address which has its limitations of course, but it's generally the case that a device connected to a venue's wifi or a mobile network will have a unique address for a while at least.

Yes, I'd much rather people came to see me in person (in general) but I see this as just another interactivity ice breaker.

Obviously the proof of the pudding will be in the eating.. it's definitely possible that it could be abused, but this like any other system of requests still doesn't come with any guarantees.

Any thoughts (other than "it's a bit green".. that's not set in stone) ? Oh, and apart from the fact it needs to feature the darn annoying EU legislated cookie warning (GRRRRR).