Issue priority: #1, Point 9, We are a community, though many want to pretend we aren't #2, point 1, making the system easier to use by non-technical users. #3, Point 10, Documentation #4, Point 7, Raising Awareness/retaining users that do join
detailed comments follow: 1) This is a summary of the issue I have been trying to get across to people for years. Sadly much of the debate is with people who love the command line and can't quite get their minds about the fact that the system is very difficult to use. Case in point is the current reliance of configuration options within text files to get reasonable use out of the system. Most of these options should be in the configuration panel so that you do not have to edit text files that may be in anyone of several places (depending on OS and OS Version). A long time request has also been for an auto-update feature or at least a notification of changes so that the downloading of an update is made simpler ... I will note however that at times the "Recommended" version is not as well tested as it should be. To put it another way, not enough people are involved in the decision to make the change to a specific version as the new Recommended, or at least I have seen no open discussion of the change... Though AMs are partial answers to some of the other points they too suffer from issues not the least of which is the fact that they have issues of their own and can be slow to react to the need for changes. I refer to my extensive test and feedback effort last year where BAM did get some updates but GR as far as I know still has not been changed. 2) My feel here is that there is less of a need for this, however, scalability issues are rarely considered when new features are implemented. Two examples, one old one new: The new is the change where the client pings projects for GPU and CPU work though the server can issue back-off times, but this does not address the question of why we are pinging for GPU work and relying on back-off when there may have been no need to add this additional server load for projects that will never have, for example, a GPU application (CPDN comes to mind). Even though back off reduces the ping rate, the reduction is not to zero. On the other side is the update rate, (as an old issue) where you have the 24 hour rule as the standard which with GPUs may be too long leaving large numbers of tasks completed and not reported (and subject to loss due to client side problems). To fix this we have the return results immediately but this is a system setting and not a project setting thus if I set this I will be pinging MW at a higher rate than I want though correctly serving other projects which have longer running tasks. 3) A grab-bag most of which have been raised in the past. Some of the points are basically that Viola did not seem to understand the way the system works. Example CPDN partial work is useful and so even if the model crashes this is not a disaster. To my mind this gets back to the documentation problem that is still not well addressed. 4) Stat sites cover most of this, but, there are statistical information about what the client is doing that is not captured that would prove useful. 5) See #3, I still think this is a issue of the lack of documentation. 6) I think it was two years ago I noted that if we could get the projects to cooperate we could actually have, now, one project a week as the featured project (there are about 50 active projects) meaning that just a little more often than once a year each project would produce an update that could be published. This is again one of those things where I advocated that we create a central cooperative that would collect and publish this information. Sadly the logical place for this to be done is out of the hub of BOINC, UCB, which to this point you have not had any interest in doing. 7) I see less of an issue of attracting new users than keeping those that we do attract. We are still at 1/6 retention rate. But we do not know why the people are leaving. There is no data, just speculation. Just as we don't know why people detach from projects ... we suggested a survey tool be added for these critical actions so we can collect data and begin to understand why people leave. 8) A point long ignored as being not relevant because it is neither important to the BOINC developers or the projects. But, it is the way the participant knows that he is actually doing something. Fairness and Accuracy are critical issues. Stupid as they are I just completed a 3-4 month effort to get my badge level to where I want it on WCG... why? beats me, but, the point is that I did and am now pursuing PG badges ... another award system that is project specific and every project's system is different from the others ... much confusion ... and not shareable (Well, there is a facebook tool for WCG) 9) I started talking about this I think over 4 years ago. We are a community and yet the pretense is maintained that we are not. I shall not rehash the points raised in those old discussions like the Participant's RIghts and Responsibilities and other discussions. The creation and maintenance of "stove-pipes" and trying to pretend that what one project does has zero effect on other projects is simply not paying attention. Simple example, MW goes down and that can cause an overload on Collatz because participant's efforts switch. A project treats people badly and some will just leave BOINC in disgust and not just stop working on that one project. 10) My point of years. I long ago pointed out that the documentation should be context specific on both the web site and GUI. Click on F1 and get linked to the web page with the documentation of the specific location. We also need to get rid of the fiction that you can document BOINC without discussing projects and how different projects affect BOINC and interact with each other. More importantly we need to collapse the 4-5 good documentation sites into one. On Jan 7, 2010, at 4:36 PM, David Anderson wrote: > Viola Krebs (as part of her Masters research) did an online survey > of BOINC users a few months back. > She's in the process of writing a paper on the results. > She sent me a summary of specific suggestions made by respondents, > which I include below. > Some of these suggestions relate to BOINC itself; others are for projects. > > Many of these are things we're already aware of > (make the software simpler, projects should provide more news, etc.) > or have already done (e.g., account managers exist). > But there are a few new things. > Comments welcome - which of these do you think are most important? > > -- David > > ---------------------------- > 1. Software and Interface Improvements > User-friendly: Improve software in such a way that it is easier to install, > configure and use, with a more user-friendly interface, usable by “ordinary” > users. > Compatible: Make the software platform independent and compatible with any > operating system (OS), as well as different video cards. > Work units: Provide work units that can adapt depending on the size of the > machine. Smaller packets should be provided as an option in order to enable > faster completion of individual tasks. > Stability: Improve stability although it is not too bad! > Adapt to the computer: Make sure that the computer is not slowed down because > of > too much RAM usage (automatic leveling of the amount of processing power used > depending on the processor's capacity and temperature (especially important > for > notebook computers). > Automatic updates: Enable BOINC to automatically update; non-proficient users > never check for newer versions. > One account, multiple projects: Provide one account that gives the user the > option to run as many projects as he would like (selection of projects from a > list), rather than individual accounts for each project. > Multiprocessing: BOINC should handle multiprocessing. > > 2. Hardware Improvements > Encourage research: Encourage research around hardware to resolve issues > related > to it (e.g. graphics card and processing unit compatibility, cooling system, > etc.). > Server: Improve the capacity of the servers running BOINC applications. > Collaborations with hardware manufacturers: Convince manufacturers of > processors > (e.g. Intel, AMD) and notebooks to design proper cooling systems that > actually > work. > > 3. Other Technical Suggestions > Improved infrastructure: Procure more funding for the infrastructure of the > systems. s...@home, for example, seems to be maxing out its bandwidth, > causing > delays in downloading new work units and uploading completed ones. > Placeholder: Create placeholders for stopped programs, so that users can pick > up > where they left off. > CPU power donation control: Provide more control over how the computer is > being > used in order to not run the CPU over a certain temperature. Give the option > to > provide 50% rather than 100%. > Credit policy: Put in place “credit-police” to make sure that no project is > grabbing the power from the others by granting too high credits. > No small updates: Stop small upgrades that are buggy and do not seem to > improve > anything. Inform about the difference between the old and new version. > Improved user platform: Create an improved end-customer platform (graphics, > options). > Screen savers: Provide screen savers for each of the projects. > Better sharing of participants: Better sharing of participant computers > between > the projects. If a project can use video cards to speed things up, use only > compatible computers for these projects. > GPU computation suspension: GPU computation should be suspended when a game > is > started, many people would just uninstall BOINC if it impairs their computer > usage. > Interaction with client and server: If I am downloading an 18 MB database > file, > why not keep that file on the hard-drive and keep accessing it, instead of > re-downloading the whole thing. > Linking: Link the projects with the users through the manager right away > instead > of having them go through all the separate sections and sites. > Efficiency vs. reliability: When a project such as climate Prediction takes > thousands of hours to complete I get a little nervous that it won't be able > to > upload and I will have wasted all that computing. Gambling days or even weeks > of > computing is less scary than gambling months of computing. > > 4. Overview and Statistics > Status report: Update a centralized status report website from all projects, > which should include not just statistics but also progress reports for > individual projects. > More graphics: Better integration of statistics into the BOINC client. > > 5. Training and Education > Importance of education: Education is also critical, especially with so many > people paranoid of viruses and so many more that have never heard of this > kind > of project. > > 6. More information about what is going on behind the scenes > More news: I want more news of what’s going on behind the scenes and what the > results have produced in a format that’s understandable for the layman. > Info about remaining time: Some of the projects don't estimate time remaining > very well. For a while, I knew to divide the estimated remaining time by 3 to > get a better estimate of actual remaining time. And if I can divide by three, > so > can the programmer! > Updates: Send emails every month to keep me informed on new projects, or on > projects I do not know about. > Information and feedback: Tell people about the research that comes of it. > Better feedback/knowledge of what was being achieved. Do the individual > results > outweigh their impact on climate change (i.e. carbon dioxide from electricity > generation)? > Translation: Giving some model of “speech”, in different languages, to > forward > to contacts/schools. > The cause: Publicize widely-supported ideals behind the projects (i.e. > finding a > cure for cancer) to attract non-technical users. > > 7. Raising awareness > Get new users: Contact universities/schools and ask them to contribute to > scientific research by running BOINC as a background task when their lab > computers are idle and unused for any other purpose. That alone would give > BOINC > thousands more cores. > Raise awareness about the system: Show people that volunteer computing does > not > compromise security of Local Area Networks in professional/business > environment. > Marketing: Better marketing, projects that can have a more immediate impact > on > society, especially in third world economies. > > 8. Rewards > Tangible rewards: Provide some sort of tangible reward. Not necessarily cash > (that would be nice), but maybe stuff donated by someone (corporate entities > or > a philanthropist) with deep pockets. Or perhaps credit for higher education > tuition. > Bring more fun for volunteers: Create game running in the background. > Tax reduction: Tax credit for the energy we donate! > Some prize incentives: Provide incentives for volunteers (e.g. prizes, > awards, > money or lottery tickets). > Variable scoring: Some projects may need to offer more credit to attract > more > volunteers. > Importance of credits: Remember volunteers are not being paid or compensated > for > any of their work – so what is the harm in letting them have a credit race? > > 9. Make it a community > Community spirit: Make it more of a community by bringing developers closer > to > end-users in an effort to gain a deeper understanding of the issues that > arise > during implementation. A faster release cycle and simpler access to optimized > binaries on a variety of platforms would also be highly welcome among those > who > donate CPU-cycles. > > 10. Better user manuals and documentation > Offer written documentation: Show some messages (news) as part of the Bionic > work screen to show how this is contributing to life on earth. Have there > been > tangible benefits from the use of CPU time versus electrical costs of running > each of the projects. > Funding for projects and documentation: Better funding and project > documentation/science from project leaders. > > 11. Promotion > Publicity: Advertise much more about. Provide more information to a broader > public. > Word to Mouth: Get governments, schools, universities, NGOs and other > organizations etc. to promote volunteer computing. Even private businesses > could > run it on their office computers and maybe advertise their involvement on > their > products. > Untapped computer power lies in universities and schools: A vast amount of > untapped computer power lies in universities and high schools. ‘My high > school > alone has over 300 computers, and I believe it is a fair assumption that > universities have even more. However, when browsing through profiles and > groups, > you rarely see schools.’ > Link to UC Berkeley: Advertise that the project is based at UC Berkeley. > _______________________________________________ > boinc_projects mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
