> How about: > - A new Activity with a list of projects (that support Android). Pretty much
> like "TasksActivity" or "TransActivity) > - Clicking an item shows a new Activity with project description. A button > that indicates "attach this project", and "back" talking the user back to the > list of projects. > - When the button is clicked the current LoginActivity comes up with the > URL already in place. Okay, so the attach button on the projects tab would launch the new Activity? We still will need to support the various options a project can define to change the sign-up process between step 2 and step 3. Specifically 'Terms of Use', whether the project uses usernames or email addresses, and min/max sizes for passwords. We can get that information via the get_project_config RPC. ----- Rom From: Joachim Fritzsch [mailto:[email protected]] Sent: Sunday, January 27, 2013 1:07 PM To: Rom Walton Cc: [email protected] Subject: Re: Proposal: Android Attach Process Expecting users to figure out what project to support with a browser and than copying the URL is definitely not intuitive. One way to avoid it: project-branded Android applications that make use of the AIDL interface to attach their project. Those would hard-code their specific project URL. Anyway, having a more convenient way to attach projects within BOINC additionally makes sense... On Sun, Jan 27, 2013 at 7:05 AM, Rom Walton <[email protected]> wrote: Joachim, et al., I have been playing around some more with the Android client and the attach process works great. I wonder if we might be able to improve it a little bit more though. The client periodically polls boinc.berkeley.edu for an updated list of projects. The UI portion of the client software can get the list of projects by issuing a get_all_projects_list RPC call. In early incarnations of the BOINC UI prompted for was just the project URL and authenticator, it led to all kinds of problems when BOINC started to be used by people who were unfamiliar with the web and/or volunteer computing. I can only imagine things being a bit worse on the cell phone form factor with spelling mistakes/auto correct causing a bunch of internet memes on facebook. We can use the information returned from the get_all_projects_list RPC to display various pieces of information about the project to a volunteer which should help in making informed choices about which project(s) they want to attach too. Granted this is much easier to do with large screen displays.It might just be enough to display a list of project names that support android, and when tapped proceed to the next step. The last button in the list could say other which would then prompt for the project URL. I think pre-selecting and only showing the projects that support Android is important. Visualizing the details of the UI interaction are kind of where I get stuck. Should clicking on a project name cause the screen to shift to the left displaying more details about the project? Which then might automatically imply that swiping left to right would go back to the project list. Should clicking on a project name expand the space to include more of the project details? Should we use an add button in the project space or is there a more natural way to move on to the next step? How about: - A new Activity with a list of projects (that support Android). Pretty much like "TasksActivity" or "TransActivity) - Clicking an item shows a new Activity with project description. A button that indicates "attach this project", and "back" talking the user back to the list of projects. - When the button is clicked the current LoginActivity comes up with the URL already in place. Swiping is usually used to see alternatives within the same hierarchy level, not for navigating back or up (e.g. going through pictures of a photo album). In our scenario, while looking at a project description, swiping would imply showing another project description from an item next in the list. I haven't run across any applications on android that use tap-hold to display a context menu like Windows CE did at one point. Nor does it appear that double tapping something is normal. "long click" is sometimes used to show a context menu. It is rather uncommon, though. Another useful RPC from the client is the get_project_config RPC. We use it to determine minimum/maximum password lengths, whether the project uses usernames or email addresses for identification, and whether or not they need a volunteer to agree to a terms of use statement. Thoughts? ----- Rom _______________________________________________ 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.
