-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement and publish website #37
Comments
worklog 2022.09.09 8:28PM
|
|
worklog 2022.09.11 11:52AM
|
|
|
|
|
worklog 2022.09.22 09:43PM
|
|
|
|
|
|
|
|
|
Tasks
FeedbacksThere are questions in the worklog video and also I'll like to ask if we would be creating both light and dark modes componentsWorklogsworklog-77Proposals |
feedback
so you understand correctly. You are correct, this is a mistake. Every design was a different mode of the popovers component, similar to how We then agreed to deprecate the popovers component and create individual components as successor components, each with their own name and version. So yes - there should not be a name/version for those designs inside the content area of the popover component, instaed they should have been just names or labels for those individual states of the popover component, so please just ignore that name/version thing :-) Sorry for the confusing, but good for pointing it out, so we can improve the video to present how we do figma versioning. So if you take an existing component version design on figma and create a final "deprecated" version, but the features or functionality solved by this now outdated components are solved instead by other components that were designed, then those components should be listed. A component can also have no succesor component and just be deprecated, because we decided to not use it anymore, e.g. imagine we would have created a merging componentsok, so i think there is a misunderstanding. If you have two component A and B, you can make a component C that uses A and B as dependencies ...that is NOT a "merged component". Instead - a "merged component" is the opposite of a "split component". So you would deprecate 2 or more components at the same time We do NOT use these old components as dependencies in the new component. So the technique is the same as in the split component, but instead of having one component and many new, we have many old deprecated and one new. Every time you deprecate components, you can list possible successor components that should be used from now on instead of the deprecated component. |
Tasks
FeedbacksBroke the components into single components then I would proceed to link them together into larger components and sections.Worklogsworklog-78Proposals |
FeedbackNov 26th 2022 Here is my feedback on the content of your work Part 1: https://www.loom.com/share/dcf12139efe54730b1212ec76e7a8bf9 Links for inspiration (code is of course not the same as these components are part of certain frameworks):
And here are some of our existing components (which might need a little bit of brushing up before use) |
#23
@todo
@input
π¦identity idea
@input
π¦website
@output
βpull requests with suggested changes
@output
π¦dat ecosystem character artwork
@output
βnew icons
@output
π¦banner image
@input
: π¦assets
output
: βfigma wireframe
@input
: βfigma wireframe
output
: βversion controlled figma wireframe
@input
βdat ecosystem github page
from Update - project_filter ComponentΒ website#15@output
π¦refined logotype versions
from tidy up the logotypeΒ #114@output
βartworks for the website and social media
@output
βwebsite UI/UX specification & wireframes
@output
βdat-ecosystem design system
@output
βlist of re-usable web components
@input
π βdat-ecosystem.org
fromcomment
The text was updated successfully, but these errors were encountered: