Support Options

Submit a Support Ticket


Wish List - Wish #234


Member avatar

0 Dislike

Alissa Nedossekina

Projects component to enhance and replace contribtool & com_contribute

Purpose: manage contribution, development workflow and versioning/archiving for various types of projects: a) tools; b) other hub resources, i.e. downloads, courses etc.; c) source code & libraries; d) data.

The idea is to blend and extend functionality of current Contribtool and Contribute components so that every content contribution and application development project share the same publication/versioning process as well as tools for content editing, access controls, archiving and usage monitoring.

Another important objective is to improve the current resource contribution process by guiding users through a series of questions to determine their specific project needs, rather than asking them to choose a contribution type up front. Depending on their choices during the simple 1-2-3 step project setup process, the component will determine the type of the resource to be created and any specific tools that need to be provisioned.

Problems com_projects addresses: – Need for subversion for non-tool resources expressed by a number of hubs – Need for version control and associated DOIs for each publication of any type – Integrate process for accepting editorial changes – Simplify resource contribution process, make it more intuitive – More management options for resource authors: ability to add and manage screenshots, describe credit information for each author, append/edit release notes for each version, etc.

Comments (4)

  1. Alissa Nedossekina

    Here is the first draft of user interface mock-ups for com_projects.

    Reply Report abuse

    1. Gerhard Klimeck

      This is very nice! A few comments: 1) on the picking of the “right name” we should have some tips for the users. We use tool names in google scholar to find references. Having a unique name is useful for tracking citations in the literature and for name recognition. 2) there should be a more detailed approach to giving credits to authors for their contributions (GUI design, core engine etc.) 3) there needs to be a step on the provision of validation of the software. There may be documents associatied with that and we want to have developers provide such documentation . There is a wish out there to include selective elements of the tool “doc” directory I like that suggestion 4) we need to have plain english descriptor of the various stages of code revision. We want to show to users in plain english the list of added features as we update and improve tools. Please see rtdnegf or pcpbt as examples.

      related wishes are

      Reply Report abuse

  2. Michael McLennan

    Another interesting addition… Right now, contribtool always checks out svn trunk (hard-coded in the install script). It would be nice if the tool contribution process could prompt the user for a svn tag/branch (“trunk” could be the default), and this parameter would get passed through to the install script.

    Reply Report abuse

  3. George B. Adams III

    There are several other comments on wishes with remarks pertinent to contribtool. Can you search all the comments to find these?

    >< Comments on com_projects.pdf: ><

    When I image that I am a first-time contributor to nanoHUB and following along in com_projects.pdf I become unhappy and then feel abused. But a few tweaks and all would be good.

    Please image that you are a first-time contributor to nanoHUB. You’ve never seen contribtool, its code, its design. Now join me in a walk through. What will you feel?

    Section A: As you begin the page is mostly blank (because you have no projects yet). Will you see the “+ New Project” button over on the right? After a while you do, because the text on this page is of a kind that is read from left to right. be nice to put this button flush left above “My Projects” and label it “+ Start a New Project”. You probably don’t notice the small annoyance of hunting for the “+ Start a New Project” link.

    Section B: You clicked “Start a New Project” and the very first thing you are told to do is “pick a project name.” However, after reading the “What’s in a name?” text block you perhaps begin to realize that you must _guess_ a unique-to-nanoHUB identifier string. So to be allowed to contribute to nanoHUB the very first thing you must do is submit to the playing the subordinate role in a game of “I’m thinking of a number, can you guess what it is?” Feeling a little unhappy?

    The next three things contribtool would do are threaten you, “the unique name cannot change,” and then imply you might not have much ability, saying “so pick a good one” and finally become demanding, “now!” Feeling abused yet? Let’s start section B over for a better first impression.

    Start with“Please tell us the title of your contribution.” That’s it. That’s all. To satisfy any need for a unique ID string for the project, have the code play that guessing game.

    Perhaps the intent is for the project ID to also be the short name that is a text alias in nanoHUB URLs, for example the way and are actually the same page. If this is the goal, it exacts too large a cost on the contributor. Use a machine-generated ID for the project and obtain a text alias at a later time and perhaps give the contributor suggestions as to strings that would be unique. Only bind the test string to the resource number at the instant of publication so that the user can have second thoughts about that text alias. This mimics the paper publication process where nothing is set in stone until the author(s) return the galley proofs.

    End of scenario of imagining a first-time contributor experience.

    Section C.1.0 “What files can I upload?” righthand sidebar. The complete list of acceptable file types should be easily available. “etc” leaves the user with the unhappy option of trying with their particular file type and hoping it will be acceptable. Users should never have to hope nanoHUB or HUBzero will work for them.

    Section C.1.2: Experience on nanoHUB suggests that asking a contributor to categorize a simulation tool as research or education will not provide valuable information because the distinction seems to be not meaningful in practice. So, I suggest we don’t ask.

    Section D1.0: This section should be swapped with section C. Co-authors come before the body of the contribution.

    Section F.3.2: HERE is where we should provide all the co-authors with an HTML snippet that they can place on their own web pages to point to their new contribution to nanoHUB.

    When the user is asked for a short name for their simulation tool we should open a new window that shows the Google/Bing/Yahoo results of search on that short name with advice on what constitutes a good name (more rare) and what might be a not so good name so that a contributor can be more informed when deciding on a short name.

    Every resource type on nanoHUB should have, as much as possible, the same fields of identifying information. Must involve Michael Witt of Purdue Libraries for expertise in this aspect. We must be totally professional in this aspect. The database of this information should be compatible with the citations database field for field.

    New versions of resources of any type should not allow co-author deletions unless deleted co-authors give permission and the version number is incremented to a new major version. Addition of co-authors perhaps could be allowed without unanimous consent from existing co-authors, but may still be too risky.

    The Editorial process should be discoverable much as the history of pages on Wikipedia can be viewed to see what changes have been made and who made them.

    Contribtool should incorporate all the aspects of the scientific publishing process. The step before publishing a journal article is the Galley Proof.

    Reply Report abuse, a resource for nanoscience and nanotechnology, is supported by the National Science Foundation and other funding agencies. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.