Where is Rosetta Interactive


Rosetta and Philae are working hard at comet 67P and how they got there makes for some good interactive content.

ESA teamed up with the visualization lab at TECField for this one and chose webGL for the interface. TEC used the ThreeJS javascript library for visualization. Data was loadied into the interface using two csv coordinate files – one for the paths and another for the timestamped milestones on the journey. All 3D model data was stored as OBJ files and texture mapped with png images. Audio uses ogg.

Elegant simple clean interfaces work best when exploring new content that stands on its own. The dash and interface are a DOM overlay on the webgl allowing for simpler responsive layout changes for window size. The milestones really pull the interactive together and it would be interesting to have them denoted as points on the scrubber timeline or allow sequential navigation between them (i.e. [next milestone: encounter with asteroid Stein 3D] )

With exportable and maintainable csv files, data compression is not optimized but export from content creators is kept simple. The app is kept up to date on a daily basis and no web backend is really needed for DB entry. It will be interesting to see if how it is kept up to date while the imagery from Philae on the surface starts coming in. It is likely there is a custom CSV editor to ensure that no errors are made and that orbital data can be imported from other engineering tools.

Any mission can use an interface like this. The spacecraft and target models could be changed up and of the CSV data on paths and milestones.

Social Media:
The big social media aspects for ESA are webcast links, first images, and animated GIFs and simulations of approach and landing. Interactive content showing a timeline has to justify itself in comparison social media and outreach tools which are dense and event-based. They attract a different set of users who want to share in exploration actions not simply the results of the exploration. To bridge the two, embedding of Twtter feed tool, YouTube videos in the milestones section would make this a gateway interface to social media. In the other direction, a ‘goto’ function and embedding capability would make this a tool that could be quickly reference on social media channels (i.e. share this viewpoint and 3 days of orbit time)


“Imagine if Apollo 13 had a 3D Printer…”


Yes, 3D printer will be taken to the International Space Station on the next Dragon cargo flight (The Dragon 2 capsule will fittingly use 3D-printed thrusters, by the way).

Check out the video interview with astro’s here

Some nice NASA vids on printing the Fuel/Oxidizer mixer of a rocket engine is here

UX Science – measurement gets the answer

The simplification of user interfaces has been proceeding quickly now that the last vestiges of skewmorphism are gone. Like any new technology, the first iterations of the interface must be familiar to the users. Early cars looked like carriages, early lightbulbs behaved like gaslight, early televisions looked like radios, and the first home computers worked like typerwriters (and still do!).

But any design trend ultimately overshoots the mark, in this case iconography has possibly become oversimlified, and buttons without outlines or contrast fill are being used because retina-class displays support the fine line widths.

Curt Arledge addresses one basic question in this user interface direction: does an outline or contrast button have more usability. Check out his results here

In summary, what seems to matter are two things. First, the users’ familiarity with the icon type: i.e. the common language all interfaces share to a great degree in the iconography alphabet. Second, that user testing is still required, since differences appear in counter-intuitive places, and some design decisions affect usability less than expected.

All you’re buying is an App Store

By sandboxing App Stores and development processes, the major players have taken on the problem of developing their app stores.  Although HTML5 promised to be a universal platform, iOS, Windows 8, Android etc. make those apps second-class citizens to the native App Store versions, forcing developers to choose which platform to develop for as an initial target.

This becomes a problem for upcoming platforms that quickly need to build App libraries to legitimize their proprietary platforms, mainly  because they want it both ways: they want to lock developers time into their platform, and they want those developers to do it when there is no critical mass in that platform.  From a developer perspective, why would I write for, say Windows 8 first when I can spend the same effort on a known distribution base: iOS? Ideally I would like to write for all platforms with one codebase. Of course if the platform creator is trying to ramp up by funding key developers and projects that can work for a while, but it presumes the target audience’s planned use for the new platform.

A simple solution would have been to allow web-based technologies to acts as a virtual machine that could be further compiled to native code for performance boost, much like Adobe is attempting to do with AIR.  This would allow a write-once platform with closer to native performance, unlike, say PhoneGap which is forced to work in a browser window and so is not really a native App. Performance on, say, smartphones and tablets, is quickly becoming good enough that a small performance hit would be acceptable.

Being proprietary does not in itself attract developers – being a good return on investment does. It may be that the performance gap between native code and HTML5-based apps is not closing as fast as it could because platform creators do not think this way.