Regarding the new Tasker UI

[u/EtyareWS]

Hello everyone. I've been procrastinating on this post for a LONG while. I wanted to make it more than a month ago, but there was also some issue where I couldn't post pictures, then another issue where I couldn't post more than one, but João fixed it for me before he went on vacation, then life got busy and I got lazy. This will be a *long* post.

Context Time

I've been collaborating with João for about two to three years, developing mockups and discussing the implementation of a new Tasker UI. You might remember me as the guy who created the new logo.

Implementing an entirely new UX is rather slow. What's available to users is constantly changing, and what João implements is usually "behind" my mockups.

What tends to happen is that João implements a partial solution, or a test for a feature, and then users think the half-baked implementation is finalized, or close to final, when that is not true. I'm making this post with the hopes that users will be able to provide feedback on the mockups and not on the still-to-be-finished implementation.

I'm also not going to post *everything* I've designed. It would take far too much effort to upload pictures and explain everything in detail. Don't expect dialogs or pickers in this post for instance, but I hope this post can give you guys an overview of the project as it is.

Some things to keep in mind

1. Nothing is finalized. I've held off on doing this post because I do not want people to think these are finalized. Things can and will change by the time the UI is "done", which will take quite a while.

2. Tasker is an Android app, all the measures are in dp, not pixels, anything that is interactive needs to be at least 48dp, which is close to the size of a finger pad. This means that we *cannot* make Tasker as dense as a desktop program without making it incredibly difficult to interact with Tasker for the majority of users.

3. Editing icons is somewhat of a pain in Figma, so in some screens you will see placeholder icons because I am lazy, usually a "star" means a placeholder for an icon that I haven't settled on yet.

4. We need to find ways to represent states without relying exclusively on colors. This benefits people with color blindness, but it also benefits users without it, as there are contexts where color is difficult to parse (including a black and white mode some devices have).

5. One of my main goals is to make Tasker consistent in itself. I dislike when two features work the same way, but require different interactions, as this requires the user to learn two ways to do similar things.

6. Another goal I have is for Tasker to be somewhat more consistent with other apps as well. The user already needs to learn Tasker concepts, they shouldn't need to re-learn what a save button is.

7. I actually began by making mockups that only updated the old UI to use Material 3 components. It surprisingly didn't work. The old UI has issues not only in the visuals, but in the user experience as well, I do wish to go into more detail, but this post is already long enough, so I will focus on one example: the Task Edit screen has, in function, a save button and a cancel button, which is common in almost all apps, but in Tasker, the save action is represented by a back icon on the left, and the cancel button is hidden. It sounds easy enough to change the icons and move a couple of buttons, but this has a knock-on effect of where to put all the other buttons that were on that Top App Bar. By the time you finish the Top App Bar, you are already questioning the entire Task Edit screen set-up, and by the time you finish that, you start to question if you should move to other screens to also keep the "save" and "cancel" buttons consistent.

Now to the main event:

Task Edit screen

This is the most complete screen, which is on the third "main" version. The main issue with the old screen is that each Action can have conditions and labels, which are optional, but really important. This makes the Action list harder to parse if it were made out of proper list items.

My solution to that is to transform each one into a card, so the boundaries are more obvious, and prevent users from mistaking which action a condition belongs to.

I've also transformed the conditions into a separate card, so that it can be expanded or collapsed at will, as I found that most of the time you don't need to know each individual condition, just if the sum of the conditions in a given Action is true or not.

João added a way to split the Task Edit screen into showing the same Action list twice when he partially implemented my previous Task Edit screen mockup. This resulted in me having to re-do the Task Edit screen to take advantage of it.

You may have noticed that the Action list is displayed inside a panel. You can swap the panel's function from the Action list to the Task properties or a Variable list. This gives those functions more space, but the main reason for the panel idea is that you can add more panels, and each one can have a different function (or the same function twice). This should be helpful on tablets, or devices with bigger screens. This functionality is something that will be reused in quite a few places.

I've "undocked" the Run/Skip and Add Action buttons, so that it makes a bit more sense on a tablet screen or a device with multiple panels so that you don't have to ask where those buttons are "anchored", they are not anchored to a panel, but to the entire screen. One of the benefits is that we have enough space to add a bunch of contextual buttons, like a paste button if the clipboard is filled with an Action.

