Page 1 of 2

Discussion/site: project description feedback

Posted: Sat Jan 19, 2013 6:24 pm
by Jesse_V
Lately I've been concerned over the technicality of many of the project descriptions. I mean some are better than others, as there's a lot of project managers in the Pande Group, and each have their own way of expressing what they're trying to do. Unfortunately, a lot of the descriptions I've seen contain highly technical language that IMO, is only fully understandable to college students majoring in biochemistry, computational biology, or related fields. I'm wondering what everyone else thinks about them, so I set up this poll. Please use the poll above to express your thoughts on this, and you can choose two options if you prefer.

The Folding@home software makes the project descriptions extremely obvious, and as such they are often one of the first windows into how F@h works and what each person is helping with. I'd hate to see newcomers driven away in confusion. Great strides have been made recently to make F@h simpler and easier to use, and I think it could be significantly more intriguing and have more of a "wow" factor if newcomers realized the details of what they were contributing towards. Some project descriptions are this fascinating, others are unfortunately less so.

What do you think?

Mod Edited

Re: Technicality of project descriptions

Posted: Sat Jan 19, 2013 7:09 pm
by art_l_j_PlanetAMD64
To be honest, I have never (until just now) read a project description.

I just finished reading the Project 7808 description, and it does seem to be "only fully understandable to college students majoring in biochemistry, computational biology, or related fields".

I'm not really sure how PG members could make enough of the details understandable to the complete layman (like myself), in a reasonably-sized description. For them to explain thoroughly the meaning of terms like "mRNA", "codons", "peptide", etc., they would likely have to use other technical terms, which would also have to be explained using more technical terms, and so on. Maybe if those terms contained links to (for example) Wikipedia pages, the readers could explore the meanings on their own, to any level of depth down the chain of technical terms.
Jesse_V wrote:Some project descriptions are this fascinating, others are unfortunately less so.
If you could please post an example of each type (ie "good" and "bad" descriptions), that could help to guide the writers of those descriptions in how they explained the work being done by each Project. They could also use the idea of links to (for example) Wikipedia pages. Just my $0.02.

Re: Technicality of project descriptions

Posted: Sat Jan 19, 2013 7:28 pm
by Jesse_V
art_l_j_PlanetAMD64 wrote:I'm not really sure how PG members could make enough of the details understandable to the complete layman (like myself), in a reasonably-sized description. For them to explain thoroughly the meaning of terms like "mRNA", "codons", "peptide", etc., they would likely have to use other technical terms, which would also have to be explained using more technical terms, and so on. Maybe if those terms contained links to (for example) Wikipedia pages, the reader could explore the meanings on their own, to any level of depth down the chain of technical terms.
Jesse_V wrote:Some project descriptions are this fascinating, others are unfortunately less so.
If you could please post an example of each type (ie "good" and "bad" descriptions), that could help to guide the writers of those descriptions in how they explained the work being done by each Project. They could also use the idea of links to (for example) Wikipedia pages. Just my $0.02.
Here's an example of what I consider a "bad" one that was launched into full F@h recently:
viewtopic.php?p=233030#p233030 (SMP project 8028)
diwakar wrote:Project Description:
Huntington's disease is cause by the aggregation of poly-glutamine repeats forming abnormal clumps in the neuronal cells leading to the cell death. The repeat length threshold is about 37 glutamines. These repeats are attached at the N-terminal of Huntingtin protein. It has been shown that the in the presence of the 17 residues fragment N17 of the huntingtin protein, the poly-glutamine repeats aggregate faster. However, the exact role of this small 17 residue fragment is not known. Several mechanisms have been proposed to explain the role of N17 fragment, including a mechanism proposed by former Pande group member Nicholas W. Kelley (Kelley et. al., Journal of Molecular Biology, 2009).
In this project, we perform constant-temperature simulations of the N-Termianl fragment of Huntingtin protein along with poly-glutamine repeats (17 residues) to elucidate the role of this fragment in the Huntington's disease.

Points: 218.5
Deadline:4.0
timeout:8.7
There are a number of similar projects out there, and their descriptions were adjusted to use simpler language. See how more interesting and understandable it is compared to before?
Huntington's disease is caused due to the presence of poly-glutamine repeats, which associate together to form toxic clumps in neuronal brain cells, leading to cell death and the associated overall neurodegenerative consequences. These repeats of glutamine are attached to one end of the Huntingtin protein. Interestingly, previous publications have shown that a small fragment at the end of the Huntingtin protein, known as N17, accelerates the creation of the toxic clumps. Although there have been several proposed mechanisms of its role, N17's exact role in this process remains largely unknown. In this project, we perform simulations of several fragments of the Huntington protein in an attempt to discover the role of this fragment and its implications in Huntington's disease. For more detailed and technical description of the project, you can read a publication by former pande group member Nicholas W. Kelley (Kelley et. al., Journal of Molecular Biology, 2009).
I mean it still is a bit technical, but much better than before. I think the key is that the project managers should assume that the donor knows nothing about the background into the project, instead of assuming that they are fluently familiar with it.

Re: Technicality of project descriptions

Posted: Sat Jan 19, 2013 7:54 pm
by art_l_j_PlanetAMD64
Jesse_V wrote:There are a number of similar projects out there, and their descriptions were adjusted to use simpler language. See how more interesting and understandable it is compared to before?
Yes, the new one is a much better description.
Jesse_V wrote:I mean it still is a bit technical, but much better than before. I think the key is that the project managers should assume that the donor knows nothing about the background into the project, instead of assuming that they are fluently familiar with it.
I agree, and perhaps the project managers could use examples (like the two you showed here) to help guide the PG members writing the project descriptions.

Re: Poll/discussion: technicality of project descriptions

