Jimmy,

I just completed a fairly comprehensive review of most of the UIs and many of the most-likely tasks UTEs and participants are likely to have. My notes are below. Most of them are minor to medium UI changes that will or could result in significant improvements. Some are larger issues to be considered.

Overall, progress since my last review is mind-blowing! This is getting rather close to being good enough to run tests with remote participants. The most important problem and problem area is the test session. The UI that guides a participant through a study needs to be extremely distinct from the UI that is being tested. The user must have 100% clarity about which text and interfaces are from their 'guide' and which text and interfaces are part of the tool they are testing. It is not clear at this stage and I have pointed out some specific issues below and offered some suggestions.

Further, it's important to give the user enough info to do the task, but not so much they might get overwhelmed. E.g. the time remaining or total number of tasks is too much info. Easy access to the task description, that doesn't lead the participant away from the test subject is also critical and part of that 'guide' UI.

Please consider taking one hour to listen to these podcasts to understand why this is important. The UTS 'guide' is the Lab 'moderator'. http://www.uie.com/brainsparks/2008/07/07/usability-tools-podcast-modera... http://www.uie.com/brainsparks/2008/07/22/usability-tools-podcast-modera...

  1. General
    1. 'Usability testing', 'Analyze' and 'Tasks' menu items still have 'expandable' type bullets, but no child menu items. I think you need to set a 'type' in hook_menu() here
            $items['admin/uts/studies'] = array(
        'title' => 'Studies',
        'description' => 'Manage studies: create, edit, copy, and delete studies.',
        'page callback' => 'uts_studies',
        'access arguments' => array('manage studies')
      );
    2. consider adding a study overview page (node/NID?) with UTS details
    3. so that the UTE doesn't have to explicitly give the most common permissions, can anonymous and authenticated users be given 'participate in study' by default?
    4. $db_prefix is not appended with a '_' character. This might be because the code in settings.php is out of date?
  2. admin/uts/configuration
    1. Invite and Session info emails are great!
    2. More help in the UI is required to let the user of the UTS know what !username, !site, !mailto, !date, !register, !participate, !session_id will be replaced with. e.g. !participate: The urls to start a session
    3. "You may be required to register an account on the site..." makes the UX too complicated for the participant. Instead, make menu handler for path /uts and uts/participate/2 handle user-registration, and bring the user back to uts/participate/2 once complete.
    4. Can !participate in the Session Info include the session_id so that the user doesn't need to copy and paste it, and the session resumes automatically?
    5. These should be defaults, shich can be overridden at invite-time on admin/uts/invite
    6. UTS and Proctor modules show on admin/build/modules in a test site / base environment. Consider hiding these modules via form_alter so that a participant can't break his own session.
  3. admin/uts/invite
    1. I'm not sure the general invite feature is worth the effort to maintain. Can we require the Study field?
  4. admin/uts/environments
    1. After opening a base environment instance, logging in, and quiting back to host drupal instance, the user gets logged out of the host instance. Is this to solve other bugs? Can the user be re-logged in?
  5. admin/uts/studies
    1. consider adding 'number of tasks' column
    2. consider adding 'number of complete sessions' column
    3. consider adding 'status' column
    4. consider hiding 'analyze' operation/link if there are no sessions to analyze
    5. consider adding 'add task' operation/link if study is 'in development'
    6. consider removing 'description' column
  6. admin/uts/studies/2/edit
    1. 2 checkboxes for enable & require would make more sense as 3 radio buttons; disable, enable, require
  7. admin/uts/tasks/2
    1. meaning of 'free' link/operation is not clear
    2. I'm not sure if the 'free' link is very useful or necessary. consider removing, or merging with 'delete'
    3. There is no link here to view or edit the study. I have to go back to admin/uts/studies. Consider putting view and edit study links here as tabs?
    4. similarly there is no context about the study here, except in the title, which is too subtle. Consider including the study's description?
  8. admin/uts/tasks/2/add
    1. after submission, consider adding link to drupal_set_message text and/or operations to record the steps for the task, since this can't be done from node-add
  9. admin/uts/tasks
    1. consider adding 'copy' link/operation
    2. after clicking 'add' link (admin/uts/tasks/add) and submitting, user of UTE is returned to admin/uts/tasks/add. Return to admin/uts/tasks/2 or admin/uts/tasks instead
    3. make values in 'parent study' column links to study overview page (node/NID)
  10. admin/uts/tasks/2/import
    1. This looks like it's incomplete. Consider removing menu item till complete, or completing it
    2. Consider complementary 'export' functions.
  11. admin/uts/tasks/4/edit
    1. 'Record steps' doesn't open a new drupal instance
    2. After recording steps, path includes starting page, e.g. admin/uts/tasks/2
  12. uts/participate/2
    1. Since a complicated base environment could be quite large and creating a test environment could be very complicated can we show the participant a throbber while we're waiting for the server to do it's thing?
    2. "Please make sure you have JavaScript enabled. To confirm that it is working click here..." Automate this. See how install.php checks for clean urls as an example.
    3. As mentioned previously, this page/form really needs to split into 2 or 3 pages/steps.
      1. to ask 'Start new session, or continue old session?'
      2. (only if restarting) to ask for the code
      3. third to give the user the link and ask them to bookmark it. This step should include the session id in the url to facilitate bookmarking and so that bookmarks and the link in session emails allows the participant to skip the first 2 screens. e.g. uts/participate/2/uts607831
    4. Session email was never received. Incomplete?
  13. uts_proctor/task/3 (in participant's session instance)
    1. It's not clear that the content of the screen is the task and the instruction. This needs to presented apart from the subject of the testing (the session's drupal instance). Possibly as a thickbox or similar?
    2. Feedback UI is awesome!!!
    3. Feedback UI should also be available when no task is active. A task may ask the participant questions or solicit feedback. Also, we need the ability to have thingies in between tasks with specific questions, and required feedback.
    4. Hitting the 'enter' key while typing feedback should probably submit feedback? WDYT?
    5. Feedback UI accepts empty text as acceptable feedback message. It shouldn't
    6. It's not obvious how to make the feedback window go away once the participant has finished submitting feedback. Consider hiding automatically? Time-out? After submission? Not sure. This needs some thought and consideration
    7. Don't display the total number of tasks to the participant. If they run out of time (for the whole study) we don't want them to feel like they haven't been helpful if they only did some of the tasks. We want them to feel helpful regardless of how many tasks they completed or didn't complete.
    8. The task description needs to be readily available to the participant without distracting them from the task (i.e. as a thickbox laid over the test session screen.)
    9. While no task is active, the menu items in the test session's drupal instance don't work but look like the should. This further supports the need to over-obviously separate task descriptions from the test subject.
    10. Also, the start, and done buttons need to be more closely connected and associated to the tasks.
    11. 'Quit' should also be available even while a task is active to allow for easy exit.
    12. The visible count-down timer is very unnerving. Don't show it to the participant. Just interupt them once time is up and ask them to please move on. Also encourage the task designer (UTE) to set very high time limits.
    13. Reconsider making time limits optional
    14. Browser's forward back buttons modify the "UTS bar" but should only be changing the test sessions' instance. This will be less of a problem once we separate out tasks from the test session's instance of drupal. iframe's might be useful here with javascript event handlers for browser back/forward.
    15. "apreciate" is misspelled
    16. Different themes are required for the participant to easily distinguish the start and end of a session and tell what is part of the test subject and what is part of the environment that guides them through the study. Consider setting different garland colors in the default base install and/or encouraging the UTE to consider changing the host site's theme.
    17. upon quiting a study early, the participant is not reminded of their restart code/link. They should be.

Comments

Bojhan’s picture

Bojhan commented

Hey, Bevan

I will try to comment on some points and I do see some of these issues, should be solved with an easier workflow instead of fixing the current screens.

1.2 : We should still look at the workflow, I spoke with a few people yesterday and they had trouble finding out the process to setup a study, I still believe that a step 1 / step 2 / step 3 type process is easier for the user.

I will make some wireframes to clarify the particpant workflow.

5: We should consider the amount of tests that will be listed here, assuming that most people only have 1 or 2 modules they test, you could assume that we have to design for about 10 studies. (Only people in the usability group will have lots more studies - but we have to redesign it a bit for usability.drupal.org anyway).
5.1 : I don't think this is necessary information.
5.2 : Add % instead of number, like 70% completed.
5.3: At the moment the status is to long to nicely be fit in an column, maybe rename them?
5.4: Agreed, but make sure to display it when there is any data.
5.5: Workflow?
5.6: Agreed, usually descriptions are to long to be easily fitted.

7: Concider workflow, people dont usually want to see all task, they want to see the tasks of one study. (BTW I couldnt attach a free task to a study?)
7.1: I found the free function really funny, it kinda looked like tasks where imprisoned task. But unnecairy functionality definitly.

12.1: Agreed, make sure that it's long enough for the user to notice its creating a new envoirment, not particulairly how long the server would do it, this is to keep the mental model of the user in mind (Like 5 seconds?)

13.1: Agreed, concider loading a black layer over the complete site, with the instructions (http://www.garrettdimon.com/themes/content/images/articles/gorilla_usabi...) - With a starting button.
13.3: Question plugin, still has to be developed.
13.4: Agreed, should trigger it.
13.6: When the user is not active in the feedback window, it should just collapse again, concider a small time frame of about 2/3 seconds when the user go's back to the screen.
13.7: Agreed, dont display.
13.8: A slightly larger top bar, where the particpant can find his session information and related functionality such as feedback?
13.10: Concider start, outside this UI, and only stop or skip to be needed?
13.11: Do people really use quit, instead of just exiting on their browser?
13.12: Agreed, a couple weeks ago I pointed boomba to this, I think he was working on removing it.
13.13: I am not sure, what about secertly doubling the given time by the UTE? I dont think its wise to leave it completely up to the particpant.
13.16: Concider the purposed, black screens with info, in between tasks.
13.17: Just wondering, cant we say like "If you have to stop, just quit and we will send you a e-mail with a continue link" or atleast something simple along those lines.

Bevan’s picture

Bevan commented

Bojhan. I mostly agree. A few further notes;

> 12.1: Agreed, make sure that it's long enough for the user to notice its creating a new envoirment, not particulairly how long the server would do it, this is to keep the mental model of the user in mind (Like 5 seconds?)

It takes a few seconds with a very basic base environment. It wouldn't need to be very large to require 10 seconds. I don't think we should intentionally be making this take longer, it's just that creating and populating 50 to 300 tables takes time. We need to let the participant know we're working on it and they need to wait for few seconds/minutes. It would be nice to estimate the time it will take to create a test session but this is not easy, although needn't be accurate. And yes 300 is a realistic upper limit for the number of tables a test environment may need to deal with.

> 13.1: Agreed, concider loading a black layer over the complete site, with the instructions (http://www.garrettdimon.com/themes/content/images/articles/gorilla_usabi...) - With a starting button.

It would be nice to show the test subject through the black overlay with some transparency, rather than opaque black. This will help the participant recall the UI when giving feedback.

> 13.6: When the user is not active in the feedback window, it should just collapse again, concider a small time frame of about 2/3 seconds when the user go's back to the screen.

That's what I had in mind. I'm not sure if this will be annoying though. If we don't start the 2-3 second timer until focus is lost from the feedback form it will probably be 'smart' enough.

> 13.8: A slightly larger top bar, where the particpant can find his session information and related functionality such as feedback?

I'm not sure larger is better in this case. If the 'guide' UI 'slides' in and out of this bar, and if they are themed similarly (white text on black / grey?, so as to be unique and different to a typical test subject) then it will be clear that the bar is part of the guide. This will involve a considerable amount of jquery animation but I believe is necessary.

> 13.11: Do people really use quit, instead of just exiting on their browser?

I believe this is important in order to provide an easy exit. Clicking 'quit' will pause the timer, remember where the user was up to, take them back to the host instance of drupal, and give them important info, like how to recover the session if they want to continue later (a link / bookamrk), and thank them for their time and help. UTE's may want to add info here such as "You're payment/reward will be made once you complete the study. You have 20 minutes remaining."

Btw 'completing the study' should not require attempting all the tasks. I think a time limit on the entire study is at least as important as a time limit on tasks. I expect it will be common for UTEs to set a time limit of one hour on a study with 5 tasks with limits of 40 minutes each. Participants are likely not to do all the tasks. That is fine. The participant shouldn't know whether there were tasks they didn't get to or not. Only the UTE will know that.

> 13.13: I am not sure, what about secertly doubling the given time by the UTE? I dont think its wise to leave it completely up to the particpant.

We can force the user to move on. But I'm not sure the UTE will always want this. I'm not sure how to deal with this issue. Maybe we need to try out the UTS in the real world before we can answer some of these questions.

> 13.16: Concider the purposed, black screens with info, in between tasks.

I wasn't refering to the participant's guiding UI whilst using the test subject (doing the tasks) but the appearance of the website they land at after clicking links in emails, and after quiting or completing a study. However it would be convenient to link the theme / appearance of the guide UI with that of the host site so the participant feels they are the same, and different to the test subject.

> 13.17: Just wondering, cant we say like "If you have to stop, just quit and we will send you a e-mail with a continue link" or atleast something simple along those lines.

Participants may or may not click the Quit button if they want to finish early. If they close the browser window we should try to 'pause' the test session for them by implementing a hook on the page unload javascript event. If the browser crashes thought this doesn't work. So I think we should be sending them an email when they start the session with the recovery/restart link.

boombatower’s picture

boombatower commented

Thanks for the thorough review. I've responded to everything in your initial post and bolded items that need a response or take a look at.

  1. General
    1. Adding type to sub-items fixed it.
    2. Already exists? Just goto the study node page. Do you want a link and menu item on the admin/uts/studies page?
    3. Other than writing a query to manually add permission I'm not sure there is a way. Is that against the normal Drupal workflow? Maybe I've just never seen it/noticed.
    4. It would require a lot of appending "-" and removing "-" throughout the code which isn't preferable. The prefix it uses is the same it displays to user, but I can change that. (I'll just need to be very careful)
  2. admin/uts/configuration
    1. :)
    2. Will work on.
    3. Possibly just redirect to registration page if required? Taking over registration process sounds a bit extreme.
    4. It reads a cookie on their computer. If they are on same computer it should auto fill.
    5. I'll look into, sounds a bit like overkill.
    6. Will do.
  3. admin/uts/invite
    1. Sure, only one line that would be alleviated, but I think it may be used for other e-mail. Just removes the ability to do general invites.
  4. admin/uts/environments
    1. Since they are running on the same site the same session cookie is used. Could be done, but with a lot of extra work trying to keep track of old session. (unless there is simple way)
  5. admin/uts/studies
    1. Will do.
    2. Will do.
    3. Will do.
    4. Hides if study is not active, but I will add that condition as well.
    5. Especially with above columns added the page is going to be a bit crowded. I think the "manage tasks" operations is sufficient, unless otherwise specified.
    6. Yea been thinking about that. Will do.
  6. admin/uts/studies/2/edit
    1. I've thought about improving that several times. Possible a bit of JavaScript to check enabled when required is checked? Also radios would work, but I'll have to see if I can get them to display in columns and be related simply.
  7. admin/uts/tasks/2
    1. Change to "free from study"? or provide a short peice of help text?
    2. This was all argued for very strongly as part of being able to have a bank of tasks. The free allows you to attached and "free" (detach) tasks from a study. Do you really want it done away with?
    3. Will do.
    4. Will do.
  8. admin/uts/tasks/2/add
    1. Will do.
  9. admin/uts/tasks
    1. Have thought about that, but haven't found a simply way of doing it. Any thoughts?
    2. Will look into, much of this is caused by $form_state['redirect'] not working with node API.
    3. Will do.
  10. admin/uts/tasks/2/import
    1. The XML import is not complete, but importing from main tasks "repository" works.
    2. Yea just low priority.
  11. admin/uts/tasks/4/edit
    1. Yea, din't think about it needing to open up base environment. Will do.
    2. Just press start when you actually want to start?
  12. uts/participate/2
    1. Throbber sure.
    2. I can work on, but from my experience there is no sure proof way of confirming the user has JavaScript enabled. I'll try making it perfrom an AJAX request back to server, but I'm going to mark this as low priority.
    3. I can work on it. Not sure if rewriting the interface will happen before end of SoC, but will try.
    4. Can only send session notification if your logged in. Which is the reason for the "participate in study" permission. I'm assuming you weren't logged in, otherwise it should have worked. I will test this.
  13. uts_proctor/task/3 (in participant's session instance)
    1. Will do.
    2. :)
    3. Feedback UI open: I'll look into as that would violate data collection API. I'm think that should be delt with differently. Questions between tasks: attempt to get to.
    4. Could change, but I received comments that it should be multiline.
    5. Forgot to fix that.
    6. It will hide when you goto a new page. I'm thinking that is sufficient for now.
    7. Since it will force them to move on after max time for each task and max study time is the sum of tasks how can that occur?
    8. Addressed by #1
    9. Addressed by #1
    10. What does that mean?
    11. I can add that, but it will behave like they pressed done and quit.
    12. Will add encouragement. I think it should still enforce limit. I will remove timer, I guess, I think it is useful.
    13. Really don't like that idea, we can discuss it, but it help the code/workflow allot if there are set time limits and if the UTE makes them large it shouldn't matter anyway.
    14. That can be worked on, but a bit out of scope as it would require a fair amount of extra code and it currently functions.
    15. Will fix.
    16. If we make it more clear when they have started (they should already have pressed a "start" button) the thank you page should be clear they are done. Setting the default theme is a bit more work, but can be done if we decide it is absolutely necessary. (UTE can always set it up and we can recommend in documentation)
    17. They just revisit the site? It reminds them to come back and finish. What else are you looking for?

