search

datdot-ui / datdot-ui

component gallery & issues for datdot-ui organization
https://datdot-ui.github.io/datdot-ui/
MIT License
0 stars 0 forks source link

datdot-ui design-folder-migration #7

Open Mehrabbruno opened 8 months ago

Mehrabbruno commented 8 months ago

@todo

2

Mehrabbruno commented 8 months ago

tasks - 2023.08.30

worklog

worklog-170 worklog-171

feedback

proposal

Mehrabbruno commented 8 months ago

tasks - 2023.09.04

worklog

worklog-173

feedback

proposal

serapath commented 8 months ago

feedback 2023.09.04

so this is a pretty good hint (you saying that you cant find specific pages anywhere), that we need to improve our process and also start linking the original source document in figma, just so we know where things came from. at some point - i would go through your datdot feedback too and compare all the materials we have to the new figma version to make sure everything is included.

I see that the old adobe link seems to not work anymore. Which means i hope we can open the .xd file to get the rest from that app

anyway - here are more sources we have to process:

  1. https://github.com/datdotorg/datdot-ui/issues (but very carefully, including all the screenshots)
  2. https://github.com/datdot-ui/datdot-assets/tree/main/design/UI%20guideline
  3. https://github.com/datdot-ui/datdot-assets/blob/main/design/brainstorm/JOBS%20-%20brainstorm.png

You can check at least the dates of those images

and finally and maybe most importantly The adobe .xd file and these folders:

regarding "unfindable" wireframes

Like the datdot-app-JOBS-v1 stuff. Let's make a note and process all remaining materials linked above and then return to this in the end, because maybe we will find it somewhere :-)

Mehrabbruno commented 8 months ago

tasks - 2023.09.09

worklog

questions worklog-174 worklog-175

feedback

proposal

serapath commented 8 months ago

feedback 2023.09.09

1. :thumbsup: for the great work in the past including the thumbs up to track what has been specified as a component

2. specifying components in our figma version control way is much more work and effort than the figjam of "tracing the evolution/history of how wireframes evolved"

3. continuing with doing components where we left off last time creates a lot more work than maybe stopping it and finishing the figjam style with the remaining materials

4. once that is done, we should continue (2.) and actually do the figma version control of components starting with the last iteration of figjam, but revisiting the entire figjam history to come up with "the best possible and complete versions" for the initial version controlled figma components

MORE SPECIFICALLY: - checking all the latest final figjam entries, but then going back through the history of those to include how we ended up with that latest version, mainly because that is how we where working back then (which means: we did not wireframe a feature in the latest version that was already specified in greater detail in previous versions to save time. We were thinking to assemble the final version by combining the features from multiple versions into a last final version)

...this was a mistake and we should have done it the way we do it today, but it is what it is :slightly_smiling_face:

lastly: regarding questions like whether e.g. wireframe10 or datdot-app-JOBS-v1 is "the updated UI". I don't know anymore. I would say - maybe looking at the date of file creation or any context/details, try to do a "best guess" and link things in the order that make most sense.

I assume if there as almost no differences in the wireframes, it might not even matter too much if we get the order wrong - so let's try a best guess and hopefully that will work ok.

It might be a bit messy. The thing is. "wireframe version X" was meant to be ideally everything about an app

While "JOBS-v1" was our first approach of trying to "break wireframe into individually tracked components" instead of always iterating and versioning the entire update even though only a single component changed.

So "theoretically", a specific version of a wireframe should include versions of components, but because we were starting to make that change in how we work, things are sadly a bit messy in this transition and only with our newest "figma version controlled components" style do we have a basically fully featured and coherent system. Back then we did not yet have that...

sadly, i do not think we captured whether e.g. JOBSv1 was part of wireframe vX or wireframe vY, so this probably needs to be approximated from looking at the content.

Basically each "wireframe" is just "the entire app" as a component having input components like e.g. JOBS-v1 or whatever. When we started, "wireframe" was the whole app as a single component and over time - when refining it, we "broke out" some parts of "wireframe" (like JOBS) into it's own component, etc...

also, it is possible that multiple iterations on e.g. JOBS happened before we did the next wireframe version. At some point we might even have stopped wireframe versions altogether and continued only with component versions .... the probably natural evolution towards what we use today

one more thing :slightly_smiling_face:

you mention an example of the "navibation bar" (included in e.g. JOBS-v1-page-2) Was there a similar design in previous design?

Hopefully we can aproximately capture by creating some "component placeholder boxes" (e.g. navbar) and link to figjam/wireframes/designs to track aprox. where did what occur when. Or maybe linking things with arrow lines. Or maybe just a list of links to all the places ordered by time if possible... just to find a way to capture it.

The final output of all of this work is hopefully the first figma version controlled breakdown of ALL COMPONENTS using the "input" of all wireframes/designs/figjams/issues/etc... that include prior work on that component. Also: feel free to add multiple "alias names" to components for now to make it easier to find and also capture all the use cases or information that comes with all the names we might have used in the past to describe a component so we can search/find it more easily.

So when we do that "final output" (after which we work in our normal figma style), all this work is supposed to create the best possible first iteration.

The reason is, that almost 3 years of full time work and many people working on it ...and between 10k-20k USD went into creating it. It also captures ALL OF OUR THOUGHTS and CONCEPTS and will help me and others to remember what we already thought of in the past, when we continue the work :slightly_smiling_face:

Those who do not study history are doomed to repeat it

If you after all the above still think doing "version controlled figma directly" ...then maybe go for it. Maybe we should have done that all along, maybe even instead of the figjam. It is still a feasible thing we could do if you think this would help, i am not against it.

btw. (because you mention it in the video)

This component was called "chunks selector" as far as i remember from the time when we worked on it :slightly_smiling_face: component

But agree - we need to ALWAYS work in a way - that makes it irrelevant whether we make a 4 hour break or a 1 year break before continuing a task. So however you decide, just keep that in mind.

What I think is good is the first hand experience you now made with "datdot wireframes" when returning to the task ...because until now this was more something abstract i maybe mentioned in the past, but now you definitely feel it yourself :stuck_out_tongue:

Mehrabbruno commented 7 months ago

tasks - 2023.09.28

worklog

worklog-178

feedback

proposal

serapath commented 7 months ago

feedback 2023.10.05

Thank you. The approach you are suggesting makes sense. I hope the figjam would not lag too much even if we add the remaining ~30% of work that is left to complete things as you say.

If it does become unworkably slow lets see what we can do, but maybe we can just manage and after that is done, we anyway move away from figjam and create our regular version controlled figma components.

The figjam is definitely proof (seeing how the latest iterations e.g. verison 13-1 of the app depends on some very old versions).

Thank you for working your way through all this. By finishing all of it and then moving to our latest version controlled figma compoents style, we will never have that problem again. Components ALWAYS only depend on the latest components, so looking forward to that :-)

Mehrabbruno commented 6 months ago

tasks - 2023.10.30

worklog

worklog-179 worklog-180

feedback

proposal

Mehrabbruno commented 6 months ago

tasks - 2023.11.11

worklog

worklog-183

feedback

proposal

Mehrabbruno commented 5 months ago

tasks - 2023.12.10

worklog

worklog-187

feedback

proposal