@Laura Goto Settings > Folders. See checkboxes (switches) on the list? These are subscription change switches. Now imagine we add multi-selection capability to that list, which would add a normal checkbox on the left of each folder name. If we do not use the blue-switch-element we end up with two unlabelled checkboxes on each record. So, styling one of them differently would be less confusing. Though still not perfect, that's only one reason. And as I've said I don't have a strong opinion.

Okay now finally understand what "tasks" is and in this context I think the Font-Icon isn't totally clear especially when the button is placed in the folders menu. Since there seem to be a lot of problems with the folders menu anyway considering the option "removing Settings > Folders" and place the tasks icon somewhere else might be something to think about- if it's worth the work

I think the Font-Awesome icon is okay as well.
I am also not sure, if this would fix the issue, maybe @Testmiriam can say something to this (after all you created this ticket)...?!

We're limited by Font-Awesome iconset. And there the tasks icon is https://fontawesome.com/icons/tasks?style=solid. I also am not sure if only the icon change would fix the issue.

Ok, but when tasks are to-do items, then how about giving them a corresponding symbol? Like an (abstract) list with several items and a pen, for example (see screenshots). Because, after all, this was also about differentiating folders better from tasks...

You can see what tasks are when you login to https://kolabnow.com/apps. Tasks are similar to calendar events, but don't have to have a date specified. In other words tasks are "todo items".

@machniak
I still haven't really understood what a "task" it, but since a task might be not so relevant to a user in comparison to folders, it might indeed make sense to not give tasks an extra-icon at al...

When we implement the new skin for Tasks plugin, users will see a new entry on the left side menu (with the same icon). Then the entry on folders list hopefuly would be less confusing. But aside of that, I agree that together with the fact that it was the last folder on the list it could have been confusing. The use of special-type folders in Kolab is another story.

Drag-n-drop works in Settings > Folders, but not in Mail UI. I generally agree that it would be nice to have all functionality of the folder manager in Mail UI, but it's just quite a lot of work.

I created an upstream ticket for contextmenu plugin https://github.com/johndoh/roundcube-contextmenu/issues/104

This should be fixed by the rework of the color palette

Duplicate of T3463

The visual representation does not work well because it fails when it comes to the Gestalt quality of "closeness",
In less fancy words: There needs to either be less space between icon and associated arrow or more space between the arrow and the next icon.
another possibility could be the usage of frames or something else that suggests what belongs together.

In T3616#53827, @Nikolai wrote:

I think it is important that when you receive the recipient feedback, you can see who received the mail and who didn't – which should be the case with the current function, right? But maybe some people thought you couldn't see that or just were not sure. So if you once get the "real" recipient feedback, showing who really received the mail, the problem might be solved. So more a problem of the use test situation/simulation, than of the real use.

T2813 has already been accepted indeed. moving this to done.

We could add a "diskspace in use" to the tooltip.
@machniak ?

The issue here is that tasklists/calendars/addessbooks are also folders from a programmers perspective that you can subscribe to/create/delete/...
I understand this is confusing for users because it does not match with their mental model.
Giving that folder management was one of the biggest issues for users, a redesign of the folder management might be the way to go.
@machniak ?

A rework of the color palette is planed.

@machniak What do you think?

Moving this to done.

bad idea

There's more than that. If we move the Options and Attachments to the right we have a (technical) problem in tablet mode. Because when switching from Options to Contacts will make them appear one on right the other on left. Which might be annoing and I can't fix that easily. You should try the tablet mode (smaller screen where only two columns are visible).

Ah, ok, now I understand! I think this is is a very good idea!

Your proposition does not make much sense to me because to add a contact you first need to select it on the list. So, while you're on the list it's better to use button in list footer than in the input, imho.

I think, having a "thin"/small sorting bar might be better than having nothing... For the desktop version I definitely think you could implement this (see T3556)!

@machniak
What exactly do you mean by "using a dialogue" for adding further contacts?

I think for the user it is less confusing when all drop-down menus look the same - and since he is currently in this program, he expects everything in the program to "look like the program".

I also think that for the mobile version a search button might not be necessary. But for the desktop version it might be good to have one for "less trained" users. (I myself can think of several people who might be a bit "helpless" if they were to start a search and didn't have any extra button for it. Hitting Enter ist not yet as intuitive for everyone as it might be for us.)

In T3478#54340, @machniak wrote:

We're here limited by the TinyMCE editor functionality. We control the Select Image dialog, so I guess we could improve it a little bit. E.g. by automatically pre-selecting newly added image and adding "Continue" or "Insert" button. We could also see if TinyMCE provides an API to replace completely its Insert/Edit image dialog.

Actually, these "issues" weren't originally from me but I think moving the whole Options box/column to the right side of where you compose the email would do...

@machniak
I find it indeed very good that the user can read which contacts he has just imported! It was just that the window stayed there and this seemed confusing for the users because they thought "maybe something is still going on in the background", or, "what do I have to do now, is it finished now?".

@machniak
I am not quite sure what you mean with "using switches for subscription changes" - wouldn't that work with checkboxes as well?
If not, I think the suggestion made in the ticket description - namely, simply to enable pushing (clicking on) and switching the switches - would be enough to improve them.

I might have a solution:

You mean the one in right-bottom corner? It's not well suited for long text. Of course, we could think if list of imported contacts is really important for the user. Maybe a number would be enough. Then it could be a popup.

https://uxplanet.org/design-a-perfect-search-box-b6baaf9599c

In T3649#54331, @machniak wrote:

We should not close automatically, because user should be able to read which contacts have been imported. We could however, replace the dialog buttons with one "Close" button, I guess.

The additional bar makes it too clattered. I also think that sorting order change is not something you do often.

That would make sense if the Contacts list was displayed in a popup dialog, but it's all the time on left. So, maybe we should consider removing the Contacts list box and use a dialog. However, there's a plugin that adds a button in contacts list footer which is used to attach selected contact vCard to the message. It would need to be implamented in some different way.

This is not the same and I don't think they need to look the same. On the first screenshot you have the standard <select> element. How it looks depends on the web browser used. The other screenshot contains a custom dialog which is not a <select> and is not a single-selection list. Of course we could replace <select> lists with something custom, but I'm just not sure this is a good practice. BTW, there's another ticket about iOS Safari select lists looking completely different, but I guess browser/device developers do this for a reason.

An icon is one thing we have a ticket about. The other thing is button position. It is placed in the toolbar for consistency. When you don't use HTML editor, you don't have the text editor toolbar above the textarea.

I agree that folder management actions should be available here. It's just a lot of work. When we'll have them in the menu, they will appear also in the right-click menu.

In current version I slightly modified the look of the icon so it does not look like a button, making it less confusing. We could consider removing it at all.

We're here limited by the TinyMCE editor functionality. We control the Select Image dialog, so I guess we could improve it a little bit. E.g. by automatically pre-selecting newly added image and adding "Continue" or "Insert" button. We could also see if TinyMCE provides an API to replace completely its Insert/Edit image dialog.

So, would you propose to:

• move the Options box to the right of the main box
• move the Contacts box to the right of the main box
• move both Options and Contacts to the right side?

We should not close automatically, because user should be able to read which contacts have been imported. We could however, replace the dialog buttons with one "Close" button, I guess.

We still might need to use the "switch" instead of a standard checkbox on desktop. It's e.g. when you have a selectable list like the folders list, where you would use checkboxes for multi-selection and switches for subscription change. Also, I think these days users are used to know switches as everybody saw them on their mobile. Though, I don't have a strong opinion about that. Maybe we should indeed not use them on desktop.

I agree. Right-click functionality is provided by an external plugin. I created a ticket there https://github.com/johndoh/roundcube-contextmenu/issues/103. We'd need also such functionality for Kolab plugins that add Settings sections i.e. kolab_activesync and kolab_delegation.

Yes they tried. But there are also other examples. Drag&drop in general is very popular to try in several situations. Like a right klick.
No in this case is it wasn't an OS X user and the test also runs on windows. But I think the problem is the same.

So they actually tried to drag&drop the folder to the trash folder?
OS X users i assume?

In T3475#53146, @Laura wrote:

I think @bohlender said once that they wanted to replace the current sliders with simple checkboxes anyway, so then this whole ticket would be irrelevant anyway... (respectively it would be solved to our satisfaction ;) )

about the feedback if the attachement is succesfully loaded/ already attached to the e-mail when shown in the middle column:

@Laura ich meinte zweiteres, weil ich mir nicht sicher bin ob man diese Bearbeitungsspalte einfach komplett nach rechts verschieben kann
Da sind ja auch noch andere Sachen wie z.B. Empfangsbestätigung etc. drin