Simplifying BOINC UX
Simplifying BOINC UX
I hope to discuss the overall BOINC UX workflow and how it might be simplified. The workflow I use is extremely bare bones, but I think it gets the point across.
As I see it, the BOINC UX can be broken into three categories at its most elemental:
- Getting BOINC
- Researching and signing up for Projects
- Using BOINC
As you can see, a user looking for information on and interaction with a project is directed primarily to the project website. This adds a direction away from the client when the user wants to interact with projects. Could the BOINC UX be simplified by moving that information and interaction into the BOINC client itself?
This would reduce the necessary steps for using BOINC from three down to two. I think this could increase accessibility to BOINC overall -- BOINC would be the only platform needed to gather information on and interact with projects. Other resources will still thrive for those who wish to delve deeper.
I am not a coder by any means. I have no idea how this integration might manifest. Just throwing things out there.
Thoughts?
You can register for a BOINC project within the BOINC client, however it does then launch the web browser for the user to input username and select a team. If we could get the username and team selection added to the BOINC client it could make visiting the website during registration unneccessary..
I believe it'd be wise to talk to David Anderson regarding his simplified BOINC client project, he received NSF funding to do this and is likely looking for help :)
Can't wait to see all the goodies from the BOINC workshop!
@cm-steem @dutch
Just to be clear, the workflow above shows that you can add projects directly from the BOINC client. "Use Boinc -> Add Project." The section that I think is causing the confusion is the "Projects" right in the middle. That represents information gathering and interaction for projects, which is done primarily on the project website.
Some projects require site navigation to get the link for adding the project to BOINC, but all projects require you to visit the website to add a team, adjust project specific settings, and even some BOINC settings that aren't in the BOINC client. Amicable Numbers, for example, lets you choose the number of CPUs and tasks it can use at a time, which is very useful.
All of that might be even more useful -- if just used at all -- if it was directly in the client. Anderson's TBD project seems to seek the same goals, but the project is young and the public presentation is not detailed -- probably for good reason (it's David Anderson, not a scam ICO CEO x,y, or z). I expect more information will come from the BOINC workshop.
Ah, yeah I misinterpreted it.
A certain problem/difficulty is that these settings are not always in the same space across BOINC projects :/
couldn't they be put into the BOINC client, then pushed to the projects when changed? similar to how boinc settings are pushed to projects now. it would require a certain degree of centralization -- or a blockchain? xD
Not all projects follow the same configuration/implementation though, so any scraping of project websites might not work for all projects in the client.
what if instead of scraping a project website to populate the client, the client pushed data to the project website?
For example, if I change my settings in Steam, the Steam website updates my profile with these settings.
This might require some sort of structure that projects should follow, but as TBD is looking to rework the structure of projects anyway, why not explore this possibility at the same time?
As TBD is going to act more as a manager, as I understand it, not all projects would need to follow this structure, but those that did would benefit from the in client user control.
TBD is only proposing to create an user friendly BOINC client, at most it's going to require projects to specify some 'keywords' to describe their project, not massive changes to maintain compatibility.
The problem is that it would require projects to follow an identical structure, this is something that isn't the case - not all project update frequently, some projects go homebrew with their BOINC web server implementation, etc.
It's certainly possible however the client would need to support each of the projects on an individual basis.
Don't keywords already exists in BOINC simplified view?
In my eyes, requesting that projects which wish to operate in a simplified client follow a specific set of guidelines ( format, for example ) is a good thing. It adds a natural barrier to security: If the project went through the effort to subscribe to these guidelines they are more likely to be reputable. These types of natural filters are going to become more and more important ( to Gridcoin as well )as less tech-oriented people begin to use BOINC the software.
I am not suggesting that all projects be required to follow an identical format.
It's similar to the SSL conversation taking place with Gridcoin whitelists. If a project head didn't take the time to implement SSL why should I trust this project?
Another way to look at it would be TBD acting as a "stamp of approval" which benefits projects which receive the stamp. Like the certified organic stamp... But you know... Worth something.
"Make it so our client can push to your project and open your project to a whole new audience of BOINCers."
Does BOINC not already let you sign up for many projects from within the client? From memory there was a small subset of projects that made me actually visit the website to sign up.