Email details page

[kulmann]

Initial Checklist

• I understand this is a user story and questions should be posted in the Community Discussions
• I searched issues and couldn’t find anything (or linked relevant results below)

User Story

• As a mail app user I want to navigate into an email so that I can read its content.

User Value

Read emails

Acceptance Criteria

• technical: email details page should have the mailbox list invisible on mobile, visible (side by side) on tablet or desktop viewports.

• clicking on an email in any email list shows the details view of the selected email with route /groupware/accounts/<accountId>/emails/<emailId>

• email list stays visible on devices larger than mobile, is hidden on mobile viewports

• email list must not re-render on desktop screens when clicking on an email

• page reload must show the same selected mailbox and selected email as before

• email details page renders the following data according to the attached mockup:

  • sender
  • subject
  • relative time
  • recipients (truncated, not expandable, yet)
  • email body

• the email title area has a link for navigating back into the email list I came from (only on mobile viewports)

• additional details are not available in this iteration (labels, flagged, attachments, appointments)

• additional actions are not available in this iteration (reply, reply-all, forward, delete, move to other mailbox, etc)

Mockups

[db-ot]

@kulmann is query parameter also acceptable instead of route ? ( in navigation AC ) > can email and list also be one route?

[JammingBen]

@kulmann is query parameter also acceptable instead of route ? ( in navigation AC ) > can email and list also be one route?

To elaborate a bit more: When looking at other mail UI's, most of them have the same spit view as described in our story (list of mails on the left, email content on the right). Why make this 2 dedicated pages? Seems like unnecessary overhead to me because we would need to create 2 independent pages that both need to load and display all emails. But maybe I'm missing something...? 🤔

[kulmann]

On mobile devices it will appear to the user as being 2 separate pages. One for the email list and one for the details view of an email. A mobile device user (at least with reasonably small display size) will never see list and details side by side. Just because of that I thought it would make sense to have two separate routes for that. Of course I'm open to different solutions. 😇

[kulmann]

As discussed in chat: we'll use one page and route on any viewport size. On mobile/small viewports the list will be hidden. The opened email is identified with a query parameter.