Skip to content

Add Studio/Insights links to Staff Instructor Toolbar#24020

Merged
stvstnfrd merged 2 commits intoopenedx:masterfrom
stvstnfrd:add/staff-toolbar-links
Jun 3, 2020
Merged

Add Studio/Insights links to Staff Instructor Toolbar#24020
stvstnfrd merged 2 commits intoopenedx:masterfrom
stvstnfrd:add/staff-toolbar-links

Conversation

@stvstnfrd
Copy link
Contributor

@stvstnfrd stvstnfrd commented May 19, 2020

Backport the new behavior from the Learning MFE.

Screenshot_2020-05-19_13-45-26

Since this toolbar can appear outside of the unit-aware (and even courseware) pages, the link behavior is as follows:

Both Buttons

If the relevant Django settings aren't configured (not the case for us, but eg: some installs don't run Insights), CMS_BASE, ANALYTICS_DASHBOARD_URL, then no button is shown.

Insights Button

  • If you're on any course-aware page (including unit-aware),
    • link goes to that course's Insights page.
  • If you're not on a course-aware page,
    • link goes to main Insights dashboard.

Studio Button

  • If you're on any unit-aware page,
    • link goes to that unit's Stdio page (via the JS hack).
  • If you're on any course-aware page,
    • link goes to that course's Studio page.
  • If you're not on a course-aware page,
    • link goes to main Studio homepage.

FWIW: We currently do not display the toolbar at all on course-unware pages.

@stvstnfrd stvstnfrd requested a review from a team May 19, 2020 00:01
Copy link
Contributor Author

@stvstnfrd stvstnfrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of a hack, but maybe not the Worst Thing Ever ™️

I may be totally missing some context (literally, the templating kind) on what data is available, but this seemed like the easiest way to fetch the current vertical ID (used for the Studio link/redirect on unit-level pages). Vertical-level context appears to be collected/passed further down the call stack, in a separate block.render call.

This is explained in further detail as code comments

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for later: the // prefix..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: No algorithm, no helper method, so we weren't off by creating the URL the same way in the MFE :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We found some similar limitations in studio for building LMS URLs... there wasn't really a good way to 'reverse' those routes, so to speak. Ended up looking much like this.

We found, also, that studio didn't have a fully reliable LMS base URL, in that if there were multi-tenancy or enterprise domains, it wasn't necessarily right. More details here: https://openedx.atlassian.net/browse/TNL-7198

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Goodbye!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Remove after local testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests seem fairly module-level specific, so probably not worth porting over as-is.

How much, if any, do we care to add testing here for the legacy view/component?
Spoiler: I've not added any at this point :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anchor tag hrefs work fine without an explicit protocol (eg: google.com or //google.com), but Javascript complains if you try to set window.location.href without an explicit protocol.

In devstack, stage, and prod, there is no protocol on CMS_BASE, but there is on ANALYTICS_DASHBOARD_URL.

@stvstnfrd stvstnfrd changed the title WIP: Add Studio/Insights links to Staff Instructor Toolbar Add Studio/Insights links to Staff Instructor Toolbar May 19, 2020
@stvstnfrd stvstnfrd force-pushed the add/staff-toolbar-links branch from 4aba540 to 0126aa6 Compare May 19, 2020 20:26
@stvstnfrd
Copy link
Contributor Author

Note: This doesn't look great on a smaller screen width; the buttons stack oddly...

Screenshot_2020-05-19_13-45-48

@marcotuts
Copy link
Contributor

If you're not on a course-aware page,
link goes to main Insights dashboard.
Thinking through this one... We may want View in Insights to only show on course-aware pages, or maybe I should ask what course-aware means. That is, View in Studio / View in Insights shouldn't show up on the masquerade bar for the progress page. but it should show up on Course Home + Courseware pages.

So perhaps there are three categories?

  1. Non-Course Aware
  • dont' show view in studio or insights
  1. Course Home
  • studio course outline page.
  • insights course home page
  1. Course Content View
  • studio unit page
  • for now insights course home page, can add context sensitive mapping of unit pages to insights pages some other time / in a future ticket.

@marcotuts
Copy link
Contributor

@stvstnfrd - For the button sizing we might need to make the width of the buttons wider than whatever percentage they have and make the masquerade area less of the width. Additionally on smaller screens the masquerade dropdown could be 100% and the buttons could be 100% so that they're stacked?

@stvstnfrd
Copy link
Contributor Author

@marcotuts Yeah, how is described is what it is in practice now, since we don't show toolbar at all on non-course pages.

re 3, for the Insights link, I didn't know where else to link directly (a sensible unit-level insights page); if there's somewhere better, that's an easy enough change 🤷

@marcotuts
Copy link
Contributor

For 3 - this is tricky because viewing a given unit page we might do different things. If viewing a page with a video we might wnat ot link to that video engagement view, if viewing a problem page then the problem performance page in Insights, but it becomes a mess when pages have both videos and problems, and other edge cases. I think for now ok to skip that level of context- sensitivity. Already this is a huge lift in the visibility of insights so we shall see how usage shifts and decide whether we should do anything else later. thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidjoy Do you have any tricks on how to get these buttons to collapse better on smaller widths?
I'm happy to look for other examples in platform, just seeing if you have anything on hand ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add display: flex to this div, it'll cause the buttons to at least stay side-by-side. At very small widths (less than 460w on my screen) the insights button is partially off screen, but at least it doesn't take up more vertical space. Hm, I also don't have the MFE link enabled, but even if it was, I think they'd all stay on a line.

Beyond that, I think you have two options that I can think of:

  • You could vertically align the stuff in the toolbar - probably a non-starter because it'd take up so much space.
  • You could change them to an icon-based buttons instead of text, or a smaller font size, at narrower resolutions so that they take up less room. Or maybe a dropdown. You'd probably have to do this via media queries in CSS. Not that bad, but you'd have to play around a bit to get it right.

I think the latter is probably your best bet for making it "right" at small resolutions. Whether staff/instructors are really going to go look at studio/insights on a mobile phone, though... not clear to me it's worth it, though it galls me to leave it not-quite-fitting. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could add a right margin instead of this  , probably.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% on the details here, but where is the equivalent of this check in the new code? Seems like in the old code we don't show the link unless the course_edit_method is "Studio", but I don't see a similar condition in the new stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrmmm, good point...

We're also not performing this check in the MFE; we always link to Studio.

@davidjoy With this implemented as-is, I don't think we can perform this check; we don't have access to the block, so I think we'd need another approach.

@marcotuts (cc: @ormsbee) Do you have background on this feature, its use/exposure/etc?

Depending on that, we should determine:

  1. If we care about this check, do we need to port this check to the MFE too? (now or backlog)
  2. If we don't, do we care enough to preserve backward compatibility here? (now or backlog)
  3. Or just ignore it and always link to the block in Studio?

Copy link
Contributor

@davidjoy davidjoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling this a "Comment" review because it sounds like there are a few small changes to make and I had a few minor questions. In principle it's an Approve, though

Copy link
Contributor Author

@stvstnfrd stvstnfrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sooo, I tried quite a few things, but here's the TL;DR:
This scales down decently at smaller widths now.
It still stacks buttons as needed, but this is cleaned up and looks nicer. See:

It's "normal" on a single line down to about ~1,000px.

Screenshot_2020-06-02_08-09-27

Drops down to a second line from ~600px to ~1,000px

Screenshot_2020-06-02_08-10-00

And then puts each button on its own line below ~600px, and still looks decent down to ~400px, with room to spare.

Screenshot_2020-06-02_08-10-24

I also confirmed that the "View as a specific user" still works at the smaller widths (it uses a bit more real estate). It's tight, but it's a lot of content 🤷

Screenshot_2020-06-02_08-11-25

Note: px values here are rounded for ease of reference; no explicit media queries are used here; that's just roughly where the breaks occur.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now it doesn't look as bad when they stack.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This handles the stacking display, as well as removing the need for the  .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrmmm, good point...

We're also not performing this check in the MFE; we always link to Studio.

@davidjoy With this implemented as-is, I don't think we can perform this check; we don't have access to the block, so I think we'd need another approach.

@marcotuts (cc: @ormsbee) Do you have background on this feature, its use/exposure/etc?

Depending on that, we should determine:

  1. If we care about this check, do we need to port this check to the MFE too? (now or backlog)
  2. If we don't, do we care enough to preserve backward compatibility here? (now or backlog)
  3. Or just ignore it and always link to the block in Studio?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could I suggest changing the align-items here to start instead of center? I think having the dropdown aligned to the top when the window width is shrunken down will look a bit cleaner.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise, I screwed around with this for a while just now and came up with much the same layout.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrmm, it might look a little better when shrunken down, but I think it may look worse when wide, since it's all on a single line and no longer centered vertically on the one side.

center, shrunk

Screenshot_2020-06-02_08-10-24

start, shrunk

Screenshot_2020-06-02_12-09-20

start, wide

Screenshot_2020-06-02_12-07-14

center, wide

Screenshot_2020-06-02_08-09-27

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, darn. Yup, looks like junk with start. Ah well.

Copy link
Contributor

@davidjoy davidjoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a suggestion to change align-items to start, but otherwise think we're good to go.

stvstnfrd added 2 commits June 2, 2020 16:00
in a feature backport from the new Courseware/Learning MFE.
in favor of display in the Staff Instructor Toolbar.
@stvstnfrd stvstnfrd force-pushed the add/staff-toolbar-links branch from 1461ff8 to 4490e4c Compare June 2, 2020 23:01
@edx-status-bot
Copy link

Your PR has finished running tests. There were no failures.

@stvstnfrd stvstnfrd merged commit 9dd97a5 into openedx:master Jun 3, 2020
@stvstnfrd stvstnfrd deleted the add/staff-toolbar-links branch June 3, 2020 16:39
@edx-pipeline-bot
Copy link
Contributor

EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production.

@edx-pipeline-bot
Copy link
Contributor

EdX Release Notice: This PR may have caused e2e tests to fail on Stage. If you're a member of the edX org, please visit #e2e-troubleshooting on Slack to help diagnose the cause of these failures. Otherwise, it is the reviewer's responsibility. E2E tests have failed. https://gocd.tools.edx.org/go/tab/pipeline/history/deploy_to_stage

@edx-pipeline-bot
Copy link
Contributor

EdX Release Notice: This PR has been deployed to the production environment.

Agrendalath added a commit to open-craft/openedx-platform that referenced this pull request Jun 15, 2021
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.
blarghmatey pushed a commit to mitodl/edx-platform that referenced this pull request Aug 2, 2021
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.
Agrendalath added a commit to open-craft/openedx-platform that referenced this pull request Nov 25, 2021
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.

(cherry picked from commit 01ada0b)
Agrendalath added a commit to open-craft/openedx-platform that referenced this pull request Jan 20, 2022
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.

(cherry picked from commit 01ada0b)
Agrendalath added a commit to open-craft/openedx-platform that referenced this pull request May 12, 2022
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.

(cherry picked from commit 01ada0b)
Agrendalath added a commit to open-craft/openedx-platform that referenced this pull request Jun 7, 2022
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.

(cherry picked from commit 01ada0b)
Agrendalath added a commit to open-craft/openedx-platform that referenced this pull request Jun 7, 2022
…utton

openedx#24020 introduced a workaround for viewing the current vertical in Studio
However, replacing `window.location.href` on `click` did not support opening
it in a new tab.

(cherry picked from commit 01ada0b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants