Open alyhxn opened 5 months ago
alyhxn
commented
5 months ago 2024.04.0845min1h30min15min@output :package: task_explorer_v0.0.1
serapath
commented
5 months ago feedback 2024.04.13
┬ └, ├, ┼, ┌ and ┴ to connect items without gaps.next input, but:button.fig as input, which when expanded shows next implement button, ok
implement button earlier (next task from "button repo" task, doesn't list it📌📭┬🔳roadmap🔗
├📭┬🔳UI/UX design🔗
│ ├📭┬📤┬🔳design button🔗
│ │ │ └➖┬❓button-repo/
│ │ │ ├🖇️🔳implement searchbar🔗
│ │ │ └🖇️🔳implement button🔗
│ │ ├📤┬🔳make button icon🔗
│ │ │ └➖┬❓button-icon.svg
│ │ │ ├🖇️🔳implement searchbar🔗
│ │ │ └🖇️🔳implement button🔗
│ │ └📤─🔳wireframe button🔗
│ └📪─📤🔳design searchbar🔗
│
└📭┬🔳implementation🔗
│ ┌📥❓button-repo/🖇🔳design button🔗
│ ├📥❓button-repo/button-icon.svg🖇🔳make button icon🔗
│ ├📥❓button-repo/button.fig🖇🔳wireframe button🔗
├📭┬📤┼📥️🔳implement button🔗
│ │ ├➕─📦button-repo/button.js🔗
│ │ ├➕─❓button-repo/button.css
│ │ └➖┬❓button-repo/button.html
│ │ └🖇️🔳demonstrate button preview🔗
│ └🔳write button js, css and html
└📭─📤─📥️🔳implement searchbar🔗for example, under roadmap - UI/UX design - desing button we have output button repo.
when expanded, button repo lists implement serachbar and implement button tasks as
next tasks and prefixes both with 🖇️, which means these are just references, links,
anchor tags (e.g. <a href="#<element-id>">...</a> which when trying to click and expand
will rather scroll/jump to the already expanded version of that task.
You can see the already expanded version under roadmpa - implementation - ...
implement buttonregarding invite, i expect to work again on the currently selected task and probably
copy some sort of invite code (maybe the task id and my user id) to the clipboard.
I can then go to ANAs task messenger and pres join and paste that invite link into the messenger input field and press "join" or enter... which will probably add that task from bob to ana's task explorer as well. Next to the messenger input field should probably be a > send button or something to press as an alternative to hitting ENTER.
So i do not expect to enter the "user id" of the user i want to invite. This is maybe an advanced feature to create an invite code that can only be used by a given userid and otherwise will not grant access, but otherwise invite code would be shared with other users and they use it to join.
Having access to the entire "sub tree" of tasks afte ran invite is ok. But, through exploring the "container tasks" (expand up), one might be able to explore all the way to the root task of that task branch.
Of course, some task branches might not be linked to from anywhere, so you cannot explore them through that mechanism.
I imagine, if bob joined task X and expanands the container tasks (=parents), bob's messenger could query ana's messenger for the listed task.id's to receive more data, slowly filling in the gaps while exploring.
We should probbaly add an artificial DELAY (e.g. setTimeout) when doing invites and
those kinds of queries, to simulate network latency and add e.g. a loading spinner until
the response becomes available.
So - no popup when an invite is given. Instead - invites happen in side channels or ... "out of band". In this case, we just use the clipboard to copy/paste. In the real world, we might also use an existing messenger to share invite codes. Or we might use "QR codes" when meeting in person. There are many ways - for now let's skip an "in band" approach for invites and just do the "copy/paste thing if that makes sense.
Also, i expected some sort of "system messages", which means every tim i execute an "add, "drop" or "edit" or any action, it will log some sort of message into the chat messenger log.
The join and add messages will probably get added in the container task chat room.
When i select a task and press e.g. drop or edit it deselects my selection and nothing seems to happen.
Also, i can't seem to sometimes add an output to a task. nothing happens.
Maybe after i added an output and click again to collapse and the try to add another one.
It's definitely buggy i think.
Again, every time i am adding, dropping, editing, etc... some sort of system level message should be logged in the task room so i can see the history of all my modifications (and maybe in the future even search/filter for specific actions that were done in the past.
Regarding the initial tasks shown in the messenger, how about adding one more button in the menu down next to the messenger input field that allows to IMPORT and EXPORT.
When clicking IMPORT it would have a simple dropup menu with only a single example-tasks.json file and it will create the kind of task structure currently visibile in the task messenger.
On the other hand, if you made enough changes, you could click EXPORT and add a name to save it into that dropup menu.
Maybe we should have a little "reset" button to reset all modification back to initial :-)
Also, we can have 2 types of imports
Both can serve to create/restore a task structure
QUESTION: should it be possible to share sub tasks between 2 or more projects or root tasks? ANSWER: yes :-)
Actually, yet another "action" should be pin, which can be clicked on ANY task and it will
pin the selected task, e.g. implement button as yet another "root task" (so it looks like a separate project) ...until you maybe UNPIN it again. It's like a bookmark.
You can then navigate to implement button by clicking directly on that root level pin and expand the task, or by expanding roadmap -> implmentation -> implment button again.
up to you.
QUESTION: can e.g. UI/UX design be used as input to a newly created root level Task?
ANSWER: maybe!
One line of though we have is, that: Tasks CAN NEVER be input or output of other tasks, only actualy results/documents/files/links can be input to and output of tasks. So a task becomes an input to another tasks only indirectly, by having the outputs of that other task become input of that new task.
Another line of thought is, you could have a task:
and then another task
So the above are just different perspectives on the same project/task structure. In one context you want to know everything about the button component and how far it is In another context you want to know how much wireframing is done already
So listing make menu wireframe as outputs of more than one task.
or ...creating a make wireframes task and making it an additional "task input" to the make menu wireframe makes sense.
I would not call it an INPUT though.
The task make wireframes is not an input to make button wireframe
It is more a container, a cateogry, a summary of the tasks it contains.
That is why i talk about sub tasks and container tasks ...not "parents" and "children". Because... to me, "parents" and "children" is what living beings have. I try to avoid words like "master/slave" or "parent/children" or "kill child process" when talking tech - even though they are traditionally in use in computer science, but are also quite disturbing when any normal person listens to the conversation :D
So given, you want to be able to customize your task perspectives and keep track of a bunch of tasks in new ways, e.g. create a new task container task and then just "link" a bunch of other tasks to track them better, i think that is legit.
So yes, this should be possible :-)
Now regarding code, e.g.:
channel_up.send({
head: [id, channel_up.send.id, channel_up.mid++],
type: 'send',
data: {
to: 'task_explorer', route: ['up', 'task_explorer'],
users, type: 'on_add_task', data: { name, ...}
}
})The issue with the above is, that we essentially HARD CODE the dependencies.
Somebody using the components would need to know.
Maybe in their app, the "route..." is a different one.
I agree, that this is a difficult problem. So just keep it in mind and see how it goes and if we can improve.
Sometimes the best way is to hard code things and then plan to use it in a different context, where it becomes a problem and then the you created yourself the circumstances that will guide the solution to solve the problem in the best way :-)
Let's put it another way - think about the "invite" feature again.
If we create an invite and copy/paste it, then maybe all the information needed
is contained in the invite link, so it comes from there and doesnt have to be hard coded.
Maybe we need a query message, which will be broadcasted forward and if an existing node
knows a receiver already, they can stop broadcasting and send the message back to the
original sender. If the intermediate node does not know the target yet, it continues
broadcasting and appends itself to the route that is sent with the broadcasted message.
(Broadcasted to all, but NOT the node it was received from).
Also - if a node already received the same query in the past it ignores it (no cycles).
...This way, the invite code only needs to contain the ID of the invite maker.
The invite user can send a message to the invite maker ID and the up (container/parents'...)
will use the query message to figure out or discover the best route towards the invite maker.
Components are connected in a graph, which means dijkstra and other algorithms can help here. But this time we deal with routers, so of course it is from the perspective of each node remembering the kind of routes to other nodes they know.
So far, the network of components is stable, because we aren't yet drag'n'dropping them to re-arrange the network :P
...but WE MIGHT DO THAT once we want to drag'n'drop tasks to re-arrange then :D
By the way +1 for the feature of adding even more users to the mix :-)
alyhxn
commented
5 months ago 2024.04.18task_explorer_v0.0.1
1h20min15min1h30min2h40min45min20min20min1h10min20min@output :package: task_explorer_v0.0.2Sorry, some features like edit, delete, and import are not there because I thought of finishing the ones already implemented, debugging, checking out edge cases, and cleaning up the code before things get more complicated. Also, I did not mention any code in the worklog because it was already getting lengthy. If you need some insights I can record another video for what's going on in code.
serapath
commented
5 months ago feedback 2024.04.18
I will edit and give more feedback after i watched the worklog, but i can give some of it already checking the app.
Haven't seen the worklog video yet, but i saw a green dot after a task, but not always and i can't reproduce it. Maybe a bug or at least a bit unclear. Maybe it gets clearer when i watch the video.
the chat area should be "above" the task explorer for usability - moving the mouse back and forther between button on the bottom and task explorer on top is tedious.
when i click the + button, the element in the task explorer loses focus (the last selected element should KEEP the focus, so i know where to add sub tasks or inputs or outputs to
writing a message and hitting enter sends it, but the send button seems to not work
when the task tree is selected with the mouse and i copy/paste, i expect it to be formatted properly in the text editor. Currently that doesn't seem to work. It would be great if we cna make that work :-) ...maybe we need to structure html a bit different. Many lintes instead of nested elements, similar to how a text editor works basically. I saw the problem, because selecting did not select a line but the entire box:
check for example the input field in discord and select the commands menu and then imagine how that would look in the terminal. We should have a few "pinned" actions, like what you currently did with join, export and add/+ (user can select), otherwise for more actions there should be a dropdown/dropup menu ...on the terminal this would look as follows:
/🛠commands > ... input field....
-----------------------------
/🗃list 📌
/📩text 📌
/🆕🔳task 🕳️
/🔳subtask 🕳️
/📨invite 🕳️
/📥input 🕳️
/📤output 🕳️
/😀emoji` 📌
/📎attach <file>` 📌Let's try to really make everything look and behave as a terminal and if i select and paste it into a text editor it also looks formatted in the above way :-)
Here is another image
Let's for now assume the root for tasks is always:
📓─📈planClick the black/gray "book" emoji to expand the plan to see all main project tasks.
📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 └📪─📪🗃─🗃⏹️project2🔗
click the first post box of project2 task to see super tasks📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 │ ┌📈plan🔗 └📭┴📪🗃─🗃⏹️project2
click the second postbox of project2 task to see sub tasks📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 │ ┌📈plan🔗 └📭┼📭🗃─🗃⏹️project2 ├📪─📪🗃─🗃✅implement button ├📪─📪🗃─🗃⏹️implement inputfield └📪─📪🗃─🗃🔳implement searchbar
click the first postbox again to collapse super tasks📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 └📪┬📭🗃─🗃⏹️project2 ├📪─📪🗃─🗃✅implement button ├📪─📪🗃─🗃⏹️implement inputfield └📪─📪🗃─🗃🔳implement searchbar
click the first drawer to show input document links for project2📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 │ ┌📥️─📦description.txt🖇🔳prepare-project2🔗 │ ├📥️─❓searchbar.js🖇🔳implement searchbar🔗 │ ├📥️─📦button.js🖇🔳implement button🔗 └📪┬📭🗂┴🗃⏹️project2 ├📪─📪🗃─🗃✅implement button ├📪─📪🗃─🗃⏹️implement inputfield └📪─📪🗃─🗃🔳implement searchbar
The `description.txt` and `diagram.svg` were outputs of the `prepare-project2` task. Now click the second drawer.📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 │ ┌📥️─📦description.txt🖇🔳prepare-project2🔗 │ ├📥️─❓searchbar.js🖇🔳implement searchbar🔗 │ ├📥️─📦button.js🖇🔳implement button🔗 └📭┬📪🗂┼🗂⏹️project2 │ └📥️─🏭project2-repository🔗 ├📪─📪🗃─🗃✅implement button ├📪─📪🗃─🗃⏹️implement inputfield └📪─📪🗃─🗃🔳implement searchbar
click the inbox icon next to e.g. `searchbar.js` to see where it is used as input📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 │ ┌📥️─📦description.txt🖇🔳prepare-project2🔗 │ ├📤┬❓searchbar.js🖇🔳implement searchbar🔗 │ │ └⏹️project2🔗 │ ├📥️─📦button.js🖇🔳implement button🔗 └📭┬📪🗂┼🗂⏹️project2 │ └🏁─🏭project2-repository🔗 ├📪─📪🗃─🗃✅implement button ├📪─📪🗃─🗃⏹️implement inputfield └📪─📪🗃─🗃🔳implement searchbar
and then the first drawer to collapse inputs📖┬📈plan ├📪─📪🗃─🗃✅prepare-project2🔗 └📭┬📪🗃┬🗂⏹️project2 │ └🏁─🏭project2-repository🔗 ├📪─📪🗃─🗃✅implement button ├📪─📪🗃─🗃⏹️implement inputfield └📪─📪🗃─🗃🔳implement searchbar
**emoji descriptions:**
00. 🏁 an output document is not used anywhere as input
01. 📥️ expand next tasks where document is used
02. 📤 collapse next tasks where document is used
03. 📪 expand sub or super tasks
04. 📭 collapse sub or super tasks
05. ✅ task is finished
06. 🔳 task is open and ready to be worked on
07. ⬛ task is not yet ready to be worked on
08. ⏹️ task is in progress (some inputs/outputs/sub tasks are done or in progress)
09. 🗃 expand inputs or outputs of task
10. 🗂 collapse inputs or outputs of task
11. 🏭 input/output document link work in progress
12. ❓ input/output document link is planned
13. 📦 input/output document link is created and done
There is of course much more to it, but let's try to make the logic above work and really solid.
---
Additionally, regarding coding.
Let's make the whole task structure persist in `localStorage`, but don't use `localStorage` directly but instead create a tiny wrapper module like
```js
funciton taskdb () {
const db = { ls, add, get, set }
function ls (taskpath = '/') { }
function add (taskpath, name) { }
function get (taskpath) { }
function set (taskpath, task) { }
}...or something like that.... but let's keep it suuuuper simple (we will later anyway replace it with real p2p data structures, so for now it has to just work and be as simple as possible :-)
serapath
commented
5 months ago feedback 2024.004.19
regarding buttons See previous feedback, but otherwise, when a "task" or any item (e.g. an input) is selected in the task explorer, it could show "quick action buttons" in the row after the task name ends. Additionally, one of the "quick actions" could eventually be a "..." or "more" button, to get a dropdown/dropup for more actions.
But if so, this should be in addition and not instead of actions next to the bottom input bar
you suggest that in the end of the worklog, and i think it is a good idea :-) also, "actions" are component api dependent....tasks might have different actions available than document links, but maybe more about this later.
regarding the join
cool idea to press the link symbol for getinng the invite :D
i like that.
But just that you know, you can replace your IP 192.168.10.12:9966 with
localhost:9966 and 📋copy-to-clipboard will work then :-)
regarding permissions which rooms are shared after an invite and visible. I do think it is ok to explore super tasks when a sub task was shared. Especially because the task explorer allows navigation to parents.
Unrelated sibling tasks are not visible, because a user cant navigate to those without an invite.
I also do think we need a "channel footer" for the chat room, to show the room members, maybe the channel title (=task name) and a list of immediate sub tasks and input/outputs.
Imagine it like github issues. If an issue corresponds to a "chat room". The super task is NOT visible The sub tasks content is not visible, because you have to click to get to the different issue, but the list of sub tasks are shown inside the github issue (=chat room)
That information can maybe be collapsed and expanded and when collapsed, it might only show a summary,
regarding chat room
cool that it says "added UI/UX design", but it is inclear that this is a task
and not a document link (input/output) ...it is also unclear if that was done by
bob or ana.
Also "added task" message, cool, but same thing, let's improve those messages.regarding export
cool that you can "save" to disk, but that's not what i meant.
The idea is to use localStorage and pretend it was the file system, to persist things.
Later we will use our "task explorer" component and make a "file explorer" as well,
but for now there can just be a little dropdown list of filenames and export means we can give it a named in the input field (which always turns into the form needed for the specific action we choose) ...if we dont choose a message, it a text message input field... a simple form :-)
localStorage.clear() and reload back to initial stateAlso cool, that only a specific "sub task" can get exported, BUT: => everything a user can navigate to/from might need to be included in that export ==> maybe the "export" needs a marker of the specific task that was focused when exported.
DATA STRUCTURE: Given a "task" can have 10 super tasks (10 parents) But also 10 sub tasks (10 children) Let's just say we have links to "sub" tasks and links to "hub" tasks
task.hubs in hierarchical networks you have hubs and super hubstask.subs you also have "sub hubsEvery task, by making "sub tasks" can turn into a "hub" for those sub tasks.
Also in the datastructure, i would just call it task.user
-> we can have task.user = { ana: 'ana', bob: 'bob' } where we replace the string names
with their real p2p public key addresses or even an object with lots of meta data about them,
or we just give it a unique local ID, e.g. task.user = { ana: 1, bob: 2 } so we can later lookup USERS[id] to get the meta data of users, similar to how we address tasks by task IDs.
So in a task you could select task.user.ana or tasks.user.bob :-)
Also, when it comes to document links, those already have the labels next and from
So we should have task.from and task.next to which point to document ID's.
A document LINK itself also has those fields, e.g. link.next and link.from to
list the TASKS it is used in as an INPUT and link.from lists only one task, where it was used as an OUTPUT :-)
Leaving us with at least 3 main data structures:
const TASKS = {}
const LINKS = {}
const USERS = {}were keys are ID's (numbers) and values are "json objects" to describe a specific task or link or user
Those are the data structures, which should actually be stored at some point in
localStorage instead of just "in memory" by using a very simple adhoc wrapper around localStorage like what i described in my previous feedback comment :-)
regarding jump action
cool. nice :-) especially with the recursive "expand" and scroll. great! :D that's neat.
ADD SIBLING TASK i dont remember asking for an option to add "sibling tasks" instead of sub tasks. The correct way to do that is to go to the "hub task" (=super task) and add the sub tasks there. The only issue is, that would add it at the end of the sub task list and not in between.
Let's first stabelize things and once they are stable, we will need to be able to re-arrange tasks via DRAG AND DROP :-) ..but let's put this in the "backlog" for now and wait until we have everything else working.
ADD STUFF TO TASK
if you add inputs, outputs and tasks to a task, it would be great to have the icons
e.g. for output: 🗃┬🗂, for input 🗂┴🗃, for sub tasks 📪┬📭 for hub tasks 📭┴📪
...to show/display right next to the input field, so i can visually see what kind of thing i am adding.
Again - no siblings for now! (maybe never) ...instead we later do "drag'n'drop"
routes
lets continue with the list of everything we said so far. This is a lot of feedback. When that is done and we have things less buggy, more stable, let's revisit the communication.
Basically - we need a specific "protocol" ...basically some types of messages, which are used internally between all "NODES" to discover routes and then to maintain their own "routing tables".
Usually any component will get connected
The configuration adresses and user provided info (where components allow it to users), can provide all information needed (such as component node addresses) needed by the communication protocol to explore other "Far away" components to talk to.
e.g. an invite link might be: bob/task-explorer/task-15
If ana "JOINS" that link, it can send to that address...
..but as said, lets put it in the backlog.
lets fix all other things first and fix the bugs and clean up code.
alyhxn
commented
5 months ago 2024.04.19+ button click / commands.quick action button after a task when it is selected. (Some buttons like add and join don't need a specific task to be selected so they are good at their place for now)alyhxn
commented
4 months ago 2024.04.242h20min4h1h30min/ command popup - 25min20min35min1h2h10min20min@output :package: task_explorer_v0.0.3serapath
commented
4 months ago feedback 2024.04.24
Nice Changes. Thanks. Below is my feedback :-)
The channel footer with the status about the currently selected task is cool.
Here is a list of stuff i noticed when watching your worklog video:
maybe update the top level task with all tasks (e.g. like user ID's)
the "root task" is not a task and should be called "plan"
below the chat text input field we should be able to expand "devtools"
refactor and cleanup the code to make it fun to read and
the / commands have a little "red pin"
... button for more to show them in dropdown"task status" and "document status" (input/output) emojis are still missing
if a document or task is clicked which is only a link to an already expanded task -> then the click should jump/scroll and shortly "flash" or light up that task -> not yet change the focus or selection, but just to indicate visually where it is
there are some visual bugs and i guess also functinality bugs, where
action buttons
task sharing
adding tasks/input/output
alyhxn
commented
4 months ago 2024.04.282h4h1h1h10min@output :package: task_explorer_list_v0.0.4@output :package: task_explorer_tree_v0.0.4
todo[ ] Create - task_explorer
@output:package: task_explorer_v0.0.1 from comment[ ] Update
task_explorer_v0.0.1@input:package: task_explorer_v0.0.1 from comment@output:package: task_explorer_v0.0.2 from comment@input:package: task_explorer_v0.0.2 from comment/command popup@output:package: task_explorer_v0.0.3 from comment