#2124 ✓bluesky
John Smith90210

Email layout

Reported by John Smith90210 | September 29th, 2018 @ 11:25 PM

Hi,

I have been trying Mailmate for a week or so and am very impressed so far. Markdown is great and emails look fantastic. I don't understand why this is the only client with this great Markdown implementation. Job well done.

There is one feature which I believe is lacking. Gmail has a great way to display and go through emails.

Namely, I have found the following very convenient and efficient to go through emails. The other layouts are great too but play a different role. I am looking for command-7!

Description of layout and workflow

  • Very similar to some of the current layouts but without the preview window.
  • Double-click an email: it appears in the panel with the inbox (i.e., it replaces the inbox list of emails). Like Gmail.

Here you can branch out to different workflows:

Read and archive

Option 1: you are done reading and want to archive the email.

3 options:

  1. Press e to archive and return to Inbox
  2. Press ] to archive and view next message
  3. Press [ to archive and view the previous message

Reply and archive

Option 2: you want to reply. Press r for reply.

The reply email appears in the same panel. Type in your reply. [shift-r could pop up a new window to type in your message.]

Here things differ from gmail.

  1. command-enter: send email and go back to inbox
  2. command-"]": send email and view next message
  3. command-"[": send email and view previous message

You could do something similar with a preview panel that opens and closes as you go through this workflow (command-8?) but I feel the gmail approach works well too.

Goals of workflow:

  1. It avoids opening a new window which is a distraction and slows down the workflow
  2. It uses a minimum number of keyboard strokes to go through the emails quickly and painlessly.
  3. It offers the options to not open the next email (the current Mailmate set-up). This is useful if you do not want to go through your entire Inbox at this time.

Comments and changes to this ticket

  • John Smith90210

    John Smith90210 October 5th, 2018 @ 03:04 PM

    Comments or thoughts? Can this be done with the current keybinding configuration files (.plist)?

  • John Smith90210

    John Smith90210 October 6th, 2018 @ 04:08 PM

    I think it might be possible to do most of what I am describing above if we add a keybinding selector that simply makes the preview empty, that is the equivalent of clicking in a blank spot in the inbox panel so that the preview window no longer shows any email. Combining with some of the existing keybinding selectors, it should be possible to implement something similar to what I am describing. For example, "e" would archive and blank out the preview window. Same for command-enter: send and blank out the preview window. Then you can add nextMessage: and openMessages: to other keybindings to make it work.

  • benny

    benny November 21st, 2018 @ 08:44 AM

    • State changed from “new” to “bluesky”

    Sorry about the late reply. There actually is a deselection key binding selector available:

    "e" = ( "archive:", "deselectAll:" );
    

    But you could perhaps also change the navigation behavior as described here.

    With respect to supporting layout-view-replacements I'm afraid it's not a straightforward change. You might get something closer to what you want if you enable using tabs in the Dock System Preferences pane.

  • John Smith90210

    John Smith90210 November 28th, 2018 @ 12:14 AM

    Hi,

    Thanks for the update. I tried a couple of things. It's mostly working with a few bugs. But I am not sure this can be fixed though.

    There is an issue around MmMessagesOutlineMoveStrategy.

    Option 1: MmMessagesOutlineMoveStrategy = next

    That's the default.

    Let's say [ is mapped to "archive:". Because of MmMessagesOutlineMoveStrategy, you get archive + next (which means go up in the inbox if it is sorted from new to old).

    For ] we need to map it to "archive:", "nextMessage:". The result is something like this. Assume we have these messages in the inbox:

    A
    B
    C
    

    The selected message is B. Press ], you get

    A
    C
    

    Then next: selects A, then "nextMessage:" selects C (going down in the Inbox). This is the desired outcome.

    Go back to

    A
    B
    C
    

    Select A. Then press ]. You get

    B
    C
    

    B is the current "selected message" at that point. next: does nothing (already at top). "nextMessage:" selects C. But this is wrong because the user intended to select B, that is the message below A. Instead C is selected.

    [ will select B. This is OK although we would be hard pressed to explain how B is the message before A (above A in the Inbox).

    Option 2: MmMessagesOutlineMoveStrategy = none

    [ no longer works. If you map [ to archive: no message is selected (which is correct). If you map it to ("archive:", "previousMessage:"), then the message at the bottom of the inbox is selected. Presumably, this is because no message being currently selected previousMessage: does not know where to go. This is similar to pressing p after *n (deselect all).

    So none of these options can work in all cases. The correct behavior is that after moving to archive, the "cursor" should point between 2 messages.

    A
    B
    C
    

    Archive B. The cursor is between A and C. Then you choose next or previous to select either A or C. This will work regardless of whether B is at the top, middle, or bottom of the inbox.

  • benny

    benny December 11th, 2018 @ 01:54 PM

    It took some time, but I've finally read your comments. I understand the issue and your “solution” is probably the most flexible. In a sense it's an alternative movement strategy similar to “none”, e.g., named “virtual” (it's possible that no-one would want “none”). I'm not sure it's easily implemented though...

    I guess MailMate would do the right thing most of the time if it just remembered the most recently selected row and used that when next/PreviousMessage is used when nothing is selected... If it's important to you then I can look into that.

  • John Smith90210

    John Smith90210 December 11th, 2018 @ 07:13 PM

    I think that's OK. Thanks for offering but this seems like a non-trivial amount of work and the current setup works really well already. I think we can close this ticket really.

    Here is my current set up for those who are interested. See the files attached.

    I selected 2 seconds for "Mark messages read after."

    I changed the default for the action after moving a message. It's now "previous".

    In a terminal window:
    $ defaults write com.freron.MailMate MmMessagesOutlineMoveStrategy -string "previous"

    New key bindings:

    • "Escape" to deselect all messages
    • "e" for archive and deselect all messages
    • Page up (fn + up arrow): archive + show message above
    • Page down (fn + down arrow): archive + show message below
    • command + return: send
    • shift + command + return: send + archive

    The rest of the key bindings are the default bindings for Gmail.

    To select the new key bindings, copy the file "BindingsPlus.plist" to the directory

    ~/Library/Application Support/MailMate/Resources/KeyBindings/

    In Preferences (command + ","), select "Custom Key Bindings Enable" and enter BindingsPlus.

    When the top message is selected in the Inbox, Page up will archive and show the next message. When the bottom message is selected, Page down will archive and show the next message.

  • benny

    benny December 14th, 2018 @ 08:30 AM

    Thanks for sharing! I'll keep the ticket in the “bluesky” state for now.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket

Pages