Tasks Redesign - Feedback


Hi all :wave:,

We would like to hear more of your feedback on the proposed redesign for Tasks.
Can you see something in the mockups that could be improved?
Can you think of other use cases you would like to see?

See the mocks and video below and share your thoughts in the comments!

[1] Invision Mockups
[2] YouTube Recording - starts @22:05

Your UXDers,
Tereza & Rox


Looking for some additional thoughts on how you perceive the Scheduled card as well! Thanks everyone!


thanks for the wireframes :slight_smile:

A few random thoughts after seeing the recording

  • why do we show tasks that are not in the time frame we defined ? e.g. if 24 hours is selected, I still see tasks running/paused older than 24 hours?
  • why do we need different cards for running and paused? (a task can be running/paused/stopped)?
  • using the term stopped is strange, maybe completed (stopped sounds negative? - such as stopped incorrectly)
  • Filters seems to be a new pattern to foreman? the syntax is also not the same.
  • what is the pagination size of tasks (i guess it should be relatively small number - e.g. show about 10 entries per screen?)
  • when clicking on a chart (such as running) the underline feels a bit strange to indicate you are in that view…?
  • how often should the dashboard update? is it expect to refresh data while looking at it? after a click etc?
  • schedule card afaiu is simply tasks scheduled in the future (not sure how further away), not sure if that includes reoccurring tasks too.

We had some offline discussion so I’ll recap it here as well.

First of all, I really like this quick drill down on top. IMHO it can become a pattern. On the host page I’d love an easy way to only show hosts in error state but there are other things. Right now I use the dashboard for that but including that makes it much quicker.

Technical implementation note: it’d be great if these widgets could be shared between the central dashboard and this page so users can easily add them to the main dashboard.

That said, I always like to hash out a feature in one place before applying it everywhere.

The placement of With focus on last <drop down> made me think that it controlled the entire page rather than just the dashboard part of it. Moving it below the widgets could reduce that perception. I would also consider radio buttons if you provide just 3 options.

This is probably an artifact of the mockup, but it would be good to see the various tasks results. Currently it only shows a green result, but the reality is that it isn’t always successful. Otherwise the page wouldn’t be needed :wink:

Icons for task state (scheduled, paused, running, finished) could also be useful but maybe too distracting.

I don’t see a Search button on the filter. Does that mean it’s always live search?

What’s the idea behind the name dropdown in the filter field?

While thinking of it, I was wondering if we already show task ‘dashboard’ does it make sense to show trends, e.g. failure rate over time, most failing tasks, most common tasks etc? top 10 tasks (that took the longest, that failed the most, that… something else)?

1 Like

I’d add some place where we would explain why users have Foreman Tasks and what’s so cool about it. They previously had bad reputation because it is the place where users often go when things break. But they allow pretty good stuff if users understand what’s going on and what they can do.

1 Like

If such explanation is added, perhaps also some more information for the always running tasks from Katello or those waiting for pulp to get picked up can be added because I see many times people have to understand why these tasks are special.

Yeah, I was also thinking a guide when things are red - what to do. Typical failures and how to solve them.

1 Like

We have a helper to link to our website docs. IIRC that was also flexible enough to change it in (for example to RH docs in Satellite). Would that be a good idea to use rather than in-product documentation? The downside is that most tasks come from plugins.

Something more user friendly like wizard could be appropriate, that’s my point.

I’ll let @iNecas reply, but as part of this whole effort, tasks themselve will provide some hints and error explanations. I don’t think it should be incorporated to this dashboard. There were also discussions about how to mark long running tasks, which are supposed to be always running. I don’t think it was part of 1.22 scope, but I think we agreed on a “system task” flag. A notification should appear if some expected system task does not run. We also discussed extending plugin DSL so plugins can tell, which of their tasks are considered as system tasks.


Let me summarize on what we are working on right now outside of the dashboardy eye candy

Notifications on paused tasks

Whenever a new task gets into paused state, a notification will be triggered so that the user knows there is something wrong

We are considering 2 kinds of notifications:

  • the user that triggered the task gets notification about the specific task getting paused, with:

    • link to the task itself
    • link to troubleshooting docs for this particular task
    • any additional link specific for this task - extendable from code
  • all admins get notification about some paused tasks being currently present in the system that need attention with:

    • link to list of all paused tasks
    • link to generic tasks troubleshooting page

To avoid high load of notifications in case the system goes south, the admins won’t get new notification on every paused tasks (this might get bad especially when the paused tasks are produced from hosts-related operations).

Instead, if there is an existing unread notification with There are n paused tasks in the system that need attention, we will update it with There are n+1 paused tasks in the system that need attention. The timestamp on the notification will be updated, so that this notification goes up in the drawer. So the admin paused tasks notifications will be aggregated.

Once the notification is marked as read, we’re not touching it anymore, but instead, creating a new notification instead

Tasks-related troubleshooting info

In connection to the notifications, we want to be able to provide useful troubleshooting info for the user, including both some textual help, but especially links to the upstream docs.

The idea is:

  • there will be a description defined in foreman-tasks, applicable to most of the tasks, that will provide generic troubleshooting text and links
  • for specific tasks, it will be possible to extend this text with task-specific info and links from the definition of the task in the plugin that is defining it
  • this data will be shown in the task details page in case the task is in paused state
  • the links will be used also from the user notifications

We would like the generic description as flexible as possible, so even in there, we will add an anchor into the link, including the label of the task, so that, in case the documentation has an anchor like that, it will lead the user to go there, without need to update the code itself. So for example, for action ‘Actions::Katello::Repository::CapsuleSync’, the help link would be something like (where exactly this page will be is not set yet):


Notifications on stale tasks

For tasks running over expected time, we would like to generate notification as well, to grab admins’ attention to those as well. It will work similarly as the paused ones, with one difference of periodic check for this tasks (while the paused notification will be triggered every time there is new paused task)

Note about system tasks

This will be probably post 1.22, but as Marek mentioned, we would like to mark the specially kind of tasks, such as ListenOnCandlepinEvents, visually, so that people know what to do with those. Not more details on that right now.

Feedback on those welcome. I would like to start pushing this changes upstream next week, so this is the right time for getting your opinions integrated.


just wondering, are there new wireframes ? (based on the above feedback?)

Hey Ohad,

Feedback was incorporated into the implementation and not the mockups as development was moving forward and that was fastest.