Design - theme widget

[Mirabrar-21]

@todo

---

• Design Theme_widget
  • @input 📦 theme_widget UX Improvement_discord messages
  • @input 📦 play project
  • improved theme_widget UX and features
  • @output 📦 theme_widget-v0.0.0 from comment

---

• updated Theme_widget tree
  • @input 📦 theme_widget UX Improvement_discord messages
  • @input 📦 play project
  • improved theme_widget UX and features
  • @output 📦 theme_widget_tree-v0.0.0 from comment

---

• updated Theme_widget tree
  • @input 📦 graph_explorer_component_discord messages
  • @input 📦 graph_explorer_widget_discussion_discord messages
  • improved graph explorer tree
  • @output 📦 theme_widget_tree-v0.0.1 from comment

---

• updated Theme_widget tree
  • @input 📦 graph_explorer_component_discord messages
  • @input 📦 graph_explorer_widget_discussion_discord messages
  • improved graph explorer tree
  • @output 📦 theme_widget_tree-v0.0.2 from comment

---

• updated Theme_widget _breadcrumb
  • @input 📦 43-feedback & discussion_discord messages
  • @input 📦 worklog-Cypher_discord messages
  • @input 📦 graph explorer_discord messages
  • @input 📦 github_feedback
  • suggested UX ideas
  • @output 📦 breadcrumb_v0.0.0 from comment

---

• made Theme_widget _ wireframe examples
  • @input 📦 44-feedback & discussion_discord messages
  • suggested UX ideas
  • @output 📦 theme_widget_step by step_v0.0.0 from comment

---

• made Theme_widget _ wireframe structure
  • @input 📦 45-feedback & discussion_discord messages
  • suggested UX ideas
  • @output 📦 theme_widget_step by step_v0.0.1 from comment

---

• made Theme_widget _ wireframe structure
  • @input 📦 46-feedback & discussion_discord messages
  • @input 📦 githubfeedback-worklog-46
  • suggested UX ideas
  • @output 📦 theme_widget_step by step_v0.0.2 from comment

---

• made Theme_widget _ wireframe structure
  • @input 📦 47-feedback & discussion_discord messages
  • @input 📦 githubfeedback-worklog-47
  • suggested UX ideas
  • @output 📦 theme_widget_step by step_v0.0.3 from comment

---

• made Theme_widget _ wireframe structure
  • @input 📦 47-feedback & discussion_discord messages
  • @input 📦 githubfeedback-worklog-47
  • suggested UX ideas
  • @output 📦 theme_widget_step by step_v0.0.4comment

---

• made Theme_widget _ Terminal UI in figma
  • @input 📦 graph-explorer-feedback & discussion_discord messages
  • suggested UX ideas
  • @output 📦 theme_widget - Terminal UI-v0.0.1 comment

---

• made Theme_widget _ Hackmd slides
  • @input 📦 graph-explorer-feedback & discussion_discord messages
  • suggested UX ideas
  • @output 📦 Theme_widget comment

---

• made Theme_widget explanation video
  • @input 📦 theme_widget step by step v0.0.4
  • @input 📦 theme_widget step by step hackmd
  • Explained hackmd slides
  • @output 📦 theme_widget explantion video pt 1
  • @output 📦 theme_widget explantion video pt 2 comment

---

• made Theme_widget iteration
  • @input 📦 Github Worklog 49 feedback
  • @input 📦 Steps wizard & commands action bar- discord
  • Experimented new UX features
  • @output 📦 theme_widget step by step v0.0.5 comment

---

• updated Theme_widget iteration
  • @input 📦 Github Worklog 54 feedback
  • @input 📦 worklog-54 discord
  • Experimented new UX features
  • @output 📦 theme_widget step by step v0.0.6 comment

---

• Theme_widget Prototype
  • @input 📦 Github Worklog 55 feedback
  • @input 📦 worklog-55 discord
  • made theme_widget prototype
  • @output 📦 theme_widget step by step v0.0.7 comment

---

• Theme_widget Prototype with descriptions
  • @input 📦 Github Worklog 56 feedback
  • @input 📦 worklog-56 discord
  • made theme_widget prototype with description
  • @output 📦 theme_widget step by step v0.0.8 comment

---

• Made Theme_widget wireframe for mobile
  • @input 📦 worklog-58 discord
  • made theme_widget Mobile wireframes step by step
  • @output 📦 theme_widget step by step mobile v0.0.0 comment

---

• Updated Theme_widget wireframe for mobile (explanation version)
  • @input 📦 worklog-59 discord
  • made theme_widget Mobile wireframes step by step
  • @output 📦 `theme_widget step by step mobile example version comment

---

• MadeTheme_widget wireframe for mobile
  • @input 📦 worklog-60 discord
  • @input 📦 github worklog-60 feedback
  • • @input 📦 Graph explorer & state module
  • made theme_widget Mobile wireframes step by step
  • @output 📦 `theme_widget step by step mobile v0.0.1 comment

---

• MadeTheme_widget wireframe for mobile
  • @input 📦 worklog-61 discord
  • @input 📦 github worklog-60 feedback
  • made theme_widget Mobile wireframes step by step
  • @output 📦 `theme_widget step by step mobile v0.0.2 comment

---

• MadeTheme_widget wireframe for mobile
  • @input 📦 worklog-62 discord
  • @input 📦 github worklog-62 feedback
  • made theme_widget Mobile wireframes step by step
  • @output 📦 `theme_widget step by step mobile v0.0.3 comment

---

• MadeTheme_widget wireframe for mobile
  • @input 📦 worklog-63 discord
  • @input 📦 github worklog-63 feedback
  • made theme_widget Mobile wireframes step by step
  • @output 📦 `theme_widget step by step mobile v0.0.4 comment

---

• MadeTheme_widget graph explorer tree
  • @input 📦 Graph_explorer_version
  • made theme_widget graph explorer tree
  • @output 📦 `theme_widget tree v0.0.3 comment

---

• MadeTheme_widget wireframe for mobile
  • @input 📦 worklog-64 discord
  • @input 📦 github worklog-64 feedback
  • made theme_widget Mobile wireframes step by step
  • @output 📦 `theme_widget step by step mobile v0.0.5 comment

---

• Outlined the components structure of theme_widget componets
  • @input 📦 `theme_widget step by step mobile v0.0.5
  • Outlined the components structure of theme_widget componets in hackmd
  • @output 📦 Theme_widget outline comment

---

• theme_widget componets explanation videos
  • @input 📦 `theme_widget step by step mobile v0.0.5
  • recorded theme_widget componets explanation videos
  • @output 📦 `Theme_widget component_explanation comment

---

• Made theme_widget Graph explorer
  • @input 📦 `worklog-67 Discord
  • Made theme_widget Graph explorer structure
  • @output 📦 theme_widget tree v0.0.4 comment

---

• Made theme_widget Graph explorer
  • @input 📦 `worklog-68 Discord
  • Made theme_widget Graph explorer structure
  • @output 📦 theme_widget tree v0.0.5 comment

---

• Made theme_widget Graph explorer Explanation video
  • @input 📦 `worklog-29 Discord
  • Made theme_widget Graph explorer structure
  • @output 📦 graph explorer explanation part 2 comment

---

• Stepwizard componets explanation part 2 video
  • @input 📦 `theme_widget step by step mobile v0.0.5
  • recorded Stepwizard componets explanation part 2 video
  • @output 📦 ` Stepwizard component_explanation part 2 comment

---

• Stepwizard componets wireframes
  • @input 📦 Muhammad Azim Worklog - 3
  • Made stepwizard component Wireframes
  • @output 📦 ` theme_widget Explantion iteration v0.0.0 comment

[Mirabrar-21]

tasks - 2024.07.17

• created wireframe
  • created theme_widget wireframe -2h03min
  • gathered ideas about UX improvement - 2h23min
  • discussion -20min
  • recorded, updated task and worklog -17min
  • @output 📦 theme_widget-v0.0.0

