RFC Sandcastle Features

[Mike LP]

Hi Everyone,

Thanks to Google Summer of Code we're going to be revamping the sandcastle web application.

I wanted to get a feel for what features people like/love about the existing one and what features people feel are lacking.

-mlp

[Hyper Sonic]

Sound great, I look forward to improvements to the SandCastle web app!

Being able to access the viewer object from the console would be great for debugging. Perhaps this is already possible, but I haven't figure out how yet. In SandCastle apps viewer is usually declared in (and only in the scope of) the startup function. So for a plugin to work with a SandCastle app, viewer has to be first be declared outside of this function as a global.

Easy plugin support would be nice as well. Currently you can't just include the plugin script in the HTML tab. I had to create a script object from within the startup function doing stuff like document.createElement('script'); which is a hassle. Maybe have the ability to add plugins with just a click of a button.

[Hyper Sonic]

One problem with editing code in SandCastle is that when you use the browser's search function (ctrl-f) it only searches the code that is currently visible. I don't know if this is fixable or not due to it using JSHINT. Also double clicking a var and have it highlight all cases of it would be nice. In the mean time I just copy back and forth between a Notepad++ instance to get these features.

[Poul Sørensen]

Would be cool if one could save scripts and link to them as a alternative to copy pasting scripts from this forum into the sandcastle.

It would make sense to look at http://geojson.io/ and how they use gists from github to save and load files.

[cfber...@gmail.com]

Hello Mike, and everyone else

As I mentioned in other post, i want to contribute and here is my little GIST:
https://gist.github.com/e37c0eec104ef11f522e.git (Clone Link)
https://gist.github.com/cfbermudez/e37c0eec104ef11f522e (GistGithub page)

This is a HTML File with simple javascript to:
-Add Static Placemark
-Add Placemark on mouse position
-Add Label on mouse position
-Add Symbol on mouse position
-Draw on mouse position
-Remove Entity
-Clear All
-Sun Light
-Show Africa
-CurrentLocation
-Load KML
-Detect browser support for CORS


If you have any comment, feel free to make it and also to use this code anywhere!!!


Thank you!!!!

[Patrick Cozzi]

One more idea for the new Sandcastle: a view query parameter so, for example, we can setup a scene for performance testing and then easily capture and recreate the same view.  See #2725.

Patrick

[Mike LP]

It's a little late for posting week #1 goals, but better late than never.

Week 1 Goals:

• Create gallery.json and demo files for mock testing.
• Modify iframe to use minified Cesium and inject demo code/user.
• Add console and implement functionality of menubar buttons
• Add documentation
• Responsiveness

There is actually a lot of great work already accomplished and we'll post some screenshots on Monday.

If you're feeling curious feel free to check out the progress on github

[Mike LP]

New blog post with the overview of the project: http://cesiumjs.org/2015/06/01/GSoC-Sandcastle-Overview/

[Patrick Cozzi]

Great post, thanks Mike and Aditya!

A few ideas:

• The ability to share a code example via embedded-url/GitHub-gist/whatever will be really useful.
• Making the path from Sandcastle example to “code running in my app” as trivial as possible will be important.
  
• We'll want to reorganize and re-envision the set of code examples.
• Include a set of CZML examples.
• Keep a representative set of the "Development" examples since the developers doing low-level graphics use them.
• Have we posted a public roadmap for the summer yet?

Thanks,

Patrick

--
You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/3eXLAv6KZEA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

twitter.com/pjcozzi

[Aditya Raisinghani]

Hi,

Just wanted to give a quick update on the progress so far-

The app has been redesigned in bootstrap using React and responsiveness has been added as well. Targets for next week are allow for a full export of code, and implement a gallery mico-app.

You can check out the progress so far here. I'll host this soon so it can be viewed easily.

@Patrick: Haven't posted the roadmap, I'll share it on this thread.

Aditya

[Matthew Amato]

I'm willing to wait until the project is a little further along to have a firm opinion, but I do have some concerns I'd like to bring up now.

The original goal of this project was to bring Sandcastle more inline with Cesium and use Bootstrap/jQuery/Knockout (replacing the need for Dojo).  I'm a little concerned about the sudden dependency on React (and from the look of it several other third-party libraries are being used as well).

I'm also not sure we want to depend on bower in Cesium either, the Cesium release zip can be deployed without an internet connection and there shouldn't be any kind of dependency on bower to get up and running with Sandcastle locally.  That being said, we could potentially just package the pre-downloaded libraries in the zip, but I see no reason for us to rely on bower at all.

I also saw some dependencies were via CDN, that's something we would definitely need to eliminate because Sandcastle should be able to run offline.

Like I said, I know it's early in the project and things will evolve and change, but I'm concerned that some architectural decisions are being made that are off course compared to where we want this to end up.

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

[Mike LP]

Some of those concerns you addressed are non-issues.

Bower is a convenience for me personally and I wasn't sure I was evan going to attempt to merge that as part of the final pull-request.  I like having it in my repo for my own dev projects, I do understand the concern though since bower is not the most multi-module friendly package manager.

The CDN stuff is not necessary and easily packaged up and would be done so before release.

We're going to look at Knockout for consistency sake, we're early enough into the game to change course, but I don't want a transition to knockout to derail the project.

To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+unsubscribe@googlegroups.com.

[Mike LP]

I would like to get some feedback from the community regarding splitting the HTML and CSS into their own separate tabs.

We would like to do this to simplify the exporting and importing of Github Gists.  The defacto industry standard for online IDE editors is to separate the HTML, CSS and Javascript files into separate tabs, aka files.  If we do the same than we can make it a lot more straight forward when switching between platforms.

This would not change the "Save as HTML" option, which by default will still combine the HTML, CSS and JavaScript into a single file, though I personally would like to have an option that would allow me to save them as separate files.

[Patrick Cozzi]

Sounds good to me.

Ed - is there a good reason we combine them now that would still matter?

Patrick

[Matthew Amato]

I'm okay with splitting up the tabs but I don't see a reason for separating them out at the file level (unless it were part of a larger "export as app" feature).  That all being said, I'll defer to Ed here as well.

--

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.

[Mike LP]

@Matt

Agreed. For this GSoC project it would only ever save as single combined file.

I have a wish list issue in the backlog to provide a checkbox option to save as separate files, but that is something for a later date. I think the majority of Sandcastle users are looking for that feature.

On Thursday, June 11, 2015 at 4:58:26 PM UTC-4, Matthew Amato wrote:

I'm okay with splitting up the tabs but I don't see a reason for separating them out at the file level (unless it were part of a larger "export as app" feature).  That all being said, I'll defer to Ed here as well.

On Thu, Jun 11, 2015 at 4:54 PM, Patrick Cozzi <pjc...@gmail.com> wrote:

Sounds good to me.

Ed - is there a good reason we combine them now that would still matter?

Patrick

--
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+unsubscribe@googlegroups.com.

[Aditya Raisinghani]

I should have gotten around this sooner, but I wanted to mention why we chose React over Knockout-

One of the main features of React is composability. This allows us to create user interfaces that can be reused and are modular. React can also reconcile concurrent updates between the client and the server. This is important if we wish to support online collaborative editing in the future. SwarmJS has already created a collaborative editor using React.

Most importantly, React is isomorphic- we can pre-render the application on the server side, which reduces the initial load time for the user. This is a huge plus point for React, in my opinion.

Let me know what you guys think, and if you have any pros or cons to add.

[Matthew Amato]

I think we need to take a step back and revisit what Sandcastle is all about (and what it isn't).

Sandcastle is first and foremost a tool for interactively exploring Cesium examples, allowing people to tweak the code or otherwise learn the API.  Secondly, it's used to showcase Cesium capabilities in some more complicated examples not strictly designed for learning.

Sandcastle was never meant to be a full IDE or tool for developing production Cesium applications.

As it stands today, Sandcastle accomplishes its goals pretty well, but of course there's plenty of room for improvement. We identified 3 key issues for the Google Summer of Code project that we wanted to fix:

1. It's fairly useless on small screens and should be refactored to be responsive.

2. The overall look and feel is dated and it would be great if it it had a more modern looking UI.

3. It depends on the Dojo toolkit, which is a bit heavy and not used elsewhere in Cesium. We wanted to remove this dependency and replace it with libraries already used elsewhere in the code, like Knockout and AMD.

Adding additional third party libraries like React, JSX, and pubsub seem to be in opposition to number 3 above, so there would need to be really good reasons to include them, especially if other libraries in the Cesium repository can already accomplish the same thing. If such reasons do exist, I would not be against adding the dependencies to Sandcastle. However, I don't see anything in that currently warrants it. In response to your specific bullet points:

1. Sandcastle is actually a fairly simple application. I don't understand how composability or modularity help it. What specific problems are you trying to solve that these features would help with?

2. Sandcastle is currently designed to work completely client side and even if we had a server-side component, we have no plans to support online collaborative editing.  Even if this were to change, there are numerous ways to implement such a feature and choosing React simply because there might be a solution that we can use for it doesn't make much sense to me.

3. An isomorphic framework would provide no benefit to Sandcastle.  As I already stated, there is no server-side component.  Furthermore, the client side rendering time in Sandcastle is the Cesium code itself (which has to be done on the client due to the nature of WebGL) and not the Sandcastle user interface.

I'll also add that the choice of libraries is not just a purely technical one. Sandcastle needs to be maintained and supported along with the rest of Cesium and each additional library or feature burdens the developers with the need to understand and support them.  Keeping Sandcastle simple and similar to the rest of Cesium makes it easier to maintain.

Hopefully some of the other committees can respond with their own thoughts on the subject.

[Patrick Cozzi]

Aditya - thanks for starting this discussion.  Perhaps I can add a few ideas to facilitate moving forward.

Matt is right that Sandcastle is about 1) exploring examples, and 2) showcasing capabilities.  It is also used as a key dev tool by the Cesium team.  When I am writing core Cesium code, I always have a Sandcastle example open to experiment with the new features.  Sandcastle's quick reload (just hitting F8 is enough in most cases), no hassle server, and basic editing are critical to keeping the team moving as fast as we can.

Matt is also right about how we approach third-party libraries (also see this discussion).  The initial Sandcastle redesign is a summer project, but I expect it would have at least a five-year lifetime.  We need to think about how the decisions we make now will impact maintenance later.

Finally, to add to the point of simplicity, we need to keep in mind what Sandcastle is to Cesium community, for example, reorganizing the current examples and adding CZML examples should be a major focus to serve our users, but we've seen very little focus on it relative to tech we could use to build a new Sandcastle.  This project needs to be about the impact to the Cesium community first, and the tech second.

As for the specifics of the libraries, I am not the right person to comment, but perhaps Ed or Scott will have some insights if they are available.

Patrick

[Mike LP]

The changes made to Sandcastle using React are in no way going to break offline usage of Sandcastle or increase the complexity of the application for users.  All of the current features of Sandcastle are either already migrated or in progress.  Aside from a simple path change in the bootstrapping it will work offline now, which might already have been done.

The path that Aditya and I decided upon does user AMD and Reach will allow for an easier integration of the same code base to a client/server model later.  If the 5 year plan is to absolutely not support any sort of optional server integration for Sandcastle, then yes, I made an incorrect assumption about what future-proofing the application meant.  In which case, maybe we should abandon the ReactJS path and migrate what he has to Knockout.  

This was not a wild decision to use some new fangled technology.  We reviewed several technologies, not just React before deciding on it.  Neither of us were aware that this was not a decision we were supposed to make.  I used my experience as an veteran web application developer to guide the decision based on our review.

Regarding complexity, I've been reviewing the code as Aditya progresses and the the complexity of Sandcastle has not gotten out of hand.  A general read-through of the code shows that it is pretty well written with verbose variable names and decent grouping for methods.  It does need to have a through commenting and JSDoc session before it is ready for a Pull Request, but I'm not finding it difficult to work with and read the code.

To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/3eXLAv6KZEA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to cesium-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

twitter.com/pjcozzi

[Aditya Raisinghani]

The main intention behind adding React is that it is a powerful UI library, and it is being adopted by a lot of developers. Its rendering times are many times better than what can be achieved by Knockout, mainly because of the virtual DOM being used behind the scenes. It guaranteed that Sandcastle would be future proofed for atleast a couple of years.

That being said, I'm going to have to agree with Matt. As such, the huge benefit in rendering would not be visible in a light application like Sandcastle. As for modularity, my aim here was to just keep it simple and structured so that if anybody wishes to start contributing to Sandcastle, the application is structured in a way that it would be easy to start adding features. As a simple example, when we decided to add a new tab for CSS, it took me only 10 minutes to get that up since I could reuse the code editor component in the React app. I wouldn't say that it would be hard to maintain or understand the application even if it were not modularised, but that was done just so that the application is structured from the beginning itself.

The only new libraries here are React and PubSub. JSX simply helps me to develop the application faster, since I can directly write HTML within the JS. Looking at the code in JSX, it is much easier to understand what's going on than it would be to see the transpiled code in JS. I've added JSX as a dependency within Sandcastle right now, but I would remove this since we can directly pass the transpiled code to the Sandcastle app.

If there is no future plans to add any sort of collaborative editing, or a server side component, isomorphism provides no benefit to Sandcastle. The decision to use React was based on the assumption that there may be such a plan in the future.

As for maintaining the application, I'd go so far to say that the React application is much easier to maintain than a JQuery+Knockout application. In my research into developing an application like Sandcastle in React and Knockout, I definitely found React as an easier option.

These were the main reasons we decided to go with React. Like I said, it is based on some assumptions for the future scope of Sandcastle, and they might have been incorrect. If the community still feels the need to remove React and go with Knockout, we can do that.

@Patrick: Thanks for raising the Sandcastle examples point. Could you help me out with the CZML examples? I haven't worked on CZML and do not know what sort of examples we are looking to add.

[Mike LP]

We would like to get some feedback from the community regarding fixed vs adjustable editor widths.  Since we're using bootstrap for the layout we were thinking of instead of a completely adjustable width we would have 3 discreet widths, a narrow, half and wide.  Narrow would be 1/3 editor 2/3 viewer, normal both half screen, wide being 2/3 editor 1/3 viewer.

This is only for desktop and tablet layouts.

[Patrick Cozzi]

Hi,

> Could you help me out with the CZML examples? I haven't worked on CZML and do not know what sort of examples we are looking to add.

We need a series of very simple CZML examples that show off CZML's individual features like the simple Cesium API examples we have for different geometries.  Mike can help you propose the set of examples.  To get started see these:

• http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=CZML.html&label=Showcases
  
• https://github.com/AnalyticalGraphicsInc/cesium/wiki/CZML-Guide
  

> Since we're using bootstrap for the layout we were thinking of instead of a completely adjustable width we would have 3 discreet widths, a narrow, half and wide.  Narrow would be 1/3 editor 2/3 viewer, normal both half screen, wide being 2/3 editor 1/3 viewer.

When I use Sandcastle for debugging during development, I often move the slider so the Cesium window is big enough (without having to go fullscreen).  I guess if the 1/3-2/3 approach is much easier to code, it might work OK-ish in this case, but I think it would be foreign to what most users expect.

Patrick

--

You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/3eXLAv6KZEA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

twitter.com/pjcozzi

[Matthew Amato]

Aditya, just to try and close the loop on this.  I'm still not convinced that there is any reason to use React (or pubsub) or any other new thirdparty libraries you might plan on introducing into Cesium.  My preference would be to do everything with Knockout, jQuery, Bootstrap and the standard Cesium utility classes.  Feel free to continue down your current path as long as you like, but unless there's some substantial benefit I'm missing, I don't expect a React based pull request to be accepted into master.

As for the adjustable width editor, I think it would be a shame if we lost it, but if it's creating technical hurdles for you, I'm okay with temporarily losing the capability.  We can always add it back at a later date.

As an aside, while I know Ed hasn't chimed in on anything yet, I know he's a big proponent of the variable width editor (but he wrote Sandcastle, so all of his biases are already built into the existing app :)

--

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.

[Aditya Raisinghani]

Thanks for your help Matt. I'm working on a Knockout version right now and I should be done in the next couple of days. The adjustable width editor has been added and we've removed the discrete options since it does not seem intuitive.