You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, many gpus have multiple options for vram capacity. Having separate "parts" for each one is ok, but it could get unwieldy with more than 2 variants (for example, nvidia increasing the memory clock rate for the gtx 1060 or something which already has 2 vram options would result in 4 options. Maybe, if multiple variants, options show up after click, sliding up from bottom with css transition? Multiple .yaml files and parts internally is a good idea though, and it could make the subtext weird...needs more brainstorming...also with relation to filtering, although it's not a huge issue I think, if done like this the user can probably figure out which variant meets their criteria without too much pain
The text was updated successfully, but these errors were encountered:
Will have "global" variants, e.g different gb on cards, and "local" variants, e.g different graphics card manufacturers (e.g, sapphire and xfx). These screenshots are for local variants. The local variant dropdowns will show on all selected parts with local variants, but only one can be open at a time. The current plan for how to display the local variants is a separate table below the main spec one which shows differences between variants of the same part. Will have red-selected styling on selected variants. Opening a different dropdown closes the first one, and deselects all variants in it.
Small design things: table borders seem too long, VARIANTS: header needs to be made a better font/thickness/whatever, might be a good idea to use svg instead of unicode for arrow.
For example, many gpus have multiple options for vram capacity. Having separate "parts" for each one is ok, but it could get unwieldy with more than 2 variants (for example, nvidia increasing the memory clock rate for the gtx 1060 or something which already has 2 vram options would result in 4 options. Maybe, if multiple variants, options show up after click, sliding up from bottom with css transition? Multiple .yaml files and parts internally is a good idea though, and it could make the subtext weird...needs more brainstorming...also with relation to filtering, although it's not a huge issue I think, if done like this the user can probably figure out which variant meets their criteria without too much pain
The text was updated successfully, but these errors were encountered: