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 :-) |
tasks -
|
|
feedback 2025.01.26` Checked your wireframes first and they look really good. Awesome :-) I will list a few things that maybe still needs improvement, but otherwise, lets get to the prototype and also lets make each component with all the responsive modes it can be in as
So here some more feedback:
You also asked for "pinning" vs. "radio button" when editing bread crumbs. Otherwise i think its great. Missing things:
I guess what we need next is the interactive prototype and each component as figma controlled versioned component to have exact instructions for ahmed. |
tasks -
|
|
feedback Noticed:
We can discuss the above on discord as well if you have concerns or questions or additional ideas. |
tasks -
|
tasks -
|
|
feedback Sweet. Looks really good. Here are some things i noticed will going through:
Additionally, the Next, if clicking the "moon", it would switch back to the bread crumbs but also expand the graph explorer and then turn the bread crumbs into an editable path while the graph explorer is expanded and a changed path can be confirmed or a user can cancel the bread crumbs path edit via the So somehow the wireframes dont look like they get this right. Now what would make sense (even though it still has the missing autocomplete command list, is, if the bread crumbs path is just like a "background placeholder text" for the command input field, so a user again gets reminded where exactly the chosen command will be executed, but then maybe the path should be a bit more grey and less contrast to make it feel more as a "background" I'm a bit confused, because the last worklog took quite a few hours, which maybe is normal, but then i wonder why wasnt it clear? I kinda had a feeling the above was discussed and expressed and understood, but maybe a misunderstanding. let's try to ask/clarify to avoid things like that in the future :-)
Actually, once the quick action or right command from the command list has been selected, the input field bar (which should probably be on the bottom) can turn into and have the name of that command and right above is will be the steps wizard bar with all the steps needed to complete the action. ...so while the current command has been locked in, the cancel( the confirm( Also, not to forget the "tabs bar", which i havent seen yet at this point :-) Now consider this: if i am on a specific tab which runs a specific breadcrumb path file with an app like the editor and displays it and i now go and start an ection from the command list and are half way through the "steps wizard", but then i get an important notification, indicated in another tab (just like tabs or messenger rooms sometimes indicate that there is something important), so i switcH tab to that other important tab and do something there first and then later i switch back to the tab i came from to complete the "steps wizard" ... That half finished steps wizard or status so to speak, should somehow be indicated in tabs, just like notificatoins should :-) ...it doesnt mean that every tab and every program will actually use notificatoins, but they could if that makes sense. So given that, it feels to me the "tab" bar should be at the very bottom, which gives us some freedom in terms of positioning the ❔ and/or the 🐿 because they could be next to the "command bar", but with bread crumbs and all the things it is already crowded, so maybe we should carve out some space left and right from the tabs bar for those instead? Now this is mainly for the mobile proposal. On a tablet or desktop size, this bar can become one bar with tabs/command bar/icons/etc... all next to each other.
Here you show the desktop version, which is fine, but you say clicking the "TAB" will create the "input field", which should not be the case
ADDITIONAL IDEA:
mobileOne thing i remembered or noticed is, that
This means we have more than one way to toggle expand/collapse tab content, e.g. editor. if you have suggestoins, please let me know :-) Furthermore:
So the user has a faster idea where they are. And again, same as for the tablet/desktop UI, the bread crumbs ahouls only become editable while the graph explorer is open, basically after togge clicking the "icon" of a bread crumb entry. Also a quick comment on this. In this screen you can see a
So lets try to make things so developers can derive how components work by checking the wireframes :-)
...but in your screen, the graph is not editable and you cant confirm/cancel anything, so kinda the wrong way around it feels to me :-) I like it. This is good. Now the bars at the bottom is what i mentioned earlier and feels "the wrong way around":
So from overview towards more detailes, where overview is the bottom bar and details are shown towards the top, the direction of the bars should be flipped.
ALSO - if the tabs bar is the bottom bar, we should always keep in mind that the In fact, we could even consider adding the Now if we - instead of selecting a running programm in the graph explorer, we select a file to spawn a new program, then it is added as a tab and to the list of tabs (which is at the same time listed in the graph explorer as running programs. Hope that makes sense - if it doesnt, lets discuss. HA - at minute You say, it is nice that it "connects with the editor".
The reasoning is, that while a user is selecting a tab from the tabs bar at the bottom, its okay to temporarily hide all tabs and action bars until the process is completed or canceled, because focusing a specific tab is a prerequisite for doing anything else in e.g. the actionbar or program or whatever...
My suggestion would be, that - given what was said above - by moving the tabs bar to the bottom and the question mark with it, we wont have the question mark anymore in the "action bar", so we could add an Whichever tab is selected from the tabs bar would "disappear" from the tabs bar and instead be shown as the action bar (closable via THe command input with command list autocomplete is instead entered when pressing the |
tasks -
|
|
feedback
Which also means, there needs to be a In this case, it shows the actionbar in command input mode with command list expanded for Otherwise, it seems correct :-)
This is fine, but it is confusing that:
Lastly, while what you show could be an option, i imagined canceling the initial "command input" field would show the "quick actions" and a user would need to click e.g. the magic wand to switch to breadcrumbs, but maybe the way you chose to do it is fine as well - if you think this is good, we can keep it and wait until we have it implemented to see what is more useful in practice.
Basically it is great - just the
Generally, i think we should show all "pinned" quick actions to the point where a use can scroll or slide - up to them. The "theme/" input field button can shrink further and further until just a small icon sized circle is left.
QUESTION:
You tell me your thoughts, but if wha ti described is how it works, it seems overkill to have 2 slightly different ways back to "bread crumbs", because we have limited space and having 2 icons reserved to do almost exactly the same is not worth it imho - it should be either or i think. ... Here you say when canceling the command input, which was entered by clicking the command input in the quick actions, it wouldnt go back to the quick actions, but it would go back to the bread crumbs? ...i find that confusing as well. If you think thats good, maybe there are advantages to it as well, but in my mind i thought of it as:
Maybe there are even better ways to structure this to make it as intuitive or logical as possible, but yeah - let me know.
Thus - it would have been better to open the graph explorer with
So there are vscode plugins (vscode is one of the most popular code editors) and it has a little file explorer to choose source code files to open them in the editor. You can create files and folders and expand/collapse folders similar to how your graph explorer wireframe currently looks. Now using that "search/find" plugins, it allows you to "FILTER" through the entire filesystem, which means - as a user types into the search/find field and it auto highlights all files/folders which do contain the typed pathway and also auto-expands collapsed folders temporarily, but shows and highlights only those sub folders and files which are matching and not everything (the highlight is different from the current still selected entry), and those folders are not really fully expanded, but only "pseudo expanded" to show any search query matches. If the user then finally selects one of those highlighted matches as the new entry, the selected file gets shown. In our case though, it would be the "graph explorer" and when the user selects a new entry, it would collapse the graph explorer or of course the user could cancel the search/find/select process to not change the pathway. IMPORTANT: Seeing this and thinking of the tabs bar and having at least one tab or later more. Similar to how you can have a image file on disk and you can open it in parallel in 3 image editing programs or some programs even allow you to open multiple times the same image independently. Only the Now we will have split screens for e.g. At most you could have
And then you can click on the tabs to switch back and forth between those programs - but thats different from a steps wizard to change the pathway for a particular running tab (also known as "program" or "app") ...basically each tab runs an app, such as a "text editor" :-) ...hope that makes sense. If not, lets discuss. Ha, finally. So in the picture above, clicking the
Imagine:
That would not make any sense. A running program is not a file you can open with an image editor. It is kinda ridiculous to even say it, but that is what it would mean to go to a tab which represents a running "text editor" with a file "night.json" opened and then edit the filepath and select "1:night.json" which would represent not the night.json file, but another running open program in another tab that you would want to open as a file... it doesnt make sense and it unclear what is even supposed to happen as a result... So hope that clarifies the reasons for all of the above. MORE: You also talk about every entry made from This means the path is not Instead - they are both independent entries in the graph explorer with different pathways.
The pin bookmark links to the "night.json" file and because our graph explorer is supposed to model inputs/outputs, there is some sort of connection, butthat is extra data we will visualize, but its not directly part of the regular file and folder paths. Most likely i imagine we will have something like:
Those are some sort of special files or folders ...not really files or folders, because we make a graph explorer and not a normal file explorer for that reason, and inside e.g. **ALSO: inside of All our running tabs or in the future paused/hibernated tabs have such an entry and we could use our extra graph explorer feature to expand/visualize those input/output connections between files and programs in the graph explorer too.
So there are 2 tabs in the image and both run an independent editor or maybe the second tab is possibly running a different program, maybe that "jsonviewer". Pressing the yes, pretty good. And the command name bar (especially when thhere are dozens of wizard steps) would also serve as an overall progress indicator. Also in this picture the bottom "tabs" disappeared, but they are important, because the active tab will still give the information what tab (=program) we are executing that command for. e.g. ...the button for tab switching or adding new tabs. Here you say clicking an entry (e.g. night.json) would open new tabs. The point was that while thats kinda correct for the Now where do we show THE END :PJust kidding. |
tasks -
|
|
feedback command input
On the other hand, sometimes "less is more", thus we could also just remove stuff that we dont need, maybe no text and icon in that input field to make the UI/UX cleaner?
One thing i notices though is that you did not add anything like the "show desktop" vertical line some windows have, which you can click with the mouse or probably on mobile you would need to tap and swipe to "drag" it or indicate that you didnt want to click an icon like the wizard hat or the question mark, but you meant to use that "show desktop" indicator to collapse the task menu bar and everything?
For example - the steps wizard could totally allow a user to select more than one input file and even show a list to add/remove input files :-) ...much more flexible concept imho.
Basically, it should NOT be a "search icon", it should not have an icon at all, but rather just a very tiny short input field barely larger than an icon that can expand when clicked.
I kinda thought or hoped we can better re-use that from previous wireframes where you already did these things in parts :-) SWITCHING PROGRAMSActually switching program is different, because all actions that are available do not depend on the input files, but they depend on the program. So if we keep it the way you show it here, the separation should be stronger than just a
So is the program switching happening when:
If we can already do it in either of those ways, then it doesnt make sense to first click the "input field button" to focus and expand it and show the command list ...to then also show the program switcher icon. The user could already do that earlier or after they collapse the focused inputfield using
Even if a "one step wizard" is simplified, whats the action/step called? MAINLY BECAUSE: I cant know if a UI element is still there because you just didnt yet update that part or it is there because it is an actual proposal to keep it that way. So basically, above, the flow to enter the step wizard did not start by choosing a quick action: "change path" or "edit inputs" or whatever...
In a way that is probalby part of designing the graph explorer in more detail, but we also need to do it, because we want ali and ahmed to implement stuff and they will only be able to if they can rely on every detail shown in the wireframes - so lets delay less of it and wireframe more and then copy the parts that are correct over to the next wireframe to really try to get everything completed in detail. It also means, "pinning" and "default" might be options to be able to select in the graph or these could also be yet other "quick actions", because one thing to keep in mind is: The "graph explorer" is a program.
Imho, this should show the quick action bar again, so a user can click "edit inputs" or choose it from the command list after clicking the inputs field button to focus and expand the command input field. If a user wants to know what files are currently selected as input, there could either be another action called "list inputs", or they would click "edit inputs" to see all selected files highlighted and then cancel the action. Great, but also slightly confusing, because "tabs" and "running programs" should be the same.
In the current displayed way we dont know what program they use, but probably "text editor". Also, again, the entries listed under tabs, the
So i think we need to merge "running programs" with "tabs". Here are words AI suggests: In Linux the running programs are called "procs". We could also call them "Apps" or "Tasks".
So, in a way, we can also keep "programs" for source codes, and for active running program tabs we only have the root program, which has a name, e.g. "theme widget" and from there on, its all sub programs ...there cant be more than one root program! ...so having a category might be overkill, because the category would alway only have a single entry, the root program, and all other tabs etc... will be sub programs of that program Here the bottom bars are very confusing
Now this kinda turning the tabs bar temporarily into an input field would make sense to me if that happens by using the "jump" button, and thinking of the "jump" button as the command input for the theme widget itself, where the tabs bar itself is the tab of the "theme widget" ..and all other programs have tabs in it
...but the way it shows here its confusing. So maybe that is what you meant, but you didnt really say explicitly that the "jump" button was pressed to get to this view. To me, the "jump button" represents in a way the "theme widget tab" itself. IF it was meant as jump button drop up menu thought, then clicking on any running program would focus it:
...does that make sense?
Now what is missing is, that the field that mentions the action, e.g. We last time said it should show progress as well for steps, including in each step whether it is completed or uncompleted or maybe has an error. We can refine it over time, but this seems like a vital part and also the same UI should be used for single step wizard, where the single step wizard, as you explained, could skip the steps and the action name itself is the single step name, so the UI/UX is cleaner. FINALLYI kinda expected some sort of explanation of a "click flow", how i start with clicking the single icon "wizard hat" or maybe rather i swipe or click that modern "show desktop" icon in one bottom corner of the screen, e.g. Here is how it shows on Windows11 We can of course also put it on the left side instead of the right side. |
tasks -
|
|
feedback Q & A
feedback"edit pathway" action
It's okay to have the
Only the custom form part can be entirely different for each of the steps in any of the actions a user selects to execute. Regarding typing to select entries (which should be part of the custom form - thus maybe an input field at the bottom or right underneath the graph explorer) to select a new entry. Now:
If the user completes the typing or clicks on any of the highlighted entries and then complete the selection, that should be good enough - i think we would not need a separate "dropup overlay list". to display the matching entries again.
I guess, change pathways should also as an action pre-select ALL currently selected inputs... the case that there is only one input selected is a special case. The progress bar should be the "change pathway" or rather the "" which - if it is positioned where the screenshot above shows the editable pathway, then it has enough space for additional progress status e.g. 1/2 steps completed or 50% completed and whether there are errors or not, etc... The steps wizard bar can scroll or swipe sideways when there are too many steps. EXAMPLE: SO you are right, that completion does now not preview the "themes/" folder as input. The issue is, that an open program can often easily open more than a single file or folder. YOu only showed a case with a single folder as input, in which case we could show it somewhere, but the issue is, what if the program supported multiple and the user would have selected 10 folders... would it still work then? Imagine an "IMAGE GALLERY" program, where the user selected 5 different "image folders"... which would you show? SO if you think this is important, then we maybe need to consider another bar or some sort of extra way to quickly show inputs/outputs of a program tab, not just quick actions.
Dont forget, a program which thinks it is important to show inputs or outputs as paths could just show them. The entire "BLACK AREA" above the quick action bar is reserved for the program when it is expanded. Nobody prevents a program from having a bottom bar inside which displays the current inputs/outputs, but maybe that isnt important for every program. Imagine you play a game like "pacman" ...your input file might be the current savegame, but is that really important to show? most games dont show it.
WHAT IF the user can click:
That way, its like a toggle
The use can switch back and forth.
Maybe it should even be possible to have both open at the same time, e.g. like chrome devtools and a browser window. each "browser tab" can open both in parallel, the tabs content, e.g. webpage + the tabs devtools, so you dont have to toggle betewen them.
Probably - to be consistent, the graph explorer should just highlight all the currently selected entries and a user should be able to unselect them. If there is a jump button
Would that be a good way of doing it? Like this:
Now what might change is the tab name itself, e.g.
general feedbackThe wireframes are great.
We have:
|
tasks -
|
|
feedback jump buttonYou said you didnt get that at all.
the actionbar itself has theme widget quick actions, such as "open new tab" or "jump to existing tab" ... show desktop swipe bardid you try adding the swipe bar to the the task bar (theme widget bar) just like windows does it? another alternative would be to have a horizontal small swipe bar on the top or bottom of the task bar and when swiped top to bottom it collapses the task bar down and, but the swipe bar would be still slightly visible and swiping it bottom to top, it expands the task bar again? ...is that better? you are right that the windows show desktop swipe bar collapses everything, but not the task bar itself. That is true and so if we would do what windows does, it would make sense to keep the task bar. But the thinking is or was, that its not really windows. So my thinking was, when a user comes to e.g. playproject.io it would only show the background program full screen and if they know and click the swipe bar, it would restore the theme widget bar with whatever was open, clicking it again collapses the theme widget bar. If the theme widget bar is open, we have tabs for "tab programs", we have the jump button as the "theme widget tab" to be able to execute actions for the theme widget itself instead of e.g. a "tab program". And we have the "wizard hat" button as the button to focus the background program and issue actions to the background program via action bar,... basically actions for playproject website in our example. It could also be, that the "background program" is a "pinned program" and there can only be one "pinned program" at any time, so by pinning a different program, the background program can be switched and the former background program becomes a normal "tab program" ... I feel overall, all that i just describe makes more sense than collapsing everything but the task bar. When would a user want to collapse all programs (including background program), but not the task bar? ...But the use case of interacting with one program, like playproject full screen and not being disturbed by a task bar make sense to me. After all, that is what playproject website is all about, to interact with playproject full screen and not be disturbed by a theme widget that a user might never want to use. yet another way to think about it: tab number to show
|
tasks -
|
|
feedback task bar swipe
You say its a swipe up action to show and also hide the task bar... maybe that is intuitive for apple folks, but might also conflict with the built in gestures and its definitely confusing for me or many android users who never used that. I kinda prefer to swipe down to hide the bars ...make them move down ....and then swipe up to make them move up again. Also - as you mentioned, on some phones, this might still conflict with the android or iOS built in gestures, so maybe having that bar left or right to prefix or postfix the action and/or tabs bar, so you would swipe left or right to toggle (collapse/expand) the theme widget bars (tabs/action bars) which we can call "task bar". ...so it would be a left/right swipe, but only in the bottom area where the task bar is. If the up/down swipe is better ...i guess we have to try it out in practice in the end, then just to not forget that both, the tabs bar and actions bar might be swipeable left/right, in case there are more tabs and/or more actions than there is space in those bars. One last thought to consider - if the app has a swipe up/down itself, there is always a risk to swip up/down and move the finger over the area where the app shows (so not the task bar), so this can cause a conflict and people with fat fingers might just struggle to press correctly. But if it is a left/right swipe on the task bar, then the finger will never even move over the area which shows the app, it will completely stay on the task bar area, so no risk here. The difference between a scroll is whether the swip action starts with the touch over the tabs or icons, or whether it starts on the left or right of that not touching the tabs or quick actions. So whatever you decide considering all this, its the version that we will roll with and then when we have it implemented we have to test a bit how it works. steps wizard
Basically the (1) circle before the step name "select an entry" can turn into a checkmark or an red error icon or a number in case its not yet filled out or some variety of different styles to indicate specific status, such as "work in progress" or "in focus" or "optional vs. required", etc... or whatever... Oh sorry - i see that you actually already show yellow and red. Basically: Ideally you would just show 1-2 screens showing the steps wizard, but then in between switch to the version controlled figma for steps wizard so show a list of all the variety of combinations and options a step can be in :-)
select entry step
I feel it should be smaller though, no? ...like a text editor bottom status bar, that often shows information like line or column of cursor and similar things. You can check "hackmd" for an example of such a bottom status bar. It has one. I wouldnt make it the same height as a bar that is touchable/clickable... i perceive it as a pure info bar not supposed to be clickable, so it could be more subtle to save screen estate? In general, clicking an already selected step wizard step again is difficult to assign any action to, because every step wizard form is different, so if at all, we might allow the implementer of a step wizard form to listen to the click on its step wizard button to react to it, so then it could do this expand/collapse thing if you think thats cool :-) jump button
collapsed taskbar
...but otherwise, thats how i imagined it :-) cool. This is fine. In the end, how exactly the quick actions look depends on the active theme, so its not super important and we can play around with different versions later on. I like this design better, but i guess i would just imagine it all icons bound or growing from the left border to fill the entire "bar", but being just icons with transparent background, but then again, there can be different themes of course :-) task json
graph explorerNot gonna say anything about the tree, because you werent really showing or explaining the details. The issue i can see is that what we have on discord using text characters to design the tree is better than what you have in figma. |
tasks -
|
|
feedback yes, seems good. lets do it so we can finally implement it all :-) steps wizard
The question in the end is if its worth showing the pathway. Either way, all the selected input paths will be listed in the
The "command name" should not be clickable to turn it into a search bar, because not every command on every step wizard will need such a feature, so its kinda the wrong place to put it imho. ...so instead lets make it part of the specific step form in a specific commands step wizard, where it is actually useful and needed. task/state
The program will have different "quick actions" than the "state view" (e.g. task.json, etc...) The file switching and doing stuff should probably be just a quick action when focusing in on the "state view", so we dont have to always have that small graph explorer view open, but it can be opened when triggering a quick action or command from the action bar while the state view is focused. It can be opened and initially focused by clicking the icon/number of the tab, and again that might auto trigger the default action, which is selecting one of the task/state files to open first. "show desktop"The only thing is maybe the "show desktop" bar or whatever we call it. You mention we could also just swipe up/down anywhere in the middle of the screen, but we cant, because playproject is a website and a user needs to be able to also scroll up and down on that website and they cant if thats now a swipe gesture to collapse the task bar. We will never know what kind of "app" a developer will program and how they want to use their gestures, so the entire space of the background or any app should not collide with our task bar theme widget gestures.
What is interesting is that you say swiping there closes the application. I checked that and there seems to be settings to do that - i'm just not using it, but i guess many do. Now the issue is, that its for bottom up/down swiping and also bottom left/right swiping, so what we could do instead is add the small "show desktop" bar on the left or right of the action bar instead of tabs bar, because then it would probably not conflict with the android built in gestures and it would still not create a bar hovering in the middle of your screen and be still very subtle on 50% opacity or whatever when the task bar is collapsed. In fact it could also be somehow in the middle between both bars on the left, making the "task bar" a 2 bar heigh task bar ... where it contains a tabs bar and an action bar... so if the task bar is the container, then we could make that "vertical prefix bar" kinda centered on the right between action and tabs bar and swiping right to left collapses it and leaves the 50% opacity vertical bar on the left screen ...to swipe left to right to bring it back? would that work? But overall, i think we are mostly done and ready to explain everything to ahmed and let him implement. |
tasks -
|
|
feedback |
tasks -
|
tasks -
|
|
feedback nice, but needs some standardization of the "task" section to have all running programs represented with the same structure. I shared that on discord as well |
@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.5comment@input📦 Github Worklog 54 feedback@input📦 worklog-54 discord@output📦theme_widget step by step v0.0.6comment@input📦 Github Worklog 55 feedback@input📦 worklog-55 discord@output📦theme_widget step by step v0.0.7comment@input📦 Github Worklog 56 feedback@input📦 worklog-56 discord@output📦theme_widget step by step v0.0.8comment@input📦 worklog-58 discord@output📦theme_widget step by step mobile v0.0.0comment@input📦 worklog-59 discord@output📦 `theme_widget step by step mobile example version comment@input📦 worklog-60 discord@input📦 github worklog-60 feedback@input📦 Graph explorer & state module@output📦 `theme_widget step by step mobile v0.0.1 comment@input📦 worklog-61 discord@input📦 github worklog-60 feedback@output📦 `theme_widget step by step mobile v0.0.2 comment@input📦 worklog-62 discord@input📦 github worklog-62 feedback@output📦 `theme_widget step by step mobile v0.0.3 comment@input📦 worklog-63 discord@input📦 github worklog-63 feedback@output📦 `theme_widget step by step mobile v0.0.4 comment@input📦 Graph_explorer_version@output📦 `theme_widget tree v0.0.3 comment@input📦 worklog-64 discord@input📦 github worklog-64 feedback@output📦 `theme_widget step by step mobile v0.0.5 comment@input📦 `theme_widget step by step mobile v0.0.5@output📦Theme_widget outlinecomment@input📦 `theme_widget step by step mobile v0.0.5@output📦 `Theme_widget component_explanation comment@input📦 `worklog-67 Discord@output📦theme_widget tree v0.0.4commentThe text was updated successfully, but these errors were encountered: