<br>Wow. Thanks for the quick feedback!<div><br></div><div>Looks like I did a bad job at communicating what I am working at. It is the MailView page as in the page that displays a received mail (maybe several mails of a discussion in the future). It is the Page between the MailList and the MailCompositor Page. The Compositor will be looked at at another time.</div>
<div><br></div><div>Now to your feedback:</div><div><br></div><div>Almost empty toolbar on composer page:</div><div>There will be at least a "save as draft/template" tool button and maybe something that indicates which mail account is selected.   </div>
<div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some feedback:<br>
- One doesn't really need to see the original mail when replying or<br>
forwarding, because its content will usually be in the composing area anyway<br>
(quoting), unless you forward as attachment, but even then you probably don't<br>
need to see it. Not showing the original mail would give us more space for the<br>
composing area, especially because currently<br></blockquote><div><br></div><div>It was actually a conscious decision. This is really useful if you reply to a thread/discussion where you want more than just the latest mail as a reference. Yes you could swipe to scroll to see the mail but that might break your "mental" focus on the text creation because it requires a "physical" interaction and not just moving your eye. (that is what I imagine judging from my </div>
<div>personal experience but you are the UX expert )</div><div> I know that "giving detailed answers to long discussions" is not part of our main usecases for the tablet version but I'd like to support it as good as I can. I agree that we might have a problem with space for the compositor so we might need to make a trade off in favor of the compositor if we can't make it work otherwise.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The address fields are too narrow. Entering something via touch keyboard is<br>
not fun anyway, and it gets even more difficult if you can't see all of what you<br>
typed. For checking if you typed the address correctly, you'd have to navigate<br>
back and forth in the edit field, which isn't a good idea. Therefore, the fields<br>
should be wide enough for common email addresses to fit in completely</blockquote><div><br></div><div>Yes this obviously need work. You will have the whole page if you write an email from scratch.  Remember that you will rarely need to add new email addresses when you reply and even if you forward an email then it is likely that you already had contact with this person before and thus have the address in your address book. I plan to have I nice "add recipients " dialog with pictures for that but as I said I am currently working on the MailView, not the Composer page.  </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- What happens if I tap "Add recipient"? Will it add a To or CC or BCC? Can I<br>
change the type of recipient afterwards?<br>
I think KMail does a pretty good job with adding recipients: You can change<br>
between To/CC/BCC at any point and you can easily add another recipient by<br>
just typing into the empty field. This seems more convenient to me than pushing<br>
a button.<br></blockquote><div><br></div><div>The whole add recipients thing obviously needs work. Probably not possible during GSoC. </div><div>(Week 7-9 MailViewPage, Week 10-12 FavFolder Page + Drag&Drop according to my current schedule)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The encrypt/sign buttons should only appear if encryption is configured. If<br>
we want to actively advertise encryption to people not using it yet, they<br>
might be replaced by a button which starts an encryption setup wizard that<br>
even allows you to create a new pair of GPG keys. That would be awesome, but<br>
not in the scope of the GSoC, of course.</blockquote><div><br></div><div>+1, great idea.</div><div><br></div><div>Like Martin said, privacy protection is one of the key features where we can differentiate, I really want to make that happen with Active Mail. </div>
<div><br></div><div>Email encryption is a hard problem from a UX point of view.</div><div><br></div><div># it breaks webmail.  nothing we can do about that. </div><div># it breaks other clients unless they support encryption and have the same key.</div>
<div><br></div><div><br></div><div><br></div><div>It requires  both parties and we can't do much</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Next thing I am going to look at is attachments.<br>
<br>
</div>That brings us back to the fact that we don't have a file picker in PA yet. You<br>
should not need to do that, so we might postpone that until a file picker is<br>
there.</blockquote><div><br></div><div>I meant to say " I am going to look at displaying/handling attachments for incoming mail in the MailViewPage"</div><div><br></div><div> </div></div>