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 -
|
tasks -
|
tasks -
|
tasks -
|
|
feedback worklog-47 #24 (comment)remaining feedback worklog 47In worklog 47 you share there is a problem with the command list In worklog 47 you talk about he command history and compare it to devtools and how there is a button to select icons. This is all a perfect idea and it should exactly work like this, but i dont think we need that special "select icon", because if the command history is expanded and you click a different bread crumb or entry in the graph explorer, the command history will automatically adapt its view to it. create theme suggestion feedback
So in the case above, you need multiple form inputs to really specify what will happen
So as a "steps wizard" in the datdot sense, this action wiard should have 2 steps before completing/submitting the form and trigger the action execution. Lastly, the "PREVIEW" should be seperate from the wizard and should get updated with each completed wizard step. Maybe the first step should be to select theme content and the second one to select a name. One thing to notice: But yes - if an action or command requires to get files, then that is something that should happen in In the context shown above, you would probably have a step to first select the "mode"
There should be a fine scroll bar (just like vscode editor tabs bar does it) to indicate that worklog-48 #24 (comment)
The icon not, but at least the text is shown correctly in a later version in the worklog: It was good, that in the bread crumbs, the 1.css had a slightly different focus highlight color.
Let me know, but i thought no matter which Especially later in the worklog you show both at once: What i can imagine or see is yet another icon next to e.g.
Now what this also suggest is, that when the editor is collapsed, we might still want to be able to see and switch or re-open any "open file", such as any of the tabs below the tabbed editor, thus, while an editor should be collapsible, maybe the tabs bar should still be visible. In fact, each tab, when you click it (lets assume they are different and not all just editor tabs for
AGAIN - here you mention a problem with the
And what if we toggle ...overall, questions over questions. Whats you take on this? Given that, i kind spontaneously feel like maybe the special extra "doc box" on top of the entire app was better? ...hmm - just brainstorming still. Also - a bit "meta", but i just had another thought about this:
Also navigation wise thats true:
|
|
feedback worklog-49 #24 (comment)
But beyond that, i think we have to take a moment to think about all the things we need to do.
|
|
feedback worklog-50 #24 (comment)It looks okay. I do think what matters for the terminal version is to actually draw the UI Another important aspect of the terminal UI is to define one that works by entering commands. To explain what i mean:
Regardless, you can type git commands in a terminal to update a git repository. So if all you had were command line commands, how would you "see" or "change" the things I think that should be the task for maybe ali and/or ahmed. Once we have the "web version", we will then try to translate it into a terminal UI as well. So please continue with this style, but now lets do it for the web again :-)
We should work on a general "wizard steps" component, where each action or command, such as "new theme" can define its own set of data requirements, which will then show one or more steps in a step wizard to prompt the user to use the different input widgets to provide the requested data :-) Next to datdot steps wizard, we can also additionaly take inspiration from discord Basically, just think that this kind of "new theme" feature example would work for ANY action and the input prompts can be customized based on actions, but they all have in common, that they will prompt the user to collect data needed to execute the action. Users need to be able to cancel, confirm, got back and forth, see a preview, etc... when filling out the form step by step before finally submitting to execute or abort the command. Basically: The input field in the command bar is probably not the right place for the various possible input widgets, because not all of them would fit in there. Finally, building up a preview before submitting the action would be good as well, to show somehow what kind of new data entry ot action and effect we are creating by filling out the form. Technically, if there are different alternative options in a step wizard, then "next steps" could depend on filling out a "previous step". Thats entirely possible :-)
As you say in the end - a "change theme" command is yet another possible command we can then design :-) ...not just that, there can be many more commands to help do stuff. Maybe at some point people can install/uninstall those kind of commands with their corresponding steps wizards or even program commands themselves and publish them for others to install those... we'll see. For now we just create the basics to later allow such things. command history
command list
high contrast themeAt last you quickly show the alternative theme with the orange. |
|
feedback worklog-51 #24 (comment)The hackmd slides look great.
Kinda like this... You also had already versions with that desinged, like here: Anyway, generally, the good part here is, that because options are so limited, it helps us to keep things basic, but as mentioned in the last feedback.
So no need to type in /history or whatever.
The problem here is that it is hard to show boxes side by side, so instead, it is better Basically what can be seen here:
Again, repeating feedback from worklog 47 or 48.
It also makes me think, that we might NOT create a full blown terminal UI with tiling boxes and all the stuff we designed for the web UI.
Thats it. various other things
Or maybe we only have the 🪄 in front and then all other icons in the end like we had it here: Maybe this has to be considerd in combination with the "tabs bar" and my feedback regarding that and also the difference between a long bottom bar like on desktop and a short one, like on mobile.
Once we have everything finalized, we can also make a "pretty" theme or multiple :-) |
|
feedback I checked your explanation videos you made for ahmed. I guess we will just need to wait for a new figma iteration that includes all the feedback from worklogs 47-51 :-) |
tasks -
|
|
feedback Perfect. Shared all feedback on discord. You can then at some point also review ahmeds worklog to give him feedback :-) |
@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.4comment@input📦 graph-explorer-feedback & discussion_discord messages@output📦theme_widget - Terminal UI-v0.0.1comment@input📦 graph-explorer-feedback & discussion_discord messages@output📦Theme_widgetcomment@input📦 theme_widget step by step v0.0.4@input📦 theme_widget step by step hackmd@output📦theme_widget explantion video pt 1@output📦theme_widget explantion video pt 2comment@input📦 Github Worklog 49 feedback@input📦 Steps wizard & commands action bar- discord@output📦theme_widget step by step v0.0.5commentThe text was updated successfully, but these errors were encountered: