search

playproject-io / playproject-io.github.io

playproject website
https://playproject.io
MIT License
5 stars 2 forks source link

Design - theme widget #24

Open Mirabrar-21 opened 1 month ago

Mirabrar-21 commented 1 month ago

@todo

Mirabrar-21 commented 1 month ago

tasks - 2024.07.17

worklog

Worklog-38 theme_widget feature improvement

feedback

proposal

alyhxn commented 1 month ago

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 commented 1 month ago

tasks - 2024.07.25

worklog

Worklog-39

feedback

proposal

serapath commented 1 month ago

feedback 2024.08.02

regarding worklog 38

action graph

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.

actions 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?

checkbox 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

regarding theme widget feedback

theme widget 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:

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.

tabs 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

They can all be linked back and forth.

serapath commented 1 month ago

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.

graph explorer

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 hascontributor1` 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.

actions

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:

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

themes 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 :-)

file actions

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.

tool

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.

preference 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?

preferneces 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.

theme widget

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.

actions 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 :-)

themes 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 commented 4 weeks ago

tasks - 2024.08.5

worklog

Worklog-40

feedback

proposal

serapath commented 3 weeks ago

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 commented 2 weeks ago

tasks - 2024.08.15

worklog

Worklog-41

feedback

proposal

serapath commented 2 weeks ago

feedback 2024.08.16

img1 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.

img2 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

img3 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 :question: 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 commented 1 week ago

tasks - 2024.08.22

worklog

Worklog-43

feedback

proposal

serapath commented 1 week ago

feedback 2024.08.24

path bar 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: 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. editor

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).

trash 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:

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 commented 1 week ago

tasks - 2024.08.27

worklog

Worklog-44

feedback

proposal

serapath commented 1 week ago

feedback 2024.08.28

see discord

Mirabrar-21 commented 6 days ago

tasks - 2024.08.28

worklog

Worklog-45

feedback

proposal

Mirabrar-21 commented 3 days ago

tasks - 2024.08.31

worklog

Worklog-46 structure prototype

feedback

proposal

serapath commented 2 days ago

feedback 2024.09.02

commandbar I imagine the "first expand" to be more minimalistic

docbox3 docbox2 docbox The help "doc box" looks good. Let's design it like that and see how it feels when implemented. If we figure out issues, we can still change the css styling to put it on the bottom, but so far it seems it could work to me.

inputfield This looks good as well, but as described above, maybe it could be merged into the "bread crumb" bar, where the bread crumbs collapse into a single prefix name or icon prompt when the input field has focus.

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.

fileexpolrer Yes, of course my above feedback stands, but otherwise this seems fine.

console At first impression it is confusing to me. I realized it is the console, but i think i would expext:

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

editor I think on a narrow mobile screen, that is exactly how i would it expext to look But if there is more space, i could imagine the editor being next to the graph explorer and the bread crumb bar being below both of them.

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.

all So this is interesting. If a command history entry is short, then having it like that would make sense, because you can see more of them. IF a command is quite long, then a wide line makes sense and having it as described above, on top of the input bread crumb bar full width, would make more sense.

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 :question: 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.