Design - theme widget #24
Comments
tasks -
|
feedback -
|
tasks -
|
|
feedback regarding worklog 38The actions in the graph explorer are definitely better.
The "card file box" emoji 🗃️ is a good idea, but should not be part of the action menu. When it comes to save preference or inject or anything that works on multiple files.
Now on mobile you don't have CTRL or SHIFT, so there needs to be an action, Lastly, every entry in the tree that is currently open in the editor can also have a special any menu or action bar should be displayed BELOW the editor or explorer, not above
regarding theme widget feedback
Essentially, we would take all these component instances and:
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
We could edit that by doing some interaction inside the file explorer.
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. 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
They can all be linked back and forth. |
|
feedback feedback worklog 39Overall 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 So one would expect, that in the lower part of the image, you can see that 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.
By the way, every css file in the graph explorer should end with
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 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. 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. 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 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.
Isn't that like complicated and horrible UX? 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.
There can be a component type called "button" Especially because it isn't that easy.... So let's assume i make a separate css file for each of the above. 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.
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 :-)
|
tasks -
|
|
feedback I am okay with the 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 :-) |
tasks -
|
|
feedback
Basically, when on the folder icon to see where
in the graph explorer and have ALL deleted entries in there to either delete them for good (empty the trash) or restore them. The undo probably also needs a redo option.
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 actually, Clicking 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. also, maybe we could consider removing the 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 which i just made up to indicate which theme is currently selected and used by the app. 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. |
tasks -
|
|
feedback
But one thing is important, imagine you selected a super entry or an input or output. The bread crumbs navigation has only a simple regarding collapsing the graph exploreryou 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:
This is how vscode does it. Here you can see 2 tabs. ...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).
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:
This means the bottom bar has only the Other than that: Yes, being able to collapse the graph explorer with your button is cool. QUESTION: |
tasks -
|
|
feedback see discord |
tasks -
|
tasks -
|
|
feedback
If a user wants to expand the bread crumbs while the input field is contains text and is active, maybe the input field could move to be positioned above the bread crumbs like you have now. That is actually good. I just think showing it in the bread crumb bar, by collapsing the bread crumb bar into a small icon/text prompt while the input field is focused makes everything even more minimal.
And you could resize them or click an icon to switch between them (like tabs?) additionally, i do think we could maybe allow to expand the command history console only when the input field is already active, which means that expand button for the console could only become visible when the input field is focused, but hide when the input field is not focused ...maybe. Just trying to find a good UX that keeps things visually minimal ... hmm
If the command history was expanded as well, i would actually mostly expect that one to extend/expand the bread crumb input bar and also be below both, the graph explorer and editor tabs, which could be split 50/50 left on top of it.
In that case, the graph explorer left and editor tabs right 50/50 split on top of the bread crumb input & command history bar would make more sense. Also: the "doc box" should probably be full width on top of EVERYTHING, not just the editor. an alternative would be, that the "doc box" opens up a "markdown file" in an editor tab to describe exactly the element that was clicked. That way, every component could always "hard code" the help text (similar to our default theme) inside each component itself. It then populates the database and gets opened in an editor tab as help text when elements are clicked while the ❓ is active. Maybe that would be even better? In that case, it makes sense to open the "doc box" just as a regular editor tab with markdown content. The remaining wireframes make sense, but everything i already said applies to them as well. Now your proposed layouts (e.g. with the console on the side) might make sense too sometimes i guess, but then again, i don't think i would ever split the "command history" from the "command line" (=bread crumb input bar), so that command input field should always be below the command history imho. ...like a normal devtools console or a computer terminal. |
tasks -
|
|
feedback
One idea from above would be to use :wand: as an icon for the graph explorer root. (click to expand more)version 12🪄➖🌐playproject.io/
┠pins/
┃┌🌐playproject.io/
┠➖themes/
┃├🎨fantasy.json
┃├🎨electro.json
┃├🎨light.json
┃│┌themes/
┃└➖🎨night.json📍
┃ ├🔗page:css
┃ ├🔗page/header:css
┃ ├🔗page/header/menu:css
┃ │┌🎨night.json
┃ ├➖page/projects:css
┃ │├🖌️header.css
┃ │└🖌️1.css
┃ ├🔗page/footer:css
┃ └🔗page/footer/socials:css
┃┌🇹app
┃│ ┌🎨night.json
┗➖🗃🧩page
┠🧩theme_widget
┠🧩topnav
┠🧩header
┠➖🧩projects
┃│┌🇹itemcard
┃│├🧩projects
┃││ ┌➖🔗css
┃││ ││┌🔗night:page/header:css
┃││ ││├🔗light:page/header:css
┃││ │├➖🖌️header.css
┃││ │└🖌️1.css
┃││ ├🔗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}
│ 🔽 🔽 🔧rename📝
│ 🔧unlink🕳️
│ 🔧link📌
│ 🔧copy🖨️
│ 🔧delete❌
└🧩footer
version 13 🪄┱1[0]playproject.io/
┠[1]pins/
┃┌[0]playproject.io/
┠┼1[1]themes/
┃├[2]fantasy.json
┃├[2]electro.json
┃├[2]light.json
┃│┌[1]themes/
┃└┼1[2]night.json📍
┃ ├[3]page#css
┃ ├[3]page/header#css
┃ ├[3]page/header/menu#css
┃ │┌[2]night.json
┃ ├┼1[3]page/projects#css
┃ │├[4]header.css
┃ │└[4]1.css
┃ ├[3]page/footer#css
┃ └[3]page/footer/socials#css
┃┌[0]app
┃│ ┌[2]night.json
┗╅1┴2[5]page
┠[5]theme_widget
┠[5]topnav
┠[5]header
┠┬1[5]projects
┃│┌[0]itemcard
┃│├[5]projects
┃││ ┌┰1[3]css
┃││ ││┌[3]night#page/header#css
┃││ ││├[3]light#page/header#css
┃││ │├┴1[4]header.css
┃││ │└[4]1.css
┃││ ├[3]data
┃├┴1┴2[5]datdot
┃├[5]played
┃├[5]smartcontract_codes
┃├[5]wizardamigos
┃├[5]dat_ecosystem
┃└[5]data_shell
┠[5]supporters
┃┌[0]cardlist
┃├[5]page
┡╅1[5]our_contributors
│┃┌[0]itemcard
│┠┴1[5]Nina
│┠[5]Serapath
│┠[5]Jam
│┠[5]Mauve
│┠[5]Fiona
│┠[5]Toshi
│┠[5]Ailin
│┠[5]Kayla
│┠[5]Tommings
│┠[5]Santies
│┠[5]Pepe
│┠[5]Jannis
│┠[5]Nora
│┠[5]Mimi
│┠[5]Helenphina
│┠[5]Ali
│┃┌[0]itemcard
│┃│▽ △
│┡┷1┯2🛠[5]{Cypher}
││ ▽│△
││ ├[2]zip
││ └[2]zap
│└[5]Ibrar
└[5]footer
↪ │ [0]playproject.io > [1]themes > [2]night > [3]page/project > [4]header.css
once that is the case, the 🪄 just becomes the first icon for the first bread crumb and also the root icon in the graph explorer of course. |
tasks -
|
tasks -
|
@todo@input📦 theme_widget UX Improvement_discord messages@input📦 play project@output📦theme_widget-v0.0.0from comment@input📦 theme_widget UX Improvement_discord messages@input📦 play project@output📦theme_widget_tree-v0.0.0from comment@input📦 graph_explorer_component_discord messages@input📦 graph_explorer_widget_discussion_discord messages@output📦theme_widget_tree-v0.0.1from comment@input📦 graph_explorer_component_discord messages@input📦 graph_explorer_widget_discussion_discord messages@output📦theme_widget_tree-v0.0.2from comment@input📦 43-feedback & discussion_discord messages@input📦 worklog-Cypher_discord messages@input📦 graph explorer_discord messages@input📦 github_feedback@output📦breadcrumb_v0.0.0from comment@input📦 44-feedback & discussion_discord messages@output📦theme_widget_step by step_v0.0.0from comment@input📦 45-feedback & discussion_discord messages@output📦theme_widget_step by step_v0.0.1from comment@input📦 46-feedback & discussion_discord messages@input📦 githubfeedback-worklog-46@output📦theme_widget_step by step_v0.0.2from comment@input📦 47-feedback & discussion_discord messages@input📦 githubfeedback-worklog-47@output📦theme_widget_step by step_v0.0.3from comment@input📦 47-feedback & discussion_discord messages@input📦 githubfeedback-worklog-47@output📦 [theme_widget_step by step_v0.0.4](https://www.figma.com/proto/HlH2j2oNcrJjeP7qPrWX1g/Design-theme_widget?page-id=175%3A444&node-id=256-7200&node-type=frame&viewport=-1600%2C522%2C0.07&t=02yBx4HALVC3aELW-1&scaling=min-zoom&content-scaling=fixed commentThe text was updated successfully, but these errors were encountered: