search

wizardamigos / wizardamigos.github.io

Intro page
https://wizardamigos.com
11 stars 9 forks source link

tiling window manager (UI/UX) -- 3 #111

Open Mehrabbruno opened 1 year ago

Mehrabbruno commented 1 year ago

@todo

@info

For Design - Components for TWM we need to refine the outputs and sub tasks based on the components we will need to design, which will become more clear when we get to that task

Mehrabbruno commented 1 year ago

Worklog 1 2022.07.29 Worklog 2 2022.07.29 Worklog 3 2022.07.29 Worklog 4 2022.07.29

serapath commented 1 year ago

feedback 2022.07.30

Worklog 1 2022.07.29

Here is some formal feedback

serapath commented 1 year ago

Worklog 2 2022.07.29

feedback:

serapath commented 1 year ago

feedback 2022.07.31

Worklog 3 2022.07.29 Worklog 4 2022.07.29

Mehrabbruno commented 1 year ago

Worklog 1 2022.08.07 Worklog 2 2022.08.07 Worklog 3 2022.08.07 Worklog 4 2022.08.07 Worklog 5 2022.08.07

serapath commented 1 year ago

feedback 2022.08.10

Worklog 1 2022.08.07 Worklog 2 2022.08.07 Worklog 3 2022.08.07 Worklog 4 2022.08.07 Worklog 5 2022.08.07

feedback videos

  1. https://www.loom.com/share/2248c05c88614b8fa2f769d609cf5bf1
  2. https://www.loom.com/share/5d23bf87a6ba484ebf4660bdeb8211b0
  3. https://www.loom.com/share/85d5e18b0e754aa7948ecd2467e072df
  4. https://www.loom.com/share/93b612534a7243fe977264c1dc8846cd
  5. https://www.loom.com/share/83a5adf2ba674f08bd43741a9d79660d
  6. https://www.loom.com/share/45e73e2366bf423fa613e121addbd87d
  7. https://www.loom.com/share/54a99d42ab224cbbb94d3503517eb289
  8. https://www.loom.com/share/fd92f7dedf024177957fd4fe23a9c33e
serapath commented 1 year ago

feedback 2022.08.11

The video belows describe all features of the TWM and all the concepts involved from A to Z.

  1. https://watch.screencastify.com/v/41yYSa1KWmvcM3lCRncT
  2. https://watch.screencastify.com/v/QvLg9OAa0hjn9icHVoTH
  3. https://watch.screencastify.com/v/SnPo6zO3Ww1t7Ug2KQz4
  4. https://watch.screencastify.com/v/yQCXIgAzeC4GBHpc2bjK
  5. https://watch.screencastify.com/v/zRSD9LDCYlfuPsjbk1an
  6. https://watch.screencastify.com/v/rVhHeR14BcKZuFTQ9CaE
  7. https://watch.screencastify.com/v/rrnDfpAPicihi48WcTS8
  8. https://watch.screencastify.com/v/Bj4Yxu6ekndK8r57pLao
  9. https://watch.screencastify.com/v/TZ7aBjYEQQOxqwxnwcQb
  10. https://watch.screencastify.com/v/vVhfxJHvSI2q4RhAJMTB
Mehrabbruno commented 1 year ago

Worklog 1 2022.08.22 Worklog 2 2022.08.22 Worklog 3 2022.08.22

serapath commented 1 year ago

feedback 2022.08.22

Worklog 1 2022.08.22 Worklog 2 2022.08.22 Worklog 3 2022.08.22

Thx. this was outstanding work. I am really impressed. You did an amazing job here. I replied with minor comment on discord, otherwise two more small changes would be cool, namely:

1

vscode while bookmarks do not have an "active bookmark", all other focus should be indicated similar to vscode, which means:

  1. focus level 0 is the file explorer icon (not visually indicated in vscode)
  2. focus level 1 is visually indicated with an orange outline inside the file explorer
  3. focus level 2 is indicated in each active tab for each tile
  4. focus level 2* is the active tab that as focus (in the upper right tile)
  5. focus level 3 is the active line inside the open files
  6. focus level 3* is the active line in the focused file

Even the cursor in the exact column could have an indicator. Also the active TILE should probably have an orange outline in the vscode example above. Anyway, the goal is to visually show the user at all times what is active and focused, but not just the exact point of focus, but the nested hierarchy of focus, like vscode does it with a high contrast theme.

2

TWM So the bottom navbar the way you show it is not necessary. I removed it and the bottom tab bar is the bottom nav-tabs-bar. The entire window is the outer tile of the bottom nav-tabs-bar. The inner tiles have their own tabs-bars and constitute the subgrid. The only thing below the bottom outer most tab bar is the bookmarks bar As said on discord - the bookmarks bar does not have an active element, but can have focus while the user navigates the bookmarkbar.

The leftmost bookmark icon is basically not needed. The bookmarkbar can be empty, but it is an option for a user to have quick access to specific parts of their "file system" which they can otherwise navigate while clicking on a tab to get the files popover and explore their file system.

Mehrabbruno commented 1 year ago

Worklog 1 2022.09.02 Worklog 2 2022.09.02 Worklog 3 2022.09.02

propose tasks:

serapath commented 1 year ago

Worklog 1 2022.09.02

  • done Designed a draft of TWM iteration 15 - refinement 3
    • done watch/read feedback video and text - 2h
    • done document/structure - GitHub and HackMD task and info - 2h:45m
    • @output :package: twm ui/ux specification v4
    • done create refined wireframe 3
    • done design - version control structure - 3h:35m
    • done design - design system components - 6h:10m
    • @output :package: TWM iteration 15 Figma File - refinement 3

