Kontact Touch MailView Mockups

[Michael Bohlender]

Wow. Thanks for the quick feedback!

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.

Now to your feedback:

Almost empty toolbar on composer page:
There will be at least a "save as draft/template" tool button and maybe
something that indicates which mail account is selected.


> Some feedback:
> - One doesn't really need to see the original mail when replying or
> forwarding, because its content will usually be in the composing area
> anyway
> (quoting), unless you forward as attachment, but even then you probably
> don't
> need to see it. Not showing the original mail would give us more space for
> the
> composing area, especially because currently
>

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
personal experience but you are the UX expert )
 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.


> - The address fields are too narrow. Entering something via touch keyboard
> is
> not fun anyway, and it gets even more difficult if you can't see all of
> what you
> typed. For checking if you typed the address correctly, you'd have to
> navigate
> back and forth in the edit field, which isn't a good idea. Therefore, the
> fields
> should be wide enough for common email addresses to fit in completely


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.



> - What happens if I tap "Add recipient"? Will it add a To or CC or BCC?
> Can I
> change the type of recipient afterwards?
> I think KMail does a pretty good job with adding recipients: You can change
> between To/CC/BCC at any point and you can easily add another recipient by
> just typing into the empty field. This seems more convenient to me than
> pushing
> a button.
>

The whole add recipients thing obviously needs work. Probably not possible
during GSoC.
(Week 7-9 MailViewPage, Week 10-12 FavFolder Page + Drag&Drop according to
my current schedule)


> - The encrypt/sign buttons should only appear if encryption is configured.
> If
> we want to actively advertise encryption to people not using it yet, they
> might be replaced by a button which starts an encryption setup wizard that
> even allows you to create a new pair of GPG keys. That would be awesome,
> but
> not in the scope of the GSoC, of course.


+1, great idea.

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.

Email encryption is a hard problem from a UX point of view.

# it breaks webmail.  nothing we can do about that.
# it breaks other clients unless they support encryption and have the same
key.



It requires  both parties and we can't do much

> Next thing I am going to look at is attachments.
>
> That brings us back to the fact that we don't have a file picker in PA
> yet. You
> should not need to do that, so we might postpone that until a file picker
> is
> there.


I meant to say " I am going to look at displaying/handling attachments for
incoming mail in the MailViewPage"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20130801/47624e7f/attachment.html>