PROC - Planetary Radar Observation Center webportal, How would you like the new ESA portal? Options

[Guest_jumpjack_*]

I know a person which works in Space industry. He just told me that during next months he will work at PROC project; part of this project is related to setting up a brand new web portal devoted to make available to the public all the radar data collected by Sharad, Marsis and Cassini missions (and other future missions).

The goal of the webportal subproject is to create a portal with two main features:
- easy of use
- speed

First one is the most difficult to accomplish, as it depends on the user more than on the system.

So, how do YOU think a web interface should be to be more comfortable?
Which kind of interface? Buttons, menus, forms, lists.... what's the best method to present scientific data to professional and non professional users?
Which kind of menus? (static, dynamic, side-located, up-located,...)
Some REAL screenshots would be very interesting and self-explanatory.

Actually I don't know if your suggestions will be taken into account during PROC webportal development, but I think it is worth of giving it a try!

[imipak]

So, how do YOU think a web interface should be to be more comfortable?

Thanks for thinking of UMSF and asking!

If I could make just one request, it's: just HTML, please. No Flash!!

On the assumption that radar data means images(?) -- it's handy if there are index pages with thumbnails linking to full-res images, as it makes it easy to "wget" multiple images. Oh, and if the endpoint URLs could have a predictable or regular form, easily reproduced in simple scripts, that's also very handy. (eg., "http://sharad.proc.org/full_res/image-00001.jpg" , "image-00002.jpg", and so on.)

[Juramike]