propose tasks:

  • task make concept and design for TWM sub components
    • task #112
    • task #113
    • task #114

:+1: yes, those tasks are ok! :-) let's do them.

great formatting of the worklog comment. amazing :-)

1

components having it version controlled by adding a box on top is 👍 the previous iterations can just be moved in "previous rows" on the same page with their own "version box"

2

popovers

here the popovers need to be each their own component, because they are way to different to be the same component with diffrent variants. we will need heavy iterations on each of them, so no way we can make them the same

so no popOvers component, but instead 6 separate components

But we can make the "search input" and "title bar" or whatever separate components and then each of those popover component has them as dependencies

3

next question:

cardBtn component, isn't that used exclusively for apps/programs a user can select from for when they open a file in a tab/tile ?

maybe we should then name it "app/program card"? and use a specific app as an example?

4

tabsContainer highlight tabs container highlight with full background color (orange) is strongly preferred. I agree 100%

Also: In the dependencies it says tabs component, but I imagine it should be called tab component, because I assume that component shows a single tab and not many ...it confused me at first, but if my assumption is correct, then i would prefer tab over tabs :-)

5

I think typography and colors as components could be skipped. To me they are part of a theme. Of course we need some sort of basic theme while creating all components, but this is the part that can be swapped later on for many different fonts/colors/theme styles, while the individual components and the way how they work will not change.

serapath commented 1 year ago

Worklog 2 2022.09.02

1

issue cool that you made many issues.

2

output yes - the output itself get's directly linked to the figma document and the page and version of that particular component. This is what should be mentioned in a separate summary video which ideally perfectly nails within 3-5 minutes how we structure our figmas :-)

But, in this case, the document needs to always be part of the issue in which it was created as an @output that links to the document. But it can also be part of other issues as an @input that links to the document.

3

sub issue while it is great that we have an output link here, we should in the future try to avoid names like TWM iteration 15 Figma file, because it is very generic. Instead, if the "change" was to refine the tabsContainer, then the output should link to the figma file with the page and version of the tabscontainer and the output link should be called tabsContainer v0.0.1 for example.

Also, to answer your question: YES :-) like this: outputs

The same figma file contains many more pages with components in many versions each of which we can link to directly to use them in @input and @output links named after the versioned component in the github issue todo where they belong.

naming tasks Tasks should not be named after outputs, but instead after the activity, e.g. design tabs component.

4

The idea of linking the "containing task" (e.g. #111) in a sub issue is not bad. We didn't do that so far, but i think we should, so please feel free to do:

view1 view2

Otherwise, issue #111 should contain a task with no inputs or outputs named:

also here tasks Every task is either just an activity that can be checked when done or a sub issue. In the latter case, the task itself should just be * [ ] #123 (if the sub task issue is number 123). Then the title of that issue 123 should be the task activity. That will make github automatically filling in the task name in the bullet list of the "containing task"

Also, here you can clearly see again, why the popOver component needs to be split into many issue, each with a different popover type instead of summarizing them under one "popover component".

5

individual popover components you say here it's not possible to link to that "individual" popover, and that is again exactly the reason why we need a separate component per popover, because we need to link to it individually. Instead we can make the things that are the same for each popover, like (e.g. the "titlebar", or the "searchbar" a component and then reuse it in each "popover type component".

Also, i checked the "popover github issue" ... it literally has the tasks for each separate popover components and makes it a quite verbose task instead of making many separate tasks, one per type of popover. Including one output link per such separate component :-)

you even almost mention it yourself in the video by noticing a few things in that direction.

serapath commented 1 year ago

Worklog 2 2022.09.02

continuation

I was checking the hackmd file and while it is not bad, i now think that it might be better to add some additional text directly into figma next to each component version to describe it. That put's all the information around a particular component in one place instead of spreading it like that.

If that is ok for you, then after you refactored the figma according to the change requests above, you could also copy over those hackmd descriptions so that we don't need the hackmd file anymore.

It is quite cool that you have links directly to figma. Otherwise it is also possible to create anchors in the hackmd and link directly to section from figma.

Still - jumping back and forth is unnecessary and those short text paragraphs per component should probably just be included in figma directly next to each version component iteration. That is much faster to read.

note: again regarding the different popovers - each popover should be, as said, an independent component, because also each of them requires a completely different description.

This eleminates the need for those "arrows" to indicate which "Variant". In fact - the need to create such an arrow is a strong indicator that something should become an independent component.

add tab

Also, the add tab "component" should in my opinion just be part of the tabsContainer component, because it is never used outside of that context and the description from the hackmd could just be part of the tabsContainer component description.

rules of thumb:

  1. everything is a component, including the entire app
  2. if something is simple and never used outside of a specific component, it can be part of that component
  3. if something is a very complex functional unit, even if only used within a single component, it should probably become its own sub component anyway - ideally so that it can theoretically be used in other components in the future
Mehrabbruno commented 1 year ago

Worklog 1 2022.09.08 Worklog 2 2022.09.08

serapath commented 1 year ago

feedback 2022.09.09

Worklog 1 2022.09.08 Worklog 2 2022.09.08

  • done Designed a draft of TWM iteration 15 - refinement 4
  • task make concept and design for TWM sub components
    • task Design - Tiles for TWM
    • task #115
    • task #116
    • task #117
    • task #118
    • task #119
    • task #120
    • task #121
    • task #122
    • task #123

:+1: yes, great new tasks, let's do those :-)

looks great. one thing to maybe share and include in our "version control" video is, that a "high level component" can show sub components which do not exist yet as standalone components.

It is ok to make a later iteration/version of the "high level component" in which what formerly only existed as part of the high level component wireframe becomes an independently version component which from then on is used as a dependency in the higher level component.

That is normal. I usually always start a project with a rought wireframe of the entire app to get an overview and overall feeling and then start breaking it down or breaking out sub components and sub sub components to iterate indenepdently on them until putting it all back together into the overall app over the course of many iterations :-)

TWM versions yes, please make all those previous iterations versions too, which can be linked to and put them on top of the latest version, which would make the latest version not v0.0.1 :-)

and overlays those should be moved to a different page - it's a different, or rather many different components, which are all dependencies of the TWM :-) ...and they were introduced in that version/iteration of the TWM.

so at the moment we have many (sub)components which are part of the overall tiling window manager wireframe, which are not yet independent components

Of course - over time we should identify all of them and start tracking them as individual components and list them as dependencies in future iterations of the higher level components :-)

example iteration For example, this menu in this TWM iteration never survived the next iteration and never made it into it's own standalone component - that's ok. ...high level component iterations might try out things and change and iterate until we really believe something is good and should become it's own standalone component. I perceive this to be a normal part of iterating on wireframes.

components yes, looks good. awesome. thx :-) so if all of them would be on their own component pages versioned, that would be sweet.

I even think - just for a sake of having that example - the popOver component that has all different types of popovers in one should have its own component page and we will have a version/iteration where we DEPRECATE that component :headstone: and list all the successor components and link to them.

Now regarding a "merge", where multiple components get deprecated and get all merged into a single new component - we don't have that use case yet, but that's ok.

regarding hackmd

I personally still think we should dissolve and abandon the hackmd. I agree "scrolling" around in the figma is tedious, but the point would be to click on the links dependents/dependencies to jump directly to them and use the dependents/dependencies on that component to jump back - alternative could be to use the browsers "back" button or open many browser windows and place the next to each other.

Instead of starting in a hackmd and reading top to bottom, somebody should start with the highest level component - which we might want to mark as an entry point page in figma (e.g. maybe prefix the main components page with a special emoji or character to indicate that) And then somebody clicks to dependencies (maybe even right click + open in new tab) and/or jump back by clicking on the dependent a user came from to wrap their head around things.

Of course - each link jumping to the exact version that we are talking about.

I think the hackmd will also get messy once we have many versions of a component listed there.

in implementation phase each component will get it's own github repository and the description will be put into that repositories readme including probably a screenshot and link to a preview page to show case it and it will link all the readme's of other components so the user can jump to those and read it in a similar way ....

That's the way to go in hyper modular web component development, which is what we practice. The single hackmd just breaks so many of the best practices and i don't buy the benefit you mention once we have the proper linking instead of scrolling around the canvas (which will not be the case anymore when each component is on it's separate figma page anyway)

github issue

So you can shorten the name to design tabContainer The "for tiles" and "in tiling window manager" is anyway implicit by it being linked under "tiles" which is a sub task of TWM anyway, so no need to repeat that in the issue names :-)

next, usually we create the @input, in this case the input of e.g. Design a draft of TWM (iteration 15 wireframe) as the first sub bullet point and afterwards we have bullet points for all tasks and the last bullet points are the outputs.

The way you did it, it looks as if the WF 14: TWM specs in WF -iteration 2- figma file is an input for bookmarksContainer ...but because bookmarksContainer is itself an issue, that input should then be listed in that issue instead.

So this is slightly confusing, but otherwise things look good.

next If you can actually link to the exact position on the canvas where specific component wireframes which are meant to be input are shown, you could link directly to those and call it something specific, like iteration XY of that component instead of just generally calling it WF 14: TWM which includes everything ...but of course - we didn't version things in the past yet, so we will now slowly transition to that style :-)

another issue example here another example. It is totally cool to just name a github issue e.g. design historyLogsPopover or design next iteration of historyLogsPopover

  1. without listing the version, because the version is clear via linked planned @input and @output documents that will have the version name included
  2. without listing what it is for (e.g. pop-over for tabContainer...), because that is implicit in the github issue where that task is listed, so that makes things a bit shorter and easier to read.

If somebody wants to know what is something for, they will know, because a specific @output has a list of where it is used as @input

e.g. inside the design historyLogsPopover issue, you would probably have

...or something like that ...and if the popover is used in more than just the tabs design, you would just have multiple next sub bullet points, so that is good enough.

output also here, this is great, but it could/should have similar sub bullet points to show where that tab_v0.0.1 is used as an input, e.g.

Because outputs/inputs have filenames that include specific versions, the task itself doesn't necessarily need it. it's ok if you want to include it, but i personally feel while that's up to you, the task name should not include what it is sub task of, because that is what we solve through the next and from links instead to keep things not too verbose.

serapath commented 1 year ago

feedback 2022.09.09

so while we could simplify things at the moment to e.g. desgin tabsComponent or design tabsComponent_v0.0.2 if you want, we can later be even more exact, like ...

basically, the more specific tasks become, the better :-) And maybe we will have a lot more tasks and each task will be done in 5min or 15min or 40min or whatever instead of everything is grouped into one make next tabsComponent iteration - 1.5h task name.

Not saying you have to do this now, naming it just design tabsComponent is absolutely good enough.

This is more meant as something we should slowly get into our work routine when we work over the days and weeks on different components and iterate and then i give feedback and based on that feedback you just turn that into a a bunch of new task bullet points that name each thing that we talked about and then you work through and check them all as done in the end ...those new task bullet points could always be made as a takeaway from feedback so you have a list of reminders for everything that needs to be worked and in the end you can double check if they are all done and that way it becomes part of the work routine.

tabscontainer here you somehow said the feedback about adding the + button to the tabs container wont work and then you show the tab component wireframe. I think i did not understand why that won't work.

To me, even an empty tabsContainer would never be without a + button to add yet another tab

tabsContainer to continue my point above. The way you describe it in your worklog, i imagine there is a missing dependency. The tabsContainer only lists tab and collapsedTabPopover (which i'm not sure what it is) ...is it "collapsibleTabPopover"? ...but anyway, shouldn't it also have a dependency on btn-icon or something if that is as you say re-using this component for the "add tab" button?

regarding linking of issues

issue linking Every issue should have a link to it's direct parent github issue, e.g. design tab (112) is a sub task of design tabContainer (114) and not of TWM (111), and so it should not contain a link to #111 but instead to #114 and then design tabsContainer should link to #111 and TWM (111) should have a link to UI/UX/concept design (39) ...which itself should have the link to the roadmapping issue itself.

...i know, most or basically all issues are not yet linked in that way, because we just or you just came up with it, but that's why i'm sharing how that linking should work :-)

otherwise input output linking You are right, that inputs/outputs already connect issues, but an input or output does not need to come from a parent issue or sub issue, it can come from any issue in the project, so this is also important but generally different.

linking yes, this is perfect. as said earlier - there is no need for such a detailed github issue name though, so would be nicer to have shorter issue names, so in this example the (..."for Tiles in tiling window manager (UI/UX) -- 3") part in the name can go away and as said earlier - the "design tabsContainer_v0.0.1" name is ok, but the more we progress, the output (e.g. tabsContainer_v0.0.1 or later tabsContainer_v0.0.5 will already be specified as an @output, so the github issue name or task name could instead be more specific in terms of WHAT is the change or feature, etc... that happend in that iteration of a component, so instead of design tasbContainer_v0.0.5 it could say add disabled state to tabsContainer which is what would then exist in v0.0.5 but wasn't yet in v0.0.4 ...that would make it more clear what actually happens in that task. more specific is always preferrable over more generic, but

design tabsComponent v0.0.5 is already a HUUUUUGE improvement over TWM iteration 17 for example, where actually maybe only the tabsComponent changed :P

Mehrabbruno commented 1 year ago

Initial Worklog videos

Worklog 1 2022.09.18 Worklog 2 2022.09.18

Serapath's Feedback

Feedback 1 Feedback 2 Feedback 3 Feedback 4

Worklog after feedbacks

Worklog 3 2022.09.19

serapath commented 1 year ago

feedback 2022.09.29

https://watch.screencastify.com/v/4u2E0f61x94Swuagm14V

Sorry, noticed there is no audio in the second half of my feedback video. Essentially it's just two minor points:

  1. the ** have spacing so it doesn't make text bold in that worklog comment
  2. the @input is missing, because in the deprecated popOvers it says the output is used as an input in the list of successor issues, but then you show one successor issue, which has it's own output, but it is lacking popOvers_v0.0.1(Deprecated) as an input from that previous issue where it was an output - so that needs to be fixed.

And last regarding time logging. Let's just say we never will do any aggregation of times, that can happen in the timelog hackmd, but instead we only always log time in the finished todos that get listed with each new worklog, so those worklogs should contain the times.

We would never edit previous older worklog comments to update any times but instead just add that time to todos in the new worklog comments :-)

Mehrabbruno commented 1 year ago

Questions & Inputs

Worklog 1 2022.10.18 Worklog 2 2022.10.18 Worklog 3 2022.10.18 Worklog 4 2022.10.18 Worklog 5 2022.10.18 Worklog 6 2022.10.18

serapath commented 1 year ago

feedback 2022.10.18

Worklog 1 2022.10.18

  1. version tags

    • let's remove version name from component names and instead add version in the green version box. Every time we make a new version of a component we make tasks for all dependents of that component to upgrade. If we at some point decide to use an older version again, we make tasks to downgrade all components to use that. No matter what we want, we make a task to do what we want (e.g. make a new component version) AND THEN we always also create tasks to also update all the components that depend on our decision, so we know for sure, once we finished all tasks, everything will be exactly the way we want it to be, because we track all tasks and make sure once all tasks are done everything is perfectly in sync, so no "steam UI" situation can ever happen.

  2. worklog videos:

    • no worklog comment without a worklog video: a worklog video describes what has changed, so all the worklogs of a component describe the component perfectly well.
    • worklog videos are task focused and explain what has been done based on tasks, including questions or how long things took or propose next tasks, and so on...
    • if some things repeat sometimes, that's ok. The audiences are different.
    • the person watching worklogs and giving feedback watches mainly the worklog video
    • a component implementer checks the input figma file with the video link
    • => so different audiences and they both need to know stuff, hence some things repeating is ok
    • to minimize duplication in worklog videos (which we always need), we can make worklog videos shorter by showing the link to the "video recording", maybe even playing it and showing parts of it - so the person watching the worklog video to give feedback can then go to figma and also watch the mentioned description vdeo recording, so we have less duplication

  3. component description video outputs:

    • let's always link a "video recording" to describe a component inside the description section of a component version in figma, so it becomes part of the new figma version output and not a separate output to have it exactly located in the place that anyone interested in that component will look at, so if the figma becomes input to the "component implementation task", the video will become an indirect input too and the implementer can watch it and maybe even use it in their output to link to it from the github repo readme too. I think i strongly prefer this.
    • also only once we come to a more final version of a component, we can decide to summarize the entire component in a single video that describes it all in one go. we shouldn't make that for every version of a component
serapath commented 1 year ago

feedback 2022.10.18

Worklog 2 2022.1018

There are many ways how to deal with the work for the talk preparation. What we usually do is to make it part of the work we already have, which is what it is.