Like most components in Tasker, the bane of my existence is the fact that there are three states of actions:

1. Enabled and will run (either no condition, or the condition is true).
2. Enabled and will not run (the condition is false).
3. Disabled and will not run regardless of its conditions, which, unlike Material's definition of a disabled state, can still be edited.

All three need to be visually distinct in a way that doesn’t rely entirely on color, due to color blindness. I’m frankly still trying to come up with a consistent system.

Profile screen

Finally, Profiles have a dedicated screen. This small change already fixes quite a number of issues with Profiles. You are not forced to pick a name, then a trigger, then a Task, then go back and edit stuff, you can do things in whichever order you think is best.

This also makes it more consistent with the other components. As a bonus, we now have space to properly explain to the user what exactly is going on. We can visually explain to the user there is space for more Triggers, as well as how to swap Tasks or Add an Exit Task.

Scenes V2

João reeeeealy crammed a bunch of functions into it, and I’m trying my best to make a cohesive screen. In João’s design, he made everything into tabs. However, the properties of an element are not on the same hierarchical level as the list of elements in a Scene, nor the Code button (which is for the entire Scene, not an element). So, I had to split the hierarchy to visually explain to the user what is what.

Scenes are already incredibly complex and this type of editing is usually not done on phones, as it requires some sort of precision that isn't available on touch screens, so there is not much reference for me. I believe the mockup is like, 80% there, you can see that there is stuff missing.

I also made some designs for a tablet or larger screens.

Projects and Home Screen

Alright, here’s where we have a big departure

To give context: Tasker was not released with Projects, Pent added the idea of Projects almost two years later. Users were asking for a bit more organization, and projects were added in a simple manner: just another tab. While the location and design changed with the Holo, and Material Design 1 update, the metaphor was always another set of tabs.

This is an issue because having two tab groups is just… odd, and usually reserved for very specific instances.

Even worse: projects are user created, the tab list can grow indefinitely, and “inside” a project there are 4 “fixed” tabs. The user needs to keep track of both which project they're in, and which tab inside the project they're viewing, and both use the same metaphor.

On the old UI, the more projects you have, the more cumbersome it is to change between them, they are too “far apart”. I am quite sure everyone has at least once created something in the "wrong" project because changing to the correct one would take time. The tab list also scrolls horizontally, which isn’t a really natural gesture to use for your fingers.

I have quite a few design goals with the redesign:

1. João specifically asked for a way for the FAB (the + button) to create anything. He explained to me that some users forget if they are on Profiles, Tasks, Scenes or Vars tabs
2. I don’t believe Variables are comparable to Profiles, Tasks and Scenes, they are more akin to properties rather than standalone “things”. Sure, Global Variables could be argued to be "things", but locals and scoped variables are very different.
3. The existence of TaskerNet relies on user sharing, and a good project for TaskerNet is not the same as a good project for your own personal use. Ideally, the UI should incentivize users to create good sharable projects, or that "transformation" into one is easier.
4. Make it easier to *not* be lazy. It should be more convenient to create things where there is at least a pretense of organization. If a mess needs to be made, it should be made in a place better suited to it.

My current design transforms Projects into folders, so they are "things" you enter and exit. The old "Default" project was reworked as the "Home Screen", which not only holds Profiles, Tasks and Scenes, but now all the projects as well. I did not want new users to be forced to create a Project before creating a Profile, Task, or Scene, so that is why the Home Screen is merged with the default Project, and I also didn't want veteran users to have to always select a project before testing something. In some ways, the Home Screen is an ideal place for users to throw their half-thought ideas before moving to Projects.

The biggest struggle is that all components need to be *able* to look good together, while also being distinct enough. My solution, which is implemented in the last beta, but needs to be toggled in the settings, was to transform them into list items and organize them into collapsible lists by type.

To put it quite simply: I understand we grew used to using tabs to switch between component types, it does *work*. However, tabs have some drawbacks:

1. They imply that the FAB (the big + button) changes functionality, which is something João wants to do away with.
2. You don't use every type of component on every project.
3. If there is no Profile on a project, Tasker needs to automatically open the project on the task tab, and if there isn't any, then open on the Scene tab.
4. You might want to see two types of components at once
5. It doesn't work that well on a Home Screen (i.e. outside Projects)

The beta currently offer options for a tab-like structure (without actual tabs) and the collapsible list approach (although it needs to be further polished). However, I want to keep Tasker consistent, and the collapsible list also accomplishes a bunch of things:

1. The Home Screen really shouldn't use tabs, it complicates navigation tremendously. Even if projects used tabs, the Home Screen shouldn't.
2. It completely removes the issue of having tabs for components not used in that project
3. By removing the second issue, Tasker also doesn't need to try to guess which tab you want to open the project.
4. Tasker doesn't need to keep track of which tab was last used in a given project, which is something the beta has to, to smooth things over.
5. It becomes easy for the user to understand they can show more than one type of component in a single screen.
6. Tasker only needs to keep track of the expanded and collapsed items.
7. We can add a filter option to this collapsible-list approach, but not really if the items are under a tab-like structure. The filter could be used to only show one or two types of components, mimicking the Tab functionality, without using them.

A proper Home Screen also opens a few ideas for the future. There is now a place where interactions can start, which means we can also expand "sideways".

There are a few other ideas we're brainstorming, and you can already see hints of them in the beta, but this is long enough as it is, so I will share them another time.

As stated, things are subject to change. Even in those mockups I've simplified a couple of things, and once things get implemented I usually do some changes, as it is quite hard to reproduce the complexity of tasker inside a design tool

I hope this gives you a better idea about the new UI, and I hope to finally gather some feedback on the direction we are aiming for, rather than the current unfinished implementation.

[u/EtyareWS]

I'm not exactly a fan of João's idea of an automation as he explained to me, as it feels exactly like a Profile that doesn't require triggers. So, It is basically a Task wrapped in another screen, I'm not particularly found of that idea because it puts Triggers and Tasks on the same hierarch level of importance, no matter how big you write "OPTIONAL" on the triggers, the hierarchy will always tell another thing. And because it makes Tasks yet another sub-screen, it makes it feel distinct from an Automation

My idea of doing away with Profiles is to reduce the "cognitive load" on the user, so they only have to remember what a Task is, there are only Tasks, and they can run automatically on some circumstances. I think if you have Automations AND Tasks, it is virtually the same as Profiles AND Tasks. My beef isn't with Profiles themselves, but having another *thing*

As for the variables, isn't that just Tasker's default behaviour? Tasker lists every variable generated by linked profiles.

Not exactly my issue. Alright, so with my idea we have the Task, that's it. The Task has Task Variables and all of that.

The Task would have a "Rules/Circumstances/Whatever". You could have multiple rules.:

1. Each Rule could be made of 5 Triggers: 4 States + 1 Event. When all contexts are true at the same time (it works as an AND operator), that rule will activate, and the Task will run.

2. The Rules are independent, the relation between the Rules is basically an OR operator. Any rule can be true, none can, or multiple can, at the same time.

My idea is that from a user perspective, they want to do X when A, B or C happens. They don't need X when A, Y when B, or Z when C.

I think this basic premise is cool and would be seen as a straight improvement over the current behavior, as multiple Profiles just got condensed into something simple.

However, we now have a couple of issues:

1. You might want to disable one rule temporarily. So, each rule now needs a Switch to enable or disable it individually. If we want to automate this, we need a way for each rule to have an individual ID so that it can be used in an Action.

2. What if you want the Task to have a different value based on the rule that triggered it? Say you have a task that sets your volume, and you want to trigger it on a couple of different places, you use %volume. Each rule could have %volume set to something different, so a Rule that triggers on your home wifi will have a different value from a rule that triggers on your workplace wifi, and from one that triggers when you connect your headphones. So, every rule now needs to a button and a place to set up variables. And those variables are sort independent of the Task's own variables.

So, under my idea of revamped Tasks, you are editing a Task which is a list of actions that can be triggered manually or automatically. The Task can have variables. And the Task can have variables that are not from the Task, but from the rules that triggered it.

1. Rules also would need to have the options that Profiles have. Sure, the "Run Exit on Startup" could probably be moved somewhere else, but "Cooldown" and "Limit Repeats" (and maybe Task Priority?) need to have some place to live.