Items that I will work on (does not include completed items):

  • 2.2
  • 2.5
  • 2.6
  • 3.1
  • 5.1
  • 5.2
  • 5.3
  • 5.4
  • 5.6
  • 6.1
  • 7.3
  • 7.4
  • 8.1
  • 9.2
  • 9.3
  • 11.1
  • 12.1
  • 12.2
  • 12.3
  • 12.4
  • 13.1
  • 13.3
  • 13.5
  • 13.11
  • 13.12
  • 13.15
Bevan’s picture

Bevan commented

Sorry for the large number of nesting etc. I'm just trying to keep this relatively readable without significant scrolling.

1. General

2. Already exists? Just goto the study node page. Do you want a link and menu item on the admin/uts/studies page?

So it does. Yes, make the Title in the table on admin/uts/studies a link to it, and consider adding link/operation 'view'

3. Other than writing a query to manually add permission I'm not sure there is a way. Is that against the normal Drupal workflow? Maybe I've just never seen it/noticed.

I'm not sure about this one.

4. It would require a lot of appending "-" and removing "-" throughout the code which isn't preferable. The prefix it uses is the same it displays to user, but I can change that. (I'll just need to be very careful)

This just makes it easier for a technicial engineer or UTE to navigate the database. If it's very difficult then forget it. It's relatively unimportant.

2. admin/uts/configuration

3. Possibly just redirect to registration page if required? Taking over registration process sounds a bit extreme.

I wasn't meaning take it over, just send the user there and catch them afterwards. Does ?destination=uts/participate/2 work in the registration process?

4. admin/uts/environments

1. Since they are running on the same site the same session cookie is used. Could be done, but with a lot of extra work trying to keep track of old session. (unless there is simple way)

I see. What if test sessions where always on a different domain to the host site? Something to think about for the future...

5. admin/uts/studies

5. Especially with above columns added the page is going to be a bit crowded. I think the "manage tasks" operations is sufficient, unless otherwise specified.

I agree that I've asked you to consider adding a lot of data to this table. I also suggested we remove the description column which would make more room for this other data.

7. admin/uts/tasks/2

1. Change to "free from study"? or provide a short peice of help text?

I think "detach" is better than "free" or "free from study", but I'm not certain.

2. This was all argued for very strongly as part of being able to have a bank of tasks. The free allows you to attached and "free" (detach) tasks from a study. Do you really want it done away with?

The problem is that it doesn't match the workflow a UTE is likely to have for this. "copy an existing Task and give it a new Study" better suits the workflow.

9. admin/uts/tasks

1. Have thought about that, but haven't found a simply way of doing it. Any thoughts?

$node = node_load($nid); unset($node->nid); node_save($node);?

11. admin/uts/tasks/4/edit

2. Just press start when you actually want to start?

I'm not sure adding more steps to the process is the right solution here.

12. uts/participate/2

2. I can work on, but from my experience there is no sure proof way of confirming the user has JavaScript enabled. I'll try making it perfrom an AJAX request back to server, but I'm going to mark this as low priority.

It's difficult to be sure server-side, but clientside it's much easier. Just swap out the warning icon for the checkmark icon with javascript.

4. Can only send session notification if your logged in. Which is the reason for the "participate in study" permission. I'm assuming you weren't logged in, otherwise it should have worked. I will test this.

Can we link UTS session ids to email addresses at participant-invite-time? So that when they click the link in the invite email, which has the session id in it, we know where to send the followup "thanks for starting the session, here's a link to resume it if you have any problems." The email address should never be shown in the interface next to the test session since participant's anonymity is important.

13. uts_proctor/task/3 (in participant's session instance)

4. Could change, but I received comments that it should be multiline.

It can still be multiline. shift+enter enters a new-line character. I'm not sure this is very important or will actually be better though.

7. Since it will force them to move on after max time for each task and max study time is the sum of tasks how can that occur?

The participant's session is complete when the study time limit is up, regardless of the number of tasks they completed. However they should be able to opt in to continue, but only if they really want to.

10. What does that mean?

sorry. The start button should be right below the task description. The quite button should be right next to the start button. The quit button should become obviously enabled when the start button is clicked. It should be clear where the buttons slide to when a task is started so they can find them when or if they want to quit

11. I can add that, but it will behave like they pressed done and quit.

for now this is okay, but ideally they can resume a half-completed task. the timer is paused while they're 'away'

12. Will add encouragement. I think it should still enforce limit. I will remove timer, I guess, I think it is useful.

for a developer and for testing yes it's useful. it will be unnerving for participants in a real study. Remember they are not likely to know what interfaces are being tested. And we really don't want them to feel like THEY are being tested, which is what the countdown timer suggests.

13. Really don't like that idea, we can discuss it, but it help the code/workflow allot if there are set time limits and if the UTE makes them large it shouldn't matter anyway.

okay

14. That can be worked on, but a bit out of scope as it would require a fair amount of extra code and it currently functions.

sure. What we have now is great. However this is a critical part of the UTS and it's important that the UTS' UX doesn't mess with the test subject's UX.

16. If we make it more clear when they have started (they should already have pressed a "start" button) the thank you page should be clear they are done. Setting the default theme is a bit more work, but can be done if we decide it is absolutely necessary. (UTE can always set it up and we can recommend in documentation)

we can't make the distinction between the test subject UIs and the UTS/Guide UIs. The more clear we can make it the better. Lets add recomendation in documentation for now and put this one on the list of would-be-nices.

17. They just revisit the site? It reminds them to come back and finish. What else are you looking for?

participants aren't likely to start a study NOT intending to complete it. therefore they are unlikely to copy the code. If they do need to leave the test session early it will probably be unexpected and they need to be given another opportunity to record or copy it. Expecting the user to copy and paste it all is the real problem here. bookmarking or emailing a link including the code is the right solution here. Can we link email addresses to uts sessions by distributing the uts session ID in the invite email?

boombatower’s picture

boombatower commented

7.2 - been working on figuring out an easy way to copy task as that was my intention.
13.17 - add to list (as part of resign of the starting process) 12.*

boombatower’s picture

boombatower commented
Assigned: Unassigned » boombatower
Status: Active » Needs review

Here is the progress I have made.

* 2.2 (DONE)
* 2.5 (NICE-TO-HAVE)
* 2.6 (DONE)
* 3.1 (WAIT)
* 5.1 (DONE)
* 5.2 (DONE)
* 5.3 (DONE)
* 5.4 (DONE)
* 5.6 (DONE)
* 6.1 (LOW)
* 7.3 (DONE)
* 7.4 (DONE)
* 8.1 (DONE)
* 9.2 (DONE)
* 9.3 (DONE)
* 11.1
* 12.1
* 12.2
* 12.3
* 12.4 (ADD issue and postpone)
* 13.1 (DONE)
* 13.3 (DISAGREE)
* 13.5 (DONE)
* 13.11 (DONE)
* 13.12 (DONE)
* 13.15 (DONE)

After reading response

* 7.1 (DONE)

** Changes have been committed so use dev tarball if you are interested. Since we are coming down to the end of SoC I think we should try to have this reviewed somewhat frequently so that we can get all the changes completed and agreed upon before the deadline.

Bevan’s picture

Bevan commented

> Since we are coming down to the end of SoC I think we should try to have this reviewed somewhat frequently so that we can get all the changes completed and agreed upon before the deadline.

IRT meeting GSoC deadlines & criteria, don't stress about it, you've already done that! :)

I'll try to review again soon, nevertheless.

boombatower’s picture

boombatower commented

Committed some commented out code for 11.1. It is rather complex to provide a clean solution and will require some more thought.

I have made several other improvements, but I will postpone 12.* until after SoC. A separate issue with wire-frames and discussions on how the new interface should work would be appropriate.

boombatower’s picture

boombatower commented

13.17 should become part of issue related to new participant interface.

boombatower’s picture

boombatower commented

2.3 the redirect stuff the ?destination works, but I'm not sure what a good way to deal with that is since the menu checks the permission. I could move that into the actual page function, but if the registration requires an e-mail it will fail anyway. ??

I'm thinking that participants should be able to figure out how to register, if not I'm not sure why they are being used as participants.

boombatower’s picture

boombatower commented
Status: Needs review » Fixed

Believe I have delt with everything that was planned on being changed.

If more issues arise lets open new issues.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.