datdot-ui project plan

[Mehrabbruno]

@todo

#1

---

• study datdot project videos to create project plan
  • study datdot intro script
    • @input 📦 datdot intro script from 🔮
  • study datdot intro video
    • @input 📦 datdot intro video from 🔮
  • Create an issue to place all the task related to datdot-ui
  • @output 📦 datdot-ui project plan issue from comment

---

• refine plan to include all datdot-ui components
  • @input 📦 datdot-ui project plan issue
  • study datdot-ui overview video
    • @input 📦 datdot-ui overview video from 🔮
  • datdot-ui component implementations video
    • @input 📦 datdot-ui component implementations video from 🔮
  • datdot-ui-wireframes video
    • @input 📦 datdot-ui-wireframes video from 🔮
  • study datdot-ui versioned pdfs
    • @input 📦 datdot version pdfs from 🔮
    • study datdot-app-wireframe-v0
      • discussion (read, study, restructure tasks) on the project plan & wireframe component breakdown structure
      • design figjam flowchart component
      • recorded video, updated top level comment (Task structure)
      • @output 📦 figjam_component_links_v0 from comment
    • study datdot-app-wireframe-v1
    • @input 📦 figjam_component_links_v0
      • design figjam_component_links_v1
      • @output 📦 figjam_component_links_v1 from comment
    • study datdot-app-wireframe-v2
      • @input 📦 figjam_component_links_v1
      • design figjam_component_links_v2
      • @output 📦 figjam_component_links_v2 from comment
    • study datdot-app-wireframe-v3
      • @input 📦 figjam_component_links_v2
      • design figjam_component_links_v3
      • compare wireframe-v3 to wireframe-2
      • @output 📦 figjam_component_links_v3 from comment
    • study datdot-app-wireframe-v4
      • @input 📦 figjam_component_links_v3
      • design figjam_component_links_v4
      • compare wireframe-v4 to wireframe-3
      • @output 📦 figjam_component_links_v4 from comment
    • study datdot-app-wireframe-v5
      • @input 📦 figjam_component_links_v4
      • design figjam_component_links_v5
      • compare wireframe-v5 to wireframe-4
      • @output 📦 figjam_component_links_v5 from comment
    • study datdot-app-wireframe-v6
      • @input 📦 figjam_component_links_v5
      • design figjam_component_links_v6
      • compare wireframe-v6 to wireframe-5
      • @output 📦 figjam_component_links_v6 from comment
    • study datdot-app-wireframe-v6-1
      • @input 📦figjam_component_links_v6
      • read, respond to datdot-ui feedback 03-dec-2022
      • convert grid lines to straight lines
      • compare wireframe-v6-1 to wireframe-6
      • design figjam_component_links_v6-1
      • @output 📦 figjam_component_links_v6-1 from comment
    • study datdot-app-wireframe-v7
      • @input 📦figjam_component_links_v6-1
      • compare wireframe-v7 to wireframe-6-1
      • design figjam_component_links_v7
      • @output 📦 figjam_component_links_v7 from comment
    • study datdot-app-wireframe-v8
      • @input 📦 figjam_component_links_v7
      • compare wireframe-v8 to wireframe-7
      • design figjam_component_links_v8
      • update github tasks and timelog
      • @output 📦 figjam_component_links_v8 from comment
    • study datdot-app-wireframe-v9
      • @input 📦 figjam_component_links_v8
      • compare wireframe-v9 to wireframe-8
      • design figjam_component_links_v9
      • @output 📦 figjam_component_links_v9 from comment
    • study datdot-app-wireframe-v10
      • @input 📦 figjam_component_links_v9
      • compare wireframe-v10 to wireframe-9
      • design figjam_component_links_v10
      • @output 📦 figjam_component_links_v10 from comment
    • study datdot-app-wireframe-v11
      • @input 📦 figjam_component_links_v10
      • compare wireframe-v11 to wireframe-10
      • design figjam_component_links_v11
      • @output 📦 figjam_component_links_v11 from comment
    • study datdot-app-wireframe-v12
      • @input 📦 figjam_component_links_v11
      • compare wireframe-v12 to wireframe-11
      • design figjam_component_links_v12
      • @output 📦 figjam_component_links_v12 from comment
    • study datdot-app-wireframe-v12-1
      • @input 📦 figjam_component_links_v12
      • compare wireframe-v12-1 to wireframe-12
      • design figjam_component_links_v12-1
      • @output 📦 figjam_component_links_v12-1 from comment
    • study datdot-app-wireframe-v13
      • @input 📦 figjam_component_links_v12-1
      • compare wireframe-v13 to wireframe-12-1
      • design figjam_component_links_v13
      • record videos and update github tasks
      • @output 📦 figjam_component_links from comment
    • Record explanatory videos of all the Figjam components
    • @output 📦 figjam_component_links from comment
  • study datdot detailed versions
    • @input 📦 datdot detailed versions from 🔮
  • study datdot adobe workflows data
    • @input 📦 datdot adobe workflows data from 🔮
  • study datdot-ui wireframes
    • @input 📦 datdot-ui wireframes from 🔮
  • study datdot wallet & storage network app interactive prototype
    • @input 📦 datdot wallet & storage network app interactive prototype from 🔮
  • propose task and subtask structure and wireframes for needed versioned ui components & repos for datdot-ui
    • @output 📦 tasks_for_current_component_repo-v0.0.1 from comment
  • refine datdot-ui tasks for wireframes of proposed component structure
    • @input 📦 tasks_for_current_component_repo-v0.0.1
    • include a data wallet component (user, apps tab in wireframes)
    • include a storage network component (plan, work tab in wireframes)
    • @output ❓ refined datdot-ui project structure

---

• propose task and sub-task structure and wireframes from the created Figjam structure
  • add and restructure tasks
  • propose task for wireframe-v0
    • @input 📦 figjam_component_links_v0
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v0 from comment
  • propose task for wireframe-v1
    • @input 📦 figjam_component_links_v1
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v1 from comment
  • propose task for wireframe-v2
    • @input 📦 figjam_component_links_v2
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v2 from comment
  • propose task for wireframe-v3
    • @input 📦 figjam_component_links_v3
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v3 from comment
  • propose task for wireframe-v4
    • @input 📦 figjam_component_links_v4
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v4 from comment
  • propose task for wireframe-v5
    • @input 📦 figjam_component_links_v5
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v5 from comment
  • propose task for wireframe-v6
    • @input 📦 figjam_component_links_v6
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v6 from comment
  • propose task for wireframe-v6-1
    • @input 📦 figjam_component_links_v6-1
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v6-1 from comment
  • propose task for wireframe-v7
    • @input 📦 figjam_component_links_v7
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v7 from comment
  • propose task for wireframe-v8
    • @input 📦 figjam_component_links_v8
    • write the task and sub-task in hackmd doc
    • update tasks and time logs
    • @output 📦 proposed_task_for_v8 from comment
  • propose task for wireframe-v9
    • @input 📦 figjam_component_links_v9
    • Read feedback provided on 2022.12.21 and 2022.12.22
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v9 from comment
  • propose task for wireframe-v10
    • @input 📦 figjam_component_links_v10
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v10 from comment
  • propose task for wireframe-v12
    • @input 📦 figjam_component_links_v12
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v12 from comment
  • propose task for wireframe-v12-1
    • @input 📦 figjam_component_links_v12-1
    • write the task and sub-task in hackmd doc
    • @output 📦 proposed_task_for_v12-1 from comment
  • propose task for wireframe-v13
    • @input 📦 figjam_component_links_v13
    • write the task and sub-task in hackmd doc
    • update task and record worklog video
    • @output 📦 proposed_task_for_v13 from comment
  • @output 🏭 proposed_tasks from comment

---

• refine plan to include datdot-org components
  • @input 📦 datdot-ui project plan issue
  • study datdot.org website
    • @input 📦 datdot.org website from 🔮
  • study datdot.org wireframes
    • @input 📦 datdot-org wireframes from 🔮
  • propose additional task and subtask structure and wireframes for needed versioned ui components & repos for datdot-org
    • @output 📦 tasks_for_datdot.org-v0.0.1 from comment
  • refine datdot-org tasks for wireframes of proposed component structure
    • @input 📦 tasks_for_datdot.org-v0.0.1
    • include a web desktop component
    • include for that a software manager sub component
    • @output ❓ refined datdot-org project structure

---

• Create components from the tasks listed in the input doc
  • @input 🏭 proposed_tasks
  • Read feedback and provide input
  • Create tasks, update issue, record worklog and add contract
  • move all the components in to a single Figma file
  • @output 🏭 datdot-ui-components from comment

---

• create datdot project plan & wireframe component breakdown structure
  • discussion on the project plan & wireframe component breakdown structure
  • finalize datdot project tasks for all wireframes of proposed component structure
    • @input ❓ refined datdot-org project structure
    • @input ❓ refined datdot-ui project structure
    • include non-wireframe included components like demo-maker and the various console logging components
      • @input 📦 console inspiration from 🔮
    • combine all tasks and sub tasks into a single project hackmd structure
    • @output ❓ final datdot project task and subtask issues structure
    • next roadmapping #1

[Mehrabbruno]

tasks

• Create an issue to place all the task related to datdot-ui - 5min
  • @output 📦 datdot-ui project plan issue
• study datdot project videos to create project plan
  • study datdot intro script - 14min
  • study datdot intro video - 10min
• refine plan to include all datdot-ui components
  • study datdot-ui overview video - 9min
  • study datdot-ui component implementations video - 11min
  • study datdot-ui-wireframes video - 12min
  • propose task and subtask structure for repos of datdot-ui - 1h56min
  • @output 📦 tasks_for_current_component_repo-v0.0.1
• refine plan to include datdot-org components
  • propose additional task and subtask structure and wireframes for needed versioned ui components & repos for datdot-org - 3h8min
    • @output 📦 tasks_for_datdot.org-v0.0.1

---

feedback

I created two hackmd containing list of tasks. 1 for the repos on the github org and other one for the wireframe of the datdot.org.
another document is in progress where I am listing all the components for the apps.

All the components are mostly taken from the Adobe XD files. I couldn't seem to download any wallet or test it any way except for the adobe xd. So, I am using those files as a reference for now.

---

worklog

---

proposal

[serapath]

feedback 2022.11.23

I restructured the top level comment tasksand the adobe interactive prototype is really incomplete. We need also the old versions of every component, so this will be a lot of work, but the problem is that older versions contain specific features we did not model in detail in newer versions yet, because we were not thorough in the past in always starting with a duplication of the previous version to not miss any features we already modelled.

You need to download the documents and we need to find a way to thoroughly process ALL of the input documents.

BUT: You do not have to thoroughly process all the documents yet to create the task structure, but instead you can create tasks in your proposed plan that will then process specific input documents in detail when the time comes, so just maybe browse through to aproximately understand the content and what it is about so you can make tasks in that overall plan for later for when to actually go through.

If specific input document links are confusing or even worse you can't open them, let me know so i can explain them or help to be able to make it work so we can add them as inputs for specific sub tasks in the overall project plan we are creating now.

---

Please also double check if the adapted top level comment and your first worklog are still accurrate.

I will give additional feedback on the output documents you have created in the next feedback comment.

[serapath]

feedback 2022.11.23

i recorded a video and i can see how you must feel, so here is some feedback including about your hackmd's: https://share.vidyard.com/watch/XzoR7zVDUUKMHFefxbLxo9?

The old "issues" i am talking about can be found here.
The old pinned "roadmapping" issue tries to explain the old structure.
check https://github.com/datdotorg/datdot-ui/issues

I recommend you go through it slowly and take it easy and just record screencasts interviewing me or asking some questions.
If you feel having a live video call would help, we can schedule that too.

---

goal:
is to get a good understanding of the overall high-level structure of the datdot project and all apps and components and their history to define precisely how they relate in terms of dependents and dependencies in each component issue.

**please let's do this slowly, step by step to not get too stressed. 🤗

Any thoughts about task details and links to some of the many old assets and documents we already have can be linked to those issues, so we can process them later when we actually focus on an individual component.

You already wrote a lot of task details per component in the hackmd.
it is not wasted, but as just said - let's focus on that and process them when we focus on an actual component issue and focus on main inputs/outputs between component issues for now.

Sorry for not making that more clear - i definitely see how that must have been a lot of exhausting work.

[Mehrabbruno]

tasks

• discussion (read, study, restructure tasks) on the project plan & wireframe component breakdown structure 1h45m
• refine plan to include all datdot-ui components
  • propose task and subtask structure and wireframes for needed versioned ui components for datdot-ui - 1h37min
  • @output 📦 tasks_for_current_datdot-app-v0.0.1 from comment

