[cesium-dev] Navigation Widget Designs

[ravi agrawal]

Hello Everyone!

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.

1. 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.
   
   
2. Compass Widget: Can be used for Pan View and Rotate View.
   
   
3. Look Widget: Can be used for Rotate View and Tilt View.
   
   
4. 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:

1. The Circles in the Zoom/Tilt Bars look much better than the Rounded Squares.
2. Version 2 in the Compass Widget is much cleaner than version 1 but compromises on the discrete click control made possible by the arrows.
3. It would be good to give a rotary feedback/control for rotation hence version 2 for Look Widget might be better.
4. 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.

Cheers,

Ravi.

--
Ravi Agrawal

Fourth Year Student

Bachelor of Technology course

Department of Industrial Engineering and Management

Indian Institute of Technology,Kharagpur

Mobile No. : +918653837032

[Ed Mackey]

Hi Ravi,

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!

          --Ed.

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Christian Ledermann]

for the 'inactive' i would like the indication what they are for (your
option 1 in the
first row)

On Mon, Jun 3, 2013 at 11:16 PM, Ed Mackey <elm1...@gmail.com> wrote:
> 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

--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

[ravi agrawal]

Hi Ed!

Thanks for your feedback.

On Tue, Jun 4, 2013 at 1:46 AM, Ed Mackey <elm1...@gmail.com> wrote:

Hi Ravi,

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. :)

[ravi agrawal]

Thanks Christian!

On Tue, Jun 4, 2013 at 11:34 AM, Christian Ledermann <christian...@gmail.com> wrote:

for the 'inactive' i would like the indication what they are for (your
option 1 in the
first row)

I am sorry but I did not get exactly which one.. are you talking about the Zoom/Tilt Bars?

 

On Mon, Jun 3, 2013 at 11:16 PM, Ed Mackey <elm1...@gmail.com> wrote:
> Hi Ravi,
>
> I'm excited to see this, it looks like a great start!

+1

 

Great! :) 

>
> 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?)

I think it can definitely be kept 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

Hmm! I am sure I did not think about this earlier.

However it would be better if you can highlight how it could affect the implementation?

Thanks,

Ravi.

[ravi agrawal]

Hi!

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:

1. The new widgets are to a large extent coherent with the existing widgets.
   
2. The visibility in the active state is good wrt both dark and light backgrounds.
   
3. 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.
4. The placement of the widgets on the right edge seems intuitive especially if the top left corner is reserved.
5. 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.

Cheers,

Ravi

[Ed Mackey]

Hi Ravi,

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.

      --Ed.

[ravi agrawal]

Hi Ed!

Thanks for the reply.

I have made some comments as follows please have a look.

On Fri, Jun 7, 2013 at 9:15 PM, Ed Mackey <elm1...@gmail.com> wrote:

Hi Ravi,

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?

I don't think it would be feasible to use just the + and - buttons.

The reason for this being that the control would then be discrete and may cause some problems for the user if he wants to fine tune the view. A better option would be to use increment/decrement (relative) control in the slide bars rather than absolute control ( i.e. the zoom level wont be dictated by the position of the slider on the bar instead dragging it up will zoom in and dragging down will zoom out, the farther it is dragged from its mid position the higher will be the speed of zooming and after an operation it will return to its mid position)

This will make it easy for the user to fine tune the zoom level if required. Also would lead to less no. of button presses.

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.

The "pan" widget may be redundant as you say and I agree with your points.

However there might be use cases when such a widget becomes very useful. Since the panning through the screen is a little slow to operate, a "pan" joystick may become useful as the speed will depend on the distance to which the blue circle is dragged from the center. 

Hence it gives the user the flexibility to control the speed of the pan and also is faster to operate.

We obviously would need to implement a "look" controller since its default control is not that evident. 

 

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.

      --Ed.

I like the right-most one! :)

It is a lot compacter and is a balanced design

 

Regards,

