Design - task messenger #12
Comments
tasks -
|
|
feedback Just some feedback while watching your worklog. One spontaneous feature that comes to mind would be if there was a mechanism to help people who work on tasks to log/track time. Basically mechanisms to help them with all the steps that are currently tedious when preparing a worklog in markdown on github, creating the worklog video on youtube, updating the hackmd file, etc... I do think, because you basically already go through this with us all the time, you have this extra insight into this process and what would really help to simplify the administrative overhead :-)
Unlike the datdot app, everything is much less written in stone, so now you take notes, but we definitely need your opinion and we need to brainstorm what and why somthing would make the UI/UX better for users in the end. Now this is when you enter a specific task room which is in an early stage. When creating a task room, there might not yet be anyone assigned to work on a task. The same is true for people who want to help fund a task to get people paid who do the work. So this process needs to also be modelled in the task messenger. What is the ideal process for it? Toshi did this and you could then manage who you work with and maybe even get other people to help you fund the tasks you want. So that is what this is about. Of course - we are still in the middle of figuring out how this should work and what david did is just his proposal and maybe we can find better ways :-) Here for example we are talking about the send message field and choosing specific "chat actions" and then a form or steps that a user need to fill out to submit a specific task action. Again, in VSCode or mnay tools, one can interact directly with the "file explorer" to edit/delete/add/... files or folders. In the same way, it remains a question what is the best way to express all that logic. We want to keep it compact and concise and minimal. Maybe what david did so far here is good already or maybe we find even better ideas. For now this is what we have, but keep in mind, that all of this can change if we decide to make it even better :-) So the above screen shows a chat user "Prof Dumbodole" writing:
So the "popup" is a prompt to the maintainer or "manager" of the task to accept those proposed changes by clicking "accept". Alternatively they can "view contract amendment", which basically is supposed the before/after or difference or basically what exactly was changed in the task structure. In that way we get a more controlled back and forth with clear intents and clear acceptance of what is actually going on :-) For example, in our methodology, in every worklog, at the end, you could provide under "proposals" a list of new or modified tasks to work on next and in my feedback comment i am supposed to accept/reject/modify those tasks and once accepted you could then go on and work on them. So that is what this is about. create task
e.g. an "exercise" is usually an unpaid task created by a teacher. So the modes in who creates a task. Who manages a task. Who funds a task... or if there are funds at all ..and in which order... might differ, but once those modalities are clear, then working on such tasks or projects follows the same logic regardless of how it was created. Your explanation was good. The ❓ just means an output is planned (doesnt exist yet) The 📦 means the output is created and wont change anymore. The specific new output or new version of a file is now ready to be used as an input in future tasks. Here the main idea was to try to represent people assigned to a task and also candidates. So a task to assess people might be a task in itself and while multiple candidates go in, only maybe one candidate is actually chosen and other candidates are either not chosen or maybe chosen for a different task. are candidates themselves 1:1 chat rooms? I don't think we have a clear answer yet, but tis is what is experimented with in this screenshot above. |
tasks -
|
|
feedback You ask on the last (Mobile Version 0.0.4), what the bottom menu shows, but i do think the idea was to have the navigation of task explorer on the bottom as well. So you can send messages in a chat or switch to the task explorer and navigate to different task chats. On desktop, you have enough space to also show both in parallel i assume :-) You also ask about one icon in the upper right corner I have no idea what it was. Maybe david has a later worklog where he talks about this version, but i don't really remember what it is. Maybe that says it's not intuitive and we should reconsider? :P ... Otherwise Great. I think if we now can implement a new prototype with all the features and all the components it uses, based off the information you have gathered, that would be great. One complete wireframe that shows every possible feature, maybe following a little "example project" from start to finish, where participants create, apply, assign, work, give feedback, close tasks, etc...to basically walk through a prototype that shows off every aspect of the task messenger, that would be cool. |
tasks -
|
|
feedback Overall, good ideas. How to aproach in general? My main suggestion would be, because there are sooo many parts and features involved, that we sketch out this app section by section or component by component. We already started with Ali to create and improve the But e.g. Form Wizards, Task Room Info, Input Action Bar, etc... we can probably try to break down the task messenger into some major components that cover the main features, and then we work out the details and put them together to slowly in detail work through everything without getting overwhelmed? below is some extra feedback about your worklog video: actions:Yes, you can add a feedback entry to actions. It would make sense to display "give feedback" when a worklog is selected. You also mentioned, that when a worklog is selected, there might be a sub thread or some section where just that worklog is discussed? chat messagesalso chat messages might need a little link to jump and link exactly to a specific chat message. also, all feedback messages we discuss or at least selected ones can become "input" for the next tasks to create the next worklog. This process will probably be refined and improved once we actually start using the app :-) action selection:Also, we want to keep things compact and minimal, also for terminal UI. A "different page", when e.g. selecting an action like worklog, makes on lose the context of the chat and tasks that were selected, so maybe a popup or just a form that expands below or above the input field would be enough and then we copy the idea of the "steps wizard form" that we have when creating plans in datdot? We can see and try what works best notificationshaving a little dot sounds good. let's see where and how :-) learning the app - videoyes agree, a 5 minute video is kinda dull to watch.
maybe options can be combined as well. e.g. could there be a "bot" that creates tasks to learn about the task messenger and then you complete those tasks and get a badge? ...i dont know. we can also save this question until the end and for now ignore the learning part. Maybe the app will be so intuitive and self explanatory that it isnt needed to explain anything at all anyway :-) task creation
Maybe this place isn't the best way to go about it and not every task even needs this. applicantsyes, what i said that applicants are inputs and an assessment or hiring task can have the chosen candidate as an output is just a thought - an option. It is at this point very unclear of what the best way of dealing with people is and how the task messenger could support the process of finding people to work with in the first place. Maybe that is "out of scope" for the task messenger in general? But then, if somebody is assigned a task to find candidates and hire them, those tasks will probably be managed through the task messenger ...and what is the output of a task to find new people to work with? ...i assume the task is completed when you found people to work with. create task formOne issue i have with this approach is, that although it looks slick and professional, it is using quite a lot of screen real estate. I think i strongly prefer to find the most minimalistic "by the way" UI/UX for most things, so that i don't even feel that i did a big intimidating thing like filling out a big form with lots of information. (i am exagerating maybe, but in terms of clicks, typing, movements and visuals) i hope we can keep it super super lean. So that's more a formal comment. Nothing is wrong with the form seen above. The content is good of course.
This "template" might influence the wizard or form to fill out, by showing some or skipping other fields when initially creating a task and assigning people to roles. feedback form
apply and/or fund
you can click the task to enter the chat room and see all details and sub tasks. you can click apply and that starts the process that makes you an applicant/candidate to maybe work on it. or you click fund and top up the budget of a specific task. if this task is e.g. a "proposal", then maybe somebody can apply as the "task manager" as well and a proposer/worker might accept the "task manager" if the task manager is a funder or maybe sent by a funder ... so that button isnt even shown. There is no concept of actually leaving or clicking and going outside of the "task messenger" ever. all links and actions are happening within. The only exception might be links as input or output documents. Those could technically live outside the task messenger, but nothing else should.
You might still see the task as read only in the same way as you can go around github repositories and read github issues. **at the moment, it is not planned to make a "public square" where people can write into a chat without being first in a role of applying/funding/manging/working/etc... Maybe there should be a way of opening a "new" task and relate it to a project, just like on github, somebody can open an issue related to a bug or a feature request. I do think, that kind of option should exist not next to "tasks" in the task tree, but next to "outputs" in a task tree, because an output can be a component or an app and users might actually want to give feeedback or report bugs or feature requests and then ...that could be the start how others can apply for that task or fund that task or manage that task... contract updatestechnically, every worklog submitted with logged time and every feedback that doesnt reject but accept the worklog is a contract update, in the sense that now there is a requirement to pay for that logged time. So the task messenger from applying as a candidate and getting some budget, all the way through managing the tasks and sub tasks and rounds of worklogs and feedback, until the final delivery of outputs... is all about creating/managing contracts if you want to "nit pick" :D
If every task is a contract or sub contract. We just want to call them "tasks" and "worklogs" and "feedback" instead of "contracts" and "sub contracts" and "contract amendment journals" because... eh... i prefer to think in terms of "productivity tooling" and not in legal terms. task explorer details
Maybe - you will even work on multiple projects - not just with me, but with others in the future, using this tool (maybe not you, but somebody else might do that). How do i keep track of all my tasks and projects and what i am working on for others and what i am working on by hiring or delegating to others and how does it all fit together? If somebody gets more experienced, they might take on bigger and bigger project and delegate a lot, but that all requires features to keep track of things. Anyway - long story short - the goal is, that everyone can use it to manage their own projects (from a shopping list) ...to (building rockets to fly to mars) The only different is the task trees become a lot biggger and a lot more people might be involved, but otherwise it all stays the same. Let's for now just roll with what Ali created and we will slowly refine it and improve it maybe later when we have all the rest figured out and a nice theme and then we can start using it as well. example: task message counts
Probably rarely somebody would be interested in the exact number of new messages - if anyone is, they can still count, but it is probably too rare to reserve space for the actual number of new messages :-) Also, the actual tasks somebody works on should be "pinnable" as well 📌 so you can just keep important stuff visible and navigate from your pin's to other stuff if important... or autocomplete search stuff. One more thing.
So there shouldn't be too many new messages and if there are, they are probably important :D This idea is on purpose to avoid big spammy rooms with lots of messages. This messenger's goal is to be very task/purpose focused on goals unlike all other messengers :-) It might even be important to visually indicate if a task has a new "text message" vs. a new "contract amendment proposal" (e.g. a submitted worklog) or a "accepted contract amendment" (e.g. a feedback that accepts a worklog). These differences might deserve different indicators ...and if somebody wants to put an alter or indicate spontaneous urgency in one task, maybe they want to indicate that as well.. maybe by tagging somebody or by submitting a special "deadline action" to the task chat. tasks inside other tasksWhatever works well. If i am in a specific task room and work on that task and then i or we figure out specific parts of that task will take more effort, it would be cool to create a little sub tasks directly which will then also be visible in the task tree and easily see inside a task how many unfinished subtasks the current task room has.
The sub task icon here means to create a sub task of the current task room also visible in the task tree explorer. The input and output means to add another input or output to the current task room (also visible in the task tree explorer as inputs and outputs to the current task then). The invite action means to generate an invite link to the current task room. What is missing here seems to be to create a worklog, but maybe that is an option only available once you have the role of a "worker" in a task and ...a maintainer would only be able to post "feedback" but only when there is already a "worklog" posted. time trackingyes - let's experiment to see what works best in practice. |
|
tasks -
|
tasks -
|
|
feedback I'll give feedback per screen for worklog 29 here. Generally, I'd prefer to start with a dark theme, because opening it full screen Also, this time, your microphone quality was really bad, so i could not really Generally my goal is to leave out EVERYTHING we can to make it feel ultra minimal, Also, it would be great to structure the entire messenger into powerful components.
This brings some high level structure to all the details we need. screen 0Let's remove the "Task Messenger [reminder]" bar. screen 1Related to screen 0.
I'd prefer to display task type on screen 0 as dropup menu next to So then UX becomes:
screen 2is the optional dropup menu if user wants to select a different task type, If we actually have a multi-stage process, then the steps should be displayed screen 3goes away screen 4The form for "task name", "payment", "time estimation", "budget", etc... screen 5When an action wizard is completed (e.g. "create task") one returns to the "home screen". As said in The bottom should instead be changed into two bars on top of each othre.
The task nav bar show the currently active task, e.g. "roadmapping". 1.
|
|
feedback Ok, general feedback on the versioning. Now I'm ok, to show a relatively plain version of e.g. the Of course, towards the end we put a high res interactive prototype together that goes into every possible edge case based on a usage scenario that of an example project that uses every possible feature at least once :-) maybe add that as a task in a github issue so we don't forget for later (of course, do this with all details mentioned in feedback comments, so we don't miss anything we discuss here - which happened a lot with previous collaborater and is kinda hard to constantly remind ourselve of when we discuss all this stuff here - it's a lot and a lot of details) Again, "guiding principle": Ok, quick feedback based on wireframes first:
Now when notification icon is clicked to display task tree filtered by rooms and maybe ordered by "impotance" of the type of notification and the notification settings taken into account, maybe it could display in small below each room or entry, which user did what kind of action to show those details and settings allow to configure whether you want that extra detail of information or not. Of course, those details might pop up in actualy system level android/iOS/desktop notification popups, but that's different from the list of notifications. The last screen has a visual of a Let's maybe split every message in the
The "post header" should be a bit technical and informative, but compact. Maybe include an icon to indicate the posted message type, e.g. "worklog" :-) The "message content area" should show the actual message or e.g. worklog card, etc... and doesnt need to show anymore the generic "room post" data displayed in the head of every message i think. The "message footer" could have some possible quick actions. Those would need to be the same as what a user can select from the additional feedback for worklog videoHere you said, if somebody has a feedback, it gives you an indicator in the command list, but that should not be the case. You would get a notification via the regular system level popup notification or when you are in the app, you see them via an indicator on the "notification icon", all described in previous feedbacks above. The command list or action list or "command dropup menu" is only for creating actions yourself and you can only create based on context and role. regarding timer action: also again, regarding actions: Some actions are basically customizing a message, so e.g. EMOJI's are not an action (=command), but instead they are part of the "steps wizard" to customize a text message. And the text mesage in the input field is a preview of what would be sent to the chat room if the steps wizard is completed. regarding task explorer tree
Those are really useful feedback. So maybe the When collapsed, it would be good to maybe expand/collapse a "STATS" or "INFO" section to show the info for the current task room, but only when the user clicks e.g. an Needs a bit of overview (=macro) planning.
We slowly need to puzzle it together. By the way - here another example of how maybe input fields can be more compact |
tasks -
|
|
feedback screen 1
screen 2
screen 3
Of course, the bottom task navbar has only space to display a single entry, which is why you can expand it or slide it up to see and navigate the full task tree. screen 4+1 screen 5+1
Also: the "task navbar" shows a filter symbol, but it wasnt there on the previous screen, so it would be good to know how exactly that works. Last: The "emoji" (as i mentioned in the previous feedback), is not an action, but part of the "steps wizard" of creating a "test message". screen 6+1 (i guess we do the task explorer tree component details in a separate wireframe) screen 7This screen looks incomplete.
imagine it like this. the "action wizard bar", when starting an action, will only turn into the steps wizard, which
A text message has only a single step, which is a form to write the text message and that form includes features to format the text message and add emojis, etc... Now if those features become too many, e.g. like a rich text editor, then we can divide it into multiple steps and the user can jump back and forth to add emojis and change text formatting. The text message as such is previewed, the same as any action (e.g. a worklog card preview for a worklog action) and is only submitted to the task room, when the user finally completes the steps wizard for that action command. last: All in all not super consistent yet, but goes into the right direction. |
tasks -
|
tasks -
|
|
feedback
screen 7: (make worklog action)
Similar to "proposals", but instead of showing changes of new or changed future tasks, it shows changes of work in progress and completed tasks. ...it's past vs. future So the difference is:
FINALLY: if we are currently in a worklog action selected from the action wizard bar, then we now are in the "steps wizard", so the screen should show the remaining steps and the cancel ❌ and confirm ✅ iconscreen 8: (make worklog action + preview)
The idea of the structure to be consistent is bottom is task navbar and action wizard bar, which you can expand to show task tree or select action and when you start steps wizard, just like in datdot there is one or more steps to guide you through a form to execute an action, but the preview will display in the visible content area... which means in our case the chat log, where the message or in this case the "worklog card" will appear and it looks like the real worklog card once sent, but in a state where it is only half filled out and not yet really sent, because sending or rather submitting happens when we complete the steps wizard and press ✅ at the end. We should choose the right amount of steps in the steps wizard to make it convenient to fill out the worklog form without overwhelming a user. The preview card can additionally be interactive, so just like a text mesage, you might be able to interact with the preview to fill out things instead of following the "steps wizard. If you choose a previous or future step from the current step, it will jump to that part of the step wizard and maybe the "preview" highlights what part of the preview is being edited. Also clicking in the preview card into t different part, might jump the steps wizard to the corresponding step. Hope that makes sense. regarding the worklog preview Also, lets try to make sure we always have the best version of the wireframe and all elements across all previous versions we discuss in worklogs :-) I think what i remembered when looking at the "worklog card preview", that already with david we went through some sort of optimization of doing a compact informative card...but anyway, lets keep up the good work. we'll get there. To answer your question:
The worklog preview could be collapsed by default to just show summary while you fill out. screen 9: (home screen: txt mode + unread msgs)This screen is similar to screen4 and has the same issue with the cancel ❌ and confirm ✅ and select action ➕ buttons. Additionally of course is shows the worklog with actions. Anyway, |
|
feedback Yes, I agree with the "Applicants" Screen and that it should be part of the "task tree" as well. The main issue I have with the screen is, that it is just a screen. There is no clear action, steps wizard and generally the flow that leads to this page, adds an applicant? ...is there an invite link to join, etc... we have a lot in Davids work about that and if we do this, this deserves a wireframe that illuminates all these steps and different phases and interactions. As a standalone screen, it does not tell me much of how i would work with this feature.
It's not a normal messenger, but a task messenger. The delete or star or copy or back? button... are clearly either Now what is always possible is, that preview or individual messages in the chat (e.g. accept/reject/modify/... of the worklog card), will have some quick actions associated with that particular type of message chat post entry. But everything that might be available from such a quick action on the post itself, like the accept/reject of worklog cards, ALWAYS needs to be available also from the generic action wizard bar For prior art or inspiration, I do think discord does a good job of enabling plenty of quick actions from the every individual posted chat message which in our case would be called task chat posts, but what we have in addition is to select one or more task room posts and then use the "action wizard bar" to display all available actions in that context and then go through the step wizard to execute one of them. One more thing we could consider is, that when you are currently NOT in "steps wizard mode" (for text messages that looks like an input bar), then you are in action select mode, but we could literally allow this to be displayed as a bar with lots of action icons and a "..." icon. If you click expand on the action bar instead of an action icon, it would still go into the dropup mode and display he Only when you finally select an action, it will go again into the steps wizard. The actions you do list seem to be somewhat useful, but again, we need to start to find a more systematic way of not forgetting all the different kinds of actions and things we talk about to make progress and avoid regression at all costs. A new thought about the "filter" icon. Hence, i do think, search/filter/etc... with a "steps wizard" to configure it, should be yet another action in the action bar and when selected gives you options in the action wizard. In the end, when you are done, you can Somehow that direction would neatly fit into our current systematic way of dealing with actions and putting all functionality in a generic standardized way into the task messenger. Create Task screens are interesting, but i do think again, the "steps wizard bar" is missing so i dont know in which step i am and how to confirm everything and where is the "task tree snippet preview" of the task tree entry or subtree i am creating while i am filling out the steps wizard. This whol form of both screens hsa to be adjusted to this generic mechanism we already have, which is steps wizard, task tree, action wizard bar action, etc... We had "applicants" and you said they might need to show up in the "task tree" and I agree, but then why is the assigned applicant not shown in the task tree that lists those things here as well? The form needs to change with this in mind. The "description" for example might be an optional step in the task wizard, but if it is filled out, then that will create some sort of freshly created single "description.txt" input document for the new task, that will contain that task. That input is special in so far, that this input was never created as an OUTPUT of a previous task. Those kinds of input exist every time, we upload a file from our disk that was not created through submitting a worklog. Regarding additional details of task creation, I think david has plenty of screens and we can even search in the github issue and wizard amigos discord channel from david if we find additional related information when we focus on the exact details. Lastly, in the bottom menu bar, you made an icon to "edit" the thing. RecommendationThere are a lot of thoughts you mention for each part of the task messenger and i would highly recommend to slowly create pages for each major component and even if we dont wireframe those components individually yet, because we are still in "overview mode", we could collect in v0.0.0 of that component just a big text box to collect "features & thoughts" about what needs to be considered and a collage of little screenshots with notes and so on. The first real draft of the component to include that set of listed ideas or thoughts, can be v0.0.1 I am otherwise a bit afraid that we will forget to capture some of the ideas we are talking about :-) |
tasks -
|
|
feedback So on the first screen, the "task nav bar" or whatever we call it does not exist yet, because there are no tasks, so the bottom starts with the "action wizard bar". Once we created a first task, the "task nav bar" will also exist and hence the "action wizard bar" is now on top of the "task nav bar". Eventually we might change the first screen to have a "task nav bar" from the beginning, but without task, but it at least contains the "user profile" ...but we'll see. I am definitely for your idea of making the "action wizard bar" always look like the "action wizard bar", so screen 1 and screen 3 should somhow show the "action wizard bar" in the same style, whatever we choose. ACTUALLY thinking a bit more, see: I was thinking So maybe we need also an empty "task nav bar" on screen 0 so that can already include the |
tasks -
|
|
feedback
same for your second version: clicking the Maybe the menu is the same. If a message is selected, a user can always use the command bar to type But the same can be achieved by clicking Now if multiple cards are selected then the card So maybe the best option is to not have quick actions on a message but just click a message to select it and click it again to unselect it When messages are selected, a user can use the command bar to use any action, like It seems to make the messenger simpler. What I am thinking is, maybe we again should take inspiration from "datdot" and have an action bar with action icons. The "quick action bar" adapts to context. How about that? regarding worklog previewSomehow this does not seem right.
Now next, the Clicking on the step "worklog video" would show or jump to the field were the worklog video link can be edited. If a steps wizard has too many steps, then Lastly, as told on discord (even though the preview here makes no sense to look like an "editor", if we had an editor, those features of showing bold/italic text or bulletpointsm etc... which look more like what should be possible for a text message type, should be BELOW the editor, no bars above. |
tasks -
|
tasks -
|
|
feedback regarding
|
|
feedback regarding worklog 37
When it comes to the "action bar".
Regarding text messages, the feedback from my previous feedback comment applies.
If a given message is selected, then the available actions adapt to that context and e.g. allow to delete or edit that message, etc... that is good. The one thing i am not sure of is the "copy message link". But in general, the way how the action wizard bar and actions should work is what i described in my previous feedback comment for worklog 36. I was thinking again about the threads and it is a tricky one. The problem we have at the moment is, we do have a "worklog channel" on discord with an endless amount of worklogs, so to bring a little bit of structure to it, we try to create threads for worklogs to discuss the worklog in that thread. Now in the task messenger we will have a much easier time to merge what we do on discord with what we do on github in one tool and it is very easy to make sub tasks, which are already like threads in a way. Usually, a worklog submitted will finish a task, which means usually a worklog ends a specific task room and we can continue in the super task room or other sub task rooms. It might sometimes happen that a worklog needs refinement or does not yet close the task room, but that should probably be fine. I think creating rooms that are threads and not task rooms is a feature i would like to avoid for now until we can try the task messenger and see if that's enough and only add additional non-task rooms, such as threads, if really needed. So no need to create any thread room names, because the task explorer will always show the current task room we are in. Message history looks pretty good to me. Now this shows your idea of a thread, but let's just imagine this was a regular task room. Otherwise, on the right side, the message that shows the creation of a thread should instead show up when we create and accept task proposals to create new tasks. Those show up in the task explorer, but also in the submitted action message, that created those sub tasks. Cant wait to see figma version controlled components for each type of message and how it looks in the chat history. Same for step wizard for creating those :-) |
tasks -
|
|
feedback
So this leads me to think, the box should probably appear at the very bottom, even below the bar that contains the ❓ button. This is great. By default, there would be NO QUICK ACTIONS, so it would look exactly the way it looks now in your wireframe.
The text input field is still basic with no extra features, like the option to select 1 or more messages as being replied to, etc... but maybe fine for now. This is the action list and maybe the clicking these messages to jump to the referenced mesage is great, but
In your example there are only 2 referenced messages, but it could be more. Maybe we need a temporary navigation bar that can appear above the bottom bars ... similar to how on some websites or in messengers, there is a button "scroll to bottom" that appears only if you are not scrolled to the bottom at the moment. we could just extend that concept with more navigation options that appear when needed.
This includes an ability to display DIFFs.
We are here filling out the "step wizard form" to execute a "text type action" So we should make sure this always is designed to fit into the general structure of:
The "step wizard" has a cancel option. It has a next step option (if there are more than one step) and it finally has a submit action ...and of course a preview. In this particular screen, many of those generic fields are missing.
Generally, no matter which "step wizard" we are defining for which action type, e.g. text type, worklog type, etc... => We should make sure they always follow the same general "Step wizard" rules for any action type.
Yes we do need version control. I dont exactly know what you mean by "parallelogram law" or why it would apply here. We will do versioning for sure. |
tasks -
|
@todo@input📦 Skill-value-network_discord messages@output📦Task messenger notes_figmafrom comment@input📦 Skill-value-network_discord messages@output📦Task messenger notes_figmafrom comment@input📦 Skill-value-network_discord messages@output📦Task messenger notes_figmafrom comment@input📦 wireframes-v0.0.1@output📦wireframesfrom comment@input📦 discord_messages/task messanger@output📦wireframes v0.0.1from comment@input📦 discord_messages/action wizard@input📦 github feedback@output📦wireframes v0.0.2from comment@input📦 discord_messages/action wizard@input📦 github feedback@input📦 Sketches@output📦wireframes v0.0.3from comment@input📦 discord_messages/action wizard@input📦 github feedback@output📦wireframes v0.0.3from comment@input📦 github feedback@input📦 github feedback@output📦hackmd-task messenger notesfrom comment@input📦 github feedback@input📦 github feedback@input📦 github feedback@output📦wireframes v0.0.4from comment@input📦 github feedback@input📦 hackmd comments@output📦wireframes v0.0.5from comment@input📦 github feedback@input📦 discord messages@input📦 hackmd comments@output📦wireframes v0.0.6from comment@input📦 github feedback@input📦 github feedback@input📦 discord messages@output📦wireframes v0.0.7from comment@input📦 wireframes v0.0.7@output📦Task messenger explanation videofrom commentThe text was updated successfully, but these errors were encountered: