iSpy:
General functional requirements.

Overview: A major theme in the development of recent technology is "ubiquitous video"; just about everything is under video surveillance. In many cases, these are dedicated CCTV systems, used by police and other agencies to keep an eye on us rambunctious citizens. But as the cost of camera technology has dropped dramatically, the number of public "webcams" has ballooned; these may be still (posts a snapshot to web every X minutes), or live video streams. Just one of many examples can be seen in the Earthcam site (http://www.earthcam.com/network/) , which is one of many "video aggragators" out there that serve as a clearing house for finding interesting webcams. Similarly, the use of cameras to monitor our homes and personal spaces has become far more widespread too ... it's not just home security any more (though that's still a common use), people often simply want to keep an eye on their kids or cats!

Looking forward, one can clearly see that this trend will soon reach the point where users will become completely overloaded just keeping track of the diverse video sources they might want to monitor... and, secondarily, by actually monitoring those sources for "interesting" events. As a forward-looking company, OZ is onto this trend and would like to have a solution ready. The goal of this Zengo module is to create an integrated app for managing your video sources. Note that the app cleverly doesn't strive to tackle finding video sources; sites like Earthcam and others have already addresses this. The point of this app, rather, is to provide a clean way of organizing, accessing, and monitoring your video sources. Like all of the ZenGo family of apps, a central goal is to support a seamless cloud-based experience spanning a variety of desktop and mobile platforms.

Your task as the iSpy design team, then, is to develop a Version 1.0 prototype for this amazing module. The exact functionality of this module, of course, will be something that you will need to determine in your design process, in collaboration with your end-user community. But here is an overall functional framework that OZ has given you to shape your design. More than with any other iMomma module, we are most concerned with UI design here --- there is, of course, no way that you can build the net-connected cameras, motion sensors, activators, etc. that you need to make this all work. So you will simply build a test harness (see tech details) that similates the input from these devices to your interface engine.

Detailed functional guidelines:

Level Grade Minimal functions
Basic basic C; B-range with a very nice GUI/app

Provide basic iSpy functionality. The system should support:

  • instantaneous status of a variety of video sources
  • able to have a closer look at various video sources, i.e., view pics taken over a period of time. Or view live video if it's a streaming web cam.
  • a basic way of organizing the video sources, i.e., something better than dumping them in a long list of sources.
  • basic alerts or notifiers for a variety of events, i.e., the event happens, it gets your attention.

Reasonable quality UI --- clean, aesthetic, smooth function

Basic Test Harness. The basic version doesn't network its state dynamically, just saves app state locally when you exit. Thus, you can only run one platform UI (Desktop, Android, etc.) at a time...which reads the saved state on launch and continues from there. Because the two platform prototypes don't interact, testing will have to settle for mocking up a scenario where you mix and match.

Hardware test harness: In the most basic form, you don't necessarily have to tap into real cams and real video. You could use folders of saved-off images that you've manually saved from webcams for "still image series". And you could use small looped video clips for the "streaming video". On the other hand, you might find that a little bit of time invested in figuring out how to actually show real cams is well-invested; certainly for "snapshot cams" (still pics), this is no more than grabbing an image off a website.
You must also have a way to somehow simulate hardware events (e.g.motion sensor on a cam tripped, a video cam failing). In this very basic version, you could have a window showing as "test control panel" somewhere that allows for simulation of these "external events".

Complete solid C, B; A-range with clean, solid GUI/app

Provide nice iSpy functionality. All of the above plus:

  • A clean implementation of a nifty extensible modular architecture that would let users easily add/remove video sources of various sorts. Demo it by showing how a new web cams or new security cams, etc, get added/removed seamlessly.
  • scheduling of cams over time, e.g., configuring various individual video sources to do various things (depending on their capabilities) over time, on sensor input, etc, etc.
  • Advanced notifications: different alerts sent to various devices, multiple alerts through various mediums (email, text, outside siren)... all user configurable in a nice clear GUI. Might include notifications to other people, e.g., police, the gardener, your neighbor when some event happens.
  • Other neat functionality specifically requests by your users.

Very clean and well thought-out interface design. Great looks, smooth function. Seamless integration of the various devices.

Scores on the A-range will have a nice, clean, balanced application that looks like something you might actually be tempted to download if posted as shareware. Doesn't have to be perfect to the point of being app-store-ready, just has to be an "excellent" effort.

Networked test harness. You can run multiple versions of the app on various devices and they all communicate via some "cloud database". This means that you could have two copies of the desktop app open...or the desktop app and the Android app...or multiple Android devices running around --- and they all synchronize across the same database, i.e., they are always in sync. Note that syncing doesn't have to be super-slick/automated --- for GUI prototype testing you could have a "sync" button that you or the test user pushes to get things updated. In most cases, you want a "manual sync now" button anyway, even if your synch is automated, to allow users to force a sync anytime.

Hardware test harness: You must have a way to somehow simulate hardware events (e.g.cameras failing, motion sensors, etc.). If you have implemented a responsive, auto-updating networked test harness (above), you can just piggy-back on that channel to allow a testing/admin user to insert events into the system: you (the usability tester) simply sits in the other room and manipulate this admin interface to simulate various events ---- to the test user, this will look like the state of the system is changing!

Extras extra credit possible

Advanced iSpy: extra-cool functionality. Some ideas:

  • Visualizations of video source changes/activity over time?
  • Other cool features that go above and beyond, or requested by users. One obvious thought is integrating a burglar alarm system into this --- add the ability to have "door/window sensors", motion sensors... and to somehow monitor this as well.

The rest is up to you! Or rather your target users. Find out what users want and need and design an integrated package. Be sure to justify any functionality you put in with direct input from users --- and be prepared to justify leaving certain functionality out.

If you have any questions or need further clarification, don't hesitate to ask.