---

worklog

worklog - 83
worklog - 84
worklog - 85

---

Feedback

hey, I address most of the stuffs on the videos. I may group the tasks in the main comment to approach each UI/wireframe separately. Currently they are all grouped under 1 task which is making it harder to read and edit in comment. Hope you are okay with that.

---

Proposed tasks

[serapath]

feedback 2022.11.24

I'm sorry that it is probably difficult with me. I will try to improve :-)

1. yes - you are right - i asked for only tasks, no input/output yet.
2. i was imagining we would only list tasks which are github issues and then sub tasks which link to their separate github issues - and no detailed tasks yet
3. i wasn't aware that some of the sub tasks are exactly that - you link to other main issues, but they are not visually indicating to do so, maybe they could be "bold"?
4. we probably now should alos add input/output to relate issues i guess.

---

Regarding next steps.
Yes, we need to identify all components in datdot-ui (which means datdot-app) which basically include what should be split into (datdot-wallet-app => user + apps tab) and (datdot-storage-network-app => plan + work/jobs tab). Also datdot-org has lots of components and is itself just yet another component.

Because those apps are made up of components, even though we have a few different main apps, they all potentially share some components and especially they do share components when it comes to basic components like input or button, etc...

Most importantly I hope we can identify all components and historic versions using the adobe wireframes and the PDFs and other assets we have, including the screenshots on old issues, to add all of it into one single big figma file with lots of pages.

Some of the old components might be deprecated and have susccessor components.
The goal is to try to capture the entire project and all it's history as well as possible.

importantly in each figma component version we would link and describe the link in the description section to know where this particular historic component came from.

That way, I can go through the figma and check all those links and compare it with all materials we have to see if we forgot something.

It is basically consolidation work
AND at the same time we "rehash" the entire project in all it's detail and can answer open questions and clarify things to get (again) familiar with every aspect of the project.

[serapath]

feedback 2022.11.24

The latest wireframes are most correct, but some features might be missing which were expressed in older wireframes.
The implemented components are the least authoritative - they only focus on general functionality, not at all on theme or style yet, which we will or should improve to make them look like in the wireframes.

---