Ravi

[Ed Mackey]

Hi Ravi,

On Fri, Jun 7, 2013 at 2:34 PM, ravi agrawal <ravi.a...@gmail.com> wrote:

I don't think it would be feasible to use just the + and - buttons.

The reason for this being that the control would then be discrete and may cause some problems for the user if he wants to fine tune the view. A better option would be to use increment/decrement (relative) control in the slide bars rather than absolute control ( i.e. the zoom level wont be dictated by the position of the slider on the bar instead dragging it up will zoom in and dragging down will zoom out, the farther it is dragged from its mid position the higher will be the speed of zooming and after an operation it will return to its mid position)

OK, I can see that.

 

The "pan" widget may be redundant as you say and I agree with your points.

However there might be use cases when such a widget becomes very useful. Since the panning through the screen is a little slow to operate, a "pan" joystick may become useful as the speed will depend on the distance to which the blue circle is dragged from the center. 

Hence it gives the user the flexibility to control the speed of the pan and also is faster to operate.

Yes, so the blue knob allows much faster panning than the screen-space controls, that makes sense.  I wonder if there could be a toggle switch to change from pan mode to look mode?  Some say it's best to avoid "modes" on UIs.

 

I like the right-most one! :)

It is a lot compacter and is a balanced design

 

Yeah the right-most one is starting to grow on me, and I've heard good feedback from one other person here too.  I can imagine the bars work just like the blue dot: they stay centered when not in use, and can be dragged further for faster zoom/tilt speeds.  That would imply they get blue dots too, perhaps not as large as the center dot.

            --Ed.
 

[Chris Ward]

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.

[ravi agrawal]

Hi Ed,

 

The "pan" widget may be redundant as you say and I agree with your points.

However there might be use cases when such a widget becomes very useful. Since the panning through the screen is a little slow to operate, a "pan" joystick may become useful as the speed will depend on the distance to which the blue circle is dragged from the center. 

Hence it gives the user the flexibility to control the speed of the pan and also is faster to operate.

Yes, so the blue knob allows much faster panning than the screen-space controls, that makes sense.  I wonder if there could be a toggle switch to change from pan mode to look mode?  Some say it's best to avoid "modes" on UIs.

  

 

I totally agree with you on the avoidance of "modes" thing. 

However I think there is another major problem even if we consider "modes" for "Pan" and "Look".

The compass as seen in the following figure combines two elementary motion controls i.e. the "Pan" and "Rotate". However if we were to replace the "Pan" control with "Look" control, the combination  of "Look" and "Rotate" controls wont make much sense since the controls are fundamentally different.

I think to maintain the coherency of the UI, it would be the best to provide a separate "Look" widget.

I like the right-most one! :)

It is a lot compacter and is a balanced design

 

Yeah the right-most one is starting to grow on me, and I've heard good feedback from one other person here too.  I can imagine the bars work just like the blue dot: they stay centered when not in use, and can be dragged further for faster zoom/tilt speeds.  That would imply they get blue dots too, perhaps not as large as the center dot.

            --Ed. 

 

Yes absolutely! a blue dot on the bars would help in making the UI more coherent. I will make some mock-ups ASAP, so that we can get a clearer view. :)

Regards,

Ravi

[ravi agrawal]

Hi Chris,

Thanks for your opinions.

On Tue, Jun 11, 2013 at 3:00 AM, Chris Ward <chris...@gmail.com> wrote:

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.

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)

We might need this higher speed for zoom since it would be almost unbounded as mentioned by Ed and it would take forever if you want to zoom a lot. 

 

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).

This would be a good feature to include in Cesium but I would have to look into the implementation part.

 

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.

I agree with you on this, the right click would be a good option to use for the look control and since we have the new  zoom widget the infinite scrolling can be taken care of.

 

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.

As per Ed a similar functionality with multi-finger controls already exists.

[Chris Ward]

Hi Ravi,

