Open WebDevJL opened 9 years ago
Here are some thoughts:
1) The primary route to the analyte/uploadList page is going to be through the Task UI. Therefore, we won't be "promoting" items any more, at least not in this context. Since we are moving away from this paradigm, best to move away here, too.
2) As part of Issue #586, we have an autocomplete feature for Lab Analytes. This means we really don't need the right hand column any more (common lab analytes) - this is somewhat redundant. We could implement the same feature for field parameters and it gives us another column to work with.
3) I like your interface to define groupings - perhaps we could use that in a popup.
4) After further thought, we will need to create sub-tasks, rather than multiple tasks. This fits the common use, say in a GANT chart or MS Project. See the attached photo. I'm not sure how to display that yet
5) If we have subtasks, as I have shown in this mockup (thanks to your clever "command + S") we could split the task up however we like, assigning different FTs to different subtasks, or to different locations, or field parameters. For now, we will focus on splitting field parameters into groups. Second screenshot.
That's all I have time to do before we talk.
Brian
On 2015-09-02 00:10, Jérémie Litzler wrote:
@bsaiken [1]
Here is my proposal:
Database details: https://diagrams.seaquail.net/Diagram.aspx?ID=24524 [2] Suggestion of UI flow: https://docs.google.com/presentation/d/1wwZR7aOZ0TTpy82iOn4UAmAXq4MjYFYzwvdkzG4gzU0 [3]
Hopefully, you have a look and give me a feedback by the time we talk.
Reply to this email directly or view it on GitHub [4].
*
Links:
[1] https://github.com/bsaiken [2] https://diagrams.seaquail.net/Diagram.aspx?ID=24524 [3] https://docs.google.com/presentation/d/1wwZR7aOZ0TTpy82iOn4UAmAXq4MjYFYzwvdkzG4gzU0 [4] https://github.com/FWAJL/FieldWorkManager/issues/1271
@bsaiken since you introduced the concept of task / sub-task, I rename this issue "Task and sub-task implementation" because the field parameters group is not applicable since there won't be any group really.
I will post more updates on the implementation soon.
@bsaiken I have push a mockup to the repository in Mockups/issue-1271-mockup.html. Here is a screenshot in case you can't load the mockup:
This is the idea of yours to have a similar menu as the mobile ui for all the legacy left menu and two icons to add a task and one to list the tasks. Add task and List tasks pages or popup would be the existing page with the difference that the List of tasks is categorised by project.
Also we could have the sub tasks indented to the left to show they are dependent of their parent task.
In my commit, we have the two new columns that will allow sub-task creation: task_type
of value "parent" or "child" and task_reference_id
which will be a task_id value is the task_type
equals "child".
I will write the functionalities behind it, trying to detail the various use cases.
Thank you.
@WebDevJL
I am assuming the top menu items would be as follows:
fa-list
is the list of Tasks
fa-plus-circle
would be used to add a new Task
id="collapse-menu-button"
brings up the legacy menu.
@bsaiken the order is up to you. The mockup is a starting idea.
Do you like that option to remove the left menu?
@WebDevJL Web Yes, this is what we talked about. The left menu is still there, just hidden, and most of the navigation can be accessed from the /task/ UI.
@bsaiken
I have an idea for tasks and subtask navigation. I'll try to pitch you a mock-up by tomorrow. I have done a very simple Google presentation so far but I want to take 30 more min to present it.
Thank you. On 10 Sep 2015 16:00, "bsaiken" notifications@github.com wrote:
@WebDevJL https://github.com/WebDevJL Web Yes, this is what we talked about. The left menu is still there, just hidden, and most of the navigation can be accessed from the /task/ UI.
— Reply to this email directly or view it on GitHub https://github.com/FWAJL/FieldWorkManager/issues/1271#issuecomment-139242679 .
@bsaiken here is my idea.
I know you wanted to remove the left menu because it had lots of links not useful at all times. So we moved it to the 3-lines icon like the Mobile UI. In addition we have a plus icon to add a new task and list icon to list task. The screenshots below are a suggestion of navigation in the tasks.
Now, I suggest to use the space on the left to display, on click of the list icon, the list of tasks and subtasks. Then, the main content area remains the same. We only need to update the logic to get data displayed and add an element "subtask" to the breadcrumb. The work to be done is under the hood rather than redoing the UI part entirely. The task navigation bar could display, in addition of the breadcrumb, a highlight style for the selected task (parent or child, whichever). See mockups issue-1271-mockup-task.html and issue-1271-mockup-subtask.html:
The first mockup (issue-1271-mockup.html) shows how it'd look when the list is not displayed on the side.
I suggest we should first tackle down this task / subtask update before dealing with field parameters group and repeat settings. The later will follow closely.
Two points remain that we need to address are:
Hopefully, you find in this something that interests you to go forward.
Thank you.
@WebDevJL This looks good. Here are some answers to your questions, and a couple other thoughts.
@WebDevJL wrote: I think we can make a similar popup as the current one with the option to select a parent type task first.
I was thinking the same. Either we have a popup option, or we use two add task icons, one is for primary task, one is for sub-task. Easy to distinguish, say a larger icon for Task Add and a smaller Icon for the Subtask Add. Plus, the subtask icon can be disabled when the user has a subtask selected.
@WebDevJL wrote: In the task list, would you need to display the project name as the first level of the task list navigation or rather have a drop-down list to pick a project to filter the task list?
Yes, it makes sense to display as follows:
If we have a this as our left menu, we do not need breadcrumbs because we can simply highlight the current Task or Subtask in the left menu. Also, everything in the left menu is selectable. We could have a contextual menu to allow the user to edit the Project, for example. With Tasks and Subtasks, we wouldn't need a contextual menu as clicking on either would take the user immediately to the edit view of that Task (or to the showForm for an active Task).
I was also thinking about how to activate and deactivate Tasks. We do not need to use a dual list any more for this action. In the inactive Task UI, we added a button to activate the Task. We could do the same for an active Task (add a button to inactivate, or make editable). Then, in the left menu, we can use a simple color coding to identify inactive, active and completed tasks. Inactive Tasks are colored (orange, perhaps), active Tasks are black, and completed Tasks are grey. It makes sense to use this same color coding for subTasks.
All commit are on the dev branch.
@bsaiken said: I was thinking the same. Either we have a popup option, or we use two add task icons, one is for primary task, one is for sub-task. Easy to distinguish, say a larger icon for Task Add and a smaller Icon for the Subtask Add. Plus, the subtask icon can be disabled when the user has a subtask selected.
see the mockup in this commit: https://github.com/FWAJL/FieldWorkManager/commit/89301d42b494970a732f585f49c13565bf47f8be
@bsaiken said: Yes, it makes sense to display as follows:
- Project Name
- Task Name
- Subtask Name
See the updated mockup issue-1271-mockup-subtask and issue-1271-mockup-task
@bsaiken said: I was also thinking about how to activate and deactivate Tasks. We do not need to use a dual list any more for this action. In the inactive Task UI, we added a button to activate the Task. We could do the same for an active Task (add a button to inactivate, or make editable). Then, in the left menu, we can use a simple color coding to identify inactive, active and completed tasks. Inactive Tasks are colored (orange, perhaps), active Tasks are black, and completed Tasks are grey. It makes sense to use this same color coding for subTasks.
I will do that later on as I need to go for now. Hopefully, the tweaks of the UI are ok with you. Let me know.
@WebDevJL
@WebDevJL said: see the mockup in this commit: 89301d4
I would rather have a button on the task/showForm/
page. One thing this does is force the user to have already selected a Task. After the subtask is created, the user can access it for further edits via the left menu.
@WebDevJL said: See the updated mockup issue-1271-mockup-subtask and issue-1271-mockup-task
I see where you are going with this. Some of the behaviors are buggy, but I do like the idea I think. It is too narrow, so we can fix that by making it much wider then have it be collapsible, like this:
http://ironsummitmedia.github.io/startbootstrap-simple-sidebar/
I assume the "+" on the sidebar is to add a subtask, but as I said I'd rather have the Add SubTask be a button on the task/showForm/
page.
I had another thought about subtasks as well. On the task/showForm/
page, we have the options at the bottom, e.g. collect field parameters, collect lab samples, etc. If we have subtasks, this could be refined a little bit and each distinct activity can be a subtask. For example, collect lab samples would actually require (usually) 2, sometimes 3, or even more subtasks - no we would have a way of neatly organizing the work. For example, when we sample a well, there are usually three distinct subtasks: 1) collect water levels, 2) purge well, 3) collect lab samples (Aurelie could explain in detail). Anyway, in this case building the subtasks would be much easier if we started on the task/showForm/
page, so we could specify some options, like the list we have now, for common field activites. It may even be that the Task itself does has fewer tabs, perhaps just a master list of FTs, Locations and a master checklist. I'll think more about it this weekend.
@bsaiken said: I would rather have a button on the task/showForm/ page. One thing this does is force the user to have already selected a Task. After the subtask is created, the user can access it for further edits via the left menu.
Ok. Does it make sense then not display the button once we know we are editing a subtask, just to make a 2-levels complexity, even if theoretically we could have as many levels as we want.
@bsaiken said: I see where you are going with this. Some of the behaviors are buggy, but I do like the idea I think. It is too narrow, so we can fix that by making it much wider then have it be collapsible, like this: http://ironsummitmedia.github.io/startbootstrap-simple-sidebar/
Ok for the menu. I will see what can be done.
@bsaiken said: I had another thought about subtasks as well. On the task/showForm/ page, we have the options at the bottom, e.g. collect field parameters, collect lab samples, etc. If we have subtasks, this could be refined a little bit and each distinct activity can be a subtask. For example, collect lab samples would actually require (usually) 2, sometimes 3, or even more subtasks - no we would have a way of neatly organizing the work. For example, when we sample a well, there are usually three distinct subtasks: 1) collect water levels, 2) purge well, 3) collect lab samples (Aurelie could explain in detail). Anyway, in this case building the subtasks would be much easier if we started on the task/showForm/ page, so we could specify some options, like the list we have now, for common field activites. It may even be that the Task itself does has fewer tabs, perhaps just a master list of FTs, Locations and a master checklist. I'll think more about it this weekend.
Have you thought more about it? This adds another layer complexity and we didn't start the subtask implementation yet. Let me know.
Thank you.
@WebDevJL
@WebDevJL said: Does it make sense then not display the button once we know we are editing a subtask?
Yes, that is the best solution.
@WebDevJL said: Have you thought more about it?
Yes. I was rambling a bit. I think we can accomplish this without too much complexity. Let's get the basic set up first, then expand.
@bsaiken ok so I'll tackle this after the release. I'll make a summary of what we need to do to see clearly what we need to code. So far only the database updates are done. On 18 Sep 2015 16:03, "bsaiken" notifications@github.com wrote:
@WebDevJL https://github.com/WebDevJL
@WebDevJL https://github.com/WebDevJL said: Does it make sense then not display the button once we know we are editing a subtask?
Yes, that is the best solution.
@WebDevJL https://github.com/WebDevJL said: Have you thought more about it?
Yes. I was rambling a bit. I think we can accomplish this without too much complexity. Let's get the basic set up first, then expand.
— Reply to this email directly or view it on GitHub https://github.com/FWAJL/FieldWorkManager/issues/1271#issuecomment-141459487 .
@bsaiken
Here is the task list from the discussion so far:
@bsaiken
You can view the first step done : on http://debug.fieldworkmanager.com/login => add the 3 icons menus in the top bar with a list icon (to display the task list), a plus icon (to add a task) and a 3-bars icon to display the legacy menu.
@bsaiken
Here is my proposal:
Database details: https://diagrams.seaquail.net/Diagram.aspx?ID=24524 Suggestion of UI flow: https://docs.google.com/presentation/d/1wwZR7aOZ0TTpy82iOn4UAmAXq4MjYFYzwvdkzG4gzU0
Hopefully, you have a look and give me a feedback by the time we talk.