---

worklog

Worklog-38
theme_widget feature improvement

---

feedback

---

proposal

[alyhxn]

feedback - 2024.07.18

Thanks for the feedback. You have discussed two points:

1. The same thing as we already discussed, besides the tick mark you are saying something else should indicate that changes are to be applied to multiple instances.
2. Dropdown to apply changes to one instance. I think we can already do this if I get you right.

Now for point one, I guess we can give a generic title such as Editor and between the title and tabs section we can have the tags sections where the selected instances can appear.

[Mirabrar-21]

tasks - 2024.07.25

• Added features
  • made a tree suggestion structure on discord -47min
  • created theme_widget_tree slides -1h57min
  • gathered ideas about UX improvement/action buttons - 3h52min
  • made a rough version of theme_widget editor features wireframe -37min
  • discussion -52min
  • recorded, updated task and worklog -16min
  • @output 📦 theme_widget_tree-v0.0.0

---

worklog

Worklog-39

---

feedback

---

proposal

[serapath]

feedback 2024.08.02

regarding worklog 38

The actions in the graph explorer are definitely better.
I'm still not happy about the "inject" and "save preferences" being part of the editor.
They should also somehow move to the tree imho.

This has to change a lot.

1. First - whether a css file is shared or unique depends on the relationship
   in the graph explorer. Either a css file is connected as a sub or super entry to multiple
   components or not. That is what makes it "unique" or "shared".
   Not an entry in an action menu.

2. What is the difference between import/export/save/load ?

3. What is "enter theme name"? Can't we just call it "rename" and when clicked,
   you would edit the name in the graph explorer similar to how you would maybe do it in VScode
   or any other "file explorer"?

4. What is "Default"? Can't we also solve this by assignment or connecting the right theme?
   To pin it or drag and drop it ot something like that?

The "card file box" emoji 🗃️ is a good idea, but should not be part of the action menu.
It should rather somehow be part of the graph explorer.
For every CSS file we should be able to collapse/expand to see all the themes and components
where it is used.

When it comes to save preference or inject or anything that works on multiple files.
Maybe what needs to be done is to first create a GROUP.
An "super entry" that takes multiple links to sub entries (e.g. like a folder),
and then you can trigger an action on that group (e.g. inject or save preferences).
That way, we never trigger anything on actual multiple items,
but we we trigger it on an entry that represents that group?

Regarding the checkbox, i think that should be done by clicking the NAME of an entry.
And CTRL or SHIFT clicking names allows to select one or multiple.

Now on mobile you don't have CTRL or SHIFT, so there needs to be an action,
to trigger those modes and that changes the behavior of the touch gesture,
to either select/unselect many or change selected icon on every click.

Lastly, every entry in the tree that is currently open in the editor can also have a special
color in the name or background or a border around the entry name,
so that it is indicated that those entries are currently open in the editor.

any menu or action bar should be displayed BELOW the editor or explorer, not above

• same with the file tabs of the editor, let's display them below.

---

regarding theme widget feedback

Here you share how multiple selected component instances and clicking inject should update all of them. While we need this feature, i would highly prefer if we change how this works.

Essentially, we would take all these component instances and:

• maybe drag'n'drop them
• or link them to another entry in the graph
• or link every single one of them one by one?
• or drag'n'drop a theme or css file group onto them?

I'm not 100% sure how we should do it, but the idea is, that we need in general a way to have one or multiple selected entries, and just like files, which can be cut & pasted or drag'n'dropped to move them into a new folder, we need a way to link them to a "theme" which itself is also an entry and if that is done and/or a theme selected, it is applied.

That is how we indirectly decide that something get's injected.

We basically have 3 types of entries we are dealing with here

• component instance entries (DOM nodes inside the HTML page)
• css files (one or many) stored somewhere and maybe visible in one part of the graph explorer as files and folders
• themes, which somehow define a mapping between a bunch of css files and a bunch of components, for now that's supposed to be json files, that specify which css file will be applied to which component.

We could edit that by doing some interaction inside the file explorer.

Here for example, the "shared" and "unique" tab are 2 different css files which are both associated with the component, e.g. Nina as an instance of a "profile card component" for example.

Now the thing is, for the Nina instance, it doesn't even matter if a css file is unique or shared. Both get applied to Nina.
This information is more interesting to see in the graph explorer to see all the css files associated with a specific instance (e.g. Nina) without all of them being opened in the editor and then to maybe inspect one of those css files in the graph explorer and see all the themes or other component instances where those css files are used.

lastly, usually one would probably also give css files a name rather than just naming all of them "unique" or "shared" :-)

Basically: The editor, when open, does NOT belong to any specific selected component or components. It just shows the content of one or more files (one or many tabs), each of which are linked to one (=unique) or many (=shared) component instances, but that linking can be defined AFTER a file is edited and saved.

We just have to have different types of entries in the graph explorer

• component instances, such as the DOM element that represents Nina
• and files, such as "project.css" or "profile.css" or whatever we call them.
• lastly we can also have a theme like "light.json" and others

They can all be linked back and forth.

[serapath]

feedback 2024.08.02

feedback worklog 39

Overall the graph explorer looks great, but of course, what needs refinement are the actions and the menu of actions and also the linking between component instances and themes and css files.

Here for example, in the upper part of the image, the light theme has contributor1 as a sub entry, which has header component as a sub entry.

So one would expect, that header component has contributor1 as a super entry, which in turn has light as a super entry, BUT

in the lower part of the image, you can see that header component has light as a super component, which has contributor1` as a sub component, which could mean, that "contributor1" and "header component" are siblings and both under "light", but that is not the case.

Either way, we have to somehow change this and improve it.

Here for example, the actions are great, but if we look at it on a mobile screen, a user would need to scroll to the right quite a bit.
Next, the specific kinds of actions need to be though through each individually and we might find better ways how to integrate them into the explorer and ideally we can even reduce the amount of actions, by presenting them as relationships in the graph explorer and defining how to link entries in the graph to each other, for example:

• select theme could just be a link between a component instance and a specific theme and defining a "sub" or "super" link between them.

By the way, every css file in the graph explorer should end with .css just so it is easier to identify them.

This one shows "default" and "dark" and can display many more saved ones like "rainbow" as well. To me this is an indicator we should probably just list them in the graph explorer as independent entries somewhere.
Next, you have actions (add, drop), which again, like any graph explorer entry that can have actions, if we made those themes into entries as well, they would be able to have actions.

All we need is a way to define new and change existing "sub" and "super" links between entries in the graph explorer.

I assume, any action in the tree would need an action to link a new sub or super entry or cut the link between an existing sub or super entry. I'm not sure how exactly it would best fit into the graph explorer, but let's figure it out :-)

---

Import is a confusing action to me.
If I want to Import a file, is that really depending on which entry is currently active?
The same with export, because for now, the IMPORT and EXPORT was meant to export all or import all in one file, so we have an easy way for a designer to use the theme widget, customize things the way they want and then export everything into a single downloadable file, which can be sent and submitted as a worklog and then the reviewer or anyone can open the website and import that file in their theme widget to see exactly the same changes.

If anything, i could imagine a specific existing or new theme, such as "rainbow" could have an export button to save only that theme and everything related as a single file.
On the other hand, the "import" action should probably be available when clicking the main "theme" folder.

In general, we should think more about which entry should have which actions available.

The RESET action should be a global action, maybe available under the root entry (playproject.io), because it just resets the entire storage.

The SAVE action should not be necessary, because every change is auto-saved in case your computer crashes, but of course, there should be a way to copy/fork/duplicate an existing css file or theme and give it a new name and then edit that to not change the original.
That might be a lot easier.

What we should consider though is redo/undo buttons or arrows to go back in history in case one typed something by mistake, because not having that would be bad if everything is automatically saved :-)

Of course - many "workflows" are possible, but we have to think about the pro's and con's to keep thing super convenient and minimal. All the above are suggestions, so if you feel strongly about something, please share, so we can discuss and fine the best solution.

---

The INJECT tool
Again, here, the "inject" tool, like any other actions, should be considers by us.
We are the experts. Let's assume we need to use this "theme widget" to do our work as "css designers" every day. Would you want to click an entry and select tool->inject to inject something? Would you also want a "un-inject" to undo such an injection?

How about clicking a css file and instead of "inject" calling it "activate/deactivate"? Would that be more intuitive?

What about linking or unlinking a file or theme as a "sub" or "super" entry of a component instance in the graph explorer?

Could the linking/unlinking be treated as a activate/deactivate (or inject/uninject)?

What would be the smoothest most convenient workflow to make this happen?

While something is linked (or active), wouldn't it be nice if changes show live automatically?

These are the things we need to consider.

---

So, you can rename a tab?
and then select something from the dropdown?
and then click save preference?

Isn't that like complicated and horrible UX?
I listened to your explanation, but every time i am still confused and have to think about what this is actually supposed to be doing. Do you find it convenient?

A normal file explorer would allow renaming in the file (or graph explorer) and maybe in the tab. But renaming is one action. save a file is another action.
What is "save preference"? is that the same as "save"?
And why do we need to mark it as unique or shared?

Maybe this indicates that there is something missing in the graph explorer?
A components VS. a component instance.
There is Cypher and datdot in the graph explorer - are they the same type of instances?
What type of instances are they?
Can i assign a css file to the instance and another css file to the type?
Is that what unique vs shared means?
Maybe we should just make the component type visible as an entry in the tree.

There can be a component type called "button"
And then there can be instances, such as "alert button" or "cancel button", etc...
All buttons look the same.
But some button instances look different.
We need some better support for that :-)

Especially because it isn't that easy....
There are styles/css that apply to every button, e.g. button { .... }
There are styles/css that apply to only a specific button, e.g. #cta_button { ... }
There are styles/css that apply to a group of specific buttons, e.g. .menu_button { ... }

So let's assume i make a separate css file for each of the above.
Or maybe a theme file as well, for each of the above.
I now want to assign a specific "button stylesheet" to all button instances
I want to assign a specific call to action stylesheet to one specific button instance only
But then i want to apply one specific stylesheet to all buttons in the menubar, but not to any other buttons in the page.

So the last option does not concern the actual css "class name", but more all button instances which are used by the menubar component.

---

The action bar at the bottom is not bar, but is it possible to have that bar below the file explorer? This might allow us to execute actions even if a file is not opened in the editor, but only selected. It would be a bit much to always have to open a file first before you can apply any actions to it.

We can definitely play with this option or even have both options available, just like our idea in the task messenger, where we have the "action wizard bar" at the bottom, but messages in the chat history can have "quick actions", which means here specific "graph explorer entries" could allow some quick actions as well.

So this is good, but it should happend below the editor.

Now still - the actions menu with the option visible here are still having the same issue as what i described above and we should think through which actions we need in what form first.

One option could be that it is a "traveling actionbar", which means it is always visible right below the currently selected graph explorer entry :-)

---

Here again, just like above - this tells us strongly that themes and css files should just be entries in the graph explorer as well and they allow actions such as load and delete and probably also rename and create new, etc... basically everything that a normal file explorer allows as well including copy/duplicate/fork so we can rename the copy and change it to create theme variations without overwriting the original theme.

[Mirabrar-21]

tasks - 2024.08.5

• updated tree explorer
  • made a tree suggestion structure on hackmd -2h16min
  • created tree on figma -3h10min
  • gathered ideas about UX improvement/action on tree - 4h13min
  • read feedback/gave feedback comments on hackmd and discord-1h53min
  • discussion -2h03min
  • recorded, updated task and worklog and hackmd-40min
  • @output 📦 theme_widget_tree-v0.0.1

---

worklog

Worklog-40

---

feedback

---

proposal

[serapath]

feedback 2024.08.13

I am okay with the + and - button for expand/collapse.
This should be themable, so we can use different icons in different apps where we use the component, but we can try these as defaults.

Otherwise it looks great.

I do think once we have all remaining features figured out, we need to create a very detailed and accurate interactive clickable prototype, so ali can see and make our real graph explorer work the same.

I would recommend to use the exact dataset we have in the playproject website for that interactive prototype :-)

[Mirabrar-21]

tasks - 2024.08.15

• updated tree explorer
  • made a tree suggestion structure on discord -27min
  • updated tree on figma -2h35min
  • gathered ideas about UX improvement/action on tree - 4h17min
  • read feedback/gave feedback comments on discord-32min
  • discussion -1h38min
  • recorded, updated task and worklog -18min
  • @output 📦 theme_widget_tree-v0.0.2

---

worklog

Worklog-41

---

feedback

---

proposal

[serapath]

feedback 2024.08.16

why is there a Night/Header.css super entry inside the (...) ...what is that good for?

Basically, when Header.css is linked, you can just click on the

  │     ││┌🗄️night.json:page/projects/datdot🔗
  │     ││├🗄️light.json:page/projects/datdot🔗
  │     │├📂[✨]◀🖼️header.css

on the folder icon to see where header.css is linked to.

First impression here is to rather have a

🗑️

in the graph explorer and have ALL deleted entries in there to either delete them for good (empty the trash) or restore them.
Seems more intuitive than having those kind of listed as a dropup in a bottom menu bar.
What we need though is something like Header.css<--light or datdot-->Header.css, because most of the time we are deleting links and not entries. The entries might still be all there, but a specific link was deleted and we want to restore it

The undo probably also needs a redo option.
I do think, just like browsers, it would make sense to have < and > arrows in the bottom bar for that. That's how browsers do it

This is your other example.
So if Restore becomes a trash bin
And Edit can be removed as you said it can
Then only Undo remains and we add a Redo and turn both into < and > icons like browsers do it.

Users still have the ❓ to get documentation/help for any element in the app to learn those buttons mean undo/redo if they cant find it out by clicking them :slight_smile:

So the idea is to have some sort of user data structure, which always starts with

📚➖[✨]◀🌐playproject.io
  │  └🔃reset
  ├📁📌▶pins/
  │┌🌐playproject.io🔗
  ├📂📂▶📗themes
  │  ├📁📁▶🎨rainbow.json
  │  ├📁📁▶🎨fantasy.json
  │  ├📁📁▶🎨electro.json
  │  ├📁📁▶🎨light.json
  │  │┌📗themes🔗
  │  └📂📂▶🎨night.json📍
  │     ├🗄️🖇page
  │     ├🗄️🖇page/header
  │     ├🗄️🖇page/header/menu
  │     ├🗄️🖇page/projects
  │     ├🗃️🖇page/projects/datdot
  │     ││┌🗄️night.json:page/projects/datdot🔗
  │     ││├🗄️light.json:page/projects/datdot🔗
  │     │├📂▶🖼️header.css
  │     │└📁▶🖼️1
  │     ├🗄️🖇page/footer
  │     └🗄️🖇page/footer/socials
  │┌➕➕▶🇹app
  ││    ┌🗃️css
  └➖➖[📥🪄]◀🧩page
     │       👇
     ├➕➕[📦✨]◀🧩theme_widget
     │       ├📝rename
     │       ├🕳️unlink
     │       ├📌link[➕➕📦📦🆕]        // link as: [➕super/➕sub/📦input/📦output/🆕new]
     │       ├🖨️copy[➕➕📦📦🆕]        // copy to: [➕super/➕sub/📦input/📦output/🆕new]
     │       └❌delete
     ├➕➕▶🧩topnav
     ├➕➕▶🧩header
     ├➕➖▶🧩projects
     │  │┌➕➕▶🇹itemcard
     │  │├▶🧩projects🔗
     │  ││  ┌🗃️css
     │  ││  ││┌🗄️night.json:page/projects/datdot
     │  ││  ││├🗄️light.json:page/projects/datdot
     │  ││  │├📂▶🖼️header.css🔗
     │  ││  │└📂▶🖼️1🔗
     │  ││  ├🗄️data
     │  ├➖[📥🪄]◀🧩datdot
     │  ├➕▶🧩played
     │  ├➕▶🧩smartcontract_codes
     │  ├➕▶🧩wizardamigos
     │  ├➕▶🧩dat_ecosystem
     │  └➕▶🧩data_shell
     ├➕➕▶🧩supporters
     │┌🧩page🔗
     ├➖➖▶🧩our_contributors
     │  │┌➕➕▶🇹itemcard
     │  ├➖▶🧩Nina
     │  ├➕▶🧩Serapath
     │  ├➕▶🧩Jam
     │  ├➕▶🧩Mauve
     │  ├➕▶🧩Fiona
     │  ├➕▶🧩Toshi
     │  ├➕▶🧩Ailin
     │  ├➕▶🧩Kayla
     │  ├➕▶🧩Tommings
     │  ├➕▶🧩Santies
     │  ├➕▶🧩Pepe
     │  ├➕▶🧩Jannis
     │  ├➕▶🧩Nora
     │  ├➕▶🧩Mimi
     │  ├➕▶🧩Helenphina
     │  ├➕▶🧩ali
     │  ├➕▶🧩Ibrar
     │  └➕▶🧩Cypher
     └➕➕▶🧩footer

actually, duplicate could maybe be renamed to copy, but when you click it, it works like link ...so basically just like the options for "link" it would give you those for "copy" but instead of linking, it would be copying.

Clicking link toggles/selects [link] and allows to press other entries in the graph explorer to create a link to those and when done, just click [link] again to turn it into link again
Clicking copy toggles/selects [copy] and allows to press other entries in the graph explorer to create a copy to those and when done, just click [copy] again to turn it into copy again

By clicking the right icon type behind copy/link you can select as what you copy/or link it, e.g. super/sub/input/output/...

Does that make sense?

There are probably many other variations possible. We can discuss :slight_smile:

Also, if you e.g. link an entry under pins/ folder, you basically get "pin" already, so maybe no need to have a separate action "pin" ...it's just link :slight_smile:

also, maybe we could consider removing the ▶icon and instead expanding/collapsing the actions when a user clicks on the "entry icon", e.g.

🖼️ or 🇹 or 🧩 or 🎨 or 📗 or 🌐 or 📌

is what we have for now. That wouls save us an additional icon per entry to make things more concise

Another thing we haven't talked about yet is the

📍 (1.)

which i just made up to indicate which theme is currently selected and used by the app.
It wasn't supposed to be the same as

📌 (2.)

which i added above as a folder icon to link entries to, so they can be accessed quickly. bookmarks basically.

The behavior of the (1.) is interesting, because selecting a different theme should probably be an action only available for themes.
When they are selected, the theme json file contains the names/id's of all component instances and which css files they use and it updates the linking inside the entire app tree to use the new theme. It's almost like automating the work of manually going to every single instance in the app and unlinking/linking new inputs to them i guess.

[Mirabrar-21]

tasks - 2024.08.22

• updated theme_widget
  • updated theme_widget on figma -1h03min
  • UX suggestion prototype -23min
  • gathered ideas about UX improvement/action on tree - 3h20min
  • read feedback/gave feedback comments on discord-13min
  • discussion -30min
  • recorded, updated task and worklog -16min
  • @output 📦 theme_widget-v0.0.1

---

worklog

Worklog-43

---

feedback

---

proposal

[serapath]

feedback 2024.08.24

this is great. we should keep that.

But one thing is important, imagine you selected a super entry or an input or output. The bread crumbs navigation has only a simple > to indicate the next level, but it does not show whether that is e.g. a "sub entry" or an "output".
So maybe we need something more here precise here?

---

regarding collapsing the graph explorer

you say while working on file content you might want to close or collapse the "graph explorer". I do agree.

I had some additional thoughts on that while looking at the editor menu bar:

1. if you click any of the tabs, it might show the graph explorer with that entry in focus
2. if you click another tab, it shows that graph explorer in focus
3. if you click on the + it shows a graph explorer with nothign selected and an empty editor which updates while you click around in the graph explorer.
4. clicking around the graph explorer of one tab is updating the editor only when you click the "name" of an entry
5. another option is in an existing tab's graph explorer, to click the "open" action, which is similar to the plus in the editor tab bar, but it shows the content of the entry that was opened and that entry in now also selected in the graph explorer of that new tab.

This is how vscode does it.

Here you can see 2 tabs.
There is a breadcrumb bar right below the tabs bar that shows the path of the selected tab.
Inside that bread crumbs path you can select and get an entire expandable file explorer

...or in our case the graph explorer should change the selection to the current tab's content and potentially update it if we select something else in the graph explorer.

The bread crumbs bar in our case is always below (not above).

Now seeing your trash can as well and the history of actions that happened with the option to "undo" or "forget" seems like a history of actions... we have actions always leave a mark in the "task messenger', also when it is not a text message.

1. Additionally, the "bread crumbs" bar shows the current location, but clicking into it, might turn it into an input field with the entire link to the current location visible so you can edit it with the keyboard instead of clicking the bread crumbs.
2. When you change it and hit enter, you essentially executed a "NAVIGATION ACTION" to update the graph explorer and maybe editor content.
3. So you could technically have a history of navigation actions just like you have those delete or unlink actions in the trash can... but if we do have that, then why not have ONE HISTORY of delete, unlink and navigation actions?

So it might make sense to just have a console or log history of all navigation actions.

The current content of the bread crumb bar is just the current preparation for the next navigation or other action.

So it would make sense to EXPAND that breadcrumb bar into a console to show also the history of former navigations and other actions.

IDEA:

• we could integrate he undo/redo actions into that expanded history list to even jump back to a specific point in time
• the trash can can be removed because we have that log history of all navigation and unlink and other actions now

This means the bottom bar has only the ? now
Maybe we can put that as the first icon in the bread crumb bar to save space. Its not part of the bread crumb bar but they could go into one line.

Other than that:

Yes, being able to collapse the graph explorer with your button is cool.
Just like we can also additionaly expand the bread crumb bar into the history console and collapse it back into the bread crumb bar.

QUESTION:
If the graph explorer is collapsed, but we edit content of a css file, can we record those changes in the history console as well to potentially undo them?

[Mirabrar-21]

tasks - 2024.08.27

• updated theme_widget_breadcrumb
  • updated theme_widget_breadcrumb on figma -2h23min
  • UX suggested tree structures on figma -50min
  • gathered ideas about UX improvement/action on tree - 4h32min
  • read feedback/gave feedback comments on discord-17min
  • discussion -2h26min
  • recorded, updated task and worklog -11min
  • @output 📦 theme_widget_breadcrumb

---

worklog

Worklog-44

---

feedback

---

proposal

[serapath]

feedback 2024.08.28

see discord

[Mirabrar-21]

tasks - 2024.08.28

• made Theme_widget wireframes
  • made Theme_widget wireframes step by steps navigation on figma -1h58min
  • prototype -18min
  • gathered ideas about UX improvement - 1h11min
  • discussion -14min
  • recorded, updated task and worklog -15min
  • @output 📦 theme_widget_step by step

---

worklog

Worklog-45

---

feedback

---

proposal

[Mirabrar-21]

tasks - 2024.08.31

• made Theme_widget wireframes
  • made Theme_widget wireframes step by steps navigation on figma -5h35min
  • made a structure suggestion on figma also protoyped -51min
  • prototype -50min
  • gathered ideas about UX improvement - 2h12min
  • discussion -47min
  • recorded, updated task and worklog -18min
  • @output 📦 theme_widget_step by step_v0.0.1

---

worklog

Worklog-46
structure prototype

---

feedback

---

proposal