Open mimi-uxui-dev opened 2 years ago
Hornet004
commented
2 years ago worklog 2022.06.14 8:28PM worklog 2022.06.14 8:28PM worklog 2022.06.14 8:28PM
done iteration 1 - visualizing paid gig/exercice contract chat logs concept
@output 📦 Figma Link1new iteration 2 - visualizing paid gig/exercice contract chat logs concept
@input 📦 Figma Link1new create refined wireframes@output :question: figma link2
serapath
commented
2 years ago feedback 2022.06.14
worklog 2022.06.14 8:28PM worklog 2022.06.14 8:28PM worklog 2022.06.14 8:28PM
doneiteration 1 - visualizing paid gig/exercice contract chat logs concept
@output:package: Figma Link1
newiteration 2 - visualizing paid gig/exercice contract chat logs concept
@input:package: Figma Link1newcreate refined wireframes@output:question:figma link2
:+1: yes, add the new tasks as described in your worklog comment
:+1: regarding all the things you share about the concept in your worklog videos
I recorded a little feedback video regarding the structure of the UI/UX and that we have plans to make it more messenger/chat like ...all of it :-) Essentially we need to merge
see: https://share.vidyard.com/watch/bu2HV3HW1X4byxmL1i5jMs?
serapath
commented
2 years ago @Hornet004 question
2022.06.15
when someone is applying ...are we collecting any information from them? (i.e doc, links e.t.c)
I am thinking of a more solid approach where you need to request to chat someone before chatting them up
You cant just read the job details and start sending the user message ...there would be lots of messages for the employer ... to check out. ...so a more apply button...then the other user receives a request decides to approve or not
@output :package: example flow
serapath
commented
2 years ago feedback 2022.06.15
@Hornet004 question
2022.06.15
- when someone is applying ...are we collecting any information from them? (i.e doc, links e.t.c)
- I am thinking of a more solid approach where you need to request to chat someone before chatting them up
hm, i would not frame the question like that.
think about it as ... we are making a tool (not just for us)
- You cant just read the job details and start sending the user message ...there would be lots of messages for the employer ... to check out. ...so a more apply button...then the other user receives a request decides to approve or not
the "orderer" can close the "gig ad" at any time i'd say once they found enough viable candidates
@outputpackageexample flow
i see your diagram, but ...i think this should be expressed in wireframes of an example conversation and how the screen transitions and how do people use the chat input bar on the bottom of the chat to create specific kind of chat messages that the other side can accept to get to contractual agreements instead of just informal text
Hornet004
commented
2 years ago Suggestion 2022.06.15
- Imagine there is a default bot that shows all gigs and updates new gigs and a sharable link to post on social medias.
- somebody on social media uses the link (e.g. on a discord server or on twitter or facebook) in a group where people with certain skills (e.g. designers) are looking for job or gig opportunities
- The link takes them to the bot page that displays the Job description before clicking apply button.
- the apply button sends an application to the Job creator - he can as well choose to accept, reject or choose to ignore
- If he accepts the new chat displays for the applicant to communicate.
Just my own opinion though because I really value the privacy
Hornet004
commented
2 years ago done create refined wireframes - Created paid gig/exercice contract chat logs concept
@output 📦 Figma Link2serapath
commented
2 years ago feedback 2022.06.17
donecreate refined wireframes - Created paid gig/exercice contract chat logs concept
@outputpackage Figma Link2
wonderful.
just please add some proposal for new or changed task structure, so we can update the top level task comment here in this issue, because your new Figma Link 2 output needs to become input into one or more tasks so we can continue the work and make it lead towards the final outputs of this issue as you can see in this video feedback from me
https://share.vidyard.com/watch/ejPxpamCe8o5jhJqcBnCbc?
One thing upfront about the wireframes ... it is all just rough boxes with no labels at all. We will need real example content and more details to really make a specification that somebody can implement. At the moment things are way to blurry - but maybe for quick iteration that is ok for the first couple of rounds so we can move faster :-)
otherwise: feedback for your worklog video
minute 0:37 bot posts available jobs
minute 0:52 buttons apply now and copy/share link
minute 1:00 about the chat interface where the gig/exercise is posted
minute 2:05 what happens when a user applies
welcome message"minute 2:23 elements in the chat
gig widget box with apply/fund buttons is not always a single task, but:
gig widget box for this task here - its complex, but not everythinggig widget box to apply for this task here - a single task representing an entire big project@info section for additional details on github, so that could be the descriptionminute 3:06 how things behave when the chat progresses
task, description, worklog ...are those meant to be filters for the chat?minute 3:49 chat input bar
contractor and gig authorminute 4:21 job description details
@info section that we have in our github issues and replace it with an initial chat message a gig author can post in the chat ...so when a contractor applies they can start from thereestimations to them in terms of time it takes or money it costs to do them... ...(we dont have that here on github issues yet, but in this wireframes we can add that kind of feature)minute 5:32 markdown function of editing description
minute 6:17 delete chat items
minute 6:43 worklogs
minute 7:21 worklog form
minute 9:20 widget to display a worklog chat entry
minute 10:28 quiz gig/exercise
@output attachments is just text with the answer to the quiz :-)
Ok, this was now quite a lot of feedback, but one thing i would like to add that wasnt yet mentioned in your wireframes :-)
When anyone applies for a task, that task can be a single quiz question, but it could also be a giant project, so usually it is something in between, but it means when i work and talk about one or a few related tasks, like we do here in this github issue about the gig/exercise web component, then we can have a chat and have worklogs, but we should not forget, that this specific github issue chat here is only about one task in the project called:
gig/exercise (paid gig contract chat logs) concept & design (as you can see in the issue title)Now - all it means is, that you could imagine this github issue more like a discord thread if you have seen those. It means a regular chat can have a little "sub discussion" in a named thread and a project where we chat only on one task is similar. Not every single task is a thread, but a bunch of tasks can be grouped in a seperate issue like the issue here is about a few related tasks that describe the wireframe we are working on and if you imagine that as a discord chat, then:
=> there needs to be a way to go "one level up" or "back" to see the parent task or issue
Basically a user, a task author or contractor should be able to navigate out of one particular chat into other chats (which means other issues) of the same project where other chat discussion, like github comments, is happening - does that make sense?
Now again - this should not be complicated, but should be as minimalistic as possible.
...we are building tools for programmers who use developer tools and terminals all day long, so the tools we are building should be more in that mindset and not big buttons and large menus like for end user apps :-)
Hornet004
commented
2 years ago done create iteration 3
@output 📦 Figma Link3serapath
commented
2 years ago feedback 2022.06.20
donecreate iteration 3
@outputpackage Figma Link3
sweet.
could you add a new proposed issue "iteration 4" or something where your figma link4 output document will be @input?
This is soooooo much, si this feedback will be endless but i will split it into multiple parts. This comment here will include the first 5 minutes of your video and give feedback. The next comment will include more.
Your video is 27 minutes long, so therefore this will be a lot of feedback. I think maybe if we bounce more instead of no feedback for a long time and then a lot if input, it would be better, because you would be able to only make 3-5 minute videos and my feedback would also be shorter :-)
otherwise...
Ok, i am watching your video and I still think we still didn't manage to entirely understand each other.
I think the overall figma template has all that default figma stuff we don't need and should delete.
for example:
On most screens you show this, but none of the visual elements has an icon or text yet.
can you change that for the next time?
minute 5:29 overviewThis is probably at minute 5:29 how you should have started the whole thing ... by introducing the overview first.
[start new project] which i think is a good idea.So probably we need a "web tool" where anyone who wants to make new projects can go and it is like a messenger and all it has is a single button: [start new project] and then leads you through the process you describe earlier/later (see below)
Now if a user later returns to that "web tool" page and they already created tasks, maybe they can see an overview over all their projects/tasks cards :-) ...BUT this is not a marketplace, this is a strictly private view where a user can see their own tasks they have created.
how do they see them?
what if i am not a task/project author, but a contractor, because i applied for a project after somebody sent me a link to apply on telegram/discord/whatsapp/facebookMessenger/etc...)?
Maybe it is possible to sort/filter all the chat rooms/conversations based on type (e.g. gig/exercise/...) or based on whether you are the author or you are the contractor :-)
minute 0:49 bot page selection option
lets remove the "bot page selection option" entirely. we don't need it.
You mention the 3 fields here are:
They are entirely unrelated. Please also see my previous feedback for minute 0:37, which means:
tasks, which could be gigs or jobs or exercises, etc... it's all the sametask (job/gig/exercise/...) and post it on an existing job/gig/freelance/etc... social media platform or messenger or whatever :-)"answer quiz", because a quiz is just a particular kind of task a task author can make using the "web tool" to create tasks (the created task could be a job, a gig, an exercise, or any other type of task) ...in the end, an exercise is just a task for a learner to answer questions and maybe get a good mark in the end instead of payment ...but otherwise we treat it the sameminute 0:49 create job
can we remove most of the stuff? ...it is ok if almost everything on the "screen" is white :-) that is cool.
can we remove:
I would say lets add only what we need.
You say this is the page to create job.
Lets imagine there was somewhere a button to "create task" (that's what we should call it, because a gig or exercise are just specific kinds of tasks)... but once i clicked the create task ...whats the first thing that i should do? ...maybe give it a title?
Maybe you can do some little google research to find ways how to make it a nice smooth experience to create a new task/job. Could be that there are some discord bots that do it well. Could be that there are some form maker or survey tools that do it well. The more minimal the better. It should feel like nothing to create quickly a new task.
imagine how discords intput bar works. it has a send icon and icons for stickers/gifs/smilies and a big + button like:
So maybe imagine it more in this direction?
Imagine you would have dozens of people you work with and on your phone you use a messenger to quickly create and assign new tasks and send them to people or post them in other chat rooms to let people apply? how would you do it?
Maybe you could just have options with create new task, and then choose the type?
or have 3 options, like create new gig, create new exercise and create new proposal? (a proposal being something you propose to do and others can fund it so you are paid to work on it)
Then when you hit send, whats next? what else do you need to fill out? ...if you check our github issue structure, and the checklist document, you see how we create todos and intputs/outputs ...thats the kind of structure you need to be able to make.
here is some more information about creating forms for user to fill out and maybe they have fun ways of creating and showing forms, because making new tasks should be fun :-)
preview https://www.typeform.com/templatessummary: it is better than previously, because it now is more a chat, but i would prefer it to be more minimal. I think discord is a good example, but instead of just "chatting" with text and emojis, we need formalized chats where maybe the "form bot" asks for specific information and your chat input field on the messenger bottom allows you only a few options, like e.g.
**it might help to create a "workflow diagram" for all the "form step wizards" we need in our UI.
I think also our checklist about how we work can help here and once we have that it could guide us with the exact interaction
https://pastebin.com/mcX2yGAr
minute 0:49 give job description
I think something like that is probably the correct first step to start a new task, but before i give it a description
Another thing is, we might need a split screen type of thing, where in the lower half you maybe have this chat the way you started it, but in the upper half of the screen you might see a "preview" of the final task ad you are creating with all the details...
Just remember one thing - instead of a description, it would be better to create taks and sub tasks with planned inputs and outputs, so the sum of all tasks and sub tasks including inputs and outputs are the "task description" and if that is not enough, once the task description is completed, we can add an "initial chat message that all applicants will see that gives some extra description maybe?
Also - for now i would remove al "sub descriptions", like e.g. Describe what you need in short and a bit about your project requirement ...i think even Give your Job a description is too long and it should be just description ...because we are at the moment creating a task, so we basically know it is a "job description" :-)
And i would skip the "minimum word limit" ...let people do it the way they want... we can still think about that kind of limit and show it once they hit the limit, but not upfront. ...e.g. on twitter the limit is shown in a very minimal fashion
we need to be soooo much more minimal :-)
minute 2:19 pick time for new taskI think a task that gets created is in essence a "project roadmap", ...see our github issues.
It could be a single task sometimes, but mostly its more than a single one.
Most tasks do not have a deadline, but maybe only the entire project has a deadline.
But tasks have "dependencies", but those are expressed in terms of planned (= :question:) @outputs and planned (= :question: ) @inputs to other tasks. Of course you can only do the next task once all @inputs are ready :-)
But what each task can or should come with is an option to ESTIMATE the task ...but this is optional and doesn't need to be done.. so we probably need a form to add a todo/task where the name/sentence describes what it is and optionally a estimated time can be given
Now if there is a project deadline, then we can also calculate the earliest time somebody needs to apply and start the task/project so that the deadline can still be achieved :-)
minute 2:34 budget for new task(s)I think we should not set a budget. By having estimations for tasks or sub tasks and dependencies, we get the total amount of time estimated. If we know the total amount of estimated time, we can pick a rate to pay per hour and that will give us a budget automatically.
Now if a candidate is good and managed to do tasks faster, their hourly rate will increase
Later, every time a task is successfully marked as done and accepted, the project completion percentage goes up and some of the money is secured by the contractor ... but that is later, when we do the task and not now when we create the new task :-)
also again - this is a later step, so the chat history should already show all the previous task step message
task ad preview in the split section that shows a preview while the task is being created :-)minute 2:55 how to pay
This is an important point, but i do not think this should be filled out during the task creation, instead this should be part of the task application process that happens when somebody applies ...so let's move it that phase later.
BUT ...lets write the process down somewhere, so maybe a text document with bullet points. i can recommend also a diagram tool like excalidraw.com or maybe you make another figma for the process for the form?
We definitely need to write down all the steps for all the different processes, not just the task creation process :-)
minute 3:09 somebody help to fundgood that you think of the funding part.
I think the "task ad" (e.g. gig or whatever) will have those buttons when it gets posted somewhere.
One button will be [APPLY]
But another one will be [FUND]
of course - if nothing else, you can be the first person to interact with the projects (=task(s)) once it is created and you click [FUND] to fund it and then when you post the task ad somewhere, it will only show the [APPLY] button, because it already is fully funded... so this is the way how to not show the FUND button
minute 4:00 task card overview
I like it. This is the thing that should be shown from the beginning as a preview while it is being filled out.
But it would look different in terms of the information shown.
Here is an example task card in terms of github issues.
imagine the following:
@info section would be the "first chat posting" in a messenger to describe the project@todo section is the split part that always shows an overview over what is going on.
done or open and they have a title and they are links which means chat threads@input documents created in other previous tasks@info section which is just again the first chat messageestimated duration and estimated budget, where we will only have estimated duration when we create tasksThe estimated budget will be calculated from the specific rate that is set at some point later
of course the github issues look messy and ugly and include a lot of irrelevant extra information, but thats why we try to take the essence of what is important and make a nicer UI/UX for it
task let's make sub issues on github for different components we identify. you succesfully identified a task card component we should probably make :-)
minute 5:40 create your own projectSo to clarify how I see this.
Again, see github link above for how a project is just many tasks and sub tasks, each of them can be estimated and marked as done and they can create outputs which are inputs to other tasks. a project could be a single task or as many as you want.
any additional materials and descriptions ...including additional files, should be added as or in the first chat messages below the task.
a single task can always only have a single person assigned to work on it, but because a single task can have sub tasks which have their own sub chat conversation threads, those can be assigned to somebody else and they would potentially produce the outputs that will be used by the same or other contractors in other tasks to continue the work :-)
according to FEEDBACK 0 (see above) a project is just a chat/conversation with maybe some sub conversations/threads and if you click on it in our "web tool messenger for tasks" which we are trying to build, you can see the chat/conversation of ongoing work, but you can also see the "summary card section" that shows the current progress and it should include a link to the project conversation
This project link can be shared and is usually public, but just because it is public does not mean anyone can write a message, but instead only the project/task author and the contractor(s) can interact and work towards finishing the tasks/project
serapath
commented
2 years ago
donecreate iteration 3
@outputpackage Figma Link3
minute 6:21 create project channelsThat's brilliant stuff :-)
So yes... project channel is the right thought. Project and Task should be the same, so a project is just one or more task ans sub tasks and more sub tasks, which are just more channels and sub channels/threads, etc... but let me be more specific
So as mentioned previously in the last comment, in our little task manager web tool creating a "new conversation channel" is essentially create new task/project and then we go through the steps wizard to fill out all the required fields and when we are done it will create us a new "proect channel"
The "create project channl" form in the screenshot should probably go away and instead we have this wizard described above in the last comment that leads to new task/project channels.
One important bit to not forget is, that we need to plan @input and @output for every single task channel.
And when we do that from out chat input field maybe, we can create new planned :question: inputs/outputs or link to next/from existing ones, which means we "connect" tasks, because a task with a specific input can only start once that input document has been produced in a previous task as output :-)
minute 6:53 create project actionsactions:
you also mention maybe we want the project details. again each task ...could be the main project channel task or a sub thread task channel ...should have some sort of "summary" section above the message chat where we can see the details for that particular task :-)
Again, you can check our github issues to see or get some inspiration what would be included in the summary or how we do it manually currently with github issues.
BUT: you say its going to be a dropdown.
I think it should not.
I think those actions should be CHAT ACTIONS which means you can type those kind of commands into the chat input field of your messenger at the bottom of the screen, which includes e.g. quitting the project for example.
...so as you can see, delete/close/quitting a project ...or submitting a worklog video... is different from copying the project link
THe project link is probably somewhere listed in the summary section and you can copy it from there... it is a "read only action", while those others do make changes to the project and people involved ..they are "write actions" which can be selected by task author or task contractor ...it is role dependent
minute 7:58 add new channel buttonThis is great, but think about it.
That create new channel button is basically nothing else than create new sub task button.
This means if our project/task outline of chat/thread/conversation rooms looks like a file explorer, it is similar to creating a new file/folder. Making a new folder in the root of our file structure is essentially creating a new independent project, while creating a new sub folder/file is adding a new task to our structure and doing so will automatically update the corresponding task detail section of the related channels with that new sub task channel.
Also, each file/folder, because it is a task ...can be marked as open or done and each of them has a bunch of potential @input and @outputs ...so it is not 100% like a file explorer ...but maybe you have ideas... we probably have to slowly refine and see how we are going to do that.
ANYWAY :-) ...once you create/add that new task channel... it will probably lead you through a form similar to the form when you created the initial project (see previous issue comment above this one) and you answer using yout chat input field at the bottom of the messenger to answer all the related questions for that "sub project/task" ...and not to forget, this should include potential @inputs and potentially planned @outputs.
IN FACT: ...we forgot to include any given initial @inputs for when you create a new project. So what was said in the previous issue comment above this one, regarding the steps wizard to create a new project, it should include all the initially given input documents too. that is a much better way than writing an initial chat message for a new project channel
our messenger should only support issue channels and no text channels at all and hopefully that would work, so we make the whole app less complex :-) ..regular messaging can happen outside of our "project management messenger" :-) a general discussion channel for a project can also be the "root project channel" which every project starts with before it adds lots of sub project tasks channel threads and so on...
minute 9:29 invite linkhmm, there should not be any invite links to invite people to a project.
[APPLY][APPLY] and we havent yet wireframed until minute 9:29 how the application process would look like and how to accept a candidate as contractor...but it should all definitly just hapen via the project link either published or privately send to somebody via another messenger app or even email and then they click [APPLY] so we dont need other kinds of invite links
minute 10:39 roadmappinggreat - again - should be same process of steps wizard like talking to a bot or "typeform" or whatever to create that issue channel and user uses their chat messenger bottom input field ...maybe similar to how discord did it... see screenshots above.
And again - i think by now we should NOT have a info/description section.
minute 10:54 add todossweeeeet :smile: :smile: :smile:
YES
Again ...just like what was said above i would not include an info ...ideally this should be self described in initial chat messages if nothing else is possible...
Now again - will one level of "sub todos" be enough? On github you can see that any given todo/task can actually itself be yet another sub project with many tasks and it needs discussion. I agree, not every single todo will be like a link to another github issue, so some are just simple textual todos that can be marked as done.
Given what was said above:
...if you would add more sub levels of todos this approach shown in the screenshot above would take a lot of space, therefor maybe we should think about it a bit more. Tell me what you think
Also: Another todo (whether todo that has sub todos or just a simple todo) it should probably be created with the messenger bottom input field bar ...where some chat actions similar to what can be done on discord would allow to create new sub todos.
...but maybe starting that process could also be done from hotkeys or from the side bar that shows all the existing project task channels :-)
also again - while you fill out the wizard, you might be able to cancel or undo/redo, etc... just like what was initially described and above when i said that during filling out a steps wizard form, all progress should be previewed and you could again change things as described above. ...which includes estimating time, choosing inputs from other planned outputs of other tasks in this project ...or planning outputs of that task or of sub tasks, etc...
IMPORTANT: Don't forget to have a mobile first design, so all of this should work on a mobile phone :-)
minute 12:42 task/project summarygreat.
So this is like a sub project card
we had that already when you introduced the task/project card in the beginning.
the sub project card is not so different
i think it should be above every single project chat to show a summary of what is being chatted about
QUESTION
now that should be possible with hotkeys too
now that should/could be possible as a chat action from our main messenger bottom input bar (discord style)
now that should/could be possible from the side bar that shows us all the project/task channels and we can make a sub channel
Some tasks might not have its own channel, which i think should be the case when they are just simple textual todos that can be marked as done ...but every such simple textual todo could eventually be turned into its own conversation sub channel.
in my opinion we should have for every possible action exactly one hotkey and one visual way of clicking at most But everything should always also be possible via the messenger bottom input field bar (discord style)
minute 13:47 add sub todo form
haha, and here we are again :laughing: :100: I agree it is of course needed, but we had this already a couple of times.
So adding a new project (sub) channel or adding the initial task at the beginning of your presentation or also adding in general any kind of task/todo/project thing ...always requires an action which starts a wizard steps form to fill out whats required and here again we need:
same as above:
minute 14:03 show sub todo
This is not bad in terms of that we of course need it, but it is bad in terms of how much screen space this all uses
This is not goo at all. Let's focus on making this work as a mobile first app.
GOAL: Let's try to make this into a little todo list app for the phone to share e.g. a shopping list with a friend so they can quickly go and buy some milk or bread or eggs or whatever and scratch them off the list (mark them as done) ...super basic ...more like somebody would make such a short shopping list on paper and we now have an app version of it.
if this is our goal - it will become a lot more minimal and mobile first will not be a problem :-)
So i agree
:+1: ...similar to how you can drag'n'drop files/folders, you might want to change how you arrange the tasks and sub tasks. :+1: ...yes each task description would show yout he accumulated estimated time/budget for all the sub tasks
one thing to have in mind is, that the real structure of the todos, which means tasks and sub tasks is NOT given by how they are described as tasks and sub tasks, but the real structure will reveal instead through the @input and @output documents and which outputs of some tasks will be inputs into other later tasks ...that is the real dependency structure and it might not be the exact same thing as how we maybe artificially group and nest tasks manually. ...so maybe the side bar which shows the channels and might look like a file explorer ... should have another view mode where it shows the *task network** the way it works in gantt/pert charts where each task - if it has an estimation and the final task has a deadline and all tasks are connected via arrows derived from the inputs/outputs relation ship, then it is possible to calculate the start and end times of each tasks and figure out ...based on the dependencies and the final deadline and the estimations, when each task has to start the latest so that the deadline can still be met :-)
serapath
commented
2 years ago feedback 2022.06.21
a quick extra thought. please feel free to clean up the task list in the top level comment here with all the tasks/takeways from my feedback.
because all worklog comments produces should reference which exact tasks you have been working on and so those tasks need to be created from the feedback i give and you can :question: plan the outputs you are going to produce, which at the moment is probably mostly wireframes :-)
i got some additional inspiration from working every day.
there might be some conversation about a task in a chat like fashio like what we do here ....and there is alwasy a bunch of messages in between one and the next worklog, including all the feedback i give, so maybe ... those messages should "fold" or "collapse" into one worklog entry that is expandable ...to see those again. ...its all the chatting that happens in between one worklog video and the next?
This way somebody scrolling through the issue comments can see worklog after worklog and the outputs, but they can expand the chatting and feedback between worklogs to see details ...otherwise its is A LOT :-)
Ok - just wanted to share that, i will now continue with the remaining feedback in the following comments
serapath
commented
2 years ago feedback 2022.06.21
minute 15:57 top menu bar buttonsSo i think you said the top bar is a search field? It also has a button to see the people in that project?
I think each project/task channel has exactly one person in. if a project needs more than one contractor, it has to be split into multiple tasks, so that again each task can have one person so the "person" or contractor can be always shown next to the task if the task has a conntractor who applied and is assigned.
There is no such thing as a group chat for now where multiple people can chat at once at least for now.
Otherwise The serach/filter functionality should happen from the messenger bottom input field bar. clicking maybe a search or filter action icon, the input bar turns into a search/filter and whatever the user types is used to search/filter the "chat history" instead of "sending" a new message.
Thats how i would approach it to keep the interface super minimal.
Also - on a side note - because you again show it.
it occupies all of the space but in fact it is all the same or should be. Think of the minimal shopping list on a paper to grab a bunch of groceries from the shop but as a mobile app.
So mobile first, the first red circle that shows the projects should just be a list of tasks. And then each task can have sub tasks which can have sub tasks which can have sub tasks, and so on ...
.. button to get one level up to the "parent task"?gantt/pert chart or google searches for inspiration how this could look like and work on mobile first instead of desktop?lets just simplify this structure a lot :-)
minute 17:03 worklogcool that you did the worklogs. a worklog is a particular type of message you can write as a contractor in a task/project chat room using the messenger bottom input field bar.
a task has:
a worklog has:
a worklog can be followed by some back and forth chatting and discussion to clarify things, etc... until it is followed with an official feedback from the task author
a feedback:
everything that was accepted as a finished task or output document and the time that was spent on those is counted as work done and automatically triggers the updates to invoices and pending payments to the contractor
minute 18:38 worklog button
YES :100: exactly - the task messenger bottom input field bar should have a worklog action to create or go through a steps wizard to fill out a new worklog ...lets be inspired by discord or rather also the typeform and other links mentioned above to online form creator tools ...to make this as smooth as possible and have a little worklog card preview while filling in the data.
The worklog form as such as shown in the screenshot should be typeformified into a steps wizard by typing each step and sending it like a chat message to create the form ...it should be similar to the steps wizard to create a new task :-)
All of this allows editing/changing until it is/was accepted by a task author, because then it becomes uneditable and part of the contract and payments are updated too.
again ...if you think of a little grocery shopping list and how minimaml this is. How could all the above be a simple as possilbe. ... just a little autocomplete input field, etc... everything very minimalistic so that it all looks like no effort instead of big menus with lots of stuff.
:100: for the button send/upload worklog to be displayed in the chat history of one or more task chats :smile: ...basically all of those that have been mentioned/referenced in the worklogand the task author is getting notifications for it.
The worklog card in the task chat should of course be as minimalistic as possible and if needed maybe it can expand to show more details and otherwise instead of lots of text it shows in the screenshot here, it should just minimalistically show the tasks, times worked and output file/links ...the date/timestamp for example just comes fomr the regular date/timestamp that every chat message anyway has ... no need to make that special :-)
Also as soon as the worklog was accepted by the task author, it will update all the parts in the "task summery section" on top of each task chat with what has been done so far :-)
REJECTION sometimes maybe a worklog is not yet accepted and requires to fix some stuff, like maybe the figma link attached for a planned output shows not the correct view of the latest outputs, or maybe there is a typo or something is unclear.
ACCEPTED once a worklog is accepted, all the intermediate informal chatting can be hidden/folded and expanded if anyone is interested in the details of what happened between worklogs or between posting and accepting a single worklog :-)
:100: :1st_place_medal: thx for all the cool wireframing. I just googled TASK MESSENGER and found this ...doesn't look like something big, but i think it is the right direction to go, but of course, looking at it, out concepts are a lot more refined than what this link shows.
minute 23:54 message emoji buttonsi understand what this is about i think.
YES, we need to accept/reject worklogs.
i just talked about it.
those should be regular chat actions and a feeback message will accept/reject all or parts of the worklog.
it could also require to correct parts of the worklog before it get accepted, etc...
I would not call it an emoji, but it is a chat action, a contract action ...but of course it could have a little emoji when we theme it maybe a :x: REJECT or a :heavy_check_mark: ACCEPT symbol, that is t rue and in general each type of chat entry could have an emoji symbol based on what type of message it was ... a normal chat message, a feedback message, a worklog message, etc... ...and the task messenger bottom input field bar can have options to create all these different kinds of chat messages and actions :-)
And YES, once a worklog has been accepted, task overview and stuff gets automatically updated including to maybe automatically triggering payments :-)
minute 24:32 manually checking tasksNO :-) ...lets not do that. yes, we do it like that at the moment, but the point of the task messenger is that it is strict and contract based, so tasks can get created and maybe tasks can get canceled by a task author, but what has been accepted in the meantime (parts of it maybe) has to be paid and tasks only get marked as done when a worklog is accepted.
We might need to think about all the options, but there cannot be such a thing as just manually marking a task as done, because that doesnt make sense to me - when would that ever be needed? ...it should be automated based on chat actions.
minute 25:42 job market placehaha :-) i like how in the end you say we have for now the job market place, but ...it probably needs to change.
Yes, i think we will not have a job market place. it is not a job market place. it is a messenger to create tasks, like making a grocery shopping list and invinting somebody to do the job maybe ...but its not a place to discover or find open jobs. this is what happens on existing social media by posting links to tasks and people can apply (and we need to see how the application process works, etc...)
But no general overview over all possible tasks that exist. we won't have that.
So NO i think we will not have any screen where you can see or browse through all the jobs created.
Also no filter to filter through them ... filters are an action of the task messenger bottom input field bar to quickly find messages in a particular task chat or sub task chat
BUT when you post a link to a particular project/task on social media, it will have an [APPLY] button but it will also have a read only view so somebody can click and explore it, but they cannot write or change anything, just see and study what it is about. ...its all public to read and so people can also see what is happening and learn from it.
The APPLY process needs to include posting some portfolio links (which might actually be public links to task messenger projects a contractor has been doing in the past :-) It also allows the contractor or applicant to ask questions. And after some time they either agree to proceed or not.
Hornet004
commented
2 years ago Suggestion 2022.06.22
General feedback
I understand all that is said in the general feedback, and I'll put them into consideration in the next designs...Regarding the Lorem text... I strongly suggest it stays because It's there to tell any designer that content is going to be there unless you want me to use boxes that would be tough to understand else if no dummy text or box, it becomes empty which would be harder to understand unless explained. The same applies to the "Marketplace "---at some point the bot is going to have a name even if it's "BOT" or a "BOT tag" perhaps if it's not decided yet, we give it a dummy text so we know that place holds a text.
Hornet004
commented
2 years ago worklog 2022.06.29 worklog 2022.06.29 worklog 2022.06.29 worklog 2022.06.29 worklog 2022.06.29 worklog 2022.06.29 worklog 2022.06.29
doing Mobile First iteration 1
@output❓Figma Link2serapath
commented
2 years ago feedback 2022.07.04
good, but can we move the title bar to the bottom?
thats how we do it for all our wireframes at the moment - always on the bottom.
task can be (gig, exercise, proposal)project can be (task, exercise, proposal)project = tasks + sub taskstask is always a single task roomtask with sub tasks is what you could call a project :-)
and then a user would click the button on the bottom of the screen to select an action, like create new task/project/exercise/proposal :-)
+ button should turn into a [cancel] button to abort the chat action.
[send] then the action happens (e.g. a new task is created) and the [cancel] button turns back into the [+] buttonnew planned input (=select autocomplete from available existing planned outputs)new planned outputWe need to think about APPLICATIONS for a task though
Also it needs to be possible to FUND a task :-)
and also which action can be used by somebody depends on their "role" (contractor vs. task author)
the upper part of that chat should when task is created, the upper part of the chat screen shows the task summary. And when users chat to add a todo and fill out the form, it modifies the summary on top.
sub todos is collapsible :-) ...but we need some sort of form steps
pay it should ask estimate time+ to add another input/output is greatfrom and next fields do not need to be filled out, because when a user creates a tasks and chooses from autocomplete list an existing output as input, the app will automatically show the from and next fields :-)One more thing: Maybe having all this in one big form is a big scary, so maybe instead it could be a form with steps (=step wizard) to ask for one information after the other?
While going through those steps, the place where the + button for choosing e.g. "add todo" was, could be replaced not just by [cancel] but instead by [<][cancel][>] so a user can cancel but can also go next and back between form steps they already filled out.
And on top of the screen there could be a little "summary card" that shows the preview of the details for the final todo and how it will get added if the user fills out everything and clicks [send] in the end :-)
So this looks great and its what somebody should see before they either fund or apply for a task, but i think this should be "on top" of the screen, kind of like a topic bar on the top of the screen and then below that card is the empty chat where the task can be discussed.
"David A. invited you to join task" should be part of the card i think
serapath
commented
2 years ago feedback 2022.07.04
So the home screen is weird to me.
search is just one option you can select from the + menu+ button of our input field :-)quick task/exercise or projects, i think that should be in the menu and maybe when a user comes to the app they could see that by default or they would see the task room they opened last and they can click the icon to show the overview of all task rooms :-)
so the + button should probably be on the "left side" of the screen, because that is where also later the bottom input field has the + button, right? :-)
+ button is located, and while the user fills out the "new project/task/gig/exercise" form in steps, on top the (=expanded chat room topic bar?) they can see the preview card of for the task room that gets created growing ... btw. each task type could have a special symbol for (gig/exercise/proposal/...)
i think i would rather have most of the screen white and like said in the previous comment and that descriptive text is unnecessary, because the form steps and preview card will show it anyway and a user can always go back and forth or cancel ...so they can learn how things work and once they know, the descriptive text is not needed and just more visual clutter that makes things messy. The form and its steps are mostly self descriptive already
proceeed button should just be a small next button where you usually would have the "SEND" button in the bottom input field ...and only in the last step of the form the user gets the real SEND button instead of the "NEXT" :-)
i think you have too much variety in the forms at the moment.
we literally have
technically they are all the same, so it doesn't even really matter, but i would not make now also todo and project ...we should decide on a minimal set of those.
And if a user selects the type, the type can be shown in the preview card on top of the screen, but the next step in the form now only asks for the "descriptive name" of the task
I don't think we need also "description",let's remove that. We describe the task by creating inputs, outputs and sub tasks. A user can make an input document with a description if they really want or they can write a first chat message once the new task room was created.
Again - payment - like mentioned above - should be about estimating time resources :-)
And the bottom button is the input bar with a next/send button at the end :-)
adding a subtask (=todo) is great :-)
...but the "skip" button should be part of the bottom input bar form step and if you wanna skip it you just press "NEXT" immediately without adding any sub todos/tasks
Keep in mind, every sub todo might eventually also be its own sub chat room.
So - the task card preview on top should probably show all those tasks in some sort of "file explorer preview" similar to the video i linked in my previous feedback comment.
Otherwise, the inputs/outputs is cool but even the initial task before adding any sub todos, should already have the option to add inputs/outputs too
Just keep in mind that should be added from the bottom input field, where you could select it as an action in that step of the form steps using maybe a + button and then if you selected input for example, you can type and get autocomplete dropdown of all existing outputs of other tasks to choose from and then hit next to add it ...so you can proceed adding another input or output, etc...
This + during the form wizard steps of creating a new todo could look like
and it shows as a temporary + button for actions relevant in that specific form step (steps wizard), when the user can add inputs/outputs for example
But all the actions should always be triggered from the bottom command "chat" input field bar :-)
We might also want another review stage for inputs/outputs, which could use a symbol like: :thermometer: or :label: or :mailbox_with_mail: or :balance_scale: or :microscope: or :telescope: or :stethoscope: for example ...any of those you think is best to indicate a "review" phase?
..but no hashtag, because the task itself should be that and the rest can be later inferred from the file name or the file ending, etc... let's keep it simple for now. Adding an input/output later on will automatically figure out from which message in which task chat room it came
serapath
commented
2 years ago feedback 2022.07.04
So that is the thing that should be shown as a collapsed summary in the task room topic bar on top of the screen or expanded as a task summary card with exactly this information. The collapsed version can be a one liner so it can be used in the task room list for overview over all tasks. The expanded version can show when you open a specific task room chat. It also shows while a user creates it or edits it and fills out the form steps :-)
The buttons proceed/skip/add_todo should be actions in the bottom input field action bar.
+ button where a user can select to add more sub todos< arrow to go back and edit previsous stepsotherwise i agree with stuff :-)
so how channels should look like was said above including my little recorded screencast
But it also shows the task channel (e.g. for "roadmapping")
BUT the task summary is - as said above - just a topic bar summary that can be expanded to show a task summary card ...and then below is the chat history ...which is in the beginning empty ... and then actions like edit should be just one option behind the bottom input action bar + button.
BUT a user cannot edit anything that was already agreed on and finish. it becomes unchangable and has to be paid. it is a contract and a contract cannot be arbitrarily changed at any point
as said above - you have the right ideas in there, but lets iterate on this a bit more.
there is no limit to how many sub levels are possible and even a main (project) task which has outputs ...those can become inputs in new tasks which makes those new tasks a super project of that project task.
A task who's output becomes input in 2 or more other tasks is technically a sub tasks of BOTH of those follow up task and not just one, this is why i talked about "linking" a task similar to how you can "link" a file or folder in your filesystem in more than one place.
now expanding/collapsing the different tasks and sub tasks is great.
More than that i would say a user can always create a task for themselves, for example a task called self organization and then they create or link all the important tasks they want to work on as sub tasks ....those important tasks can come from different projects too ...so basically the self organization (which could also called quick bookmarks is just an easy place to see all the currently important tasks if the list is otherwise long :-)
But doing it this way means any user is flexible to use the tool the way they want instead of us deciding that there will always be a "quick task/exercise" category ...let users make it if they want to and otherwise it is all just a single long list with sub items and sub sub items :-)
You say again: anyone can just come and create a task without the need to create a project ...i think thats true and a task if it has sub tasks is already becoming a project, so why make the "distinction" at all :-)
So let's just say at any time, any task can get as many sub task levels as a user wants and a task with no "parent super task" ...you call it a project ... can technically later become a subtask of a new project, when the new project uses the outputs of an old project as inputs ...so that is why it makes no sense to make the distinction so strict.
everything is a task or everything is a project
...a project can be a single task with no sub tasks at all or it can be endlessly complex thats fine.
I like how the + button becomes a - button while the menu shows.
This is the [cancel] button i was talking about ...can also be used if there is many steps of a form that will follow
THIS IS COOL
PERFECT... :star_struck:
:heart::heart::heart: i love the icon for task list menu :-)
serapath
commented
2 years ago feedback 2022.07.05
worklog 2022.06.29 worklog 2022.06.29
doingMobile First iteration 1
@outputquestionFigma Link2
Just wanted to quickly repeat some of the actions we might need.
feedback which is only available to the task author**So this shows we need to later make wireframes where the task chat room is shown (maybe with different colors) to indicate which role is using it. is it task author or contractor?
As said earlier. The form and everything is technically correct, but the style is not.
So this should all be done in form steps based on the selected action in the bottom action input bar and while adding inputs/outputs/etc... the summary card in the topic channel on top should slowly show the preview ....that way we have the same result as shown in this screenshot, but its a different more consistent style.
all said before - invite preview box is cool, but name and that its an invite description should be part of the card box. and the remaining part of the screenshot is something a person can explore before clicking for example [apply] but thats all described above in the comments already :-)
one more thing about the "overview" over the task list. You have the number indicators (thats notifications?). This is cool, but the chat should have an indicator line similar to discord to show what you did not read or see yet since the last time you checked a particular task chat room.
Also, ...i think once you have let's say 3 people who clicked apply ...how does the interaction with those candidates look like before a candidate gets choosen? We don't have wireframes for it yet i think.
It is cool that a candidate can be "assigned", but if a task has lots of sub tasks and 3 people apply, maybe all of them can be accepted but they get assigned to different sub tasks :-) ...that is what i in the end did with you and helenphina and even joshua alexander, even though he never showed up in the end :P
Also we do not have yet any wireframes for when somebody wants to "fund" a particular task
Hornet004
commented
1 year ago worklog 2022.07.17 worklog 2022.07.17
doing Mobile First iteration 1
@output🏭Figma Link2serapath
commented
1 year ago worklog 2022.07.17 worklog 2022.07.17
doingMobile First iteration 1
@outputfactoryFigma Link2
Ok, watched your videos and also after some discussion on discord, i thought i give feedback here, but i try in screencast format
Hornet004
commented
1 year ago serapath
commented
1 year ago cool, first impresion - looks great :-)
first impression:
write button js, css and html does not look like it was a "sub task" of implement buttondemonstrate button preview also doesnt look like it is a sub task of somethingimplementation is technically a neighbor task of ui/ux design and dit lines up, but if it wasn't for those orange helper lines it wouldn't be super quick to see.
This one looks much cleaner, which i like.
...but if that is possible, i definitely like how clean it looks even though it has no lines :-)
I was also thinking, maybe we need the :outbox_tray: and :inbox_tray: as an icone that toggles from :outbox_tray: to :inbox_tray: when you click it and indicates "expanded" or "collapsed" - in general, every icon we use should indicate something. There are plenty of emojis we can use :-)
Cool thing with emojis is, that this makes sure it will work in a terminal too later on, because many developers work exclusively in the terminal it is definitely a bonus if the UI works in a terminal too :-)
todo i think for the next iterations of the wireframe, we should also try to use figma for interactive prototypes where we can model a scenario between a contractor and a client, where they actually work on a couple of tasks.
We can then slowly start refining that "scenario" and the "interactive prototype" to include all the features we need based on some sort of work for an imaginary project.
📌📭┬🔳roadmap🔗
├📭┬🔳UI/UX design🔗
│ ├📭┬📤┬🔳design button🔗
│ │ │ └➖┬❓button-repo/
│ │ │ ├🖇️🔳implement searchbar🔗
│ │ │ └🖇️🔳implement button🔗
│ │ ├📤┬🔳make button icon🔗
│ │ │ └➖┬❓button-icon.svg
│ │ │ ├🖇️🔳implement searchbar🔗
│ │ │ └🖇️🔳implement button🔗
│ │ └📤┬🔳wireframe button🔗
│ │ └➕─❓button.fig
│ └📪─📤🔳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🔗So if i compare your project structure with this example structure above, i think it would be better to adapt things.
make button icon and wireframe button are sub tasks of design button...but in your example they are not
roadmapping and UI/UX design have different icons than design button...but it doesnt make much sense to me.
Is it because ui/ux design has sub tasks but no inputs/outputs and design button has only inputs/outputs but not sub tasks? ...that would make some sense, but then again, in the above diagram, design button has sub tasks too, so therefore, lets find a project structure example that covers all the edge cases our "diagram langauge" or component needs to be able to express :-)
also here, there is an input/output icon at the end of "implement searchbar", but maybe that doesnt have any meaning?
Maybe this is why an "interactive figma prototype" would make sense.
I feel with the chat and the action bar and the task tree menu, we really have the major building blocks to maybe try.
the bright and faded arrows to open/collapse the tree is a good idea. it definitely works and makes it lighter on the eye. awesome. ...too bad those arrows don't seem to exist as emojis. ➢ ➣ ➤ ◄ ► ◅ ▻ ◀ ▶ ▲ ▼ ➤ > ˃ ˂ ᐸ < ᑉ ᐱ ^ ˄ ˅ ᐯ ⌃ ⌄
at least there are some unicode characters like the ones above and then again even terminals support colors, including white but also dark gray ...so maybe that could still work.
Of course - in "the best case" it will be very readable. But for me the question is also - in "the worst case", when many things have many sub tasks and inputs and outputs and so on ...will it still work? ...of course, when things get a lot and very detailed it will always be a bit more messy, but not every project will have all those details, but just in case we are dealing with the most complicated situations, does it still work?
I think thats what we should aim for when we create an example project structure for the interactive figma prototype :-)
We probably have to refine the project example scenario multiple times to add more details to show all the features of the "gig/exercise component" or rather "task messenger" component we are working on :-)
amazing move to add the "next" tasks at the end of the input and indent them a lot.
Still - maybe by default the button-repo could show a little number that indicates the amount of tasks it is used in and when a user clicks, then it expands and shows those tasks, because i might expand inputs/outputs to see them when i work on design button task, but i might not always want to know the "next tasks" ...unless i do want to know.
One idea is, that as a project manager i would want to expand the "next tasks" to see some more details to maybe understand or remind myself what they were about and then collapse them again.
Also - if names of tasks and outputs are long and nestedness is deep, you might not be able to see the "next tasks" anymore without scrolling to the left ... you can see some names are already shortened like implenent search... because there is not enough space.
so what you are seeing here is many things. I can show some snippets i already posted on discord earlier.
📌📭┬🔳roadmap🔗
├📭┬🔳UI/UX design🔗
│ ├📭┬📤┬🔳design button🔗
│ │ │ └➖┬❓button-repo/
│ │ │ ├🖇️🔳implement searchbar🔗
│ │ │ └🖇️🔳implement button🔗
│ │ ├📤┬🔳make button icon🔗
│ │ │ └➖┬❓button-icon.svg
│ │ │ ├🖇️🔳implement searchbar🔗
│ │ │ └🖇️🔳implement button🔗
│ │ └📤┬🔳wireframe button🔗
│ │ └➕─❓button.fig
│ └📪─📤🔳design searchbar🔗
│
└📭┬🔳implementation🔗
├📭─📤─📥️🔳implement button🔗
└📭─📤─📥️🔳implement searchbar🔗if you have things expanded like above and then you click into the empty space in front of implement button, like this:
│
└📭┬🔳implementation🔗
👉 ├📭─📤─📥️🔳implement button🔗
└📭─📤─📥️🔳implement searchbar🔗it will "bookmark" or "pin" this task.
Maybe because you currently frequently work on the task and don't want to always expand roadmap > implementation > implement button ...but just see it directly
so it turns it into:
│
└📭┬🔳implementation🔗
├🖇️🔳implement button🔗
└📭─📤─📥️🔳implement searchbar🔗
📌📭─📤─📥️🔳implement searchbar🔗now if you expand implement searchbar, you can:
┌📥❓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 htmlso implement button has:
write button js, css and html.js .css and .html
.html file is used as input in demonstrate button previewbutton repo/button-icon.svgbutton.fig wireframewhat is the reason why somebody would want to pin something?
imagine your project is to build an airport
so you have a roadmapping (for airport) task
then you have the main areas of the airport
then you have in each area many building sections
maybe you have many buildings in each section
then you have a specific building in one section
then you have a specific floor in that building section
then you have a specific corridor in that floor
then you have a specific room in that corridor
then you have a specific part of that room
in that part of the room there is also a display
that display is connected to an IT system that runs software
that software has a bunch of sub components
one of those sub components is ....
i don't know - or maybe you have the electric cables for that projector, but the point is, that if your project is large enough and you are working on one tiny part of it ... you might not care for the large overall structure of the project, so you want to PIN that particular task you are intereted in and forget about the rest for now :-)
also - if you would expand sooooo many levels in the task tree menu, you would need to start scrolling to the left a lot, because it just doesn't fit onto a mobile screen anymore.
Hornet004
commented
1 year ago Hornet004
commented
1 year ago Hornet004
commented
1 year ago Hornet004
commented
1 year ago serapath
commented
1 year ago feedback 2022.08.08
worklog 2022.06.8 worklog 2022.06.8 worklog 2022.06.8 worklog 2022.06.8 worklog 2022.06.8 worklog 2022.06.8 worklog 2022.06.8
@output:question: Figma Link2
Great worklogs. First - there is one or more tasks missing. The figma link2 output does not list a task, e.g.
done make figma iteration 2 - 3h20min
done design this - 1h15mindone design that - 20mindone make this and that 50min@output :question: Figma Link2This is just an example, but if you could edit your previous worklogs to update that and then also update the top level @todo comment with the output and mark those tasks as done, that would be cool :-)
serapath
commented
1 year ago feedback 2022.08.08
First - can we start making a glossary document? :-)
I think defining all
and then consistently using those names will help us a lot. We might need to go over this a few times and refine names, but coming up with a concise way of talking/naming everything will help in general
let's call this invite link
task author has copy link icon
let's call this task menu
I assume your definition of "todo" is a task that does not have a chat or sub tasks And a "task" would have a task chat and can have sub tasks.
Anyway...
GOAL: Maybe I should try to define one of the most important goals, which is:
The last point does not mean users can do everything, it is often READ ONLY until they get accepted to also have write access
It is because this app should support any kind of project, from a grocery shopping list to running an entire country. Projects can start small and grow bigger while people work on it, so simple todos can grow into large sub trees of sub tasks and sub sub taks. Also, a task delegated to a worker can also grow when the worker outsources work to others and creates more sub tasks and those sub workers might repeat the process, so maybe you have 10 workers working on sub tasks and sub sub tasks and sub sub sub tasks...
So - one major goal of the app is to support this - which is why we aim for solving it and not avoiding it :-) The structure needs to be able to grow like a tree with new branches and so on all the time, so a tiny project can always be extended into more details as time moves on if necessary. So the whole point of the app is that it needs to be able to deal with infinitely growing todo trees :slight_smile:
note: because it is open source, somebody can later take the code and make a variation that has also the privacy/closed features, but let's put this on the side for now and leave it to somebody else or maybe us in the future, once we have the app.
i like it, but lets rename them to something short
let's call the roles
candidatewhen they apply,funder,provider,client
Elsewhere we still say worker and manager but that comes more from employment.
A modern self employed and self organized "worker" doesn't need a "boss" in the same way an employee needs one.
So I think provider and client is much more appropriate
If you feel that "contractor" is different from "client", then let me know. Otherwise, I think "contractor" is confusing, because it could be the "client", but it could also be the "provider" It all depends from which perspective you look. From my perspective you are the contractor and I deal with many. From your perspective i might be the contractor. ...so i would rather avoid ambiguous terms.
So basically - there are no hierarchies anymore as in: "a contractor is also a worker but higher than a worker of a contractor" No matter who you are, it is always either provider or client and nothing else.
let's call this apply button and fund button
When somebody creates an invite link for a task, they can choose to
Because maybe somebody creates a task and:
So basically the "create link" (which you just call assign), should probably be called "invite"
and it should become an action from the bottom input action bar that allows a task author to configure it properly
maybe you do remember how we did the "application phase" all public on github with helenpina, joshua-alexander and yourself and even a bunch of others who were not selected into the next rounds Everyone could learn from the process and also see what portfolio and results others delivered to learn who was selected and why. I think that would be fair, so i would want to have it all transparent for everyone.
It will be a tool to support our specific peer to peer open source ecosystem.
We are making it because none of the existing tools supports these very specific ways of working.
So yes, this should be visible to everyone always to establish a specific open work culture and who doesnt like it can use a different app :-)
It is level playing fields - equal cards for everyone to promote fairness and openness, which we have way to little in this world sadly.
This will not work.
But maybe the whole task tree menu can still be explored and if any task has nobody assigned and has an open invite link, then somebody could just apply for it directly, by clicking on it, which would probably open the task chat and only show [APPLY] or [FUND] as possible actions
We need a flow for both (apply and fund) and i like the flow for apply where the main action you can do is chatting :-)
The flow for funding is still missing.
BUT ...everyone should always have READ ONLY access to the entire task menu. everything needs to be transparent.
But of course - depending on what specific task the invite link was for, that task is expanded and pinned and all other tasks are collapsed.
So imagine ralf applied for design buttonand then in the design ralf browses the task tree menu so it would look like:
┌📪─🔳roadmapping🔗👑👷david
┌📭┴🔳UI/UX design🔗👑bob👷david
│ ┌👥eve🔗
│ ├👥ralf🔗
│ ├❓button-sketch.jpg🖇🔳make button sketch🔗
📌📪┴📤┼🔳design button🔗👑david👥
└➖┬❓button-repo/
├📭─📤─🔳implement searchbar🔗👑charly❔
└📭─📤─🔳implement button🔗👑Ralf can see already in the chat that eve applied too, but he can also expand and see that in the task tree menu if he decides to expand that
Ralf can see that there is a button-sketch.jpg input to that task and it was created in make button sketch
Ralf can also see that design button is part of UI/UX design task if he wants to check that
Ralf can even expand that further to see that UI/UX design is part of the roadmapping task
Ralf can also not expand that so it looks like
📌📪─📤─🔳design button🔗👑david👥
└➖┬❓button-repo/
├📭─📤─🔳implement searchbar🔗👑charly❔
└📭─📤─🔳implement button🔗👑Ralf can also explore the planned, outputs see where those outputs are used as inputs If Ralf is not interested in that he can also just look at the planned outputs
📌📪─📤┬🔳design button🔗👑david👥
└➕─❓button-repo/
**IMPORTANT:**
This is probably the view that should be shown by default to a worker.
Because - as you say - the worker is not interested in anything else.
But a "worker", or rather "provider" like you, who already works on this project for some time,
might want to see a little bit more to get a better understanding of what the bigger project actually looks like.
Mostly "first time" workers might be scared of seeing too much initially.
Ralf can also check the sub tasks of `design button` and expand that
📌📭┬📤┬🔳design button🔗👑david👥
│ └➕─❓button-repo/
├📤─🔳make button icon🔗
└📤─🔳wireframe button🔗...and so on :-)
here you say the + is for candidates to submit stuff, maybe portfolio documents, but later maybe worklogs.
That way we can get rid of lots of visual clutter and actions will always be triggered from the bottom action bar
This is cool.
Probably we need multiple screens of this, depending on context and each role to list exactly all the possible actions.
Maybe that will help us to later define the interactive prototype scenarios to show every feature of the app.
ACTIONS:
send messageattach document (file or link) - basically same is true for emojis, gif's and other standard messenger featuresadd (sub) task/todo - user can check a box to decide if a task should have it's own chat room attached
edit selected itemdelete selected itemfund (sub) task - funder role : only possible if task is not yet fully fundedapply for (sub) task - candidate role : only possible when a task has nobody assigned yetactivate invite link - manager role : can create invite link to assign ppl and customize buttonsdeactivate invite linksubmit worklog - worker rolegenerate invoice - worker role : (a worker works on many tasks and invoices can be combined)
manager and workerpay invoice - manager role : (is currently missing)We will have to think systematically how to smartly organise and group actions
Also, i think it is realistic, that a provider can quit at any time and a client can remove the provider at any time.
But, the submitted and accepted worklogs have to be paid and cannot be removed.
I think this is the most flexible and free for all sides.
Usually it is not necessary, but it is easier that way, so we need actions for this too.
i think this should go hand in hand with designing a very smart input action bar in general
I think that was already part of my last feedback.
Could we make it more like the discord input bar?
The + could be in front of the input field
The smilie at the end inside the input field
and so on ...
And in discords input bar they use different color for background and input background, so they dont need a border
Can we try that too?
I think i shared that already in the last feedback videos.
Also - on the start screen and later in the chat and generally everywhere.
This action input bar should always be there, but depending on available options
The action bar can be fully featured or less fully featured
Just depends how many actions are available.
On the initial start screen - the "send message" action is not yet available, but only in task chats later on
If you are already a user of the app, your start screen won't be empty, but it will show your task tree menu, which represents all the "task chats" you currently participate in (similar to how other messengers show all your conversations with people)
Now if you are new and your "home screen" is empty, then it can show the video instead that explains how to use the app.
I believe we should merge the explanatory video and the empty task screen :-)
looks good.
But same feedback as further below (see mutual agreements/contract amendments)
Every type of message should have it's own visual representation.
Contentwise or feature/functionality wise i agree with this flow.
BUT: notifications will be shown outside of the app (e.g. mobile phone or browser notifications)
So, please check the feedback for "mutual agreements" or "contract amendments" below.
the flow is ok for now.
it is good that there is no additional task description.
a task description can be created by attaching an @input document to the task that describes it.
so here a user can "Create task" to finalize the form, but then they can still create sub tasks
consider 1:
Maybe we can already preview the new entries in the task tree menu while the user fills out the form?
That way the user can see what changes this will cause while they are filling out things.
I also think the task tree menu should be editable similar to how a file explorer is edited
consider 2: After the user finished creating tasks and todos and sub tasks and input and outputs... They might see that they made a mistake or they want to update something. So they still need to be able to select any of the tasks and todos and inputs and so on and edit it and then save that. Which means all the form fields we have to create the task will also need to be available again once the user edits. Which means those form fields are filled out with the current values, but can now be edited.
I like this screen. It shows the current task tree menu (e.g. only the roadmpaping task) And it shows the form - maybe because the user is editing or in this case adding todos, but could also be planned input/output documents.
When it comes to input documents, a user can always upload/link to existing documents, but at least text and propable markdown files we as input documents can be created inside the app, so that it is easy to add a "Task description" document as input document if necessary
ok i think we need to get one thing right with our word definitions.
On github there is no such thing as a distinction of "todos" and "categories/tasks"
task form, it has no option for inputs/outputstodo form, it has no option for estimation/paymenton github, every checkbox todo can be turned into a seperate github issue and no matter if:
They should all be the same thing - they are all "tasks"
Our goal of minimalism includes conceptual minimalism. Being able to give any task sub tasks and inputs and outputs allows a user to create any project structure. We don't need any further distinctions. They can later edit it the way they want.
Some tasks can be used by a user to just represent some sort of "grouping" of tasks, like (UI/UX design) or (roadmapping) ...but it does not mean that those are not still normal todos which can have their own inputs and outputs and so on...
On the other hand, the same is true for todo with no sub tasks in that it can get its own payment/time estimation and so on...
Let's not distinguish between those things. It just makes the app conceptually more complex, beacuse as a user now i have to learn about tasks and todos and how they are different. I don't see any win here.
do this later button actionI think we don't need it.
As long as you can cancel any action or form while filling out, it is clear that you can always again create a new task.
A user should also always be able to edit so that is why it is normal that somebody can "choose to do it later" by not doing it now,
but later creating more or editing.
@inputs
THis is cool
BUT: :-)
next tasksThis is an option only available to outputs and not to inputs.
Also, an output can have zero or more next fields in case the output is used as inputs in many future tasks.
An input will either be a file or link to a document from outside the app, but if it was already created inside the app,
then there should be an autocomplete to quickly choose from the available output documents of other existing tasks in order
to make that output an input to this task :-)
another problem is here, that currently it seems every task can only have a single input, but a task can have
inputsoutputs
also the task tree menu can make things a alot more concise than what is shown in this form
It makes sense to see a delete and edit item.
You also said "click close" (once you are done), and cancel is also important in case you change your mind half way
But this is literally true for every task, input, output and so on...
How can this become minimal for everything?
If I want to just update the task name or just rename one todo item or just change one status from planned to in progress or just link one output as an input to two more future tasks or maybe unlink them?
=> This essentially becomes editing details of the task menu tree
So maybe that is what we should aim for - similar to how a user can edit their file system tree in vscode. That way we can also skip a lot of those forms and just let the user edit things on the fly :-)
Tapping on the title in the task chat header shows this:
I like how you say that this what you see here in the overview is the same thing that is visible outside in the task tree menu too.
I think this takes way too much space and should be space saving the way it is in the task tree menu
Also there wont be a description, because that needs to be in a task input document With an additional description input, it could look like this in the chat header:
let's call that task stats
ℹ️👑david💰$10.25/$100.00⏱️2h13min/24h65min
📌📭┬📤┬🔳design button🔗ℹ️
│ ├➕─❓description.md
│ └➕─❓button-repo/
├📤┬🔳make button icon🔗
│ └➕─❓button.svg
└📤┬🔳wireframe button🔗
└➕─❓button.figThis for example shows the same information, but it fits into a small area, so the chat is still visible and doesnt need to switch to a different screen.
So if a user "taps" on any of the items, they become selected and there are multiple actions available to change/edit/update them or to create additional entries (e.g. more sub tasks) or to delete some of them. Of course - some changes need agreement of the contractor/worker first if one is currently assigned
Clicking on any items will show all the available "actions" in the action menu bar on the bottom, e.g. the "edit action" and others ...which will then edit the selected item ...or actually it will already show the form that was shown when e.g. a task was created ...and the form input fields will contain the information of the selected item ...and the user can just change something and confirm the change to apply it to the task tree menu
We are always trying to make things more lean and minimal with less clicks.
Overall the wireframes you show make sense and the functionality is needed. Still I want to re-use more, make things a lot more compact and get rid of every extra input and verbose button as much as possible. For example, i prefer the round (+) button on the home start screen over a full width row button Discord Servers and other messenger input buttons also do more minimalistic buttons/icons
If the app feels like only a single screen with not much to do, that would be amazing. At the moment I feel there is too much text and buttons going on.
What if ...
If we have the task tree menu on one screen And If we have the task chat but the header would also show a small snippet from the task tree menu which is relevant to the task
Then technically maybe, task tree menu and task chat should always both be visible?
What if we ALWAYS show the task tree menu, but a user can select a specific task in the task tree menu, which will switch the chat to show only the chat for that task.
But the chat in general is maybe collapsed, but when it gets expanded it will show in the bottom half of the screen. And if the task tree menu gets collapsed it collapses into the chat room topic bar
The user can click on the chat room topic bar to show the task tree menu again and expand more if they wan
If the expanded task tree menu needs more space, the user can collapse the chat
Maybe we should try this, so then there is literally only a single screen. No swiping No Clicking to change the screen Just expanding collapsing of different parts
I personally feel tapping to switch between
Is a lot back and forth clicking through screens instead of summarizing it all in one screen instead.
A new user can only add to create a first task
An existing user with tasks in the task tree menu can expand/collapse and select any of the tasks
The chat of the selected task shows and can be scrolled
The action bar can be used to send more messages or edit the selected task
Which shows the form with the filled out values to edit and save them
Yes, we need this.
I think this should happen but instead of via overlay popup, it should just focus on the chat input bar to show the message and form to select the new option or change, but when it is clicked, it won't change anything, but will send the request to the contractor first
The contractor will see a special change request type of message in the chat, which they can confirm or reject
"Do you want to send this change request to the contractor?" [yes] [no]
yeah, perfect, we can keep that :-)
only idea, maybe those buttons can be buttons next to each other? [accept] [modify] [reject] If that fits into one line on mobile, i think that would be sweet. To [view] the exact changes, i imagine the user can click anywhere on the contract amendment method.
In fact - each special type of message should probably have some sort of message type indicator e.g. a color or icon or whatever to visually differentiate it from a normal text message
If you really think it is necessary, then an additional [ ] I accept the contract amendment checkbox could be added.
But maybe it also works without in practice and would just be annoying.
accepting it or rejecting it or whatever produces an additional message. choosing [modify] posts a message back to the task author with the changed contract amendment counter proposal this can go back and forth ... and in between there can be some text messages to discuss things before accepting/rejecting
you said here you could have a group of workers and tasks and if you make a change many need to accept or reject.
I think we should not support that use case initially. You have to make an agreement with everyone 1:1 So if you have many tasks and many workers (only one worker can work on a specific task anyway) ...you have to create each change request independently
Once we have the app and we see there are problems, we can then think about refining this further.
serapath
commented
1 year ago feedback 2022.08.10
serapath
commented
1 year ago feedback 2022.08.13
I ike that the action bar shows the currently selected/active task in the input field background.
That is pretty cool to me.
in this copy of your sketch:
In summary - that looks a bit unclear in terms of what belongs to what
Also, imagine:
It could be, that "design searchbar" has no inputs and "design button" has outputs which include the inputs of design searchbar, or It could be, that "design button" has no outputs and "design searchbar" has inputs which include the outputs of design button...
This doesn't look bad, but to me it says:
eve and ralf are candidates for "UI/UX design",nina, alex and david where candidates for "roadmapping"from "make button sketch" so it is an input
eve and ralf (according to what i just said) would be candidates of UI/UX Design or Design buttonUI/UX Design because that is what you said about roadmappingnina, alex and david are actually candidates for UI/UX design and not for "roadmapping"OK - you say button.svg is an output of UI/UX design ... which is not true.
It is an output of make button sketch
But it should be an input of Design Button ...something here is not perfectly clear to me.
OH NO :-) ...
You just said that "make button icon" and "wireframe button" are supposed to be sub tasks of "UI/UX Design"
...but they are not. They are supposed to be sub tasks of "design button".
That is a problem - somehow without the lines you confused yourself too.
OH NOOOOO :-)
And then you say "implement searchbar" and "implement button" are SUB TASKS of "design button"
That is all wrong. So getting rid of the lines that connect things confused you even though you are familiar with things.
That is a bad sign...
Hornet004
commented
1 year ago serapath
commented
1 year ago feedback 2022.08.20
So this one does not include avatar, only identicon
the timestamp should be more technical, e.g. 2022.08.20🗓14:25🕐
it lacks a little copy to clipboard link to get direct link to the message
like most or all existing messengers, the entire column on the right is wasted with white space just so there is space for the avatar, but maybe we can do something smarter (css supports it), like e.g. https://codepen.io/serapath/pen/mdxvvpg
it should use the full with and space available and maybe seperate from the next message via border or different background color
no actions are listed to be able to react or do something with the message or to select it
The quoted messages (if more than one) should probably have a optional top section of the message to display a bit of the quoted messasge and then some sort of mini navbar or ways to expand the full message or jump to it and move between the current message and all related messages.
So this is not bad. maybe it can be further optimized, but i like it. maybe that solves what i just said above.
Regarding "actions" like "reply" or "forward" or "copy", i strongly prefer the option on the left screen and to put those actions into the bottom action bar - still i feel things could have smaller font and be more dense. So this is a good choice i think :-)
Basically - given we are dealing with professionals and work (especially programmers) and we want to be efficient and we will all be power users (because casual users will stick to tiktok/insta/whatsapp/...) i really want to see the "worst case" when a conversation gets really involved and densly packed with information so we need to utilize every last inch of screen estate to have all information available while interacting. This is really something i would optimize for.
This looks cool to me too, but let's not spend too much time on the action bar.
But i agree - this is definitely the approach we should stick to
Otherwise:
I hope we can first create some or many example message flows that fill the message log with messages in different scenario and optimize it like mad ...and we just assume all actions needed will somehow be magically available in the action bar and we can make a list of them, but we can optimize the details of how those actions will be available in the action bar later.
But quoting, selecting, responding to messages and scrolling through messages and see all the details around those and navigating between quoted messages, etc... i'd like to nail that.
In this context we can also go through all the different scenarios, like
Those kinds of things...
I like the way we can move through quoted messages and the little navigation button on the bottom to cycle through them.
i think the name/avatar/identicon/timestamp should probably be on top of every message (even before the quotes? ...just a thought.
Also I still think things are not yet packed densly enough.
One thing to consider is to make the avatar and identicon small - more like the size of a favicon or at most a tiny bit bigger than that.
or the size of emojis...
but keep them as tiny as possible without making them unrecognizable.
We can still allow a user to click to "expand" the avatar/identicons if they want to.
But even if they are small, it is enough information to quickly understand who wrote a message.
regarding actions All the actions and interaction and navigation you explain make sense. Lets say the main focus is to represent them somehow and keep a list of all of them, but for design, lets first focus on getting the chat message log right and all the interaction with it.
once we have that, we can then do another iteration and try to get the "action bar" in order.
What is meant by that is, that if the user had a live conference call (audio only or video - maybe with screen sharing, etc...) that is also causing a message entry in the chat log that records when and how long that video/audio call lasted and technically this allows both sides to download the recorded audio/video stream or re-watch it later on.
It is also possible to make a message and e.g. "QUOTE" that video call and then maybe write a summary of what has been discussed in that call - maybe even make it a worklog and request the other party to accept the tasks that were derived in that video call.
It could also be, that such a type of message can be expanded and has a few attachements (like notes that were taken during the video call) ...
If you want to see how this will work, you can check https://keet.io (which is a p2p video conferencing alternative to zoom and the likes. It already works and uses the same technology we will be using for our app.
BUT: let's not design yet the video call or audio call itself, but just assume it happened and is over now ...and how will the message that represents that video/audio call look like.
It is just yet another type of message.
So the worklog message type will look like our worklogs here on github.
serapath
commented
1 year ago feedback 2022.08.12
if a user selects a message, they should have an option to auto-collapse all messages not part of the message history of quoted messages, e.g.
if message-90 quotes messages 81, 77, 56
and message-81 quotes messages 16 and 3
and message-77 quotes message 15
and message-56 quotes nothing, then the chat log should temporarily show just
message3 message15 message16 message56 message77 message81 message90
and in between things should be collapsed like in the screenshot, but of course much more dense and compact. the screenshot wastes loads of white space that could be packed with content.
Hornet004
commented
1 year ago serapath
commented
1 year ago not bad, but would be good to post worklogs more often instead of a long list of them all at once :-) But thanks
Hornet004
commented
1 year ago serapath
commented
1 year ago feedback 2-22.08.26
@outputquestionFigma mobile components
Thank you for the worklogs. One issue is, you "say" many things in the worklog, but not all those details you say are captured in the outputs. Just looking at the figma file does not give me all the context you share in the video, so the figma file should be structured a lot better to capture all that information you share.
If i understood you right, this is the normal message
and below is the normal cancel
Maybe you said something else, but i think every message should have a separate label
It should have a separate version/timestamp, so that we can compare a later iteration with this iteration.
Also, the "action bar" is a separate component and probably shows when a message is selected,
But i would then design a normal message actionbar, which shows the actions for when a normal message is selected and that is a different component.
Again, it is a separate component and should get a label and version/timestamp in case we do later iterations of this component.
I am personally no fan of preview. I think it makes the chat verbose and noisy.
Sometimes I would maybe want the preview, but discord for example always gives the preview, but then you can "opt out" ...i think when writing a message, showing the preview should be "opt in", so the author has to decide to show the preview or the reader can click to show the preview.
This looks good to me. I think even the "preview" message should look like that, but instead it would show the link maybe with the favicon in front and a little button to click to show the preview. I like that the attachement message has no default preview and is more compact.
THOUGHT
In our *Task Messenger, every conversation should keep it's focus, so if people exchange all kinds of random messages, at any time, it would be good to keep visible what the current overall focus of a conversation is.
Of course - every room is a "task room", so it is clear that the task of the room should be solved.
Also, every worklog is supposed to list at least one task that was worked on.
At the moment you don't do that. You only list worklog videos and outputs, but not what task was being worked on. You avoid it, because it is extra effort to think about the tasks, but it keeps things aligned on the goals, so it is very important - but also almost nobody does it.
So if every worklog is supposed to solve one task, it basically solves a task room. The usual flow would be a worklog literally closes a task room once it is accepted.
It sounds very extreme, but i think we should aim for that and be radical. It is always easy to "relax things later", but it is hard to do it the other way around.
If a worklog solves some stuff, but not the entire task, then a worklog could propose a sub task with an output and solve it immediately, which means, if multiple worklogs are being submitted and all of them do not solve the task yet (e.g. your worklogs now do not solve the "gig/exercise" github issue yet, then they would propose "sub task rooms" with "outputs" and once i accept the submitted worklogs those tasks get created and immediately finished with the outputs being accepted.
I would usually not accept them until you make a plan where or how you would use those outputs as inputs to the next tasks you plan to work on. In that style we get the goal orientedness into the task messenger.
This should be labeled worklog message - v0.0.1 - 2022.08.26 and have it's own column on the entire figma file canvas you have. In that column we will only add iterations of that component.
The worklog message is not bad, but: I think it could be more compact by putting avatar + name + timestamp + message type into one line. Here the message type is worklog and is in the second line under avatar+name+timestamp.
I like that things can expand/collapse, but i think it is bad to add labels to the section.
those things are self explanatory. A task is :black_square_button: or :ballot_box_with_check: which indicates that something is done and the task itself has a task name that describes what it does. An output file has a name too and also a file extension or something that makes clear that it is an output and we also know it is :question: or :package: so that is self explanatory too. Lastly the list of questions will all end with a ? and also if you read them you understand what it is, so we can save some extra space by not adding those labels.
Also I really thinkg we should literally cut/paste the same visuals we use in the task menu or rather re-use the same "task menu" component inside a worklog messages to show all the tasks, inputs and outputs related to that worklog message inside the message instead of inventing a different style of visualizing tasks and outputs inside a worklog message.
This should be labeld worklog message - v0.0.2 - 2022.08.26
So this is the result of iterating the design of the worklog message, but it is not in the row below the previous iteration of this component, so for me, without watching your video, it is super hard to find. I literally have to scroll around, check things and guess that this is the second iteration and not the first..which one comes first, which one comes after? is that the only version? is there another somewhere else on the figma canvas? ...let's improve the structure.
otherwise:
still the same applies as to the previous iteration.
The outputs are now shown below the tasks, which is more similar to the task menu, which is good, but the task menu can always collapse things. Also still, next to the worklog messag type icon/title it should list the amount of tasks/outputs.
Or think about what i say below in thoughts... if there is only ever a single task per worklog, then the worklog message itself could have the task name as the title.
The expand/collapse of the worklog icon row in the message would then basically be the expand/collapse of the solved task name ...kinda exactly how it works inside the task menu itself.
Now the same goes for preview. preview of attachements (outputs) should only show on demand and not by default.
THOUGHT
So again - I want us to be extremely radical, which means minimalistic and very goal oriented.
Of course, we could give the user many options to do it like this or that, but more options means everyone will do it slightly differently, but on the other hand, being very strict means everyone will or has to do it the same, which means every user who uses the app and knows how to use the app will have the exact same style of working - which makes it very easy to work with others, because nobody can develop different "styles" of working.
What I mean by that is, right now for example:
But in our future task messenger we can be a lot more strict about things, which means:
This style of working keeps the main chat clean and encourages to create many sub tasks on the fly and if a worklog for that sub tasks does not get accepted right away, the discussion can continue in that new sub task channel until the revised worklog is accepted which is when the task room gets finished and closed.
GENERAL PATTERN: Basically, the chat is a "change history". It includes messages people exchanged in the chat, but it also includes any kind of action. The task room is like a contract and every message in the chat history is a "contract amendment". The action bar is just a tool to help crafting those "contract amendments" and some amendments, like a message with a funny gif doesn't do any substantial change to the contract, even though it counts still as a contract amendment in a very gernalized sense.
Sub Tasks are just sub contracts with sub contract amendment logs. Just have that in mind as a general pattern for everything when thinking about things like "proposing new tasks" or whatever... everything is a contract amendment to a contract. Some of those amendments require approval by the other side, some don't.
serapath
commented
1 year ago feedback 2022.08.26
worklog 2022.26.8 worklog 2022.26.8
@outputquestionFigma mobile components
You say the feedback should be part of the worklog message, but as the general pattern mentioned earlier, here a little bit of technical background of how literally every message will look like in terms of data structure:
const messageA = { // example
head: ['david', 'alex', 15],
refs: { cause: ['alex', 'david', 4] },
type: 'worklog',
data: { questions: [/* ... */], comment: 'hope you like it' }
}
const message6 = { // example
head: ['alex', 'david', 12],
refs: { cause: ['david', 'alex', 15], worklog: ['david', 'alex', 15] },
type: 'feedback',
data: { action: 'accept', comment: 'good job', answers: [/*...*/] }
}So we are definitely dealing with distinct messages. Now that is not to say that a series of related messages could be collapsed/rolled up into a visuall summary which only shows the details once you expand those, but at the end of the day, every message has a specific receiver and sender and smashing that all into a single visual message box confuses who was sender and who was receiver.
Again - this is all for wizardamigos, so using the UI/UX should educate about the technical structure that is underneath the visual interface.
Also: a worklog marks the task in the task menu as done once it is accepted by the client (=task author)
Great to have actions [accept] [change] [reject] available for a worklog message when the client (=task author) looks at them, but let those actions be [cancel] when the provider (=worker) looks at it while the worklog is pending, which means the client (=task author) did not yet take any action. ...cancel means basically "unsend", which is possible in the time between sending it and the client taking an action.
As an author, any action taken, will provide a form where the client should send a comment or answers along with their feedback message to answer the question in any case, whethere they rejected/accepted offered a change proposal to the existing worklog.
THOUGHT:
Now thinking about this more, maybe we should generally NOT have an option to propose tasks when submitting a worklog, but instead we have a special message type which is for proposing tasks, and if you did some work and created a worklog but there is no task yet that would fit the work that has been done, then maybe there should be a batch message:
And the client would respond with a feedback message to accept/change/reject those.
This makes each message simpler and not stuffing too many purposes into a single message.
guiding principles:
THOUHGT:
We might want one column "message types" on the entire figma canvas
That column could include a "sub table" with one column per message type
We then have in each row of those message type component columns a label and timestamp
Also if we make a specific e.g. worklog message type iteration and we re-use the exact same layout for the task/input/output as it shows in the task menu component, then we should mark the exact column and row/label/version/timestamp of the task menu component we are using in this iteration of the worklog message type iteration.
So if we have something like this, as mentioned earlier as some sort of collapsed rollup of a series of related messages, then it should be marked as such.
We would first need to decide a strict technical criteria how and when we group messages and is there a possibility for intermediate unrelated messages that can be send in between and what happens with those?
Anyway, if we have a clear concept, then i would call those not "summary messages" but: conversation summaries inside of a task chat.
Now think again - IF (as said earlier)... a worklog always basically closes a task chat, which means we are really radical, because we make the tool and we can and it really helps a lot by working actively and a lot with the tasks (which is something we sadly dont do at the moment), THEN: a task room that gets closed with a worklog is already a "converation summary" around that specific task.
So do we need more than that? I know this is a lot different from what we do on github, because we have long conversations here always under the same issue with lots of worklogs, but this is bad and this is mainly because creating so many github issues all the time and then closing them properly and so on is a lot of "administrative overhead"
We don't do it because it is too much work, but a messenger could make it effortless and the advantage would be an up-to-date task structure that is really heavily in use and shows us our progress quite well.
Thanks for mentioning you are gonna add the "time spent" to each worklog. Please have in mind the list i wrote earlier on the chat.
You mentioned you feel like you did not miss anything in that list,
but your wireframed worklog message type only shows open questions
I did not see how a provider can propose a list o (sub) tasks + inputs/outputs - that is different from existing tasks which have been finished in the sent worklog with the created outputs. This is for new (not yet finished) tasks that should exist and that will (if accepted by the client) be completed in future worklogs.
I also did not see an additional free form text - just the section labeled as "open questions".
now again - thinking about what is written above in this github feedback comment of mine - maybe we should separate those additioanl worklog message type features from the list below which i just described into separate message types and then a provider (=worker) can submit a batch of messages for approval, one of them is a worklog but another one is proposing additional tasks. That way things are more flexible.
1. time/date stamp
2. user (avatar + identicon)
3. list of tasks that have been worked on and how much time went into each
4. list of outputs that were produced
5. [optional] a list of open questions
6. [optional] a list of suggested (sub)tasks and inputs/outputs to add to the issue to be worked on in the future
7. additional free form textand the protocol for changes looks like
⛓CHANGED: [📃change] ⌛PENDING -> ❓REQUEST 🆗INITIAL: [📃change] ⌛PENDING -> ❓REQUEST ⌛PENDING: [🚫cancel] ⛔ABORTED -> ⛔ABORTED ❓REQUEST: [👌accept] ⛓CHANGED -> ⛓CHANGED [📃change] ⌛PENDING -> ❓REQUEST [❌reject] ⛔ABORTED -> ⛔ABORTED
feedback 2022.08.26
This is the figma canvas.
Of course it does not include all the previous parts containing our iteration on the task menu, which it maybe should include.
But on top of that - from a zoomed out high level view, this figma canvas does not look like a table, but more like a mess :sweat_smile:
here is another figma canvas where you say it is mobile, but the headlines say desktop.
:+1: for the versions, but still timestamps are missing. Another problem is, that it only says "desktop" (maybe you mean mobile), but either way, it is only a summary view, which technically should be one "column" in the canvas and then rows should be versions of the "desktop component" (which means the component that combines everything, basically the entire app), but there should be a lot more columns for all the ingredients, the separate components that are used by the desktop component column ...and of course, each row, each iteration of a component like a desktop component would use different versions of other components.
this way we only need a single large figma canvas that contains everything ...and if that is too much for figma, we can maybe outsource some component columns to different pages, but if possible i would want to avoid that.
TASKS I think it would be totally worth it, to create a new figma file and go back to the very beginning when we started working (previous worklogs and figma components) and copy them over onto that new figma canvas into different column components and iterations.
We can create some github issue tasks with the output of a new version controlled figma file to re-build the figma history in this very precise and controlled manner.
so, in programming people strictly work with commits so the entire change history is visible and it is possible to roll back and see earlier versions
I would like to get to something similar when using and working on many components in figma over time.
Here I recorded 2 videos to explain how i imagine that and would be happy if we can try to slowly convert our figma files and stick to a style like that.
serapath
commented
1 year ago feedback 2022.08.27
@outputquestionFigma mobile components
i like the idea.
agree => let's go for the first version and show [accept][reject] directly, but let's also include [change] which means not accepting or rejecting it directly, but asking for refinement before accepting or rejecting it.
more specifically:
lets use the "upper left" and the "lower right" as the collapsed and expanded version, so in terms of figma, it would be cool to have another row/iteration in the column of the worklog component, where we show those two and not the ones with the "action+accept+reject" anymore.
It is a quick copy/paste but then removing the ones that we wont use anymore :-)
super simple, super quick but clearly communicates what our latest decision is.
after selecting an action i agree there should be a "feedback input component" (lets make a column for that with a first iteration in the first row of that) and i am cool with that proposal you show.
It should show though which action was selected.
was it or will it be a feedback that "rejects" or "accepts" or requests "changes"? ...unclear from that feedback input box alone.
also
i would strongly recommend to replace at least partially the bold/italic/bulletpoints/list formatting options and instead we will make the input field support markdown.
even the "smilies" could be an autocomplete dropdown that gets activated when the user presses : because :100: for example will produce :100: and all we need then is a little "markdown help" icon that a user can click to see all the possible markdown commands instead. typing markdown is anyway lightyears faster than selecting text and then pressing those formatting buttons, so we want to promote/facilitate that users learn the future literacy and then they become way faster and more productive :-)
This component might exist with a first iteration before the individual parts exist. ...but then we discuss it and we roughly agree and then maybe we make the individual components included in this flow, which are the "worklog message" and maybe the "worklog actions" a user can select and a "feedback input field" component and make columns that also have a first iteration of those ...and then afterwards we can come back to the "feedback flow component" that puts all of that together and we make a second iteration that refines it.
This is essentially the continuation of the "feedback flow", so technically, once we improve the "feedback flow" component we might figure out that we should call that a "worklog-feedback-conversation-component" so maybe in iteration3 or iteration4 of that feedback flow component column, we decide to rename it into "worklog-feedback-conversation" component.
.... or not, maybe the "feedback flow component" is a sub component of the more complex "worklog-feedback-conversation component".
I think we will figure that out while working on the iterations :-)
here the marked actions and the expand/collapse are ok, but what is not ok is to have a single message with the title showing, e.g.:
david + avatar + identicon + timestamp ...but having both messages, the worklog and feedback, even though the feedback was sent by nina.
ninas feedback message has it's own avatar + identicon + timestamp, so it should be separate messages.
But maybe those messages can be collapsed into some sort of third component which includes a series of related worklog/feedback messages and we call that a worklog-feedback-conversation component which can be expanded to see all the individual messages or it can be collapsed into something that looks like what you show, but is clearly marked as a conversation and that means it needs to indicate that in the title by showing at least both names, avatars, identicons and also showing 2 timesstamps, the timestamp of the first and the timestamp of the last message ...so a conversation is a time interval. ...and it could also include a message counter and some other statistics (e.g. number of outputs or whatever.. we will see by iterating that conversation component.
in general in this worklog video 49 you explain flows with lots of component "screenshot" snippets going back and forth between them and it makes sense, but this sense exists because of the video. It is not so east to see how that flow comes together by just looking at the figma file alone, so that's also why i think we need to make specific "flow components" and also individual ones and have all these iterations and columns labeled, timestamped and for complex components in every iteration list the specific "sub component columns with iteration number" to know exactly what are we looking at :-)
serapath
commented
1 year ago feedback 2022.08.27
@outputquestionFigma mobile components
So the "worklog input component" should get split into simpler actions. This form is already too complex.
Let people just send multiple different type of messages or use the "batch actions" feature to create a complex message that includes multiple connected messages of different types.
Also - again, for tasks, outputs and time we should re-use the "task menu" as much as possible and have it more like an "editable file explorer" (like vscode file tree explorer allows change actions)
The whole change is then proposed in a message and if the worklog is accepted it will change the actual task menu (e.g. change a planned output to a done output and change a task to finished)
also the "completed task" worklog type is not necessary, because the task itself will have a checkmark and be marked as finished so that's already self explanatory.
*note:** actually, it would make sense to allow a provider who wants to work on tasks to actually start/stop timers ...it is relatively easy to integrate "time tracking" too, so they will have an easier time with that part :-) ...if we already build a task messenger, maybe it would make sense to think of that essential feature that everyone anyway will need somehow.
Yes perfect, lets give that component it's own column and name.
I agree we somehow need this.
note: this component will also be used in the task menu component i imagine.
for example this part of the worklog input form, i imagine more similar to the task menu, which means i would click on the "task name" listed further above in the worklog, the one which i finished and log time for and now, because that task is selected, the "bottom action bar" would show me an action "add output"
or alternatively, because a specific task is already selected and the planned outputs can be expanded, just like in the task menu ...we can now click on one of those planned outputs to select it and that will show the "upload" or "link" action in the bottom action bar and if i click it and select a file or paste or type a link, that will then update the planned output to done output with the uploaded or linked document ....
That would feel more natural and in line with our general concept of:
=> and here in the worklog form we do it the same way again like everywhere else - so nothing new to learn by the user and we can re-use the existing action bar and task menu components.
this is good, but as said earlier - let's switch this and make it a markdown input field instead :-)
serapath
commented
1 year ago feedback 2022.08.27
@outputquestionFigma mobile components
again, watching all the videos. Main wish is to structure the figma file into the columns and rows and annotate everything with iteration number and complex component iterations with the list of sub components used, etc.. so that i can easily get an overview over our progress and what lead to what over time.
i love the iteration on the worklog component.
as said earlier, more changes are required, but i can definitely see a good imporvement.
:+1: for having the time included the person :construction_worker: david can be skipped, because that's implicit in the sender of the message. of course- only the assigned provider can trigger the worklog action, so the name of the provider is already included in the title bar of that worklog message, what could be included though (next to the time) is the amount of outputs and whether the worklog contains a comment or not.
Again further more, the grouping of worklogs and feedbacks needs to change too - see previous feedback comments above :-)
So basically, one take away:
Let's name every component and give it a column with the iterations for that component.
Let's list the specific iterations of all sub components used in an iteration for a more complex component column.
@todo@input:package:what have we built hackmdfrom #45@input:package:history content slidesfrom #45@input:package:brief summary slide deckfrom #42@input:package:concept outline descriptionfrom #46@input:package:wizard amigos summary pagefrom #102@output📦Figma Link1fromcomment@input📦Figma Link1@output📦 Figma Link2 fromcomment@input📦Figma Link2@output📦 Figma Link3 fromcomment@input❓idea came fromcontext 59#comment so what is a QUIZ in this context? section@input:question:idea came from59#comment section B@input:question:idea came from59#comment section A , first todo@output:factory: hackmd file@output:question:gig/exercise data generator slides@output:question:gig/exercise data generator wireframes@output:question:gig/exercise data generator linked markdown file per slide in "./slides/<slidename>.md"@output:question:gig/exercise viewer slides@output:question:gig/exercise viewer wireframes@output:question:gig/exercise viewer linked markdown file per slide in "./slides/<slidename>.md"@output:question:gig/exercise editor slides@output:question:gig/exercise editor wireframes@output:question:gig/exercise editor linked markdown file per slide in "./slides/<slidename>.md"@inforegarding bounty programs and gigs in general, here are pages that do those:
more infos
the only difference between an
exerciseand agigis, that the exercise is posted by a bot and the "gig chat" of an exercise is about talking to a bot and the payment at the end is 0 but the learners has a finished exercise, so UI wise those are almost identical and can be re-used mostly. Technically an exercise can even have a real payment attached and a gig could technically also be managed by a bot, so the distinction is not super clear and for a learner it might not even matter.Layout is a special instance of #60
Get paid
Not Real Moneymaybe points? when the task is anexerciseinstead of agigGet Paid Real Money
“chat actions” (= type of messages), like: a worklog messages (where you record/upload a short screencast video) + a feedback message + probably some other more contract related type of messages to set, review, accept, confirm, etc… work and issue payments
some gigs can be pro bono maybe its something not executable, like a question or just a thumbs up, maybe that has to go into the chat and you can subscribe to answers there too ...or the gig is to answer you the question and the bounty is 0
the gig view will let you do messages of type comment (like on GitHub issues), but also some other “chat actions” (= type of messages), like: a worklog messages (where you record/upload a short screencast video) + a feedback message + probably some other more contract related type of messages to set, review, accept, confirm, etc… work and issue payments
CONTRACTUAL Another thing is, that clicking a "custom action" like apply for a gig just means some sort of special "chat message" (or "chat action") In fact, when doing a gig and talking to the author of the gig and working on it, there are many such "chat actions", for example:
So when a user clicks "APPLY" on a gig, thats the first message in that chat. The response of the author could be an accept/reject or some text before the accept/reject is issued once accepted, maybe the gig disappears from the public list or is in progress and others are then not able to apply But if the author rejects, the gig is again open for others Now details whether that discussion is public or private is for later and for now i would all keep it open, because thats how we work and how github works and its for now one less thing to worry about. Also: other applicants can already learn from previous applicants and the conversations instead of going through all the questions again and again :-)
Infoclicking on "submit feedback" is basically opening or making a gig and the gig can be closed/removed by the maintainers, also like every gig, a bounty can be attached or maybe other users who want to submit feedback see an existing similar gig feedback and just add some more information and add some more bounty, other kinds of feeedback would probably instead just be a "chat message", not in the workshop chat, but in the chat of maintainers. submitting a feedback is opening or participating with info or bounty in an existing feedback gig