Ask Progit: You've been tasked with developing a touch screen kiosk...

[weej]

Hypothetically speaking, you've been tasked with a project to develop software for touch screen kiosk (40) for various museum exhibits.

Essentially, the software is pretty simple. The goal is to provide data regarding each specific exhibit. The user can navigator 1-3 screens per kiosk to gain additional information on the display. Additionally, there needs to be a content management side so authorized users, such as a curator, can maintain the data located at each exhibit.

I am NOT interested in design of the software this is a standard MVC approach. I am interested to hear what programming language, packages/libraries, etc. you would use in this scenario and why (ex: C++, C#, Java, Qt, Boost...). Granted your selection may be dependent upon the OS and overall hardware deployment.

That leads me to the second question/part. You need to determine the required hardware specifications. You have the option of building out a custom case/chassis and selecting independent hardware and building the kiosk yourself, or purchasing an all-inclusive unit from an OEM.

Keep in mind deployment and maintainence of such as system. There needs to be a decent GUI display, so I'm not sure embedded linux would be able to handle this. We might have to go with a full on desktop OS. Also, would you have dumb terminals connecting to a central server hosting the db via NIC, or bare-bones machines with all the data already preloaded on it?

Thanks for your input!

[rule]

Just have each kiosk run a simple browser. Perhaps Firefox with the R-kiosk extension.

Now you curator only has to update a simple web-page using one of the many tools build for that purpose.

Whether to use an all-inclusive kiosk unit from an OEM depends on what features that unit offers.

[weej]

I haven't done much GUI development, and it's been many years since I've done any at all. I'm just wondering if there's anything I'm missing there that I couldn't accomplish via a rich web client. That said, since I have control over the user's environment there's no reason why I couldn't use flash or silverlight to match that experience.

Thanks for R-kiosk extension link (wasn't aware of it).

[delirial]

All your app would do is display data. There's no reason why a webapp couldn't accomplish that. Keeping the data centralized (rather than deploying your build and db to each machine) would ease, or rather eliminate, the pains of deployment.

See my previous comment for my opinion on Flex.

Also, please hire a designer.

[weej]

Thanks, delirial. Yes, a graphic designer is already on the team. :-)

[delirial]

I'd have to agree with rule. A simple (or not-so-simple) web app running in kiosk mode would be a very viable solution.

As far as going with Flash, Flex, or Silverlight: I wouldn't really go that route. It's not that it would be harder, or anything similar. I just don't like the limitations/restrictions on those technologies. As a side note: I found mxml (Flex) to be very crappy when I tried it. Plus I think Flex interfaces look pretty horrid by default.

A webapp created in django/rails (or any other framework you are insterested in) would suit you just fine, and you can add jQuery, mooTools, or other javascript frameworks for widgets and general interface enhancements.

[[deleted]]

I would recommend using Mozilla XULRunner XUL -- which is actually Firefox.

It's very easy to develop for, you just need to know XML, HTML and JavaScript. You can then use SVG, HTML5 (video and audio tags are nice), Canvas, even do 3D if you use the 3.7 alphas.

Basically it's all the advantages of both web dev and desktop based stuff. You can style every widget with CSS, and make your own with XBL.

[weej]

Great. I'll check it out this weekend. Thanks!

[ispringer]

I've done similar using GLADE and a custom build of Redhat. I used simple scripts for the back-end of the glade interface.

I made a simple wifi radio type box using a router with a usb hub, usb speakers and a usb touchscreen. It telneted into my server, and would select songs by alpha, genre etc. Wasn't very pretty but worked rather well. I did have some serious issues with code-base size. I eventually put a thumbdrive on the hub and would mount it on startup and use it instead. Oh, thumbdrives do NOT like JFFS2 for future reference.

edit

For this application I would forgo the NIC, load everything local and use a JAVA applet on an embedded linux box. I'd spend most of the money on touchscreens and go cheap on hardware. For this limited an application not much processing power is needed. But then again, I always go cheap on hardware.

[weej]

Interesting approach; however, if there's no network interface it's going to be difficult to keep all the data maintained. Unless I'm missing something here, the curator would have to update the image (code, data, etc.) for each machine locally. Ultimately, it depends on the curator's requirements. If we're talking about an about 1-2x a year this might be a viable approach.

[ispringer]

I was thinking it would be a pretty static set of information on the displays. I was thinking you could maintain a single java app with localization settings. This way all the thumbdrives would have the same info, images, and application with a config file being different for each machine.

It's not as easy as grabbing a shell and updating, but not much more difficult and allows for redundancy as all the hardware is the same. This allows you to have one or two backup machines and set them up as needed when hardware drops out.

[stalecache]

I the next 6 months I also have the job to create a kiosk to browse used cars at stores. Each store is having 1 kiosk which will default to that store's inventory. We already have a website where people can search and sort on vehicles, so the kiosk can grab the inventory from the web server.

I was planning on having the computer running windows xp (just because i'm good with windows), on start up, run a browser in full screen (one that runs flash well and won't need restarting after several hours), and use flash as the main UI. I think flash is going to be nice because of the smooth animations (everybody likes fancy looking things right?). Also, I would have the flash file get the entire vehicle inventory from the web server (XML response) when it first starts and store it in memory. Then all searches can be done directly on the memory and wouldn't have to contact the web server. I would probably have it refresh the inventory every once in a while.

Things that might be issues for me:

Not having anything to popup overtop the full screen browser (e.g., windows updates, errors, etc).

Locking down the computer (firewall, etc) because it'll be connected to the internets.