Arvados

Last page of modal should have direct link to not just doc.arvados.org but also the port-a-pipeline step-by-step tutorial specifically.

Implementation notes / details¶

No notification bar ("new here?" etc). Instead, show the modal itself if it hasn't been shown yet. (cf. email)

Make a "getting started" modal in a partial, so it can be invoked the same way as "report issue" et al.

• Make sure the modal doesn't change its height when flipping pages. Perhaps the content goes in a div with "height: X !important"?

• Render the "getting started" modal partial inline (so it shows up, already open, in the initial page render -- without an additional AJAX call).
• Set the user's "getting_started_shown" preferences entry to the current time.

Most user fixtures (active, admin, spectator, etc) should have the prefs flag set. The "new" users (like "inactive") should not have it set. A few existing tests will probably need to be updated to hit "close".

The "welcome" change should be done in the default welcome page and in the Curoverse theme.

Optional: The button in the "thank you" message on the user profile page should say "Get started" instead of "Back to work" if the "getting_started_shown" flag is not set.

Suggestion for app/assets/javascripts/modal_pager.js

// Usage:
//
// 1. Add some buttons to your modal, one with class="pager-next" and
// one with class="pager-prev".
//
// 2. Put multiple .modal-body sections in your modal.

$(document).on('click', '.modal .pager-next', function() {
    var $modal = $(this).parents('.modal');
    $modal.data('page', ($modal.data('page') || 0) + 1).trigger('pager:render');
    return false;
}).on('click', '.modal .pager-prev', function() {
    var $modal = $(this).parents('.modal');
    $modal.data('page', ($modal.data('page') || 1) - 1).trigger('pager:render');
    return false;
}).on('ready ajax:success', function() {
    $('.modal').trigger('pager:render');
}).on('pager:render', '.modal', function() {
    var $modal = $(this);
    var page = $modal.data('page') || 0;
    var $panes = $('.modal-body', $modal);
    if (page >= $panes.length) {
        // Somehow moved past end
        page = $panes.length - 1;
        $modal.data('page', page);
    } else if (page < 0) {
        page = 0;
    }
    var selected = $panes.hide().eq(page).show();
    enableButton($('.pager-prev', $modal), page > 0);
    enableButton($('.pager-next', $modal), page < $panes.length - 1);
    function enableButton(btn, ok) {
        btn.prop('disabled', !ok).
            toggleClass('btn-primary', ok).
            toggleClass('btn-default', !ok);
    }
});

Update: Modal with pre/next buttons now on branch by Radhika. I will implement HTML content for model over the next few days using existing deployed modals + inspector tool on Chrome/Firefox.

Future story, perhaps: How someone can get "just workbench" branch on localhost running very quickly, like with the /docs portion of Arvados.
"you need to first start the api server and the sso server and the workbench" (or point workbench to existing api server)
http://doc.arvados.org/install/index.html
https://arvados.org/projects/arvados/wiki/Hacking_Workbench

Implementation notes:

• The workbench dialog is implemented in arvados repository branch 5493-getting-started-modal

• The curoverse welcome page is updated (and manually tested locally) in curoverse-private repository branch 5493-welcome-page-links-to-arvados-wiki

Radhika Chippada wrote:

• The workbench dialog is implemented in arvados repository branch 5493-getting-started-modal

Reviewing 1f225f2c

• Because Tom specified that the modal content should live in the main layout HTML, we can just always include it there directly. This would reduce the amount of code necessary for this feature: we won't need a new route, a new method for that route on application controller, etc. Here's how to do this:
  • In getting_started_popup, give the <div class="modal"> a unique id attribute. (You should be able to make this getting-started-modal-window and get rid of the <div> in body.html.erb.)
  • In body.html.erb, always render the getting_started_popup partial.
  • Move the user condition down. When the condition is true, the <script> inside the condition only needs to call .modal('show'). No rendering is necessary, since the modal HTML will always be included in the body.
  • In the Help menu, the link to bring up the Getting Started modal should have the attributes data-toggle="modal" data-target="#yourModalId". Bootstrap's provided JavaScript will automatically make the correct hookups to show the modal when this link is clicked. data-toggle tells it to toggle the shown state of a modal, and data-target tells it which modal to render.
• The mockup shows the "Prev" and "Next" modal buttons at the far left and right of the modal, respectively. Could we achieve the same effect with pull-left and pull-right? And then the page count could probably be centered between them.
• I'm not sure arvados_wikisite is the right level of configurability we want for the "Public Pipelines and Datasets" link. Other sites may have their public data documented on different wiki software (e.g., Mediawiki); on a static HTML page; or they may not have public data at all. I think this feature will be more adaptable if it specified a full URL for the documentation page, and if Workbench did not render the link when the configuration value was unset. The name could be something like public_data_doc_url.
• This branch renames the active_prefs_no_profile user fixture, but there are still several Workbench and API server tests looking for it. Try git grep '\bactive_prefs_no_profile\b'.

Radhika Chippada wrote:

• The curoverse welcome page is updated (and manually tested locally) in curoverse-private repository branch 5493-welcome-page-links-to-arvados-wiki

Reviewing commit:e2c004e

I see that you implemented Nancy's text verbatim. I have some concerns about this text:

• I don't think we should say we are "based on" Arvados. I'm concerned it could give readers the impression that we have secret proprietary components, which is not true.
• "open-source" should not be hyphenated.
• "datasets" should be two words according to my dictionary.
• I think talking about data that can be "viewed anonymously" is a little too technical for people who may not already be familiar with Arvados.

I would suggest the following as an alternative: "We use the Arvados [link] open source platform. For a curated list of public pipelines and data sets, please visit the Arvados wiki [link]."

Thanks.

Brett: Made all the suggested updates, except the placement of Next and Prev buttons. When these buttons are placed using pull-right and pull-left respectively, accessing them was tedious. To go back and forth, I need to move the mouse from one end of the dialog to the other. This was quite bad user experience. Checked with Nancy also and she also liked them this way and not having to move the mouse too much. Thanks.

Reviewing 1f5a673.

• The changes to ApplicationController are no longer needed now that the modal is included in the layout HTML. Please revert them.
• In body.html.erb, the comment next to the partial <%# requires JS support below %> is not applicable in this case, and should be removed.
• In user_profile_test.rb, the different tests "visit home page when profile is configured for user #{token}" have a new boolean variable, but it's never unwrapped or used, so I don't think anything's happening with it. The signatures of several helper methods changed, but none of the calls did, so I suspect they're running unchanged.
• In other Workbench integration tests that perviously used the active_prefs_no_profile token (application_layout_test, report_issue_test), you've extended them to use both tokens. Since none of the tests are expected to change their behavior in either case, I believe it would be better to choose one or the other and use that, not both. The time expense of trying with both variations of the user doesn't seem worthwhile for testing these common UI elements that are relatively static.
• In the test "test getting started help menu item", nothing reads the variable foundDisabledNext. I believe it can be removed.

Thanks.

Brett: thanks for your patience, the third comment above uncovered a bug in code which was uncovered once the test is corrected :). Yes, you are right; since user_profile_test is covering all scenarios, no need to add additional test cases to application_layout and report_issue and hence they are now removed. Deleted "foundDisabledNext" from test since I am no longer relying on it to verify that the Next button indeed is disabled. Thanks.

a89c721 is good to merge. Thank you.

personally, I really hate the "popup and overlay everything when you first login" modal behavior we implemented right now. It's especially terrible if your window is small and the modal takes up the entire screen almost. Then

"What you're looking at right now is Workbench,"

doesn't make any sense, because "what you're looking at right now" is a modal, not the Dashboard...

A little red circle like for ssh, or small blue bar "New here? Check out our sweet getting started guide"[link to modal], or something would be much nicer, so people can see what is going on before they get this confusing modal overlay.

Will confirm with user testing my intuition next week.