Your 3 documents (hackmd's) are a great start.
The goal is to merge everything into one hackmd at some point and where possible make components re-use other components.
e.g. a button on datdot-org can re-use the output from the button repository or issue, which we will also use in datdot-app => or rather datdot-wallet-app and datdot-storage-networka-app, because that is how we split the current but old datdot-app into 2 apps instead.

---

I would recommend just continue the way you do.

1. Maybe start with the structure of the current versions (repos/datdot-org+datdot-app wireframes) so we have one component structure that covers everything.
2. Then we continue (before we do figma) to check out ALL old wireframes and versions to add missing components and/or add links to those older version documents to the issues for each latest component task, so when we translate things to figma, we know what historic versions existed.
3. when creating the actual figma file with all the pages and component versions, we take into account all that history and also link on each component version to the original documents that contain the original material of that component

[serapath]

feedback 2022.11.24

...

One thing about the PDFs:

We call them v0, v1, v2 .... v13, BUT you have to know that we did not create a strict system in the past like the one we have now with figma.

So the way you have to think about those "versions" is ... it is just "new work" the previous designer created.

1. sometimes it is a slight upgrade to the UI components of the previous version
2. sometimes it is a different part of a different app

All versions (=all PDF's) cover everything, but think about them as different incomplete hypothetical "snapshots" of "some parts" of a complete figma file with all versions of all components.

I think, we have to link each PDF as input to one or more tasks in the overall design components task structure, so when we come to a specific component task, we see ALL PDF's that show that specific component in different version and then translate that into Figma.
Then we go to the next component task and check all the PDFs that are related to that component and do the same thing.

** => Basically, when you go through the PDFs, the goal would be to decide under which of all the "Component Tasks" you made so far should have that PDF as an input.**

Once we have ALL OLD MATERIALS linked as inputs to the specific "tasks" you created and think everything is great.
We can then create the real github issues from your hackmds

Then we can start working on a figma file and going through all tasks and for each task designing component versions based on all the inputs.

When we finish all of that we can check if some dependencies/dependents relationships can be improved for all those component versions by going through them systematically.

[serapath]

feedback 2022.11.24

ALSO for old github issue discussions.
Just link those as "@input" to the component tasks you plan in your hackmd's where those are relevant and when we have all tasks prepared and start working on those tasks to create our single figma document and make all the pages one by one for each task the version controlled component designs, then ...we will have all the links to old documents and old github issues that talk about a component.

...and i would just say, take some time, lay back, relax, and work your way through those components and discussions, bit by bit ...and take notes to summarize what the details of those components where to then add the figma component version designs and any details can be added to the components description section.

IF there are too many details how a specific component works, then put those descriptive details into a hackmd and link it into the component design version's description section :-)

---

1. we won't implement/code historic versions
2. we don't make extra tasks, but have one component tasks with all the historic documents linked
3. we do need to have them designed in historic component design versions on our figma.

It is possible that a few components actually do not use any of the historic features, BUT, this is not how we worked back then.
Back then we on purpose worked in a way to leave out details in newer component designs that we already covered in older designs, so we could instead focus on parts that we have not yet designed in older version with the goal to one day put it all together ...but that day sadly never yet came.

Bear in mind - the crypto wallet UI is also special, because we are not designing a traditional crypto wallet, but something called a "data wallet" which works slightly different, so we can just e.g. copy metamask and call it a day sadly.

Lastly
Older designs have more design details, but to speed things up, we started simplifying the wireframes more and more to capture the essence and move faster and lose less time with "pretty designs" ...which doesnt mean that we want the newer versions to "look simpler"... it was just a technique to save time, but makes the historic components important to not lose what we already brainstormed and decided in the past sadly :/

[serapath]

feedback 2022.11.25

datdot app walk through
https://share.vidyard.com/watch/Sdaez4Vdk2PmPjokwur11F?
https://share.vidyard.com/watch/Yu4jQm4Gntyu7PxfgT37Ys?

[Mehrabbruno]

tasks

• study datdot-ui versioned pdfs

  • study datdot-app-wireframe-v0 - 2h35min
    • design figjam flowchart component - 40min
    • recorded video, updated top level comment (Task structure) - 35min
    • @output figjam_component_links_v0

• discussion (read, study, restructure tasks) on the project plan & wireframe component breakdown structure - 1h49m

---

worklog

worklog - 86

---

feedback

I suggest we layout the entire flow and connection between components and pages in Figjam. Once then it will be easier for us to pin point all the components at once, their links, version etc that then we can focus on 1 specific components and their version at a time. Scroll through HackMD doc mostly get a bit confusing or hard to read when there are more text.

---

proposal

Since I'm doing the FigJam while going through the pdfs we should start creating outputs for each version I cover.
Therefore I suggest restructuring the task. I updated it a bit but may update it later as well, so there is a proper link between out tasks and their outputs

[Mehrabbruno]

tasks

• study datdot-ui versioned pdfs
  • study datdot-app-wireframe-v1 - 3h1min
    • discussion on wireframe-v1 - 16min
    • @output figjam_component_links_v1
  • study datdot-app-wireframe-v2 - 1h20min
    • @output figjam_component_links_v2
    • record and upload video, update tasks etc - 20min

---

worklog

worklog - 87

---

feedback

---

proposal

[Mehrabbruno]

tasks

• study datdot-app-wireframe-v3 - 25min
  • compare wireframe-v3 to wireframe-v2
  • design figjam_component_links_v3
  • @output 📦 figjam_component_links_v3
• study datdot-app-wireframe-v4 - 46min
  • compare wireframe-v4 to wireframe-v3
  • design figjam_component_links_v4
  • @output 📦 figjam_component_links_v4
• study datdot-app-wireframe-v5 - 42min
  • compare wireframe-v5 to wireframe-v4
  • design figjam_component_links_v5
  • @output 📦 figjam_component_links_v5

---

feedback

• In wireframe_v3 there weren't any changes apart from the profile-side-navbar
• In wireframe_v4 there was a bottom navigation. Not sure if it is an update of the previous panel_navigation or something new for this panel

---

worklog

---

proposal

[serapath]

feedback 2022.12.02

feedback video 86

---

1. welcome screen component

you mention the button component, but no the rest.
When a user opens the app for the first time and have no account and no hosting plans or apps yet, the app is mostly blank/empty, so the idea is to maintain a "welcome splash screen component" to display and it might include text or even a little video to introduce first time users.

We haven't decided yet the details, but we definitely need a "datdot splash screen" component :-)

---

2. link to specific pdf pages

as you figured out, github is not showing all pdf pages directly
If you open a pdf (not embedded in github, but choose the raw pdf link)
e.g. try http://www.pdf995.com/samples/pdf.pdf#page=3

check how you can do it:
https://share.vidyard.com/watch/d1dZ4jG6c3MmmNM1fFsCEC?

you can use #page=X at the end of the pdf to make browsers (e.g. chrome) open that particular page of the pdf to link more specifically to components.

I think this is very valuable for component design versions to quickly check all the original sources and not searching through the pdf's where something came from exactly.

---

3. confusing dependency lines

makes sense when i select a line, but without selecting it, it is hard to tell what goes into what. all lines seem to connect into a grid that goes everywhere.

Maybe less neat but more direct lines would make it a bit more clear without the need to click select lines first?

---

4. actions

Ok, if it helps you try - my guess is that this could get very tricky and very messy quickly if we tried to express the interaction (UX) too, so try - but maybe it is good enough to just express which component uses which one without describing any transitions or interactions and so on...

I personally think that is adding even more lines to the document and although they have a different color it obfuscates the component dependencies, so please be careful to either skip that part for now so we do another document or somting maybe later when we have everything in version controlled figma component designs.

---

5. "progress bar"

This is not a progress bar.
It shows the utilization of your computer.

• 40% of disk space is filled with data unrelated to "storage network app"
• 20% of disk space is filled with data because you rent out disk space on "storage network app"
• the rest is still un-used disk space

...probably this can be expressed better and we changed it in later versions, but a pie chart would probably be worse in utilizing the available screen space.

**instead of progress bar i would call it stacked chart
...it's like a pie chart but as a vertical bar...

---

6. panel navigation component

This should probably called action menu component.
It is a single button to execute the default action.
it can be expanded to select a different action.
The available actions depend on the app context (e.g. which screen you are on)

It is not for navigation.
The circle with dots in is meant to show more and is not related to the "panel navigation component".

This is/was meant to be an action menu, but some of those actions might have been to show a specific extra view in the very beginning when we started it, but it is meant to be specifically about actions and not about navigation.

---

7. overview

This is a good approach, but as said above, maybe lines could be less grid like overlapping to make things even more clear.

I am compelled to add this kind of chart on one extra special figma page to show give an overview how all components relate and clicking on a specific component will jump to the component page and to that specific designed version of the component.

That "overview component" itself can also have or should have versions, every time a new component is introduced and/or the relations between components change, so in this way it is not different from other components.

We might even decide in the very end to make this "dependency tree" or "component dependency network" a real component and use it on a design system page for all components ...as a menu :-)

So, yes! I agree with your proposal shown below

BUT, please just call it a "component dependency network** component or something like that and treat it just like any other real component and make versions in the same style.
The lines or cards (maybe they are button cards) might be themselves a component or maybe we decide that this component has no dependencies and no dependents for now. One componeent version below the other, like for all other components.

Every iteration is using all the components we have and will make in figma :-)

---

[serapath]

feedback 2022.12.02

worklog video 87

---

pdfs in figma

I see you scrolling around to show e.g. the "filterable archive list screen or component.
It takes some time, so moving copies of those screens onto the same page you create for the v0.0.0 component design of that thing would show them all at once and additionally they would have a description that includes the links to the original pdfs to the exact page.

...

do you think it is possible move/copy those pdf screenshots into each specific component, v0.0.0 of course and make them "just regular figma version controlled components, with description and link to the original pdfs instead of creating a separate figma page where you just have all of them next to each other?

The "component dependency network" can still use or link to those

---

deprecation - password vs account component

👍 i love it. good idea to indicate deprecation like this :-)

BUT
The "create password" and "create account" both exist, even though it might not look like that, which is what i meant when i said some screens or components where not designed in future versions, but they are still relevant even though only included in old versions.

The way it works:

1. creating an account is creating a "seed/recovery phrase" for your keypair which never changes
2. ADDITIONALLY you define a password, which encrypts the seed phrase on your device
   • you have to type it into your app to unlock the seed phrase
   • you can change your password, but not your seed phrase
   • if you setup a new device and import your seed phrase, you have to set the password again
     • you can choose a different password if you want

So this is not replacing the password component.

---