Hey all!
First of all, I'd just like to apologize to anyone who I may iritate if this post is in the wrong category. It's a fairly general question, so it's hard to find even the correct forum, much less category, to ask it under.

Before I ask the question, I should explain some things. A little while ago, I had an idea for a project I wanted to try. It would involve a video terminal that could be placed in the room of a patient with alzheimer's disease. Through past experience in nursing homes, I've seen some late-stage patients in some pretty fear-stricken states -- terrified because they have no idea where they are. Since the staff can't possibly be expected to follow these people around, providing the constant reassurance that would calm them, they are reduced to living a life filled with bouts of constant fear and anxiety.

Having talked with some staff at local nursing homes, I've been told that many Alzheimer's patients are aware enough of their surroundings to take notice of an on-sceen message. With this in mind, I was thinking it would be nice if it were possible to have a video console which would stay permanently in their room and work something like this:

The screen would display a custom text message from the family when not activited (Something like "Dear Ann, If you are confused about where you are, press this button"), and below the screen would be a big and obvious e-Stop button that could be pressed. On pressing, a video message, pre-recorded by the family, would be played full-screen. It would just be a simple loving message, with maybe an explanation and encouragement, and a reminder that the family would be in to visit soon. After the video, the original message would reappear, and the option to push the button again would be available for whenever the patient again became anxious or forgot where they were.

All that would be accessible to the patient would be the button, but on access with a phyical key (in the family's or nursing home's possession), a door in the display could be openned so that the family could access the computer controls and remove the webcam for recording.

When I was trying to figure out how all of this would work, I was intending to teach myself the basics of a programming language over the summer. I am still completely dedicated to making this work, so I am not asking for any free handouts, but I am at a loss as to which language is most appropriate for my needs. The key requirements would be the ability to support a full-screen program, recording and playback at decent resolution (640x480 and 30fps), and ability to easily interface through the serial or parallel port with a bias switch e-stop button.

And I realize that I'm pretty ignorant at the moment, so any help would be greatly appreciated. I have no illusions that learning is going to be easy, but I'm willing to put in the long-term time to see this through -- I'd just rather not waste effort learning a language that won't suite my project very well. I'm no computer science major, but I have been in the habit of self-teaching (PC-wise) since I first taught myself HTML in grade 8. I've taugh myself flash, 3dsmax, adobe premiere, photoshop, css, basic, after effects... I know, I know, hardly anything compared to real programming languages, but I'm just saying that I'm used to doing this type of thing on my own. Jack of all trades, though master of none, I suppose...