That means, the TWM issue (which is not yet perfectly structured the way we want it to be structured) has a task called "prepare figmva versioning talk with TWM as an example" and it can have sub tasks and the output is the recorded talk

Then we can have another main task called "continue designing TWM v3" with all the remaining TWM tasks as sub tasks and it has the talk video as an input.

That way, you or whoever continues to work on TWM 3 issue can watch the talk to know how to exactly work with figma and github issues when continuing the work.

Of course - we can also use that talk video as an input to all kinds of other future tasks that don't even need to have anything to do with the TWM issue itself :-) We just link it as an input :P

Is that answering the question?

serapath commented 1 year ago

feedback 2022.10.18

Worklog 3 2022.10.18

just a short feedback about

issue

yes, that's legit, but if you don't list Design - tab or Design - collapsedTabsPopover somewhere as a task, then you can't really check them or mark them as done, so if you don't list them as tasks in this issue, then you need to list them somewhere else. This is how the system currently works and i wouldn't want to change it. It means every task (also task issues) need to be listed or linked somewhere as a task (not just as a from of an @input) :-)

Also, I think we now decided that documentation videos to describe components are jsut part of the figma file and linked from there and thus part of the figma output link on github issues instead of being a separate output

one worklog -> taking about multiple components yes - some worklog videos need to link to more than one worklog comment on github in their video description.

That is ok. A single worklog video can be linked in more than one github issue worklog comment. Each worklog comment has different tasks and times logged, but the worklog video is the same in many.

we try to avoid this by making a specific short worklog video per worklog comment, but it is ok to sometimes link the same worklog video in more than one issue if we list all the worklog comment links in the video description

serapath commented 1 year ago

feedback 2022.10.18

Worklog 4 2022.10.18

Regarding the "active action icon" You might be right and maybe we should keep things simple for now. ...but the three vertical . . . do not make me expect that i can see actions and trigger some actions in there, so a better icon or solution would be cool :-)

Just some context of where i am coming from:

The tab has

If you think in terms of a "terminal" with a command line, think of the above as:

  1. the history of navigating (e.g. ls, cd ..) and maybe even commands
    • using the arrow up key you can often see previous commands, including ls or cd ..
  2. the file path is what you see in the command prompt as a prefix to your cursor
  3. the program doesn't exist, but just imagine is as some sort of REPL
    • e.g. if you type node in your terminal, you can start executing "js commands"
    • so node is a program and imagine any program can be started to then allow actions
  4. let's skip permissions for now, this is more like sudo or some sort of permission settings to allow certain commands or programs or whatever to execute or to read...
  5. actions are then meant to be available in the context of a program
    • so while you start typing a command, it might offer you autocomplete
    • this is what our action popover does - it's like an autocomplete

So, while you might change file path and program and all the other things on the terminal, once you decided on the correct file path and program, let's say it is ~/home/toshi/workspace/project-x and you decided on a program, e.g. git or node, then you would mainly focus on the interaction using commands.

Which means we can start typing an action and it will autocomplete. That is what the actions menu represents :-)

Once you decided for a file path and program and start using it (maybe an editor), you will start triggering lots of actions to create or change content, so actions need to be really nicely accessible (you might even define hotkeys for them), but you want to be able to trigger lots of different actions fast, ...so autocomplete is not bad and shortcuts neither, but i still feel the . . . menu is a little bit hidden and doesn't make people think of something very important or that this is about actions.

history popover vs. collapsedtabs popover

you say you don't wanna merge things because maybe we have different designs on e.g. popovers the "actions popover and the "file explorer popover"

yes we do have different ones in those cases, that is why i specifically mentioned the history and collapsedtabs popover. From the perspective of building that component, they are in functionality nearly identical. Not only that, even an individual item in the list is nearly identical (unlike the applicationPopover), which is also a list, but each list item is quite different, because it has a program icon, a title and a subtitle or description.

regarding the merging I would probably say we need a more generic "list popover" component (a new component) And then we change the history popover and collapsedtabs popover and give it a new dependency, which is the list popover or something. So it is not a merge, but instead the components become more minimal, by re-using most of the list popover component ...what do you think about that?

If we did that, it would only literally affect those two, not any others in case you were thinking of that. i only mean those specific ones.

otherwise...

Even if we still don't do it. What about the "file explorer popover" ... How is that different from the bookmarks popover? I feel it is literally the same. The only different is, that when you click on a bookmark, it opens the file explorer popover starting on that specific bookmark (e.g. a tile.json file) If you click on the file path in a tab, then it will open the file explorer popover with that file path as a starting point.

So there is no such thing as a bookmark popover - it is the file explorer popover ...so here we can do the merge, right?

serapath commented 1 year ago

feedback 2022.10.19

Worklog 5 2022.10.18

bookmark popover

You describe things correct. The way a tile with sub tiles is saved is as a tile.json file. It is a json file that contains the data to describe the structure of a tile with sub tiles and what files and programs are open in those.

A feature of the file explorer in general is that it should allow to expand/collapse folders, but if a file is a tile json file, it can also expand/collapse those.

This is described in earlier iterations of the TWM.

So this is a feature of the file explorer. It is also how technically a bookmark of a tile with many sub tiles is saved as a tile json file It is also how we display it in case a user clicks on such a bookmark. No difference in the file explorer.

So if you click in a tab on a tile.json file it will turn that tab into a TWM tile with sub tiles and open all the sub tiles specified in the tile.json file.

But if you click on a tile.json bookmark, it does exactly the same thing.

Clicking on a folder will usually open the "file explorer program" in that tile to show the content. The program is the file explorer (which is usually just a popover)

Clicking on a folder bookmark to open it does the same thing, but in a new tile.

