The code is divided into five main parts: the draw() function, the setup, the class we used, the mousePressed() function - which defines all the actual action possible for a user -, and a time based function that simulate what happens when the fishing procedure is on going. Almost every action in the code has a comment, so that is easier to read through the code and finding information quickly.
Since we decided to use a class to define objects and related function, we created a sort of “mini-library” that enables all the function of the objects we used. In this way, it is possible to everyone who want to develop the code to add proprieties (as those in there like x, y, width, height) and functions to the objects, and use only those needed recalling them into the draw() routine.
As we decided to flat the hierarchy and focus the user experience on the meeting procedure, there are only few action a user can do in the menu.
A user can check status, spots, profile and contacts (acquarium). Right now no other features are available, but in a full working programme a user would be able to change her/his status; chose a certain time to see which are the most crowded spots; change mobile number, language skills and profile picture; call, text or block a contact from the acquarium.
We also decided not to consider, from a prototyping point of view, all the dynamic information related with bluetooth and GPS tracking.
Moreover, the meeting procedure is only one way: once a user decided to invite a person, there is no actual way to come back. Anyway, all the functions to chose different solution (send an invitation later, accept an invitation later or ignore it) are graphically there and would be develop in a working programme. We opted for theese solutions for several reasons.
First of all, because we though it was more interesting to see what happens in the core scenario, the one which is supposed to be the most relevant and used one.
Secondly, we thought the programme would be felt as real environment also with not many working features. So, we preferred to give an overall idea of the possibilities given to a user instead of developing just a less core section entirely working.
Thirdly, because lack of time we decided to concentrate on those aspects that seemed more relevant to us.
The actual code was developed in Processing (0135). We used this software instead of Mobile Processing, because there was no iPhone (or other smartphone) available to test the prototype. In fact, italian iPhone does not support java by default. Moreover, without a real device, it is pretty difficult to predict the response on a touchscreen just with an emulator. Anyway, we had already thought - at least conceptually - how to translate the code in Mobile Processing, whenever we can find a touchscreen phone supporting java.
In details we would:
- change mouseX and mouseY with pointerX and pointerY;
- set the rollovers only on pointerPressed;
- define the actions option on pointerRelease instead of mousePressed.
These changings are related to the shift in the kind of interaction: mouse cursor corresponds to a finger on the screen; but as a finger on a screen always press a part of the screen itself, it is necessary to set a change only when the finger releases an interactive part of the screen.
Source:
Light version (without background animatics)
MIDlet [.jar 2MB]
Source code[.pdf 52 KB]
Processing sketch folder [1.8 MB]
Full version (with background animatics)
MIDlet [.jar 20.06 MB]
Source Code[.pdf 52 KB]
Processing sketch folder [.zip 19.92 MB]
How you use it || Conceptual Framework || Graphic design || Technology || Early Investigations || Code || Downloads || Credits