search

playsign / fidemo

FIWARE Demo / Integration project
Other
16 stars 6 forks source link

UI logic: Camera controls & Lollipop / AV movement & the highlight area #24

Closed antont closed 9 years ago

antont commented 9 years ago

Currently there is kind of two ways to select an area and those don't interoperate. Is this how it should be?

Also, the camera controls are just what 0.2 vizi defaults to and I at least don't really like them (is hard to pan with a laptop, and panning is AFAIK the most common operation with a map).

About the 'two ways':

  1. I can pan the map to look at an area. In a way that is selecting a place to view. But the lollipop / av doesn't follow that panning, so I actually won't be seeing e.g. cafes in the place that am looking if just move by panning .. need to also move the lollipop/av there.
  2. I can click around to move the lollipop/av. But if I e.g. click at the border of my view, camera doesn't follow. This results in the selected area / highlight being partially out of the view. Which seems awkward -- why would I not want to see what I just selected to see?

I suspect this is currently just an accident and not by design but that's the whole point of the issue: the UX & UI & controls etc. should be designed and implemented as a whole.

Also, it would be nice to know what the planned camera views are. For example I like to look at the scene from close to street level, with a kind of low-flying perspective, but then e.g. the lollipop menu becomes huge (an icon can will a quarter of my screen :) . Same with the traffic icons but that can be sometimes even nice as it looks like a bus driving by (have been actually thinking of Mobile AR applications with the traffic info & vis but that's another story)

antont commented 9 years ago

Is (mostly) solved now: cam follows lollipop/av movement. New start position is in use.

Also, Tapani made it so that the traffic icons get smaller when viewed from close. Some might be nice for Ludo's icons, perhaps including the lollipopmenu.

When designing the start sequence we figured (with Tomi) that it would be good to not show the lollipop & highlight at all first but only after user's first click. That's not made (yet).

Camera also has a basic limit to not go too low / below ground now.

Stinkfist0 commented 9 years ago

Now avatar (and camera) moves and menu appears on both left and right click. Would it make sense f.ex. to only move on left click and move + show menu on right click?

antont commented 9 years ago

AFAIK Ludo's idea is that the basic action is to both make the selection & open the menu there, with left.

Perhaps it might be clearer to not do it with right click but then again we don't use plain right click for anything so unless it interferes with right-click-to-rotate I figure current is fine.