I am thankful to you all for providing me this opportunity to contribute to the Navigation Widget Project as a part of GSoC 2013.
I am really excited for the project and have developed some preliminary designs for the Navigation Widget. I would like you to have a look at the attached designs and provide me some suggestions/feedback so that the designs can be further improved. Meanwhile I will be working on some alternate designs for the widget.
The file attached contains the designs for the following widgets.
Zoom/Tilt Bars: Used to control the Zoom Level and Tilt. This may or may not be used for tilt if the control is provided by another widget like the Look Widget.
Compass Widget: Can be used for Pan View and Rotate View.
Look Widget: Can be used for Rotate View and Tilt View.
Display Widget: Can be used to display important information during transformations.
The complete Navigation Widget will consist of some combination of these widgets since multiple options for a single control may induce redundancy.
Following are some of my thoughts about the design:
The Circles in the Zoom/Tilt Bars look much better than the Rounded Squares.
Version 2 in the Compass Widget is much cleaner than version 1 but compromises on the discrete click control made possible by the arrows.
It would be good to give a rotary feedback/control for rotation hence version 2 for Look Widget might be better.
A Display Widget can be a good option to increase the usability however can be replaced by Tool-tip.
I would appreciate any suggestions/feedback for the designs so that it would be possible for me to incorporate the new information into the further designs.
I’m excited to see this, it looks like a great start!
Some comments, in no particular order. The widgets’ first impression on a user will typically be against a dark/starry background, but the widgets can also be seen against colored or light backgrounds depending where the user zooms in. It might be good to show mockups of widgets against light and dark backgrounds, and show how they fit in with the existing animation/timeline/etc widgets to form a coherent UI.
For the zoom widget display, instead of a percentage, we’ll probably show distance in kilometers from the camera to the target object or Earth surface.
I like the compass with the 4 arrows especially. Generally the more functionality we can get out of a smaller space, while still being easy for “fat-finger” tablet users, the better. I think it will be important to get a complete picture of the intended UI, with all controls in place, ideally before the official start of coding.
Everyone else is encouraged to give their feedback on these ideas as well. This should be an interesting summer for Cesium!
for the 'inactive' i would like the indication what they are for (your
option 1 in the
first row)
Hi Ravi,
I'm excited to see this, it looks like a great start!
+1
Some comments, in no particular order. The widgets' first impression on a
user will typically be against a dark/starry background, but the widgets can
also be seen against colored or light backgrounds depending where the user
zooms in. It might be good to show mockups of widgets against light and
dark backgrounds, and show how they fit in with the existing
animation/timeline/etc widgets to form a coherent UI.
For the zoom widget display, instead of a percentage, we'll probably show
distance in kilometers from the camera to the target object or Earth
surface.
+1 for elevation in feet/meters (configurable?)
also keep in mind that the object shown does not need to be the earth,
it could just as well be mars
or the moon
I’m excited to see this, it looks like a great start!
Some comments, in no particular order. The widgets’ first impression on a user will typically be against a dark/starry background, but the widgets can also be seen against colored or light backgrounds depending where the user zooms in. It might be good to show mockups of widgets against light and dark backgrounds, and show how they fit in with the existing animation/timeline/etc widgets to form a coherent UI.
I was first trying to focus on the functionality of the widget i.e. how it will work and left the choice of the color scheme as the next logical step. But as you say this is actually quite important and hence I’ll make the corresponding mock-ups which shouldn’t take much time.
For the zoom widget display, instead of a percentage, we’ll probably show distance in kilometers from the camera to the target object or Earth surface.
It would actually be more sensible than the percentage thing.
I like the compass with the 4 arrows especially. Generally the more functionality we can get out of a smaller space, while still being easy for “fat-finger” tablet users, the better.
Absolutely! this is the intention behind all the design.
I think it will be important to get a complete picture of the intended UI, with all controls in place, ideally before the official start of coding.
It seems like a good achievable target and I am on to it with all my efforts!
Everyone else is encouraged to give their feedback on these ideas as well. This should be an interesting summer for Cesium!
Yes please!
your feedback is extremely important in the development of an awesome UI for Cesium.
I have attached one of the examples of how the UI may look like after implementing a combination of the above mentioned widgets. Please have a look at the mock-ups and share your thoughts!
Following are some of my views:
The new widgets are to a large extent coherent with the existing widgets.
The visibility in the active state is good wrt both dark and light backgrounds.
The visibility in inactive state is slightly affected over light backgrounds.
However it also interferes much less with the background image while still being visible, which can be beneficial.
The placement of the widgets on the right edge seems intuitive especially if the top left corner is reserved.
It maybe a good option to do away with the Tilt Bar by incorporating it in a different widget.
It would be important to get some feedback on the implementation and the above points. Meanwhile I’ll be developing some alternate designs.
Looking good so far. Some of my thoughts, in no particular order.
The existing widgets already demand a lot of space from the content view, and of course we want to maximize the viewable area, and simplify the controls as much as possible. For example, I’m not sure we need the long vertical slider bars. The zoom bar is almost unbounded, once Cesium gets the ability to display other planets, there will be almost no limit to the amount of zooming possible. Can we get away with just + and - buttons?
Using the 4 arrows in the middle as a “pan” widget is probably the most redundant, if it’s hooked up to the same controller as the left mouse button or single-touch pan. The entire screen is effectively a pan widget. I’d actually like to keep the 4-arrow widget and assign it to the “look” controller, the same one used when you hold down SHIFT and drag the left mouse button. That’s one that mobile devices currently don’t have access to, and many desktop users don’t think to try holding SHIFT.
I’m attaching this morning’s doodle to this email, it’s a little scrappy but it has some more compact arrangements for you to consider. The one on the right shows bars-without-knobs; I imagine you could grab the bar from anyplace and drag in the intended direction to get relative motion along that axis. Obviously the lines would have to be drawn more neatly, I drew them crooked and uneven.
From an end user perspective, I like the direction you are going with the new widgets. I wanted to add some thoughts about the “look” control Ed mentioned.
On the desktop I don’t find the current right-click functionality very useful since I already have the scroll wheel to do that. I also think the scroll wheel is a better approach to zooming for a couple reasons:
1.) It allows the user to change what is being zoomed by moving the mouse to the target between scrolls (not currently in Cesium, but in say Google Maps).
2.) It is a better fit for the infinite scrolling you want to support instead of having to keep picking up the mouse as you zoom further.
In a game I’m playing right now, right-click is used to control the camera “look” and I find that much more useful.
On a tablet device I was wondering if you could maybe use your hand as if you were grabbing the earth to control the view. You would put down all five fingers in a circular pattern and twist it to rotate or slide around to adjust the camera tilt. I’m not sure how hard that is to implement, but it seems like it would be quick to use.
With any of those options for look control, you still have the problem of discover-ability which a widget could help with, although an interactive tutorial for first-time users might be sufficient.
For the zoom control, the scroll wheel may be a good option but the right click does have its own benefits like the speed with which you can zoom. (Scroll wheel is pretty slow)
You’re right that the scroll wheel doesn’t have as much speed as the
right-click for zooming purposes. I feel that if I was going to zoom so
far that it actually matters though, the right-click faster zoom may be too imprecise at such a large distance without the “targeted” Google Maps zoom that the scroll wheel can provide. So I would probably prefer using your zoom widget for a long distance anyway in favor of reserving the right-click for the camera look.
As per Ed a similar functionality with multi-finger controls already exists.
Ah okay, I thought there was no multi-touch for camera look based on this quote: “That’s one that mobile devices currently don’t have access to, and many desktop users don’t think to try holding SHIFT.”.
In any case, I looked into it more and it seems Google Earth for example handles this with two fingers so I agree that’s a better way to go.
I had one other idea for camera look on touch devices. What if you could hold down a button in the upper-right corner that causes the camera look to be linked to the device orientation? Basically how the Google Sky Map application works, where as you move or tilt the device, the camera look changes too. I’m not sure if it’s actually better, but it may be interesting to consider.
I have made the following designs based on the previous concept. Hope you like them.
In the first one, the click can be done anywhere on the bars and then dragged in a particular direction. However in the second and third one, the user will have to drag the blue slider.
Very nice! I think I like the one with the lines, on the far-right, but the dots would be OK too. I’m not sure they should “stick out” from the bar, and the blue doesn’t stand out enough from the gray, but these are minor style issues that can be fine-tuned now or later.
If we make the “N” ring and the side bars a little thicker, would it work better as a touch-enabled widget? Each piece needs to be wide enough for a finger to land on. Alternately, keep your current widths, but shrink the middle 4-arrow area a bit, so the whole thing gets smaller. Maybe if you grab the blue dot in the center, the center expands to cover up the N ring temporarily, to give a larger area.
The widget could go in the top-right under the toolbar, or could go in the bottom-right above the timeline and the fullscreen button. I think I like the idea of the bottom-right better. It should be roughly the same size as the animation widget on the other side. That widget currently uses media queries to change its size based on the size of the browser window. We may change it to use JavaScript to change its size based on the size of the Cesium canvas.
The new widget should be rendered with SVG, or on a 2D canvas of its own, but not as a collection of images. All our current widgets are vector-based and scale fluidly. If you change the browser zoom level (press CTRL-Plus repeatedly, or use the menus), you can make them arbitrarily large without seeing large pixels.
Ed,
Ah that makes more sense - we are coming from different contexts. I’m trying to use Cesium to model various types of sensors (satellites, aircraft, webcams, etc.) that are all focused on the Earth. I would argue that for use cases focused at the planet level, scroll to zoom with right-click camera look for exploration is the most useful control scheme. This would take a bit more work to implement, but what if Cesium could adapt the scroll-wheel speed based on the user’s behavior so we could have the best of both? For example, if I scroll the mouse once it would work as it does now, but if I continue making a few scrolls quickly in a row, then the scroll speed ramps up to the speed of the current right-click zoom. When I stop scrolling, then the speed resets back to the normal speed. That would allow me to zip around from planet to planet, but then have nice control at the planet and finer detail levels.
More code control over the zoom speed would be very helpful. I actually spent yesterday spelunking through the depths of ScreenSpaceCameraController trying to sort out how the zoom code worked so that we could speed it up. I couldn’t override the existing implementation because it’s all inside a closure, which is understandable. I eventually realized that most of the constant values (like “zoomFactor”) were actually public. We fiddled with zoomFactor values for a while and eventually decided that bumping it from 5 to 20 felt better in our application. Still, it would be nice to have some more obvious ways to manipulate the zoom handling.