A bookmark can be many things. In case a bookmark is a tile.json file that describes lots of tabs with lots of file paths and programs open, then clicking and opening that bookmark from the bookmarkbar will restore exactly that ...but some bookmarks might just be normal files or folder

  1. In case of a file explorer popover you can:
    1. select a specific file or folder but open it in a new tab
    2. select a specific file or folder to open in the current tab
  2. In case of the bookmark popover you can:
    1. select a specific file or folder but open it in a new tab
    2. select a specific file or folder to change the current bookmark to something different

Is that even a difference at all? I don't see why we would design things twice. It is not even something visible in the bookmark popover or file explorer popover itself. It is only visible as the result of an action outside the popover :-)

Mehrabbruno commented 1 year ago

Worklog 1 2022.10.20 Worklog 2 2022.10.20

Input on your feedback - 2h48m Worklog 1 2022.10.20 Worklog 2 2022.10.20 Worklog 3 2022.10.20 Worklog 4 2022.10.20

Mehrabbruno commented 1 year ago

Worklog 1 2022.10.21

Mehrabbruno commented 1 year ago

Worklog 1 2022.10.21

serapath commented 1 year ago

feedback 2022.10.21

Worklog 1 2022.10.20 Worklog 2 2022.10.20

  • done Modify the component canvas information header design

    • done remove all the green version tags from the canvas headers - 10m
    • done add explanatory videos to each component's description - 20m

Input on your feedback Worklog 1 2022.10.20 Worklog 2 2022.10.20 Worklog 3 2022.10.20 Worklog 4 2022.10.20

Worklog 1 2022.10.21

  • done Modify each component's/issues's tasks to add recorded videos task before output - 15min

    • done Update each component's/issues's comments accordingly - 10min
    • done Record a worklog recording of them - 5min

add proposal comments to our workflow

@Mehrabbruno do you take notes from all the feedback?

I didn't check, but would recommend you to update tasks and sub tasks with all the little things you want/plan to do based on my feedback. I think that way, when you continue work the next day nothing gets forgotten :slight_smile:

I would even go so far and say that we could introduce another type of github comment. we have:

  1. worklog comments
  2. feedback comments
  3. proposal comments (which would be a comment to write down a list of tasks.

You can share the link to a TWM3 github issue proposal comment on discord in the wizardamigos/TWM channel and tag me so i see it and can give a feedback comment to accept it so you can update the todolist of the github issue and start working on them.

So far we didn't yet still have a good example of proposing tasks in worklog comment and i would say, we should add or change our existing project management to include proposal comments for new tasks (perfect for writing notes to yourself of what is all the stuff that should get done based on the feedback you got from me an watched) :slight_smile:

AGAIN You just mentioned in Worklog 52 how you forget some things mentioned in earlier comments by the time you come to the lower comments. => Yes, i can record a video, but still, by the time you watch the last video you would forget what was said in the first videos.

We need to fix this. Therefore, as said, let's introduce the proposal comments into our workflow and you would just take notes to summarize everything that needs to be done and then post that in a proposal comment so you don't forget anything and i can also double check all the tasks and next steps you derived from the feedback and approve it or give again feedback in case something was forgotten.

Then i can do text or video but either way we get a more systematic way of not forgetting stuff :slight_smile:

Let's try this next. Please try to make such a proposal comment from my current feedback (or multiple proposal feedbacks) And also let's update our ask management & figma version control video to include it

feedback to all the above

  1. yeah, name it task management & figma version control or something like that?
    • if it takes more than one video, name the playlist like that and add the video(s)

pic1

  1. i think you can just add new tasks for it (no inputs, no outputs) and log time on those. or - if the questions & input was to some specific tasks, those tasks should be listed as sub tasks under those basically, any task can have a bunch of sub tasks like watched and processed feedback video or whatever related to those tasks so that if we already have "generic administrative overhead tasks" we will group them under the design or programming or whatever tasks that they belong to maybe, you can create a small list to collect those little corrections or additions and then when we have all of it and i managed to work through all the videos and gave all the feedback, then i can watch your talk video and we plan maybe a final update to include what is missing.

also, please update those issues to make the TWM issue and it's sub-issues the "perfect example"

also - yes, the video recording only appears linked on figma, so not on github issues. it is indirectly part of issues because the figma component link is pic2

the next version of a spcific component e.g. tabContainer_v0.0.2 can have a task "create component summary video", just like it has "action list CTA" as sub tasks too, but we only mention the tabContainer output once and all those sub tasks somehow fed into it.

So the task of making that video can still be part of the todo list, but only at the end of a few of those todos we have the figma version link to the component and it includes all those changes

hope that way works

but it is good to describe mention it in the explanation of our system

e.g. administrative tasks, like worklog recording, watching feedback, etc.... e.g. a sub task list of requested changes can have no inputs/outputs, but only at the end of that sub tasks list we have one output (e.g. componentX_v0.0.5 which includes all the result from all the sub tasks that where done instead of linking inputs and outputs to each single task in the list of sub tasks

does that make sense?

regarding tasks pic3 yes, github issues are tasks themselves

but, no github issue should be a lonely isolated github issue. we have one single issue that can be a standalone issue and that is the roadmapping (or rather the project issue) every other issue is a direct or indirect sub task of the project issue. TWM 3 is also a sub task of the UI/UX design issue which is a sub task of the project issue And something like design tab or design collapsedTabsPopover are also direct or indirect sub (issue) tasks of TWM 3 which means they are also indirect sub tasks of the project issue itself.

does that make sense too?

@Mehrabbruno regarding your summary talk video. it is an @output it does not have a next and is in fact a final project output. it should have not been produced under TWM 3 but should have had it's own issue - like a new issue with a single task * [ ] document project management if you want you can still create that

there will be a next too, but not yet. The next will be that i will make some issues for David and others and link it as an input there. But you don't have to bother with it now

and in the future for other people i might create some onboarding tasks and link it there as an input too so they can learn how we work :slight_smile:

pic4

also the final TWM ui/ux output will actually have a next sooner or later. i will basically at some point link it as in input to the implementation task

maybe while you go through the learning videos and create a github repo with the learning vanilla js results

@Mehrabbruno regarding components, i agree. you are correct that we should probably keep things separated in terms of design and join it or use it as an input for the implementation phase.

![pic5](https://imgur.com/7TMLsQ7.png]

one thing to keep in mind is that the "file explorer" popover which will also be used in boookmarks and the likes is quite a sophesticated component with lots and lots of details and we need an interactive prototype ...but making it twice even though it is mostly the same feels a bit overkill.

So maybe we just have to create a file explorer component and then use it in the bookmarks popover and the file explorer popover

and the file explorer component will have the more detailed version of all the features while the 2 popover designs will not go into all details but show just the main design for the popover and the rest follows from the file explorer component functionality which is specified in that interactive prototype of that component we will make.

what do you think about that?

+1 otherwise to also have a header, body and footer or input in popover components and name them and maybe even specify them seperately ..and for body we will have multiple options, e.g. like the above mentioned file explorer component design with interactive prototype.

and then in popovers we use those header, body (e.g. file explorer) and input footer as dependencies, but add the specific design for the popover that is necessary for implementers to know how to adapt the more generic dependencies it uses.

can we do that?

pic6 So basically on the design side, we don't do arguments

in those situations we just create new dependency components that show the generic fully features dependency (e.g. file explorer) and then the popovers will list that one as a dependency and show the themed or adapted version of itself. I think based on that a programmer would understand what kind of params they would need to create to pass to the dependencies to make them adapt to match our designs :slight_smile:

also, please can you share your timer tool? what do you use and can recommend? :slight_smile:

serapath commented 1 year ago

feedback 2022.10.21

Worklog 1 2022.10.21

  • done Record worklog videos for each components - 25min

    • done Upload the videos and update all the components comments - 25min

The Tiling Window Manager Github process updatescould maybe have the "task management and figma versioning video" as @input :-)

...not super necessary, but basically that video is the basis on which we do those changes to the github issue of TWM, right? just a thought.

I guess this means it needs a separate issue where we collect all the tasks to refine or improve that video (=task managent & figma versioning), which is the output.

Mehrabbruno commented 1 year ago

Feedback 2022.10.24

do you take notes?

Yep, I keep my notes on Notion. If you want I can start sharing a link to my notes


We should introduce proposal comment

I agree, I think having a comment where I initially structure how the tasks will look like should be beneficial


you can just add new tasks for it (no inputs, no outputs) and log time on those.

I agree with creating a different task for stuffs like this (discussions, feedback etc) where we can log our work and time. I think I have addressed this before in certain cases such as this one. When you are providing feedback for multiple topics/tasks at once. It becomes hard to track the time spent on those task which are specific to a certain design.


also- yes, the video recording only appears linked on figma, so not on github issues.

Yep, I have already made this change in the issue and Figma file


every other issue is a direct or indirect sub task of the project issue

Since, all the components are already listed in the main TWM3 issue as tasks. I think that makes them indirect issue already right? In that case, we should be able to avoid mentioning it for example tabs-issue is already mentioned in TWM3-issue therefore, we don’t need to mention it in tabContianer-issue correct?


So maybe we just have to create a file explorer component and then use it in the bookmarks popover and the file explorer popover

I thought about this a little bit. I agree that the design looks similar. Right now I think those should be 2 different components because


have a header, body and footer or input in popover components and name them and maybe even specify them seperately ..and for body we will have multiple options

how should be divide these issues? should I deprecate the previous pop-overs, create a separate issue and a page on Figma for pop-over container. Then a different issue and Figma page for each pop-over’s body contents?

Also, since this change will be made on every pop-over component. I create 1 worklog and link it everywhere? This will also, require us to create different explanatory videos for those changed pop-overs. How about we just use the worklog rather than creating explanatory videos? Since those are basically addressing the same thing.


then the popovers will list that one as a dependency and show the themed or adapted version of itself.

If I understand correctly, you are taking about using dependencies to showcase what will be the possible parameter in that component designs?


also, please can you share your timer tool?

I use Focus To-Do. It is mainly used for Pomodoro. The mobile version is free but the desktop is one-time-purchase but it’s cheap. It was good for me before I started working on this project :D I think there are many improvements to be made.


The Tiling Window Manager Github process updates could maybe have the ‘task management and figma versioning video as @input

Yes, I think that should be the case. I would also recommend we create another task for a document. Something like video-script and use that to create the video. What I have noticed is that the final video is much easier to produce once the script is finalized. We can decide what to put in the video, what to say in those section, what we are missing etc. Furthermore, it is far more easier to make adjustments to than a video. During recording, if I mess up once, I have to restart the whole recording again. Which is a huge waste of time.

Mehrabbruno commented 1 year ago

Proposals 2022.10.24

Mehrabbruno commented 1 year ago

Worklog

worklog-1 2022.10.25

Tasks

serapath commented 1 year ago

feedback 2022.10.26

maybe share a short video about how you structure your notes in notion again. :-)

Regarding your task proposals:

  1. proposal comments are now part of an optional section of a worklog comment
  2. don't forget a separate issue and the video Task management & Figma version control is a version controlled @output
  3. Rest looks good, but please read below to refine

For example when I start my timer you were talking about the task-management. In-between, you change to talking about the pop-overs, and learning web-component videos etc. In this case, you provided feedback on 3 different tasks. Sometimes, you refer to your previous paragraphs/topic of your feedback within 1 sitting. This make it hard to track specifically how much time someone has spent on the each section of the feedback. Sometime there are feedback on multiple components at once. In all these cases, I run my timer 1. Whatever the total time is after I finish reading your feedback, I calculate that. Pausing and restarting timers for each topic is difficult because you never know what the next paragraph will talk about. Even trying to track all that will be to some extent considered as micro-management. It gets frustrating after a time, when you are confused on how to divide your time on the feedbacks you read.

I will try to improve this. Thank you for the feedback. Having separate issues per aspect of our work helps me. Initially we had just TWM3 as an issue, now we have many, so i can split my feedback.

Since, all the components are already listed in the main TWM3 issue as tasks. I think that makes them indirect issue already right? In that case, we should be able to avoid mentioning it for example tabs-issue is already mentioned in TWM3-issue therefore, we don’t need to mention it in tabContianer-issue correct?

Yes. If you made sure all issues are linked somewhere as sub tasks, it is ok. We should only avoid that the only place an issue is mentioned is as a from field of an @input or next field of an @output Every issue has to be at least once mentioned somewhere as a sub task of another issue in the project.

For the sake of understandability. The developer can see the visual design, and know exactly how each pop-over looks like. Therefore, will be easier for them to design/code the component. After going through the components, I think those 2 may look quite similar but have different functionalities. In the file-explorer you can navigate to any parent, siblings and children directory (open any folder or file you want). However, in the bookmark-popover you cannot go back the directory but only forward. You can open any children file of folders but neither parents nor siblings.

Hm, I am thinking and would want to be able to also "go bck the directory". That way i can understand where exactly a specific bookmark i am checking is actually located in the file system. Also it allows me to replace the bookmark with another bookmark (e.g. the parent folder). But clicking the bookmark popover action should definitely start the file explorer expanded and the exact bookmark item to be selected/highlighted.

One more thing I think we should remove it the function to remove files and folders in the file-explorer-pop-over. Since those files and folders are uploaded by the workshop creator. Only they should be able to make adjustments, not the user.

So - this depends on the permissions. A "learner" can always create and add their own notes, which they can also edit and delete. Also - things depend on the permissions, but even if a user does not have permission to "edit/delete" workshop files, they can still do it, which makes it count as a fork. Basically a user edits their local copy the same way you can change facebook by editing the code in the browser devtools. It just changes for you and nobody else.

Also, if a user edits and changes things, it is always version controlled, so they can always "roll back" That is just inherent in the technology we are using, so its quite straight forward to implement later on.

how should be divide these issues? should I deprecate the previous pop-overs, create a separate issue and a page on Figma for pop-over container. Then a different issue and Figma page for each pop-over’s body contents? Also, since this change will be made on every pop-over component. I create 1 worklog and link it everywhere? This will also, require us to create different explanatory videos for those changed pop-overs. How about we just use the worklog rather than creating explanatory videos? Since those are basically addressing the same thing.

Yes, do that. The new component version doesn't need to have an explanatory video linked to it. We still have the previous version that has it. And when we use the new version as an input, a user can always find the from issue and check the comment where that input was created and watch the worklog.

We only produce an explanatory video for special version. I would say the next time we do that is when we finish the TWM and know all components are final. Then we do one more round of explanatory videos and create a final version for each component that has an explanatory video again.

If I understand correctly, you are taking about using dependencies to showcase what will be the possible parameter in that component designs?

Yes, basically. The developer will see the popover component The developer checks the dependencies The developer also reads the component description Also - for the final version when we finish the whole TWM - we will add an explanatory video per component This knowledge should be sufficient for a developer to figure out how to structure paramters

I use Focus To-Do.

Sweet. Looks cool. I am always only using free open source in browser tools. This one looks amazing, but it's an app that needs downloading.

The Tiling Window Manager Github process updates could maybe have the ‘task management and figma versioning video as @input

Yes, I think that should be the case. I would also recommend we create another task for a document. Something like video-script and use that to create the video. What I have noticed is that the final video is much easier to produce once the script is finalized. We can decide what to put in the video, what to say in those section, what we are missing etc. Furthermore, it is far more easier to make adjustments to than a video. During recording, if I mess up once, I have to restart the whole recording again. Which is a huge waste of time.

Perfect. Yes do it. Also the script thing sounds good. could be a sub task (=sub issue). Maybe create a hackmd output document and write down the first version of the script.

Actually "hackmd" supports slides. I would preferif we prepare the slides in hackmd. Hackmd itself also allows to include a Note: with each slide. That Note won't be visible to the audience, but only to the person presenting. We maybe should use those Note: and generally the hackmd slide deck mode to create that "script" you are talking about.

For example, check my slide deck from the conference

If you click the green SHARE button and click on slide preview, you can see the slide deck mode

If you click ? in the slide presentation mode you can see all hotkeys, including how to show speaker notes

serapath commented 1 year ago

feedback 2022.10.26

worklog-1 2022.10.25

  • done Create a Task management issue to handle all the management task

    • done create the issue Task Management #124 - 5m
    • done List all the recent completed tasks related to TWM management in the new issue - 25m
    • done record a video and update comment - 18m

looks good. But please, can you link the @input and @output documents too?

Which contains the initial video, which should even include the version you shared with me before the talk. Then the version you talked about during the code camp Then the version you made now And then the next upcoming version of the video. All with a version tag (in the video name)

That's kinda missing, otherwise, great :-)