It looks like a video game, what with the colorful status boxes, photorealistic 3D earth, and translucent blips of debris. Does modern scientific software really look anything like that? I was under the impression that they were all ugly, function-over-form designs, but I admit I’ve never actually seen any in action.
(I understand it’s just a simulation, but you see people in another picture sitting under the same interface showing slightly different data, so it’s at least not just a single photoshopped image).
Watching their video, it seems increasingly improbable. There’s too much info on screen flying by to really make sense of anything, each tracked object supposedly has a nifty green 3D futuristic-looking portrait attached to it, and each new object found seems to pop up a new modal dialog box.
I can’t imagine it actually working that way, but it sure is beautiful…
(ETA: And apparently this is over a year old. Whoever told me about this is way late, but the question still stands)
Well, it’s possible that somebody decided to spend the PR budget making a presentation interface that looks like a video game. Beware: relevant TVTropes link. I’m pretty sure the GUI that’s actually used by people who work in the field looks much more like a spreadsheet.
Those fancy displays are usually just for show, at least in part. Sometimes there is useful information and/or control on them, but function over form is the norm. That’s not to say that the standard UI won’t be graphical; it certainly will be when that’s the best choice. In the linked example, I suspect that the side and bottom panels might be actually used/useful and that the middle bit is for show, except in that if something goes horribly wrong in the monitoring system, it might first get noticed by a drastic change in the earth/satellite imagery.
If you ask the regulars in the JPL mission control room about the pretty displays near the ceiling that are flashing all sorts of vital-looking stats about current missions, most will say something like, “Yeah, I’m not sure what all those are showing. We don’t look at those. They’re for the public.”
It’s not unusual for a programming team to create a “pretty” UI for display in the building lobby and impress visitors, often fed from the same data as the real UI.
But yeah, I concur: pretty or not, this isn’t a UI designed for day-to-day usage. It’s either a early prototype, something to impress investors, or a pretty display for the lobby of the building.
The pretty graphics there isn’t hard at all. The little colored dots for the satellites are about the easiest sort of graphical task there is, and the wireframe Earth (I’m not sure how you get that it’s photorealistic) is available from a number of standard libraries that they probably have lying around anyway. The windows to the side are probably less likely; the majority of user input in most scientific software is via boring terminal command lines.
I don’t really see what’s so special about the image. It’s easy to make satellite tracking software or radar software look cool and 3D plots can be useful. I use a program for weather radar that has a more photorealistic 3D earth than this one, the only difference is that weather radar returns are superimposed on top of the map instead of floating around the globe and the menus have less decoration. But the program I use is free and was created by a college student in his free time.
To expand on the previous answers, when we give a presentation the issues and risks with a launch vehicle and mission, all of the real data is either text and simple line graphs (structural and thermal margins, useful life estimates, component qualification, logic flows, et cetera) or complex “squiggly line” and statistical charts (Nichols and Bode plots, statistical assurance criteria, Monte Carlo distributions). However, the things that grasp the audience’s attention are the color contours of finite element and fluid dynamics analyses and trajectory animations, even though there is often little discernible information from these, especially for an audience that is mostly managers and executive-level decision-makers who don’t have the first notion of assessing convergence criteria or local strain energy gradients. We probably spend more time–and get more kudos–on these fancy animations than the actual analysis and data reduction work, just because it is visible.
Similarly, while I’ve never worked console, most data at the console is strictly text. However, every control room I’ve ever been in–even one for launching small sounding rockets–has a “big board” (these days a collection of LCD screens ganged together) which has the primary function of keeping the MHG and dignitaries occupied while the flight director and worker bees do the business of managing and monitoring the launch ops.
There are times when a graphical interface can be very useful for visualizing information, such as comparing CFD simulations to wind tunnel flowstreams or the first order response modes of a flexible structure, and there is an entire field of research within data science called visual analytics which studies how to create visual outputs that provide sufficient detail to make analytical decisions about the quality and content of the data being presented. In complex scenarios–like real-time financial market monitoring–the amount of textual data can be completely overwhelming, and having an algorithm not only preprocess but provide a kind of rational analysis is becoming increasingly invaluable.
Fortunately, with the current suite of visualization tools using open source and commercial packages and tools like VTK, Aviso, HyperView, Maya, and others it is relatively easy to build so-called “dashboards” for performing real-time data visualization like the one cited by the o.p. with relatively little effort. The visualization methods are just objects that one streams data into and the control panels (data boxes, sliders, radio buttons, et cetera) are “widgets” that one invokes with simple object definitions or even just create using a GUI tool and linked to a function or variable. I’ve built simple dashboards for my own use just with Python and VTK to reduce the amount of command line interaction and attendant typing errors, and also to allow for observing batch processes without having to repeatedly edit text files. Given a few days to understand the model and data, and access to standard libraries for orbital mechanics and visualization I could probably create something similar to that referenced by the o.p.
