My goal with Blocks Calculator was to have each "piece" of a formula independently manipulable. As a working metaphor, I named those pieces blocks. They helped clearly represent operation order. A formula such as (4+7)x5, consists of first an addition block, which is inside the multiplication block. In my mind, I envisioned to have these blocks movable, so that formulas could be "built" like assembling lego pieces together.
So I had to implement multiple ways to interact in the app that went beyond the simple click. Fortunately, android includes everything needed to recognize gestures. The implementation is very good. I rarely experienced cases of multiple gestures being detected at the same time. It also handle scrolling very well : when we move fingers on the screen we easily get past the bounds of the objects we focus on, ending with the finger on another object. No touch event is triggered on the other object.
My first notion was to use short pressing (click) for selecting blocks and long pressing to drag them. Since multiple blocks would overlap, I implemented a selection cycle from smallest to biggest in successive clicks. This works well in my opinion, however I received suggestions that the cycle should be reversed, i.e. selecting the complete formula first, then narrowing selection to inner blocks.
The second group of gestures I added to the app were scrolling and pinching. I wanted users to be able to place formulas anywhere, so that it would be possible to rearrange them. Such a feature however meant that formulas could easily end up off screen as they are expanded. Consequently, I introduced scrolling and zooming on the sheet. I think they give a great sense of freedom. |
Early example of selection cycle
|
At this point, all the 4 gestures introduced worked nicely together. Conflicts between gestures appeared however when designing the buttons area. One thing I really looked after was to have these buttons dragable, so that new formula stubs could be directly placed on the sheet. And a second thing I considered was to give an alternate function to each of those buttons, similar to the SHIFT button on pocket calculators. It occurred natural to me that long pressing the button would trigger its alternate functionality, but this conflicted with the previous role of dragging I had given to long pressing. As a temporary solution, I decided to have the drag started when the user would lay the finger on the button and then move away from it (actually this is the same as a scroll gesture).
This got further complicated when I added the memory area. It had to be unlimited in size, however its display size was definitely limited! So I made it scrollable, much like the sheet. At this point the gesture/action mapping looked like :
This got further complicated when I added the memory area. It had to be unlimited in size, however its display size was definitely limited! So I made it scrollable, much like the sheet. At this point the gesture/action mapping looked like :
Gesture
|
Click
|
Long click
|
Scroll
|
Pinch
|
Sheet
|
Select
|
Drag
|
Move around
|
Zoom
|
Buttons
|
Perform
|
Perform alternate
|
Drag
|
Value
|
Memory
|
Select
|
Drag
|
Scroll up/down
|
Value
|
The first thing I came to realize was that introducing alternate functions for the buttons was pointless. The idea was inspired from pocket calculators, and pocket calculators needed to introduce the SHIFT button because the number of buttons they could have was limited. On a smartphone there is not such a limit however, I can add as many buttons as I want, they just need to be in a different category. This way I could also avoid to put too much information on the buttons, them being already small enough. Ok, so now I could drop the alternate function idea altogether, right? Well, I actually wanted to keep it for the equal and delete buttons. The first display the computation options, and the second act as a clear button. |
It all became simpler when letting people test the app. They enjoyed the fast drag from the buttons area, and found that the long press was too long. So it appeared a good idea to adopt the "scrolI" gesture to drag blocks. This seems problematic at first, as I already use scrolling to move around the sheet...
As I was rightly pointed out that, I could move blocks when starting the scroll on them, and move the sheet when starting outside of them. Most of us would naturally not scroll the sheet by placing their finger on a block first, as that would select it.
This was the solver to the gesture conflict. Long pressing would finally not be used to drag and could be kept solely for the alternate functions of the equal and delete buttons. However, the memory area now needed modification : blocks use most of the space in it, so it is very likely that you cannot lay your finger outside of a block to start scrolling. I changed the memory area to split in multiple pages automatically when too many blocks had to be displayed. Scrolling in the memo was no longer needed.
As I was rightly pointed out that, I could move blocks when starting the scroll on them, and move the sheet when starting outside of them. Most of us would naturally not scroll the sheet by placing their finger on a block first, as that would select it.
This was the solver to the gesture conflict. Long pressing would finally not be used to drag and could be kept solely for the alternate functions of the equal and delete buttons. However, the memory area now needed modification : blocks use most of the space in it, so it is very likely that you cannot lay your finger outside of a block to start scrolling. I changed the memory area to split in multiple pages automatically when too many blocks had to be displayed. Scrolling in the memo was no longer needed.
Click
|
Long click
|
Scroll on block
|
Scroll outside
|
Pinch
|
Select/Perform
|
Alternate function
|
Drag
|
Move
|
Zoom
|
In conclusion, I am pretty satisfied with the gesture/action association as it is now. It follows well the maxim
"one gesture always has the same outcome"