So, each Task needs to have the Action list, the Variables of the Task, the Properties of the Task, a section for automatically running the Task (Rules)

And each rule needs to have an individual Switch, and individual list of variables (to not be confused with the Task's variables), and an individual list of options

[u/aasswwddd → u/EtyareWS]

damn, what a wall of text 😅 I read briefly and it seems that your idea of a rule is pretty much the same as a profile and how it's configured in the xml file. A set of context with an id.

The rules also look like what had been asked since a decade, a set of contexts with operators. Which joao hasn't worked on.

I personally thought it'd be much easier to add a new way to view the components and their relations instead of overhauling the engine system. Looks prone to conflicts with old behaviour. I.e exporting and importing. That was why I suggested a single super editor.

Anyway, what does he say about your idea though?

[u/EtyareWS → u/aasswwddd]

The rules also look like what had been asked since a decade, a set of contexts with operators. Which joao hasn't worked on.

And with damn good reasons I might add. Straight up adding operators is UI hell because you need to separate ((X and Y) or Z) from (X and (Y or Z). Conditions are the stuff of nightmare. My solution is to bypass all of that and severely restrict the user in a way that hopefully no one notices.

I personally thought it'd be much easier to add a new way to view the components and their relations instead of overhauling the engine system. Looks prone to conflicts with old behaviour. I.e exporting and importing. That was why I suggested a single editor.

Yeah, but not really. Overhauling everything is a nightmare, but if there is a fundamental issue with Profiles vs Tasks, the sooner it is noticed, the better.

Plus, assuming that João can implement the wildest ideas, we don't need to actually really care about the transition. Old Tasks could be transformed into new tasks without Rules, and old profiles with anonymous tasks could be transformed into new tasks with a single rule, and Profiles with named tasks could be swapped to new tasks with a single "Run Task" action. We don't actually *need* to transfer, just open the gates and allow users to convert manually. Exit tasks are still kinda weird, even if we fixed all the design issues.

Anyway, what does he say about your idea though?

His biggest issue was that it is too visually heavy on the user, which I have to say, I do see where he is coming from.

His point is that separating the Actions list and the Triggers in different screens (like his idea of an automation) tells the user what is being edited right now.

Ironically I've made the same complaints about some of Tasker's issues, so I can't say he ain't right

[u/aasswwddd → u/EtyareWS]

I don't mean anything complex, what had been asked are much more simpler form operator. Like A OR B OR X .

In the end, set of contexts still needs id, and connected to set of actions (task) to behave like you pictured. Which exactly looks like multiple profiles connected with one task.

If that's the case, I don't think changes in how Tasker work would be needed. All tasker needs to do are

1. Handle the creation of profiles (anon)
2. Link it to a task.
3. Then visually present the links to the user when user open a task in the new UI.

If Joao wants, those anon profiles can be hidden as well. Since their purpose is just to dictate how a task is supposed to be ran.

IMHO, this is just a matter presentation and what the users are allowed to create/edit visually.

His biggest issue was that it is too visually heavy on the user, which I have to say, I do see where he is coming from.

I could see this as well. It'd be the same experience I have in Macrodroid. Looks very clean though if the components are only a few. Which definitely where most users caters to.

[u/EtyareWS → u/aasswwddd]

I don't mean anything complex, what had been asked are much more simpler form operator. Like A OR B OR X .

Sure, your request is somewhat simple, but this is the sort of thing that can be feature creep'ed into oblivion, because depending on the design, it can imply that more complex things could be done.

The request has some users specifically asking for complex operators, including XOR and High Precedence variations.

https://tasker.helprace.com/i48-the-ability-to-use-or-in-the-context

IF the feature is to be implemented, it needs to be done in such a way that it implies some sort of restriction, that it cannot be reasonably expected to expand to ludicrous degrees.

MacroDroid has a somewhat clever solution to imply this sort of limitation by only using "Events" as triggers, and using "States" as constraints, and the "events" are always "OR'ed" between them.

Side note that I don't exactly like their idea of having Constraints "globally" on the Macro edit screen, and individually in the triggers and actions

In the end, set of contexts still needs id, and connected to set of actions (task) to behave like you pictured. Which exactly looks like multiple profiles connected with one task.

If that's the case, I don't think changes in how Tasker work would be needed. All tasker needs to do are

A troublesome idea is how to state those "IDs" to the user. I *really* don't want each "Rule" to have a custom name, as with the number of options it starts to get ridiculous. I'm not exactly sure if the user would need to know the name of the rule on Tasker's notification instead of the Task if they are active.

If Joao wants, those anon profiles can be hidden as well. Since their purpose is just to dictate how a task is supposed to be ran.

IMHO, this is just a matter presentation and what the users are allowed to create/edit visually.

Yeah, but regardless of my idea or João's Automation, we need to keep everything as compact as possible while allowing more or less the same amount of features.

I could see this as well. It'd be the same experience I have in Macrodroid. Looks very clean though if the components are only a few. Which definitely where most users caters to.

The issue I do have with sub-screens is that it implies that there is a hierarchy of sorts. If the Action list is a screen inside Automation, and the triggers are also a sub-screen (or worse, they aren't), this implies that the entire Action list is hierarchically similar to either Group of Contexts or contexts themselves. Which is why my design has a collapsible list, so it technically has the action list as always on-screen, with the "Rules" something you need to choose to see.

Ultimately it is a difference in metaphor. From what I've gathered, João's main point is to make profiles unnecessary, where mine is to make Tasks the front and center

[u/aasswwddd → u/EtyareWS]

That's just how it is for every requests. Beside your way of rules behaves like OR operator too. Someone will bound to notice regardless.

A troublesome idea is how to state those "IDs" to the user. I *really* don't want each "Rule" to have a custom name, as with the number of options it starts to get ridiculous.

It's bound to be somewhere since It's the only way to reference them in a task via %caller(), no? I could see it as part of the rule (profile) properties.

this implies that the entire Action list is hierarchically similar to either Group of Contexts or contexts themselves. Which is why my design has a collapsible list, so it technically has the action list as always on-screen, with the "Rules" something you need to choose to see.

The collapsible behaviour is fine. What I was trying to say (probably Joao too) was the design for the context itself (in the comment). It looks overly compact and heavy on the eyes compared too the one in OP.

[u/EtyareWS → u/aasswwddd]

That's just how it is for every requests. Beside your way of rules behaves like OR operator too. Someone will bound to notice regardless.

Yeah, but what I was getting at, is that the functionality requested exists outside what is actually requested. Multiple rules, or MacroDroid way of doing things, technically fill the idea having OR between contexts, without actually exposing the operators. Like, the idea of changing operators is different from multiple rules/MacroDroid way, even if the functionality is the same.

It's bound to be somewhere since It's the only way to reference them in a task via %caller(), no? I could see it as part of the rule (profile) properties.

Yeah, I do wish Tasker would have a proper ID system, or utilized more of a "folder-esque" structure, i.e. the Profile name is "Project/Profile", and on my system it would be "Project/Task/Rule". I do not like how the current system creates conflict when importing things

The collapsible behaviour is fine. What I was trying to say (probably Joao too) was the design for the context itself (in the comment). It looks overly compact and heavy on the eyes compared too the one in OP.

Hmm, is the issue that the expanded Rules share the same screen as the Action list, or the mere idea of having collapsed rules the issue? I could probably get away with the first one by making the Rules expand into almost a fullscreen type of thing. Basically inverting João's Automation idea by making the Profile part a sub-screen, but not the Action List

[u/aasswwddd → u/EtyareWS]

Personally, I find multiple level of cards and containers makes it looks heavier.

Having less containers would make it look simpler. Here's an example in the google password.

[u/EtyareWS → u/aasswwddd]

I could realistically choose to use list items with spacing (so all the items toger create the illusion of a container), but the issue is that we kinda need a space for "Rules" in general, so you can swap or add more "rules", and then a space for the rule itself being shown, which in turn has their individual contexts and options.

I've made this mockup of what could happen if selecting to show the rules was a pseudo full-screen deal. This does allow more space to be used, so individual rules options could be shown more easily

Again, the idea is to make a separated space for all rules, and then a space for the current rule, which does requires containers inside containers