Is your feature request related to a problem? Please describe.

Essentially this storybook should be used by others through NPM. If we can get this working early we can then test and make use of the components elsewhere.

Describe the solution you'd like

Create a release on GitHub => Add version (tag) to GitHub. Pretty simple.

We must also start thinking about how we should export from the NPM module.

A color palette defines which colors you're allowed to use when developing, for the most part. Exactly which color values we choose isn't as important as how we structure them and use them. We can have as many different colors of gray as we want, but how do you as a developer choose which one to use?

Variations:

Blue should have a darker blue which we'll use for backgrounds like the header. A more neutral blue would be used for your typical interactive element, like buttons.

Orange is our accent color (unfortunately), but orange is a hard color to work with. We probably don't need a lot of variations for it, and it should be used sparingly, especially on white backgrounds. We've had some success with orange on dark blue backgrounds, like fadderukesplashen.

Grays are important. Having a just-darker-than-white background color is part of our design on OWF now, with white cards to contrast with. Some very-dark gray should be used for text, and this is mostly a question of "how many shades of gray?".

Status colors are also important. A green confirmation/success color, a red error/danger color, a yellow warning color, etc.

We've also toyed with the idea of having group/type-based colors, like a "bedpres" color or a "fagkom" color. Personally I'm not a fan and think it makes our design messy, but it requires mentioning here regardless.

A classic navigational helper that probably belongs at the top of about every page we use. Text example:

Home -> Profile -> Statistics -> Events

The crumbs should link to the relevant page, so one can easily move up in the site tree.

It's nice to have a description without using up a lot of space. Like on forms, having a tiny circle with an "i" or a "?" in it can be clicked to get more information. The information box could also potentially appear when hovering over certain things?
The box itself could be a simple white box with a shadow, and a tiny arrow-like thing pointing at the thing being hovered over.

Input type where you step up in set intervals. Don't know the use case, but the component could exist.

A vertically-progressing chain of events, known commonly as the pièces de résistance of fadderukesplashen. It has events that can be on different days, you can hover on them to see the dot on the line be highlighted, you can click on events to see their description, etc.
We also have a lighter version used on jubileum.online.
It's a super specific, large component.

More of a general layout component, this might be better suited for the projects that use DS instead of DS itself. Sections can be straight forward centered, they could have a filled background color that stretches to the edges of the page, maybe even a variation for a slightly tilted section (like the fadderukesplash)
I've fought against this issue before, and this is a really dope solution to how you could have a colored section for the entire page width, despite being in a limited width of content.

Fonts, where different fonts are used, and which sizes of headings we have. Most commonly a sans-serif font is used for body text, and sometimes a serif font is used for certain display headings.
Supporting a nice range of sizes would be good, like h1, h2, h3, ingress, ingress strong, body, body strong, info, info strong, etc.

The main logo, currently displayed at the top bar at online.ntnu.no.

Variations

• Online
• Lyn-O
• Static spinner logo thing (if approved by prokom)
• Straighter, less gradienty logo that Ole made that one time, we use it for favicon on OWF?

A core component! Text inputs clearly indicate when they are focused, and when something is wrong. Variations include passwords, indicators for when there are a limited amount of characters, maybe a built-in label. A quality-of-life option would be having a "clear input" cross on the right. An optional icon on the left could help indicate your action, like a magnifying glass for a search field.

This probably also includes input types like email, telephone number, maybe number field, search

TODO

• Plain
• Input type
• With label
• Disabled
• Focused
• Clear input
• With error
• With OK
• With alert

Our default button should probably be blue, idk lol. We have a lot of variations, like the one on opptak.online, or on fadderukesplashen. I don't think we should use all the different kinds we have, they're not all good tbh.

• Filled, inversed, flat
• With Spinner
• Logo Button
• Disabled
• Success
• Danger

An important and weird variation is the link button, where it looks like and behaves a lot like a button, but it is actually an anchor tag. This is important for semantics and accessibility

Tiny badges like we have on attendance for rule bundles and that kind of thing, maybe? Appearance similar to labels on Github etc? I might be missing the original meaning, because this seems super unimportant.

Not actually based on page load or something like that. It's more of a progress bar like you have on LinkedIn, or an install wizard. So it can have a different color based on the percentage value.

Manual or automatic, a manual could be used for offline menu or some shit, and an automatic could be used to cycle between images for events?

Make a selection from a range of values, fairly rarely used, but useful if you have a fairly analog selection.

We already have some variations of these. The infamous logo-based spinner. The dope "kvitteringsskjema" blue-orange spinnyboy. The blue-purple waity waity genfors thing.

A lot of work for fanciness, but we kind of have this already for OWF, so just rip it out and stuff it in here boi.

Click on a thing with a default option (or not) and see a list of options. Select one, and only one of them. Then move on!

Describe the bug
Linting errors.

To Reproduce
yarn lint

Expected behavior
Should pass yarn lint

Select a specific date or a range of dates. Not sure we would use it a lot, and it can take a lot of time to make.

This is one of the most common components, we kind of already have it in part in our profile email settings page, but it's treated more like a radio button.

• Disabled
• Error
• Checked or not, controlled?

A simple white (maybe also an off-white) background, maybe with a border.
#30 would handle the shadows

Like a tiny popup on the side or corner of the page, with a few steps that maybe ends in an action?

A field where you can click to choose a file, or maybe drag and drop it in.

• Being able to tab through a component logically
• Seeing the correct item have an outline
• Support for contrast outlines
• Being able to use spacebar or enter or similar to interact

Shadows indicating some level of elevation from the page background. Commonly paired with #26, but it could be separated into its own styling if there are other components that could have an elevation. Potential other components that could use elevation would be like a header or a footer or some other type of layout component that isn't a card. If we don't see a whole lot of use-cases for it, just bake it into card instead.
Variations could include the level of elevation, maybe even the direction?

An extension of text input, where you type in something and select an option, and you can have more of them. Useful for filtration and that kind of thing.

More of a layout thing, less of a styling thing. Functionally this would have a menu of tabs, and a container of the content for the given tab. Oftentimes the not-selected tabs are grayed out in some fashion, and/or there is some indicator on the selected the selected tab.
Advanced mode would have transitions when switching tabs, or the indicator moving around on the row of tabs.

You know, the kind where the screen goes darker and you only have that one box in the middle to interact with. Options could include "does clicking the dark background close the modal, or do nothing?", having a close cross mark in the corner, so on. It should maybe take in children and put it in the central cardthing?

• Dark overlay
• Option for in-place non-fullscreen?
• Background close
• Exit-button

Functionally an accordion is some item where when clicked, expands. Aesthetically this can mean a whole lot of things, like a longer text where only the first few lines are shown, but when clicked, the whole text is available to read.

Some kind of throttling/debouncing

Typically circular, less like a "check" based indicator, more like a "filled background" indicator. Only one can be selected at once in the group.

This refers to the kind of calendar we use for events on OWF. It's fairly complex, might not have a lot of use-cases, but could have a lot of variations for week, month, year, so on.

A general component where you send the name of an icon for whichever icon library we end up using, and you get the icon! Also include relevant options for color, maybe size? Or have the size be adaptable to its container.
The first step is choosing a free icon library with many icons.

We have a version we've used since SDF, which is also used a lot of places in OWF. It's sort of like a checkbox, but it's more "yes or no". More used for "show more info" kind of things where you change the DOM maybe?

Sort of like a popup, think like "hey man we use cookies and shit" where you also have a "fine, mom" button to remove the banner. A button-less banner could be used to inform a lot of users, like having a button at the top of OW4 saying "yo there's a beta for owf, click here to go there"

Typically only used for mobile, sometimes called "bottom navigation". Oftentimes has between three and five icons, maybe with a text label, navigating you to a specific site/category.

Status / infoboxes that can be used to inform users. Classic variations include a red error, yellow warning, green success, and a more bluegray neutral info.

Common styling for a typical list, numbered or otherwise

That thing on the frontpage of OWF with the events and the cards and maybe an image and hey guess what, emojis.

Apparently this exists somewhere already. Tables or lists of data with sortable headers with dope icons, maybe alternating colors on the rows.

Kind of like a card, but a very specific component for displaying a tiny bit of text, maybe with an image, and it's fairly wide instead of tall.

Add a button component

We want the header in OWF to be more category-based, with a dropdown on hover with several options therein. At first the menu could be a fairly simple list of links. Design-wise, it would be cool to have like a square with an arrow pointing up at the hovered item, classic stuff.

Most likely based on what OW4 provides, variations for size and thumbnail. Being able to click on any image and see the original size is a nice possible feature.

In a perfect world, any design would scale perfectly with any size of container. However, designing every page and every component so generally that it fits to every size is very hard. To keep it simple, we could operate width fixed content widths, maybe with stretching for mobile.

This allows us to use fixed pixel values for components without fear, and we reduce the headaches that come from trying to make everything adaptable.

Example from Vy: Three breakpoints (tablet, desktop, widescreen), used with min-width media queries. This setup promotes mobile-first, as your standard styling will apply to mobile and everything larger, unless overriden by a breakpoint.

.biggie {
  font-size: 1.5rem;

  @media screen and (min-width: 756px) {
    font-size: 2rem;
  }

  @media screen and (min-width: 1200px) {
    font-size: 2.5rem;
  }

  @media screen and (min-width: 1704px) {
    font-size: 3rem;
  }
}

In effect, you have a fourth value to keep track of, which is the minimum width we design for. At Vy they use 320px as the absolute minimum content width, which is the same size as iPhone 5/SE. Personally I found that very limiting, so opting for a step larger allows for more complex interfaces, at the cost of things looking weird for people with older phones.

Ultimately, the choice of minimum width should be determined by looking at Google Analytics and figuring out how many people use however old phones.

For choosing which specific breakpoints you could also look at analytics, but there are so many possible phone/tablet sizes, that just going for something and sticking to it has merit.

The kind you pull in from the side, I think. Maybe activated by a hamburger menu? Mostly mobile-focused.

Your typical anchor tag, meant to link you to other pages.

Nice.