I think KExternalLink ought to either give the option to - or just by default open links with target="_blank" rel="noopener noreferrer" attrs to open external links into a new tab.

I'm making it work so that KDropdownMenu allows a KIconButton because our specs have required the ability to do so.

The API here ought to be improved though. text is a required prop that isn't required for a KIconButton - but a KIconButton does need some tooltip text.

I think this is likely to be more useful as we near implementation in Studio.

We removed the target="_blank" rel="noopener noreferrer" due to learningequality/kolibri#7480

However, KExternalLink ought to have a boolean prop openInNewTab when true will apply the proper attrs.

It also should be tested in Android and other special-build versions of Kolibri designed to run in a web view.

First, this must be finished: learningequality/kolibri#7482 because Kolibri uses KExternalLink for internal routing at time of writing.

<router-link> is like router.push() - in that it creates a new history

We can extend the replace prop from <router-link> to KRouterLink so that we have the option.

https://router.vuejs.org/api/#replace

I noticed this while looking into the first listed issue in this: learningequality/kolibri#7366

Where the back button "doesn't work" but it's really just that you're getting a bunch of history items pushed to the history stack.

Observed behavior

CSV import instructions at Facility - DATA - Import and export users - View spreadsheet format reference suggests using email address as an Identifier -

But an email address overlaps with gender field even for short emails in the Facility - USERS list -

Expected behavior

Identifier field's value should not overlap with gender field value.

User-facing consequences

Unreadable data

Errors and logs

…

Steps to reproduce

…

Context

Kolibri 0.14.0

Observed behavior

• default is supposed to be bottom but is actually top
• modifying prop does not seem to have an effect

Expected behavior

placement should work

User-facing consequences

sub-optimal placement

Steps to reproduce

try to change placement

Context

0.12

Observed behavior

There are at least three implementations of search boxes.

• Some of them have shared components, when they shouldn't: for example the search box in the app bar and the search box in the learner content search page
• Some of them don't have shared components, when they should: for example the search box in the learner content search page, the coach lesson management search box, and the kFilterTextbox

Expected behavior

• We should have a single re-usable core search box component that is used inside of pages
• We should have a single special-case search box component for use in the app bar

User-facing consequences

• inconsistent user experience
• very hard to maintain code

Context

0.12.3

The DocsColorBlock component has a boolean definition property, which is intended to be:

• true when the color block is being used on the "Color" page and is the canonical "definition" which gets linked to.
• false when the color block is being used as an example or illustration

Setting definition to false should cross-link to the actual definition in the colors page.

The docs intentionally have their own styling and focus highlighting behaviors independent of the library code. However the examples don't render properly:

The examples should use proper focus highlighting:

This was originally a problem in learningequality/kolibri#6301, and I'm wondering if something changed with the KModal in this library, because I'm seeing the KModal form appear over the disconnection overlay again. Fortunately, I can close the modal without seeing the same errors as in that issue.

Observed behavior

We have duplicated code 3x for switching colors based on content types.

Expected behavior

Move to a shared helper utility. See learningequality/kolibri#5540 (comment)

User-facing consequences

None

Context

0.12.3

Not sure if this is actually from KLabeledIcon, but here are some screenshots of text + icon overlapping in RTL

https://kolibri-beta.learningequality.org/ar/learn/#/topics/c/544c345f9d6c4b90a4f51c56d95243fe

Side Nav

Observed behavior

In particular, we want to make sure that the optimizations from learningequality/kolibri#4075 are being enforced

Expected behavior

Style updates are expensive, and should not be allowed to be called more often than necessary

User-facing consequences

potentially lower performance

Context

k011

In a recent change related to granular import/export (#2610), we added a new prop to the core breadcrumbs component:

+      /**
 +       * When set to 'true', a breadcrumb will be shown for each item in 'items' array.
 +       * Otherwise, the first item will be omitted.
 +       */
 +      showAllCrumbs: {
 +        type: Boolean,
 +        default: false,
 +      },

https://github.com/learningequality/kolibri/pull/2610/files#diff-d37333989ca3443ceed46359f1fab1feR113

We need to update the style guide to give guidance on when this prop is intended to be used.

cc @khangmach @jtamiace @jonboiser @christianmemije

Currently we have a situation where there is one top-level package.json file, and:

1. some dependencies used by the shared component library (/lib) are in dependencies
2. other dependencies used by the shared component library (/lib) are expected/assumed to be provided by the library user
3. all other design system dependencies are in devDependencies. This includes both build and run-time dependencies

This situation will be hard to maintain. Preferably, we want:

• Depending on the shared component library be fast and easy:
  • install only the dependencies needed in node_modules
  • support tree shaking in webpack
  • handle situation where dependencies may already be provided by the user (perhaps using peerDependencies?)
• When managing design system dependencies, we should be able to distinguish between run-time and build dependencies.
• While using sub-packages might be a good strategy, we've also encountered many developer ergonomics problems with both Lerna and yarn workspaces, so we should approach this strategy with caution

The following changes to shared Kolibri Components have been made recently in Kolibri develop. They need to be added here before learningequality/kolibri#6595 is merged in

• learningequality/kolibri@a024934#diff-7d9c37dc9a600932d07e64be8ff7b11e
• learningequality/kolibri@c037b6e#diff-053a10dd1d40a8a0dabc76d4f84cb32a
• learningequality/kolibri@af2c8fc#diff-053a10dd1d40a8a0dabc76d4f84cb32a
• learningequality/kolibri@e0b154e
• https://github.com/learningequality/kolibri/pull/6660/files#diff-2425a6167bea4c6f2460022a0cb7a512
• learningequality/kolibri#6830

Example in KDP Sync modal:

From discussion in this google document https://docs.google.com/document/d/1Qm1vpbbqlgTGn4m-qRX57YLpUr9cKmtH2QkEoy0P8-0/edit#heading=h.c1qqiboowt5l

Bringing clarity on modal behavior since they do not have a URL

The browser back button should function the same as dismissing the modal - the same as hitting the "cancel" button

Hints use this "1/4" thing in the margin which is hidden for me with the narrower PageContainer padding

Observed behavior

Having validation only on the backend means that the theme "API" isn't well defined.

Expected behavior

It would be better for the front-end to clearly define it, and possibly to provide internal defaults so that unit testing is easier

see thread: learningequality/kolibri#5688 (review)

User-facing consequences

themes and tests that need themes are confusing for devs to work with

Context

0.12.4

Observed behavior

As observed by @jonboiser in learningequality/kolibri#3173 (comment), the k-select component interprets {} as no option selected. If any keys are available it may interpret it as a valid input.

Also, it would be helpful to communicate the fact that input is valid to the wrapping component, so it can handle disabling input buttons.

Expected behavior

Should validate for the two keys value and label that k-select expects, and either expose its current validation state to the parent component, or have an externally accessible validator to check this validity.

User-facing consequences

May implement confusing work flows as demonstrated by learningequality/kolibri#3171..

I think that, perhaps, the only difference between them ought to really just be how we handle events.

• KRouterLink takes a :to route which must be a valid router route.
• KExternalLink takes a download prop (among others) to manage external URL links
• KButton goes "click" if you click it and you can do what you want with that information.

All of them should have:

• Primary or no?
• Appearance basic-link raised-button flat-button
• icon and iconAfter props & slots w/ a consistent sizing/styling
• disabled prop

And I'm suggesting that If any of the components receive the same values for these props, they should look 100% identical. The only difference being how they act.

observed in #68 on mac + chrome:

Would expect the icons to be perfectly middle-aligned vertically with the text

Observed behavior

Seems like a log of CPU and GPU for the animation

Expected behavior

Light-weight animations

User-facing consequences

decreased battery life and spinning fans

Context

0.13.0

I wanted a button to be a router link. The "Create Account" button on the sign in. I wanted to also make that button disabled when the form is submitted.

But KRouterLink does not have the disabled prop that KButton has and I think that it maybe ought to.

<a> and <button> both have common enough uses for being disabled.

My solution was to wrap KButton in a <router-link> - which worked fine - but if KRouterLink can pretend to be a button then let's help it be better at it?

For example, copying tokens.correct below results in tokens.correctlink to section

Observed behavior

We're currently using the old Material style of textboxes. In addition to having proven UX issues, it also leads to inconsistent vertical rhythm:

Expected behavior

upgrade to the new style:

User-facing consequences

According to the study, this has improvements in three dimensions:

• Identifiability: The number of correct versus incorrect clicks
• Find-ability / scan-ability: The time it took a participant to find and click on a requested element
• Preference: Participants rank-ordered each text field variation

Context

0.12.x

Observed behavior

A PDF and an ePub with the same title are indistinguishable: http://35.196.115.213/learn/#/topics/t/2c953cb70c4d57dbb91a879ab4953834

Expected behavior

User-facing consequences

Certain sources offer both a PDF and ePub version of documents with the same title. Ideally we would want to import both file formats, but it can be confusing if icons for both document sub-kinds are the same.

Severity: minor

@indirectlylit made this prop required in a minor release, which broke existing users.

Let's follow up in a major release in #168

Observed behavior

Similar to learningequality/kolibri#6043, when (shift)-tabbing through a KModal form, keyboard focus will be lost when going out of bounds:

1. If at first focusable element, Shift-Tab will take you to top of the KModal element outside of the form (but tabbing once will bring you back to the form)
2. At the last focusable element, Tab will take you to the browser chrome (in Chrome, at least).

Expected behavior

A more convenient keyboard navigation, similar to the fix to learningequality/kolibri#6043 but within KMOdal.

User-facing consequences

…

Errors and logs

…

Steps to reproduce

…

Context

…

To fix a problem where two buttons in a Button Group would wrap if their container got too narrow, I added a white-space: nowrap rule.

https://github.com/learningequality/kolibri/pull/7393/files#diff-127f6559e90cdff95ed013563555933d

I think this will be a pretty common usage where we want buttons to stay in a side-by-side layout, so it would be helpful if this was either a default or can be controlled via a prop.

Adding a gerund to a title gives the user the impression that the task is in progress when it's not. Several anecdotal accounts of this happening from team members

Slack thread which contains other links
https://learningequality.slack.com/archives/CTG8XDTCL/p1597436796011600

Side nav isn't highlighted:

The header anchor links don't work in firefox. For some reason the first click goes to the top of the page, and the second click goes to the actual anchor:

GIF:

Example from SyncAllModal.vue in Kolibri . Hovering over the "Sync" button will not cause the tooltip to appear

      <KButtonGroup>
        <KButton
          :text="coreString('cancelAction')"
          @click="$emit('cancel')"
        />
        <KButton
          ref="syncbutton"
          :text="coreString('syncAction')"
          primary
		  :disabled="submitDisabled"
          type="submit"
        />
        <!-- TODO make tooltips appear when hovering over disabled buttons-->
        <KTooltip
          v-if="submitDisabled"
          reference="syncbutton"
          :refs="$refs"
        >
          <span v-if="noRegisteredFacilities">
            {{ $tr('noFacilitiesTooltip') }}
          </span>
          <span v-else>
            {{ $tr('currentlyOfflineTooltip') }}
          </span>
        </KTooltip>
      </KButtonGroup>

Observed behavior

We've run into on at least two occasions.

First in learningequality/kolibri#3652, the select menu in the language switcher login-page caused major issues:

More recently in learningequality/kolibri#4016, select boxes that towards the bottom of scrolling areas (or that contain many items) have a very poor user experience because they require the user to scroll down in order to see the pop-up:

Unfortunately, this behavior is built-in to our current custom select widget, and in fact may be unavoidable for any custom select widget.

Expected behavior

A true native select box appears on top of everything, even the outer window:

Since we cannot achieve this and retain our custom styling, we should avoid using select boxes anywhere that they might exhibit this type of behavior. In particular, this means:

1. Select boxes should always have a maximum number of items that can easily fit on the smallest screen size
2. Select boxes should never appear at the bottom of a scrolling pane

We should also update our style guide with guidance to this effect

User-facing consequences

Hard to select items

Steps to reproduce

see steps in learningequality/kolibri#4016

Context

0.11

cc @khangmach @jtamiace

Observed behavior

In learningequality/kolibri#5843 we distinguished KGrid from KFixedGrid and KGridItem from KFixedGridItem.

@jonboiser commented

It may make the Vue devtools component view more noisy, as grid items are now nested a level deeper under KGrid > KGridItem > KGridFixedItem.

Expected behavior

We should move common functionality to composables, like we do with mixins for KButton to improve the developer experience

User-facing consequences

none

Context

0.12.7

We do not have control over the length of text in buttons when they are being translated.

In the (rare?) case that the width of the button group in modals happens to exceed the width of the modal, the buttons should wrap, with the secondary action appearing below the primary action. They should still remain right-aligned.

Based on a Slack thread

Issue summary: We have inconsistent ways of handling the alignment of flat button components in our products. Should the text or component be aligned to a page container?

A couple of takeaways (copy pasted)

1. Add the rules “For flat buttons: align button text, not the button component to container content boundaries; in button rows, keep 8px margin between components” to general Button Patterns documentation
2. Add a new Boolean prop on flat buttons offset which, when set to true, adds -8px left and right margins, which will align the button based on text rather than outer boundary

Implications for 2 current PRs
#16
#21

Observed behavior

1. After closing dropdowns, they don't leave the DOM, they just stick around: notice the many tags with .drop-element. This is from the UserPage, where clicking "Options" opens the drop down menu. They go away after navigating away from User Page, at least.

2. The drop elements have a higher z-index of 60 than the AppBar (z-index 4), so they appear over it:

Expected behavior

1. Closing dropdowns destroys the UIPopover element in the DOM, so it is not adding to the DOM.
2. UIPopover's don't appear over the AppBar

Context

Kolibri v0.13 (develop)

ref: #95 (comment)

Intent was to include an intro paragraph that does not generate a section link and anchor:

However the props are required:

https://github.com/learningequality/kolibri-design-system/blob/v0.2.x/docs/common/DocsPageSection.vue#L17-L26

We should update DocsPageSection so that:

• title and anchor should be optional props, so that they can be omitted entirely. In this case, no title or anchor link is created
• validation messaging should ensure that if either anchor or title are provided, the other is also required

Note that an alternative might be to omit the DocsPageSection component altogether, like this:

  <DocsPageTemplate>

    <p>These principles allow Learning Equality to apply its core values to the product design process. For non-designers, they also shed light on how the design team makes and prioritizes design decisions internally.</p>
    <p>When making decisions that affect our users, we encourage you to reference these principles during the product development process and to hold yourself accountable to these standards.</p>
    <p>Finally, these principles are a work in progress. The intent is that this is a living set of principles that will evolve to better serve the design team, the product process, and our users.</p>

    <DocsPageSection title="Equitable access" anchor="#equitable">
      <p>Equity is at the heart of Learning Equality’s mission. Our products address barriers of access to educational opportunity that are faced by marginalized populations.</p>
      <ul>
        ...

However this results in the text being full-width because it's the DocsPageSection which provides a max content width:

This is desirable so that other components like component examples can be full-width.

The padding rule for its small class makes it look lopsided. I would recommend keeping it an even 16px on all sides

Actually, even the default padding makes it look un even, because margin-top is less than the other sides.

KTextbox will not show error state - even when the invalid prop is true - if the value of the field has never changed.

This makes a validation like "This field is required" not show up if the user just flat out skipped it. Even if the field was focused at some point, the invalidText won't show unless you've ever entered a value.

Seems that if you have a Boolean where the implementing parent component says whether or not a field is valid that this should be everything you need to determine whether or not the message is shown.

I'm curious where the use cases were that necessitated the changeOrFocused value and why the focus on the element isn't making it show the error as expected.

The text filter and div scroll position should be maintained as you navigate around the site.

This is a bit challenging because every page is intentionally implemented as an independent HTML page, but should still be possible.

Currently, some parts of Studio are using the Vuetify VImg component, which produces responsive images, but does so by setting a background image onto a div - this goes against good accessibility practices, and is something that @nucleogenesis did significant work to address in github.com/learningequality/kolibri

It would be good to port that responsive image work to a more general component to allow us to use accessible responsive images across our ecosystem.

SSR-related issue related to #6

Kolibri Linter: Linting errors for lib/styles/trackInputModality.js
Kolibri Linter: 
lib/styles/trackInputModality.js
  116:3  error  Parsing error: 'import' and 'export' may only appear at the top level

KRadioButton has a description prop but KCheckbox does not.

Use-case:

learningequality/kolibri#7051

Want to give k-checkbox the same treatment I gave k-radio-button in learningequality/kolibri#3472

Some value adds:

• Allows for use of v-model with k-checkbox the same way we'd use it with a native HTML one
• Allows for descriptions in checkbox label
• Allows us to apply display:xxxxxxx to the parent element. Right now, locked into using table.
• Leverages native HTML behavior for things like click-label-to select, highlight.
• Simplifies logic of the component

From Netlify:

A reminder that starting April 14, 2020, sites without a custom domain are being moved from your-site.netlify.com to your-site.netlify.app

Currently the buttons page does not mention spacing between buttons or the new KButtonGroup component