Comments (19)

Here is one idea for the layout (viewable on the dev site). It brings most important resource information on top along with screenshots that encourage visitors to explore. ‘Most Popular Content’ module displays links to resources (and possibly topic pages & other content items) that were viewed/launched by users most in the past week or month. The idea is borrowed from NY Times and other news sites. The same way we could show related content.

I think Alissa’s redesign improves the visibility of the different modules on tool pages. The current ones are rather static in arrangement, while this particular redesign would likely compel users to explore (or at least notice) the content of the different modules. I also think the repositioning of the “Launch Tool” bar/icon/link is helpful in that the tool itself is more closely aligned with the tool name (and the authors’ names).

Tool pages, and all nanoHUB pages with an active use nature, should be designed with the natural sequence of steps to perform that use presented with a flow similar to the flow of words on a page meant to be read — left to right, top to bottom. The most important and frequent use points should be at the top and left.

Lines are shorter (shorter lines are more readable lines and make for understandable content).

The Launch Tool button is repositioned (more central, hence more visible & more likely to prompt its use).

Versioning is near the Launch Tool button (which tells the user when they press this button, they will get this tool version).

Open Source designation has moved to a logical location within the ranking module that offers lots of critical information about the tool. This was a request voiced in the User’s Forum!

The Supporting Document is also located near the “launch site” (button) and that placement makes loads of sense. But I think the title should be “First-time User Guide” instead. What is the utility of the archive button in the same place?

Author names could be located to the right of the tool’s title, freeing up more space for important info about the tool (relates to George’s comment about information hierarchy).

Also along these lines, I love the nav bar with the screen shots, but think it is too wide. You could make a standard two-screen shot nav bar (with the arrows that will move users to add’l screen shots). Doing this, too, would free up space in this important cyber estate. Not all tools have so many screen shots, and even this page layout shows five, with gray space leftover. And that gray space could be re-purposed for more tool information.

That better purpose would be increasing at-a-glance text from a line or two to a small paragraph.

Am also unsure whether the gray line in the middle of the proposed layout is necessary. The tabs serve as a demarcation of a new section, while the gray line seems to indicate two separate sections of the page and in some ways “feels” like a visual barrier to the “rest” of the page.

The new module, ‘Most Popular Content,’ is nifty: it is a means to bring information to the end user in a way they are already accustomed to seeing it on their home news pages, and that, too, could engender more exploration of the site’s topics/articles/resources…

Gerhard had a good idea about supporting documents: Take the space available on Alissa’s mock-up for screen shots and divide it in half. On the left half, show the screen shots with arrows to scroll through. To the right of that, make a similar display for supporting documents. If the supporting document is a resource, we can use its thumbnail (if it has one). Otherwise, we can use an icon for the file type (PDF, PPT, etc.) with the title beneath the icon.

I think a redesign like the mockup provided here is crucial. Looking at this beautiful example, it’s almost difficult for me to look again at the current tool layout. That is a huge compliment to the impact of this wish.

To reiterate some of what other comments have already suggested, the few changes to the mockup that I envision are:

1) Give more visibility to the supporting documents as side-by-side thumbnails to the right of the screen shots (as Mike M. mentions)
2) Remove the horizontal dark line above the tabs. The line seems to separate the lower section of the page, as though it should only be navigated by “advanced” users, which I don’t think should be the message.
3) Make the box in the lower right for other related content and resources. Somewhere, perhaps here, I think the resource’s tags should be listed for the user to see. This way they could click on the tags for more resources of the specific type they’re looking for. This would also encourage the use of tag navigation.

the tool authors should be linked to the tool author page.
But the institution should not be derived from the author tool page, but should be static to the time when the author was added to the list. The key is that when authors move to other institutions (this has happened) the institutional credit should not move.

like this a lot
I like all the little icons of a compass and Ski slope and Teaching.
I presume the “open source text” vanishes when it is not open source.

On the First time User guide compass, I wonder if that could be a standard icon in the screen shots as well. Maybe not inside the scroll area but outside – I really like the compass symbol and we keep getting the question about how do we guide our users.
I like the tabs being small enough, but in the middle of the view – indicating that there is a LOT of information available.

In some of the tools we will have introductory videos – I guess they are well-placed in the screen shots area? In that sense I would also like the compass in that area as well – .

On the Teaching though I am not so sure if this grabs the issue of appropriateness for
1) Freshmen/Sophomore,
2) Junior/Senior
3) Masters
4) PhD.
I almost think that this is like a keyboard where multiple buttons could be pushed.
Meaning, some tools could very well reach 2-4
Some other items are very good for teaching but really only for 2 or just for 4.

This is a very nice design! The tool author should be deliberate about including relevant links in the first paragraph of the Description. For example, on the ABINIT page, we have links to the ABINIT web site and user guides at that site; these should be more visible on the page, but I think the tool page author should be responsible for that.

Props to Alissa for a very cohesive re-work of the tool page, with all the feedback nicely synthesized!

I just have a small few bits of feedback.

Users, reviews, and wishes in the ranking module have unnecessary parentheses around the plural s/es. Delete them.

What is the purpose of the blue square icon w/ intermediate label, when you are showing the k-12/undergrad/grad/advanced grad scaled “heads” immediately to its right? Doesn’t the coloring of the heads say “in the middle (intermediate)”?

Also, on the scale of “heads,” I think Gerhard wanted to represent only college students and grad students…so I guess it’ll be important to get that meaning squared away for best use of the icon (which is brilliant…).

Final note: Rhetorically, however, it would appear that the head size is inflated, the higher up the academic ladder the degree…does anyone else read the icon that way?

Some tool authors are very concerned about the assignments of credits to their work.
I think in the contribtool process should offer a set of standard choices that can be checked off for each author
These standard choices could be from the following set:
1) developed (parts) of the core simulation engine
2) developed (parts) of the graphical interface
3) defined simulation tool and user requirements
4) managed the tool integration
5) Other – free form text

Handling of version annotations, or release notes for EVERY new version of code.
It should be part of the contribtool process where the developers are being asked to enter some ptoper english text about the new release.

Look for example at the very cluttered description that is now in
tools/rtdnegf

All these version notes should go with the “versions” tab.

Also each of the releases a developer should see the list of open tickets, questions, or wishes that may be “clicked-on / chosen” indicating that the new release of the code closes these items or addresses these items.

That should create a link on the versions tab to the question or the wishlist or a ticket number.
It should also close these tickets, questions, and grant the wishes.

The new design is in place on the dev site and ready to be pushed live. (see latest screenshot)
The experience/skill rating system is actually a separate wish (http://nanohub.org/wishlist/general/1/wish/118). Let’s continue our discussion on this item there.
The ‘Most Popular’ block will be turned off for some time, it needs more discussion. Instead, ‘See Also’ area will move up.
Supporting Documents will appear in a separate tab, with a link to it under the launch button.
Non-tool pages will have the same layout as tool pages.
If noone has serious reservations, I can push the code live as early as Dec 11.

The following items should make separate wishes:
1) Version notes handling
2) Handling of author credits
3) Handling of library credits (isn’t it what we currently have under ‘Powered by’?)

I doubt we can complete them all by the site visit. Version notes handling seems most important and I will get to it next.

On the multiple institutions example, Purdue University, West Lafayette is correct for both instances (#1 & #4) and a semi-colon at the end is unnecessary. Several of the mock-ups have a semi-colon at the end of the authors’ lists, so I thought I’d mention it.

On the archive tool page, is “unpublishing” a jargon word, widely used? It strikes me as a bit odd.