Life Cycle - Community Needs

7 posts / 0 new
Last post
Life Cycle - Community Needs

The Community Needs page seems to have the right stuff on it, but it's heavy on terminology and light on explanation.

  1. There should be a brief explanation (2-3 sentences at most) about what we mean by community needs (Who is "the community?" What's our scope?) and what information the RSP has about community needs. If necessary & appropriate, we can link to more information about the community and the scope that describe the vision beyond XSEDE.
  2. There's a major disconnect between the page title (Community Needs) and the options provided, all of which talk about requirements and use cases. We should probably add a link--either in the list of links or in the descriptive paragraph mentioned above--to a single page that explains in layman's language what a use case is. Link text: "What's a use case?"  And why are requirements mentioned, anyway? This is the only place in this section we use the word, and it doesn't look like we have any information about requirements available. (This page: community needs. All linked pages: use cases. Requirements are only mentioned, not explained or linked to?)
  3. The option to enter a new requirement or use case is probably the most important feature of this page. It shouldn't be last in the list, and it should say "enter" or "propose" instead of "submit." (No one wants to "submit.") I would really, really like this to be available, functioning, AND featured when the RSP goes live. I'm happy to help. What can I do to make this happen?
  4. The "Discover use cases" link currently goes to a filterable alphabetic list of use cases. The UI controls take up most of the visible part of the page and only one or two use case titles are actually visible. I don't think most people will know what to look for or do here. I think this should instead go to the landing page for the use case repository described in this discussion thread: Products: use cases, delivery priorities, and delivery plans. Specifically, this should be a page that invites users to browse use cases by category, by user type, or by software, or use the "advanced" faceted search interface. If we can't do that, at a minimum this page needs to display far more use case titles (a dozen would be good) without having to scroll the page so people get the idea of what they're looking at. Preferably not the "enabling functions" (CAN-* category) because those aren't user-facing use cases and their titles aren't inviting. (Compare these to the first three or four campus bridging use case titles and you'll see...)
  5. The "Discuss requirements and use cases" link currently goes to a page that has a (single-entry) list of discussion forums. This needs more explanation of what it is, who it's for, and what to do when you get there. Ideally, there'd be more discussion topics. But--truth in advertising--we aren't really using this capability yet, which is why there's not much here. So perhaps we shouldn't offer a link to this until we've figured out what we need here and officially launched the capability? Maybe it should be a "coming soon" list entry without a link?
  6. The "Prioritize use cases and delivery plans" link goes to a page that lists 13 priority assessments, only a few of which seem to be about use cases. First, most users will be unable to do anything here but look at what other people have done, so the "Prioritize..." link is not accurate. Second, there needs to be some explanation of what this is, who it's for, and what to do when you get here. Third, it should probably only list the rating campaigns that are actually about use cases.
  7. On the "Prioritize use cases..." page itself, the filter interface doesn't really help or make sense. The "Title Contains" field is useless because we have no idea what kinds of terms or keywords are likely to appear in a title. (A normal person would have no idea that a title might be of the form, "Fall 2017 Use Cases and Capability Delivery Plans.") The "Ratings Mean" pull-down seems out-of-place since we came here from a page promising that we were going to "Prioritize..." something, not rate for satisfaction. The pull-down menu for "Rated By" is the one thing that does seem useful. But one of the entries--the one most appropriate for use case priorities--is "Prioritization Team." This is too vague. The other three options kind of make sense--I can imagine what they might mean--but this one refers to something specific, and most people will have no idea what it is. We need to make it clearer that it's the one to choose. Also, it should be made clear that it's an XSEDE team doing the rating. Maybe
    "XSEDE User Representatives?"  Or just get rid of the whole filtering interface and only list the UREP campaigns.
Delivery Effort Stage: 


Thanks for all these suggestions. I was hoping you would jump in with both feet into this specific content. We will definitely need your contributions for the content. We'll you let you know when we're ready for it.


I've drafted a page for the "describe a research need" feature. In this draft, the page allows users to "build" a description of a research need in the lightweight use case description format we've been using in XSEDE-2. I don't know how easy or difficult it may be to create an interface like this in Drupal. If it's difficult, it could be simplified by changing things to freeform text entry with a bit more instruction, but we should do our best to tell users what we need from them. E.g., the user experience should be a list of numbered steps, the person type should be one or more of the following, separated by commas, etc...

Regarding the user's contact information, I personally think we should allow everyone to login to the RSP, automatically provisioning a new account if there isn't a matching user. (It's probably ok to require an XSEDE identity, since anyone can register with XSEDE if they haven't already.)  If we can do that, then it would make sense to require that the user be logged in to submit the form, and we wouldn't have to ask for their name & email address because we'd be able to get it from their logged-in identity. If we can't do that right away, it would be ok to require them to enter a name and email address.

Hey Lee,

I made a few changes in "Suggestion" mode so you can review and approve/reject them.

We allow anyone with XSEDE credentials to login to RSP and submit content where authorized, post to threads etc. For discussion threads we require a person's first posting to be approved and then allow them to post freely after that. That way we can verify the person is at least initially legit. So, we can track who entered the form without the person having to enter anything, and if you want we can display who they are on the entry form so that the person is aware that we're tracking this entry from them.



I've filled out the page content for the Community Needs page. This handles the issues numbered 1-3 in my initial comments above. Issues 4-7 are for views linked from this page.

  • I can't change Item 4 myself, but my comments explain what I think should be done.
  • I changed the link text for Item 5, but there isn't a page to link to, so I still think this link should be removed or changed to a "coming soon" non-link.
  • I changed the link text for items 6 and 7, but the page it links to needs to be changed as described in item 7.

Looks great. Thanks!

Hi Lee,

We have a revised Community Needs page that addresses most of your comments.

What we've leaving to address later:

  • Feedback item 2: we currently link to the new Use Cases Registry page. Once you help us create that more descriptive "What's a use case?" page we can link to that also.
  • Feedback item 5: providing an improved front-page to discussion forums is going to take a little effort. We probably want to include options to create forums if a use case doesn't have them, or to simply list all the use cases and auto-create the forums when people try to post to them for the first time.
  • Feedback item 6: What do you think about a brand new view that lists use cases separately from the campaign where they were rated? I think a rating campaign centric view makes it hard for users to discover by use case.




Log in to post comments