Hi, I was playing around trying to fix some small issues on the Task detail page, and I accidentally redesigned the whole thing (without talking to you). So here I am asking for:
Feedback for the proposed design (e.g., combining tabs, naming)
Any current pain points that come to your mind
Are you even checking tabs or are you going directly to the Dynflow console
When do you use locks?
Is it possible to create human-readable error notifications?
Using a short inline alert to display problematic issues
The progress bar was displayed just during the progress
Some buttons are hidden in the kebab
More informative empty states
More informative Locks tab
PF5
Proposed designs
Bear in mind, this is not pixel-perfect; it’s a draft. Everything can be changed, microcopy still needs review. Dummy data, state terminology is not precise (I am aware). I am not sure about primary, secondary buttons - so u can see multiple alternatives here.
On this picture, is auto reload on or off? I would assume it is off, but I’m not sure.
I know this is personal preference, but the fields like state, label and so one were easier to read in the more table-like layout of the old design.
Also, the “Start at” field is a relatively important one for things which were scheduled for the future.
The “Temporarily suspended step(s)” makes it sound a bit as if it is an outcome of some user action while in reality (and in most cases) it is just the task waiting for some external action to finish. With that being said, I don’t really have any suggestions that would read better.
In theory, there can be multiple warnings, errors, inputs, outputs, exceptions and backtraces at the same time for example if multiple concurrent steps of a single task failed. How would this be displayed then?
Afaik there is no documentation on resource locking as that is a mostly internal thing that the user has little to no options to affect.
This is a from a very quick glance, and may be biased by looking at the old page for years, but I agree that the state and such on the old page feel easier to read quickly.
The result and state values both indicate the status of a task so it’d be good to retain the result field for task details.
On the success screen I like seeing the 100% complete green progress bar on the old UI. It tells you immediately that all is good. Same for the red progress bar for errors.
I very much appreciate the tabs being combined. I never really understood the seperation between “Task”, “Running Tabs” and “Errors”. The locks tab could very well just not exist in my opinion. As a user, I never found any value in that tab.
I would like all the important information being on the default page, which your proposed design seems to achieve.
Sometimes, but I primarily use the “Task” tab for a general overview of the tasks state and the “Raw” tab to recieve Task IDs when I need to manually do task cleanups because something broke.
Literally never. As a user, I believe that tab has absolutely zero value to me.
That would be great, but I would assume that primarily depends on backend services returning better readable error messages?
Get a general overview of a tasks status/error messages; Wait for the progessbar to fill; Try to fix broken Tasks (Resume, Cancle, get task ID from Raw to throw into a cleanup rake task); Click Dynflow console and hope it helps me any more than the error messages on the tasks page.
In general, I like the direction you took with the redesign.
Personally, I really dislike Kebab menus in general. In this specific case, the main reason I go to a task page at all is to troubleshoot broken tasks, which usually includes either the Resume or the Cancle button, which are both hidden behind the kebab menu in your proposed design. While the whole UI is moving more and more in this direction, I would argue that common tasks for a page should not be hidden behind a kebab menu.
What exactly do you mean by this? The buttons seem identical to me in all the pictures except “Auto reload” being blue sometimes.
Side-note: Is there any real reason to have a big, prominent button for toggling auto reload at all? I know it has been there forever, but I personally never found myself in a situation where I wanted to turn it of. Maybe I am overlooking something here, but having it as one of the two buttons that are not in the kebab just seems like wasted space to me. (Looping back to my “I don’t like kebabs point”).
I would also agree that this needs some better wording. Just from looking at it, I have no clue what that state is even supposed to be.
+1, please keep both fields
Some additional notes:
Why is the Name/description on the top of the page duplicated? Is this some intended effect of combining some fields or just random placeholder text?
Please keep/parse newlines in the Exception, Backtrace, etc fields and either make them expand to show the whole thing by default or at least have a “expand” element to make everything visible at once. This would make these fields way more readable by that more useful imho.
Regarding the progess bar: Would that still be present for tasks in paused state? I would be fine with the progress bar missing on finished tasks as long as that accurately represents a task being 100% finished. I believe a green checkmark or the yellow/red alert boxes should be enough visual feedback for a tasks state once one gets used to the new design.
Perhaps a minor detail, but should the status icon in the title be after the text? I’m talking about the one after Refresh Alternative Content Source refresh alternate content source. If you have it at the start of the line then it’s always in the same place. Visually it’ll be easier to find.
Then it is very close to the Result so that may feel a bit redundant. Perhaps Result and State should be combined? What are even the various combinations?
In the code I see some values:
But I think Result is only relevant for Stopped tasks so is it valid to never display Stopped but rather the result if it’s stopped?
Does the Started at value (relative time) have a hover with the absolute time? It may make less sense, but the Duration could also have a hover with the Ended at time. I’d still display them in the expanded tab because I’m unsure how well hover works on mobile interfaces but it may still help some users.
I also wonder how often people look at the task ID and if it should be moved to the expanded details section.
We look at it any time we need to kill a stuck job/task - with an average of 150k jobs a day, it happens. Then we need to go into foreman-rake and kill it with its ID, since the UI doesnt handle job aborting all that well.
@ekohl
Based on the previous feedback, I added ID and also state + result part since people were asking for it. (Of course, I can see the combination - scheduled, paused, running, success, warning, error, cancelled.)
@andreilakatos came up with these, pls let him know if they are incorrect
I do not know what results Paused state may have. Is it just an error?
Is it a problem if you need to expand the details?
Can you also elaborate on what foreman-rake task you exactly use? If we don’t expose that, perhaps that’s the bug we should be addressing rather than making a design that makes an internal detail a prominent feature.
We use it to clear out tasks that get stuck and wont cancel/abort. Generally this is due to a task that went missing, a proxy that had an issue, or some random host that thinks it still needs to run the job. But it ends up working that no matter how many times you click Cancel or Abort, no matter how long you wait, the job will sit stuck in a Running state forever.
This is the current process we have to run:
Removing Stuck Tasks (running/pending)
1. Open the Rails Console foreman-rake console
2. Identify Your Task Model
Most commonly used model: ForemanTasks::Task
For Salt-related tasks, it might be: ForemanTasks::Task::DynflowTask
Check the existing task states and results: ForemanTasks::Task.pluck(:state, :result).uniq
If you see [“planned”, “pending”] or [“running”, “pending”], these are likely stuck tasks.
)