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
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.
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.
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.
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!!!!
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
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
New blog post with the overview of the project: http://cesiumjs.org/2015/06/01/GSoC-Sandcastle-Overview/
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
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
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.
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.
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.
Sounds good to me.
Ed - is there a good reason we combine them now that would still matter?
Patrick
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.
@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.
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.
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:
-
It’s fairly useless on small screens and should be refactored to be responsive.
-
The overall look and feel is dated and it would be great if it it had a more modern looking UI.
-
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:
-
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?
-
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.
-
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.
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
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.