On Tuesday, June 11, 2013 2:41:53 PM UTC-4, ravi agrawal wrote:

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.

[ravi agrawal]

Hi Ed,

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.

Points regarding the design:

1. Neat and Coherent.
   
2. Compact but does not organize space (in a rectangular screen) so well. 
3. Would be suitable for desktops but not so much for the tablets and cellphones.

Cheers,

Ravi

[Ed Mackey]

Hi guys,

On Tue, Jun 11, 2013 at 3:55 PM, Chris Ward <chris...@gmail.com> wrote:

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.

My main point of reference is STK, our desktop software.  Its 3D window will zoom from about the size of a baseball on the surface of a planet, out to Pluto's orbit at the edge of the solar system.  Right-click zoom is your friend there.  My hope is that we can make the nav widget equally capable without sacrificing fine-grain control.

 

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.

Yeah, 2-fingers is already a little overloaded with three different possible actions.  But 3-finger gestures are not even available on some hardware, and are reserved for the OS by default on others.  We should find some way to hook it up, and if the nav widget can provide that, that will do fine.

 

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.

That's a great idea!  Maybe not holding down a button, but the option to use device orientation is appealing.  I could rewrite Satellite AR as a Cesium app.

       --Ed.

 

 
 

[Ed Mackey]

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.

--

[Chris Ward]

On Tuesday, June 11, 2013 4:10:58 PM UTC-4, Ed Mackey wrote:

My main point of reference is STK, our desktop software.  Its 3D window will zoom from about the size of a baseball on the surface of a planet, out to Pluto's orbit at the edge of the solar system.  Right-click zoom is your friend there.  My hope is that we can make the nav widget equally capable without sacrificing fine-grain control.

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.
 

[mark.e...@gmail.com]

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.

[ravi agrawal]

Hi Ed,

I am sorry for the delayed reply but I had some issues with the internet connection.

On Wed, Jun 12, 2013 at 1:50 AM, Ed Mackey <elm1...@gmail.com> wrote:

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.

Its good that you like the designs. I think I will prefer the one with the dots however we can implement both and choose the better one. The minor issues are just there because the software I use for the design doesn't provide much flexibility. They can easily be sorted out later once the widget is in action, I hope this would be okay.

 

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.

Yes! If we make the "N" ring and the side bars thicker, it would make a good touch-enabled widget.

However I have a feeling that this design would only work on a tablet but would be troublesome to use on a cellphone. The reason for this is that if the widget is made touch friendly it would cover a large amount of screen. I have included a possible snapshot below..

 

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.

Bottom-right would definitely be better for this widget design since it looks kind of heavy on the screen.

 

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.

Yes! I have an understanding of this and the widget would be implemented accordingly. Most probably using SVG.

[rez...@gmail.com]

Since this thread is dead and I never found any example code, check out this jewel: https://github.com/alberto-acevedo/cesium-navigation

On Friday, June 14, 2013 at 11:42:30 AM UTC-4, ravi agrawal wrote:
> Hi Ed,
>
>
> I am sorry for the delayed reply but I had some issues with the internet connection.
>
>
>
>
> On Wed, Jun 12, 2013 at 1:50 AM, Ed Mackey <elm1...@gmail.com> wrote:
>
>
>
> 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.
>
>
>
>
> Its good that you like the designs. I think I will prefer the one with the dots however we can implement both and choose the better one. The minor issues are just there because the software I use for the design doesn't provide much flexibility. They can easily be sorted out later once the widget is in action, I hope this would be okay.
>
>  
>
>
> 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.
>
>
>
>
> Yes! If we make the "N" ring and the side bars thicker, it would make a good touch-enabled widget.
> However I have a feeling that this design would only work on a tablet but would be troublesome to use on a cellphone. The reason for this is that if the widget is made touch friendly it would cover a large amount of screen. I have included a possible snapshot below..
>
>
>
>
>
>
>
>  
>
>
>