@Viktoria
Yes, my point was, as I wrote, that anyway the user first has to realize that he has to click on "reply" (1.) and then on "templates" (2.).
But maybe this is really not such a big problem, then we can also close this ticket...

I referred to the discussion we had on the function "responses" after the heuristic evaluation. Like @bohlender noted, we agreed on renaming the function "responses" into "templates" because this name describes the function better (-->the function can also be used when the user writes a "normal" e-mail, i.e. no reply). And when the function is called "templates", I think the user will recognize that when he wants to reply to an e-mail with a template he has to click on "reply" first and then insert the template there.

Yes, that was my initial idea when I wrote the ticket. Maybe I didn't make that clear enough.

I had a similar ticket (see below).
My suggestion for step nr. e would be the following:

@Viktoria
Oh, thanks, I will try to add it there, yes!

@bohlender
I actually think yes because the problem here was not that the participants didn't understand that "Responses" ("Schnellantwort") is the button they need to click on, but rather that this button wasn't visible in the first place! So they had to realize themselves that they first needed to click on "Reply" so that this function would appear (instead of the program simply "offering" them this option)! Yet of course one can argue if "Responses" (or however it might be called then) is important enough a function that it need be shown on one "level" with the most "general" functions such as Reply, Forward etc. ... (@Viktoria what do you mean here, for example?)

@Testmiriam
Ok, so your suggestion would be to move the column to the right and additionally display the information about attachments above the email field?
Or do you mean leaving the "attachment box" where it is but additionally displaying the information about attachments above the email field?

@Viktoria
I think you got me wrong here: I didn't mean to add some "extra feedback" after the email has been sent, but actually to display feedback (in a "feedback box"/"feedback window") right after the user selected the option! Because as far as you describe it, this would be what your subjects would have needed?!
So, say: I click on "return receipt" and then directly afterwards a feedback appears saying "Return receipt has been requested successfully" Do you think that would be sufficient?

Ich schließ das hier mal, ok?

See T3478

Can this problem be united with T3478?

I also think the main problem here is that participants did not know the function "responses" and couldn't imagine what this function does and how it works. Renaming the function should solve this problem in my opinion

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.
...do you understand what I mean?

Would this still be valid if "quick response" gets renamed to "template" as we discussed?

the search can also be started by clicking on the "down" arrow and then on "search". Not optimal

Let's see if others had this issue as well.

@bohlender
We had a very similar ticket already for the search function for emails (e.g. for searching for an email in the inbox).
In case this has already been dealt with and the search function has been (or is about to be) improved altogether, this ticket referring specifically to the search function for contacts may be irrelevant and can be closed then.

Yes Davids ticket describes "both" problems now so we wouldnt Need this one anymore
I just think the solution to show it twice (like the suggestion you can see in the picture in the taskdescription; it might also make sense to show it on the right side next to the writing field like in davids ticket) might make more sense then showing the whole column on the right (what David suggested) since I don't think the programmer want to change the whole layout: the editing field / emailfield is always right and the field where you can select different options in the middle
so changing could become inconsistent and cofusing

Maybe the problem is rather that you would want to know if everybody gets the e-mail but there is no clear feedback if choosing "delivery status" means you will get the delivery information for everybody or just for the "main"recipient

Problem is valid.
We need to refine the solution.
How would

@machniak What do you think?

What is the use case here? In what situation do I want to be sure that some recipients received my mail, but I don't care that much that others did?

We decided to use monochrome Icons for a reason.
If we add colors to every button that users have trouble finding, we would end up with rainbow.
Why should we color THIS button ?

I think my participants would have needed some kind of confirmation that they have a) selected the function they wanted to select and b) that the function is active and (normally) works correctly (right after selecting the function). Simply presenting a feedback after sending the e-mail doesn't make sense in my opinion because when the e-mail has already been sent the sender has no possibility to change the settings he made regarding the return receipt.

I agree, I think the logout button is much more salient in the current beta version.

@bohlender
Yes, I guess so... (see screenshot)

Then for me actually this ticket would be finished, what about the rest...?

Would this still work on a tiny phone screen?

In T2762#53128, @Laura wrote:

So my suggestion would be - if the majority of subjects had no problem to find the logout button (which is not yet totally clear...), then nevertheless the logout button should always be red, not only when you click on it!

@Testmiriam
Ok, I have edited David's ticket description and added the problem that you have described here (namely, that users didn't realize that files were already attached), so maybe we can close this ticket then...?

@NG
I am not sure whether drag&drop does actually not work for other parts of the program, so if you have more information about this, maybe you could make a corresponding ticket so that we can close this one?

ja klingt gut

feel free to close this , once the other thing is in a new ticket

Exactly!

they are different kinds of menus, but they could be designed in the same way, meaning same font, same background color.

I think this is covered sufficiently in T3502 and T3472.

@Testmiriam
Maybe the idea that David suggested here (T2723) would also solve the problem?

Good suggestion!

Not sure what you mean, maybe similar to T3529?

Could you make this a bit clearer maybe, also with a screenshot maybe?

Yes, it's "only two different designs" but the point is that actually in email program all (drop down) menus should look the same (concerning color, font etc.) - and this is not the case here.

Originally there was a checkbox to select the e-mails but I think we agreed on reducing the options to just marking the e-mail (with a slide colour). Maybe if the colour was more obvious, the problem would be solved.

No, I just wasn't sure whether you meant moving the complete box, which is currently on the left side, to the top (above the email field) or whether you are fine with my suggestion of showing attachments always in two places (on the left and above the email field).

I think we already had this discussion that "flagged" - which is the English equivalent to what would be "als wichtig markieren" in German - must be translated appropriately; only calling such an email "markiert" ist not good since you can also "markieren"/"mark" an email as read/unread! So maybe calling this "gekennzeichnet/nicht gekennzeichnet", as in your screenshot, is already the outcome of what we have been pointing out before, and I have to say I find it not so bad a solution...

naja es sind doch nur 2 verschiedene designs oder?
bei einem kann man EINE option auswählen (z.b. aufsteigend, ungelesen...)
bei dem anderen kann man MEHRERE Optionen auswählen indem man Schalter umlegt

naja es sind doch nur 2 verschiedene designs oder?
bei einem kann man EINE option auswählen (z.b. aufsteigend, ungelesen...)
bei dem anderen kann man MEHRERE Optionen auswählen indem man Schalter "umlegt"

I think an extra box is a good idea
thats also what I suggested as a pissible solution in the ticket
or do you mean something else?

Yes, ok, the question would be now (can you maybe explain this, @bohlender?)

1. What exactly is a "task"?

and 2. would in then be possible or make sense to make an extra menu only for "tasks"?

@Testmiriam
How do you mean that?

Ok, but then the question is how we could implement this... What do you think about my idea? Or do you have any other suggestions?

Many of the test subjects were not sure if the attachment file was effectively attached because they did not look at the middle column (they attached the file via the 'functions row' at the top).
After they'd found it, they confirmed that the location of the column (especially with those functions) was not where they'd expected it (which is on the right of the comopsing column).

Same for me.
One even got to the e) interface several times but did not realize what to do next.
I think the interfaces should be reduced to only b,d,f.

In T3487#53227, @Laura wrote:

@Moritz
I would say displaying a warning message is easier to implement and does what we want...

In my opinion, though, this should then be applied to all parts of the program where one creates or changes something which must first be “saved” by explicitly clicking in that button (e.g. after creating a folder), so I think we should change the ticket accordingly

Do you mean this?

Ich gluabe es sind einfach zwei unterschiedliche Designs, je nachdem ob es Auswahl von Optionen ist, die in dem Feld erscheinen können oder "eigene" Optionen die man an und ausstellen kann?

Ich denke es wäre notwendig, dass man nicht innerhalb von Tasks über die selbe Funktion/das selbe Symbol über das man auch E-Mail Ordner erstellen kann, einen neuen Task erstellt ausversehen wenn man links "Tasks" ausgewählt hat

@Laura the Problem was not that they didn't see that they created a new "task". They deliberately selected "Tasks"

Isn't this just depending on wether you use the right click dropdown, or just the "normal" dropdown. I could imagine that with the normal one the developers just implemented the operating software specific design? Therefore it would be interesting how it looks on a non Mac computer.

Yes Laura thats what I ment