Kontact Touch MailView Mockups

[Thomas Pfeiffer]

On 01.08.2013 21:01, Michael Bohlender wrote:
>
> 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.

Aaah, okay. Well, if you put up two screenshots, you get feedback on two 
screenshots ;)

> 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.

Okay, now I'm starting to get why you did that. This is something that 
should be decided based on an empirical basis: Since this probably won't 
be too hard to do, you should make one prototype for each variant, test 
them with a few users and see which one works better. Deciding this on 
an abstract level based solely on "expertise" isn't a good idea.

>     - 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.

The thing is: If there are edit boxes, they should be usable, regardless 
of whether there are alternative ways available to select recipients. 
But yes, we can figure this out when you're working on the Composer.

>     - 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)

So there won't be a functioning Composer at the end of the project? Is 
it possible to open the KMail Touch Composer from KMail Active, then? 
There has to be some way to compose and send an email from even the most 
basic email application...

>     - 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.

Since Kolab is positioning itself as a defender of privacy right now as 
well, maybe they can find a solution to make at least their own 
webclient work with GPG...

> # it breaks other clients unless they support encryption and have the
> same key.

Ex- and importing a private key isn't rocket science. It's a little work 
but it's definitely doable.

> It requires  both parties and we can't do much

Of course. But someone has to start, right?

>      > 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"

Had I known that you were currently only working on the viewing part, 
I'd probably have guessed that ;)