Posted: Sat Jan 19, 2013 8:07 pm
by Kornflake
Personally, I don't get worried by how technical a description is. I'm more disappointed when a description is totally missing.

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 12:41 am
by Alan C. Lawhon
I took a little bit of physics and chemistry in college, but that was many years ago and I never used what I learned once I got out into the "real" world. (I wound up in computer science, specializing in relational database technology.) When my sister was stricken with Parkinson's disease, I began a serious study of Parkinson's which led me into DNA, biochemistry, computational biology, and (eventually) protein folding and the Folding@Home project. After I downloaded the FAH software and began folding, I became interested in the Project descriptions. I was especially keen on the projects in which my computer was crunching work units. I did notice that some of the descriptions are rather sparse, such as one which states something along the lines of: "This project studies Markov state models which have applicability to protein folding dynamics" (I'm paraphrasing slightly.) That statement could be said (or inserted) into nearly every one of the projects. Then, as Jesse has noted, some of the other project descriptions are much better - with much greater detail and clarity.

I think one of the problems here in translating "scientific language" and jargon into layman's terms is that it's really difficult to translate technical concepts and abstract ideas into ordinary everyday language that is easily understandable for non-technical folks. (I include myself in this group of "non-technical" folks.) When I first began folding, I started bookmarking articles and topics beginning with the "DNA" topic on Wikipedia. For every new term or definition I came across, there was a separate Wikipedia article with its own hyperlink - which I dutifully bookmarked. I haven't counted the exact number, but I am well into between one hundred and two hundred topics (and sub topics of sub topics) all of which I have bookmarked. (I've read maybe a quarter to a third of all the information I've bookmarked.) In my browser I have separate folders set up for: (1.) DNA, (2.) Biochemistry, (3.) FAH, (4.) Parkinson's Disease, (5.) Protein Folding Dynamics, (6.) Supercomputers, and I've even added a separate folder for "Rosalind Franklin" and bookmarked several articles related to her. I'm also in the process of reading a book, "DNA: The Secret of Life" by James D. Watson, which is a pretty good explanation of the science and history of DNA written especially for the lay person. (Dr. Watson had a collaborator/co-writer, Andrew Berry, who probably did much to help make the book more understandable to ordinary people. I highly recommend this book if you can find a copy.)

One thing which has become obvious to me in reviewing and trying to understand all this information is that understanding biotechnology, protein folding, and living organisms is an area of study and science where one can literally spend their entire professional lifetime - and many great scientists are doing just that. (Some of the most fascinating reading I have uncovered on Wikipedia concerns the scientists themselves - such as Cyril Leventhal and Christian B. Anfinsen - and their discoveries and contributions. These scientists have won Nobel prizes for their contributions. That in and of itself tells you that there is nothing "easy" here - that these folks are working on really tough problems.

Understanding what is going on inside the cells of our bodies is complex science. Some scientists and researchers are better than others in "simplifying" and expressing in lay terms what they are doing, but it's not easy taking a complex multi-disciplanary subject of this complexity and translating it into simple english for the understanding of lay people. If we get a good "non technical" explanation in a project description, maybe we should look upon that as a bonus. The important thing is not to distract these scientists and let them do their work. We donors are making a positive contribution in donating our CPU cycles - and we can all be proud of that - but I'm thinking about my sister and what she's going through. The more we can do to help the scientists do their work, the sooner we can look forward to the day when our loved ones suffering will stop.

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 12:54 am
by Jesse_V
Alan C. Lawhon wrote:I think one of the problems here (in translating "scientist language" into layman's terms) is that it's really difficult to translate technical concepts and abstract ideas into ordinary everyday language that is "easily understandable" for non-technical folks.
I can see this being a problem, and I'll recognize that some people are better at this than others. If a project manager is having difficulty with this, how could they get help with this?

You reminded of my bookmarks bar as it appeared last year for my research for Wikipedia, though I don't think had that many! I had more scientific publications than web pages. :)

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 6:53 am
by bruce
When I read a project description -- or, for that matter, one of the technical publications a year or two later -- there's a lot of technical terms that I don't understand. I have found, however, that if I just keep reading and I understand some small percentage of what is being said, I'll eventually come across a tidbit of education that fills in some of the missing pieces. I don't mind that the scientists know more about their field than I do. In fact, that just reminds me that FAH is on the forefront of important research.

Nobody should use obscure language just to try to impress, but some concepts just can't be explained with layman's terms. I'm the one that should be learning those terms.

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 8:01 am
by Jesse_V
Bruce, sure the curious may pursue the definitions and try to figure out what they mean, but that requires that they invest time and effort to do so. Not everyone is going to do that, nor should they have to. I'm going to respectfully disagree with you on your last point though. The Science FAQ and the F@h Wikipedia article are two examples where complex concepts are expressed using non-technical terms. There are other places too, such as most of the F@h videos from the PG.

It's possible to go too far in the other extreme and make things too simple. That's not good either. IMO, the project managers should assume that we're on the level of an college freshmen with an undeclared or non-science major. That seems like a good mid-way point to me.

The poll results so far indicate that there's a problem that needs to be fixed. Clearly not everyone has invested the time in effort in crash courses in math, molecular biology, and computational chemistry, whether it's their responsibility to do so or not.

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 9:58 pm
by compdewd
To include one simplified version and one technical version to satisfy both ends of the knowledge spectrum would be the best IMO. Though, as mentioned before, the simplified version may take more work to come up with than the technical version. I think that having a simplified version will certainly benefit the project, but the question is will it benefit the (Folding@Home) project more to have the (individual) project managers use their time to come up with a simplified explanation or to do the technical work that moves the (Folding@Home) project as a whole forward? I don't know how much work gets done in about 15-30 minutes of a project manager's time, but take 15-30 minutes out of each project manager's time to come up with simplified versions of project descriptions for each project and that may make a significant impact on moving forward with the Folding@Home project.

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 10:12 pm
by Jesse_V
compdewd wrote:To include one simplified version and one technical version to satisfy both ends of the knowledge spectrum would be the best IMO. Though, as mentioned before, the simplified version may take more work to come up with than the technical version. I think that having a simplified version will certainly benefit the project, but the question is will it benefit the (Folding@Home) project more to have the (individual) project managers use their time to come up with a simplified explanation or to do the technical work that moves the (Folding@Home) project as a whole forward? I don't know how much work gets done in about 15-30 minutes of a project manager's time, but take 15-30 minutes out of each project manager's time to come up with simplified versions of project descriptions for each project and that may make a significant impact on moving forward with the Folding@Home project.
Good idea. Although a researcher will launch a number of similar projects with the same description, you're right that getting the wording right in the first place does take time. I don't know how much works gets done in 15-30 minutes either, but it may be a worthwhile investment of their time. What could help with this? Post in the beta team forum and ask for help clarifying it? Open a Google Doc? Appoint someone specifically to help with the wording?

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 20, 2013 10:31 pm
by compdewd
Jesse_V wrote:Good idea. Although a researcher will launch a number of similar projects with the same description, you're right that getting the wording right in the first place does take time. I don't know how much works gets done in 15-30 minutes either, but it may be a worthwhile investment of their time. What could help with this? Post in the beta team forum and ask for help clarifying it? Open a Google Doc? Appoint someone specifically to help with the wording?
IMO your suggestion of opening a Google Doc and appointing someone to be in charge may be the most efficient way of accomplishing the task of making simplified versions available. A subforum on this site could be made where each different set of projects had their own thread where the people on this site could contribute their individual research efforts of what a technical sentence means. Then the person that we put in charge could pick what the best description of a sentence is and consolidate each best description for each sentence into one Simplified Version on a Google Doc or in the original post of the thread for that set of projects. Some problems with that idea: having threads for each set of projects could cause a mess in the "View new posts" and having one thread for every single set of projects could cause clutter and confusion and a lot of posts to look through. Other than that it seems like a feasible idea. Having the community do some research to contribute will educate the community as well :) Win-win!

Re: Poll/discussion: technicality of project descriptions

Posted: Sun Jan 27, 2013 8:50 pm
by Jesse_V
compdewd wrote:
Jesse_V wrote:Good idea. Although a researcher will launch a number of similar projects with the same description, you're right that getting the wording right in the first place does take time. I don't know how much works gets done in 15-30 minutes either, but it may be a worthwhile investment of their time. What could help with this? Post in the beta team forum and ask for help clarifying it? Open a Google Doc? Appoint someone specifically to help with the wording?
IMO your suggestion of opening a Google Doc and appointing someone to be in charge may be the most efficient way of accomplishing the task of making simplified versions available. A subforum on this site could be made where each different set of projects had their own thread where the people on this site could contribute their individual research efforts of what a technical sentence means. Then the person that we put in charge could pick what the best description of a sentence is and consolidate each best description for each sentence into one Simplified Version on a Google Doc or in the original post of the thread for that set of projects. Some problems with that idea: having threads for each set of projects could cause a mess in the "View new posts" and having one thread for every single set of projects could cause clutter and confusion and a lot of posts to look through. Other than that it seems like a feasible idea. Having the community do some research to contribute will educate the community as well :) Win-win!
Thanks. Your ideas make sense, and I'll agree that having a section in the forum would be a problem. I wonder if the contributions could be proposed in the Google Doc itself. That would consolidate everything. With that in mind, here's how I think this could work:
1) Create a Google Doc under someone's account. Publicly viewable, editable by anyone.
2) Copy all project descriptions from psummaryC to the Google Doc. Some overlap so these can be consolidated.
3) Have some way to propose alternative wordings for the description (is it feasible to work on a per-sentence basis, and if so how would that work?)
4) Have an area for a small discussion or where people could ask questions.
5) Some place for the researcher or the "person in charge" could choose from the alternatives and merge them into the final description, marking that section as "resolved".

