WIP: Recreate Data Velocity Interactive

[eAlasdair]

Relates to #1182

Currently WIP.
Planning to change everything so keeping a record of the old version here

[eAlasdair]

This is a nearly functionally-complete attempt to recreate and improve upon the proposed Data Velocity interactive for use in the field guide. My problem with both is that they seem to miss the point of what Data Velocity actually is.

Data Velocity, as I understand from my research, is the rate at which data is processed by a system (processor in most cases). This generally could be a very large amount of data (e.g. thousands of photos being uploaded to a social media site every minute) or data that needs to be processed as soon as possible (e.g. credit card checks at the till). To help explain my thoughts on this interactive here are a few points to mention:

• Data Velocity is about what the processor does with data (i.e. the speed at which it does so).
• The speed that data moves along a physical cable (copper cable, fibre, WiFi etc) is constant (or close enough) and not related at all to Data Velocity.
• A measure of success would be the time taken between receiving data and having that data processed. This could be 'can the processor work fast enough that its internal memory buffer never fills up?' (the photo example) Or similarly 'can it work fast enough that I can submit data and have it processed within a certain amount of time?' (the till example)

The original design has the user to try and catch 'data packs' (coloured balls) falling from the top of the screen with a USB cable that can move left and right. The more balls caught the more of an image is revealed. At higher levels, the balls are dropped faster and at shorter intervals. There are several issues relating this back to Data Velocity:

• The balls drop at different speeds and are caught by a USB cable, implying that DV is about the speed at which data moves along the cable.
• The balls are processed instantaneously when they hit the cable, again implying DV isn't about the processor
• The balls can miss the cable and be lost. Combined with the other two this makes it seem more like packet loss for error correction than loss from not being fast enough to process what came before

The new design has the user catch the balls with a bucket-shaped CPU and drops them at the same speed. The difficulty is increased by having the user catch balls for multiple photos at once, dropping several balls at a time. This addresses some issues with the original but fundamental problems remain:

• The balls are still processed instantly when they hit the bucket - processing a ball doesn't affect whether or not it can process any other ball even if two or more are caught simultaneously
• The balls can still miss the bucket and be lost, which still doesn't do well to demonstrate the consequence of exceeding the limit

I propose keeping the assets and general idea of processing photos while completely redesigning the actual 'game' the user plays in order to do so:

• Balls should drop either in bursts (one burst per image) or at a slowly increasing rate
• The system must catch every ball and store it
• The user acts as the CPU, completing some sort of simple puzzle to process each ball
  • The user is competing to 'drain' the storage as it fills to keep it from overflowing - This is a proper concept of Data Velocity
• Eventually the system becomes full and ball(s) overflow its storage, ending the game with some sort of score screen - This is the proper consequence of exceeding its limit