Current behavior
While some algorithms use data structures such as stacks, queues and so on, there is no element in the app visually describing their purpose.
Desired behavior
A queue visualization needs to be intuitive and clear.
I think that some kind of tunnel with an arrow should be enough.
Elements move towards the arrow side, representing the queue movement.
Example:
Visually, it would be best if elements going in/out could be somewhat tweened, with a simple animation showing them perhaps fading in and moving down the queue + moving out and fading off.
Approach
This element is a scene of its own.
A queue might be used by many algorithms, and so it should be somewhat generic.
How generic should the implementation be
I don't think it's possible to make this super-generic in such a way that the same implementation will work for every algorithm.
Each algorithm might need different visual representations of the elements inside the queue.
Because of this, I think the queue implemented here should be somewhat generic.
It should expose a simple API such as:
func enqueue(element) -> void
func dequeue() -> void
Notice that the dequeue function returns NOTHING. This is because this queue is a VISUAL representation only. The actual algorithm logic will have it's own logic-only queue it will use for actual logic operations.
These functions will also trigger the relevant visual effects to display the data.
If some algorithm requires more control of the elements shown inside, it will have to create a duplicate queue scene of this implementation, and change it to its needs (e.g., DijkstraQueue).
Current behavior
While some algorithms use data structures such as stacks, queues and so on, there is no element in the app visually describing their purpose.
Desired behavior
A queue visualization needs to be intuitive and clear.
I think that some kind of tunnel with an arrow should be enough.
Elements move towards the arrow side, representing the queue movement.
Example:
Visually, it would be best if elements going in/out could be somewhat tweened, with a simple animation showing them perhaps fading in and moving down the queue + moving out and fading off.
Approach
This element is a scene of its own.
A queue might be used by many algorithms, and so it should be somewhat generic.
How generic should the implementation be
I don't think it's possible to make this super-generic in such a way that the same implementation will work for every algorithm.
Each algorithm might need different visual representations of the elements inside the queue.
Because of this, I think the queue implemented here should be somewhat generic.
It should expose a simple API such as:
These functions will also trigger the relevant visual effects to display the data.
If some algorithm requires more control of the elements shown inside, it will have to create a duplicate queue scene of this implementation, and change it to its needs (e.g.,
DijkstraQueue).