I'm thinking lines, italics, and bolding could help seperate the sections. For example, I'm thinking of something like:

---------------------------
8028, XXXX, YYYY, and ZZZZ
Huntington's disease is cause by the aggregation of poly-glutamine repeats forming abnormal clumps in the neuronal cells leading to the cell death. The repeat length threshold is about 37 glutamines. These repeats are attached at the N-terminal of Huntingtin protein. It has been shown that the in the presence of the 17 residues fragment N17 of the huntingtin protein, the poly-glutamine repeats aggregate faster. However, the exact role of this small 17 residue fragment is not known. Several mechanisms have been proposed to explain the role of N17 fragment, including a mechanism proposed by former Pande group member Nicholas W. Kelley (Kelley et. al., Journal of Molecular Biology, 2009).
In this project, we perform constant-temperature simulations of the N-Termianl fragment of Huntingtin protein along with poly-glutamine repeats (17 residues) to elucidate the role of this fragment in the Huntington's disease.

Discussion:

Alternative 1, by Derpington:
Huntington's disease is caused due to the presence of poly-glutamine repeats, which associate together to form toxic clumps in neuronal brain cells, leading to cell death and the associated overall neurodegenerative consequences. These repeats of glutamine are attached to one end of the Huntingtin protein. Interestingly, previous publications have shown that a small fragment at the end of the Huntingtin protein, known as N17, accelerates the creation of the toxic clumps. Although there have been several proposed mechanisms of its role, N17's exact role in this process remains largely unknown. In this project, we perform simulations of several fragments of the Huntington protein in an attempt to discover the role of this fragment and its implications in Huntington's disease. For more detailed and technical description of the project, you can read a publication by former Pande group member Nicholas W. Kelley (Kelley et. al., Journal of Molecular Biology, 2009).
Discussion: I'm still confused. What are "poly-glutamine repeats"? -Derpina

Alternative 2, by Derpina:
This project is focused on Huntington's disease. We're studying a small molecule that appears to accelerate the process that leads to the disease.
Discussion: Nice, but IMO there's not enough information. I think people would like to know more. -Derpington
---------------------------

What do you think? Is this practical? Would this be viable in the long term?
This task seems too big for one person to practically handle by themselves. In order for this to work, people need to chip in. If a dozen people contribute five minutes, that saves someone from spending an hour. :)

Re: Poll/discussion: technicality of project descriptions

Posted: Mon Jan 28, 2013 5:28 am
by compdewd
I think this is a fine idea! In fact I'm putting together some preliminary Google Docs to see what you think of them :D. I think we should put a couple trusted people in charge rather than just one person so the pressure is not just on one person and so that some evil person can't come along to the open, editable document and erase it and cause those in charge to have to make backups and stress and whatnot. I think that there should be a form for contributions and a document that is maintained by a few trusted people that actually holds the current version of the simplified project descriptions. There could be another document (or a thread here may be easier) for the discussions of the proposed descriptions and questions.

Re: Poll/discussion: technicality of project descriptions

Posted: Mon Jan 28, 2013 5:58 am
by Jesse_V
compdewd wrote:I think this is a fine idea! In fact I'm putting together some preliminary Google Docs to see what you think of them :D. I think we should put a couple trusted people in charge rather than just one person so the pressure is not just on one person and so that some evil person can't come along to the open, editable document and erase it and cause those in charge to have to make backups and stress and whatnot. I think that there should be a form for contributions and a document that is maintained by a few trusted people that actually holds the current version of the simplified project descriptions. There could be another document (or a thread here may be easier) for the discussions of the proposed descriptions and questions.
Each Google Doc maintains a version history, and you can roll back any unconstructive edits. (which is brilliant)
See https://sites.google.com/a/lunenburgsch ... us-version and http://answers.yahoo.com/question/index ... 008AAOtU3H that I found in a quick Google search.

Your idea of a form got me thinking: if we can get a format down, I could write some PHP (backed by a MySQL database) and make this organized, kind of like viewtopic.php?f=14&t=22281. If this is a better idea and would be worth the effort in the long run, one of our first steps is figuring out what the PHP needs to do and how it's going to work. You've taken software engineering as well, so you know what needs to be done there. :) I could set up a repository in Github to organize the code, and it's easy to add collaborators. What are your thoughts on this?