I'm a huge fan of NASA's planetary photojournal format: (Example here: http://photojournal.jpl.nasa.gov/target/Titan)
(my only additional suggestion would be to add a reliable way to do key word searches or jump to a particular page)

For some of the particular planetary bodies, it might be nice to have a static display of different hemispheres of the planetary body with embedded links to jump to a particular image.
(A great example is Emily's Titan RADAR page: http://www.planetary.org/explore/topics/sa...tan_radar.html)

-Mike

[djellison]

One very simple point that the PDS seem unable to grasp ( at least, several parts of it )

If you've got a data set with a few dozen to a few hundred files in it - on an observation by observation basis - please PLEASE provide them as ZIP's or GZ's or something - a single, compressed file to grab a coherent chunk of data is a massive bandwidth and time saver.

[Tesheiner]

For some of the particular planetary bodies, it might be nice to have a static display of different hemispheres of the planetary body with embedded links to jump to a particular image.
(A great example is Emily's Titan RADAR page: http://www.planetary.org/explore/topics/sa...tan_radar.html)

Another example is this one: Map of Mars Reconnaissance Orbiter (MRO) HiRISE Images

[imipak]

Interesting. I'd always assumed that:

(i) compressing image data isn't going to save many bytes (unless they're raw bitmaps of course). Certainly in JPEG, PNG, GIF etc a lot of entropy's already been squeezed out, so there's not much scope for further compression;
(ii) modern webservers/clients do content compression on the fly (which is why your browser announces "Accept-Encoding: gzip,deflate" when making HTTP requests)
(iii) ...and therefore there's no time or bandwidth saving.

I've been wrong before, of course, and I've never checked. [ Intermission: *short break for a little experimentation and googling* ] Hmmm, gzip'ing a randomly selected directory of UMSF type imagery with default settings gets me a 144Mb zip archive from 151Mb of source images, a ~5% reduction, which is non-trivial... unless the server's already compressing the data itself.

[djellison]

Try zipping up a 2 meg RAD IMG from MER. It shrinks - and you get exactly the same data out at the end as well.

Doug

[helvick]

Zipping the data for compression alone is one thing but the other critical thing is creating zip "bundles" of data files that would otherwise have to be downloaded one by one. The challenge is to decide in advance what sort of bundles people want to see or to be able to create a process that can bundle them on the fly - that may seem expensive in terms of processing power but if you have a lot of smallish files it is generally cheaper (in terms of overall cpu overhead involved in sending lots of files down the wire) to zip\tar them up into a single file on the server side before sending them along to the requester.

[djellison]

The small bodies node does a great job - bundling stuff into a flyby data set, or a day by day data set. It makes getting the whole lot just so much easier.

[imipak]

Right, yes, I see - that makes sense. 'wget' helps to some extent for getting multiple files in one hit, but it does have some drawbacks (command-line, not particularly Windows/OS X friendly, steep learning curve, etc) so I can see how a one-click archive of data would help. (wget was previously discussed here: http://www.unmannedspaceflight.com/index.php?showtopic=2005 )

I'm attached to wget partly because years ago, in the first flush of excitement at getting my first dial-up net connection (and discovering Linux , etc) I emailed a random webmaster to suggest making their whole site available as a one-click archive file. Eric "ESR" Raymond replied politely, suggesting wget did the job - and I notice UMSF is missing the "blush" smiley, so picture it here.

[maschnitz]

If you're using Firefox, and wget is too twiddly for you, I highly recommend a Firefox add-on called "DownThemAll". DownThemAll will parse a web page for image links, then queue them up for download automatically, all from a nice friendly user interface.

Along that vein, jumpjack, if your friend can present pages so that all the links in a set are present on a single page, you can make it easier for tools like DownThemAll to work.

Also, an aside: I think the savings you get in bandwidth by wrapping up sets .gz's or .zip's aren't worth the extra logistical effort involved. It's just not enough of a win for the work done.* That said, it might be worth it if you believe it satisfies your users better than the alternatives.

* ... unless you were to zip up raw formats such as BMP - then the gains would be significant. In that case, the compression can act over the whole set at once.

Compressing things twice, such as when you use JPEG lossy compression to compress raw data, then create a GZIP archive of those JPEGs, almost always means the second compression is feeble. This is a consequence of information theory - all the redundant information has been squeezed out of the JPEGs already.

But the file sizes on uncompressed BMPs and such are a bit unwieldy.

[Guest_jumpjack_*]

What do you think about HiRISE site?
http://hirise.lpl.arizona.edu

I'm really enthusiast of it: fast, easy to use, lot of informations even for not-scientists.

[maschnitz]

It's very nice. Nicer than most, definitely.

A pet peeve I have with mission sites in general is that their front pages tend to make it hard to tell what you can do with them. (We used to call this "hiding the chalupa"). Web users focus in on the primary area of a page almost subconsciously. This is the area roughly 400x300 a little down and to the right of the top right corner. Unless end users know already what the site does, or unless it follows a recognizable structure like a board or a search engine, they expect that area to contain a link to what this site does, or a menu or description of the same. If it's not there, they get confused.

The first page hit, without scrolling, also needs to convey a rough site structure for mental note, and an overview of what's possible for a variety of user types.

Mission sites tend not to do this well. HiRISE's first page hit is a decent example of this. On the first page hit, without scrolling, it's hard to tell what the primary use cases of the site are as an end-user. "What's an anaglyph?" (I know what it is, but I'm saying an end user wouldn't.) "What's a stereo pair?" "What's on this site that I can understand and use?" It's possible the HiRISE website people did an analysis of their user base and decided to focus in on the more technically apt enthusiasts and the scientists using the site. But even so, the support for casual enthusiasts and plain curious-but-not-enthusiastic taxpayers still needs to be there. Typically your more advanced users will find what they're looking for no matter where you put it on the front page.

Also, as a general rule, you don't want a menu with more than 7 items in it. People can navigate & remember 7 items with their short spatial term memory. 8, not so much. 9, forget it. A 9+ item menu says to the first-time user, subconsciously, "ignore this for now".

The end effect is that the site is off-putting to the casual users that help pay for it.


All that said, HiRISE does several things much better than most. It does the front-page hit decently well, once the user overcomes that first critical initial impression. The big, clear, web-sized pictures are great. It reminds me a bit of boston.com's The Big Picture (which, BTW, is a great example of how to structure a site simply and clearly and utilize the web's basic strengths - note in particular the great use of vertical scrolling, something all browsers do well). I want more of those web-sized pictures in general. The layout is nice, wide, crisp, and consistent. The fonts are easy to read and in good contrast. The pages aren't noisy with a variety of small images and table structures.

In general, I'd recommend concentrating more on the 4 or 5 primary use cases the site provides, particularly the 2 or 3 all users could care about, putting the 5-10 secondary use cases "off to the side" a bit more, creating a (secondary?) blog-like structure for news so there's a visual temporal component, and presenting more medium-to-large sized images on sub-pages (don't be afraid) with links to larger blow ups and other formats. And all the great stuff HiRISE is already doing that I listed above.


Phew. Sorry for the long post. Guess I care about this stuff more than I thought!

[Guest_jumpjack_*]

Phew. Sorry for the long post. Guess I care about this stuff more than I thought!

thanks, very useful post.
Have you got any "reference" for what you say? For software interface I rely on "GUI Bloopers 2.0", an excellent guide to "what to do and what NOT to do" to build a good interface, but I can't find anything similar specifically oriented to Web pages.

For example, where did you read about the 400x300 area and he "7 items limit" for menus?

[maschnitz]

For example, where did you read about the 400x300 area and he "7 items limit" for menus?

The magic Google phrase for the 400x300 area is "eyetracking studies" - Jacob Nielsen is a big champion (an aside - it's totally embarrassing that this famous guy who's done all these detailed usability studies has this UGLY but usable site. Please ignore that).

The "first page hit" part is strongly anecdotal. It's a common chestnut in Silicon Valley web design. On a first page hit, people generally skip the menu entirely and head straight for the content. I think this too came from eyetracking. Personally, I tend to think about web users in "reptilian brain" mode when browsing fast, acting mostly on instinct and only slowing down after a minute to really look around.

The 7 items limit is older. It came from a cognitive study in the 1950s. It's generally known as "seven plus or minus one or two" or just "7 +/- 1" in shorthand. Individuals' actual numbers vary and it's important to remember that.

Sorry I don't have the single usability book to point to! All my knowledge comes from others. Usability is sadly a bit of a eldritch art, even 15 years into the Web. I imagine Nielsen's books talk about all of this, but I've never read them. His website at least a good place to start. Also, I'd recommend branching off from "web usability" and "cognitive studies" in any research you do.