So again, the final question is this: Being as objective as possible (since I realize that I'm on a C++ forum!), which programming language would be best suited to tackle this project?

Thanks a bunch people! I really appreciate it!!!

Sincerely
Pat

C++ could help but it's much harder to learn and may not suit that project as it doesnt use much calculation

I would recommend C# and Visual C# Express as it is much easier to learn and the C# Express IDE is very useful

BTW You learnt a lot of stuff on your own! Woot Woot!

Aw hey thanks a bunch killzone! You're awesome dude
If you're interested, I'll letcha know how-slash-if it all turns out

I think that any recommendation is going to be tied directly to the hardware platform that you're using.

I don't know that having a web cam in the device is such a good idea. Since most "families" would already have a PC, perhaps making the unit more single-minded might be a good idea. That is, let them use their own web cam and just upload their data to the target system. That could greatly reduce the per-unit costs of the system, too, by not requiring so much hardware and by not requiring the storage capacity necessary to basically edit video/audio. It may also allow you to develop a prototype more rapidly that demonstrates proof-of-concept.

You may also want to consider that PC hardware (for the target) is going to draw a lot more power than some other embedded target options. If a care facility is going to invest in the product, they will be considering the entire cost of ownership, which includes the constant pull of power.

My recommendation starts with establishing a suitable hardware base. I'd probably recommend one of any number of SBCs or single board computers, probably in the Intel/Marvell XScale variants with an LCD/touch panel and and SD card and/or CF slot running Windows CE, which gives you the media player.

Writing an application then is reduced to something akin to the scripting type languages that you already have experienced.

Another aspect of your system is that no matter how well you think you understand what it should do, someone else involved in the project is going to have another idea of what it should do...and some of those people might be paying the bills. That means that you need to be flexible in your thinking and get something out quickly so that you can quickly receive input from the various user categories, too. That enables you to make any necessary modifications to meet the changing needs of a potential user base.

A lot of SBCs provide wireless and/or wired networking. If is not unrealistic to suggest that whatever the target is, that it could simply be a "dumb terminal" whereby it receives a stream from some upstream server. That way, a care facility could have a "message making" room, where families record their messages using a single set of tools provided "at the server" and in a location that can potentially be modified with different backgrounds and props and not just some random "patient room" backings that might be more "sterile" or otherwise less comforting or pleasant. It also allows the care facility to offer a "turn-key" package to families at the least possible direct expense per family and dramatically reduces the per-unit cost of the target devices.

The "client-server" design also allows for system expansion. Of course, having a web cam at the patient's terminal would also allow the family the potential to monitor the patient, but then the issues of privacy might crop up.

I guess that my point is don't try to do everything on the box. Try to do the core feature. Make that work well and with an eye to being extensible. No matter what, just about every project morphs over time, sometimes to where it has nothing that can be recognized with its genesis.

As a proof of concept, you can easily bring in a USB key of a reasonable-length message, upload it to the target and write enough scripting to play/loop/replay/whatever without requiring much interaction. Also, once you gain some proficiency in the environment that you select, you can add more management and administration features. What I mean by this is that the patient is unlikely to have their own USB key(s). So why do we need a "key" to unlock a door to modify the content? Upon inserting a USB key, we could easily run an application that would present a management interface. Therefore, I'd propose an "open" system initially, so that ease of use is provided over "system security," and add levels of management/administration as required by customers.

As a means of developing a rapid prototype on a PC running Windoze, you could easily attempt a lot of what I'm suggesting by buying a new USB key and adding a .wmv file to it. When prompted as to how you want to respond to the insertion event, select always and run program choosing media player...or your app that copies the file to a set location and then invokes media player.

Once you're able to accomplish the basics, then you can continually modify your app to provide the additional features that you feel it needs. However, I would recommend that you aim for the fewest possible set of features that allow you to demonstrate the essential functionality, present the unit to potential customers taking their input. During that process, you empower the customer with a system that "is of their choosing," so that the natural sales process is greatly improved, since they now have some "ownership" in the design. As you sit with them taking their feedback after some initial trials, you can seed a pilot project with questions like: "If I make those changes, will you commit to taking X number of units in a pilot project starting next quarter?"

There will be a cost associated with every unit and in volume there are discounts, but also, the minimum number of units for "standalone" versus "client-server" will evolve out of your explorations into these areas. You may find that for some number of installed units that what you end up with--in terms of general system architecture--is analogous to a lightweight hotel-type streaming video-on-demand system or a TiVo-like system.

Another thing to say about the web cam on every unit is that I'm not sure that the patient would know if the message were changed with any particular frequency. I do think that it would be an interesting case-study to see how frequency of change helps the individual patient, but I'd also be somewhat of the opinion that it may not be that much more help than the basic concept. Managing costs, wires, applications, processor interactions, etc. are all aspects of the system and its relative complexity. My recommendation is to disassociate yourself with the notion of a general purpose computing platform, which is basically what desktops do for us, and start thinking in terms of an application-specific computing platform, which is what I think you need. Let your operating system, programming language, networking, hardware, etc. choices evolve out of the pros and cons associated with meeting the needs of your application-specific requirements.

I'd also recommend farming out some programming labor to qualified professionals if it helps you meet your project schedule. oDesk.com is a resource that allows you to specify fixed-price and hourly wage jobs where hundreds of developers are available to you. I don't mean to discourage you from learning new skills, but I've seen a lot of code written by those learning it that appears to work, but is really rather ugly. Finding a need such as the one you've mentioned and fulfilling it doesn't necessarily mean being the Lone Ranger. An option could be to make it a sourceforge.net project, if open source is a viable solution for you.

Let's take a brief look at your question:

Would C++ be a good language to make this prototype product?

This product suggests a lot of interactions that have not been discussed by you. Until you resolve some of your system architecture and design issues, I don't think that you can select a programming language to write an application, which sounds like just one part of the "product."


:davis: