Review: The new Outlook for Windows

Outlook is asking for my feedback. I went to the bother to type it up, so I'm posting it here as well to get as much mileage out of my effort as possible. I don't trust Microsoft in general to read feedback, but I think that the Outlook team does.

Likelihood to recommend: 1/5

Why?

The feedback

I am a programmer, not a suit. Outlook's strength is in coordinating meetings. My job doesn't require many meetings.

I have to use Outlook because my company does. The features I would look for in an email client:

• Plain-text email
• Markdown support
• HTML editing
• Keyboard-based navigation
• Scripting capabilities

I do appreciate that Outlook now allows me to check email headers.

I find Microsoft 365's Ctrl+Backspace behavior idiosyncratic and unhelpful--except that it works properly in this feedback box, which is nice.

I actively disable any sort of smart tooling, even spelling autocorrection, and definitely including Copilot. I don't use Copilot to draft emails because it would be simpler just to send the prompt. I don't use Copilot to summarize emails because I don't read emails that need summarized.

Outlook and Teams have all these buttons I will never use and care about, but I still get a reminder for a recurring meeting every day at the default time even though I changed the reminder time. The notification comes up fifteen minutes before the meeting. The little drop-down box says "10 minutes before", which is what I selected. It is most amusing.

The "Upload to OneDrive" button

1. I go to attach a file to an email.
2. The file is too big, so I drop it onto the button for "Upload to OneDrive and send link".
3. I send the email.
4. The recipient emails me back to tell me that he can't access the file at the link I sent.

What good is a link that the recipient can't access? If I am attempting to email a file, can we not assume that I wish the recipient to be able to read it? Why can't the "Upload to OneDrive" button make the file accessible by the recipient of the email? Or at least provide a quick way to do that?

I feel as though the assumption is that I will mostly send files to others within the company. But I do nearly all my internal communication through Teams. So if I send a file by email, then I am almost certainly sending it outside the organization.

(Unless I am sending a script that isn't in the Git repo. If I send new versions by Teams, then Teams will increment the file name of each version. This increment will include a space character, forcing the recipient either to rename the file after downloading it or to quote the file name when he types it into the terminal. So I might send the script by email to avoid having the file automatically renamed. But I digress.)

Generate more, parse less

Be liberal in what you accept, and conservative in what you send.

--Postel's Prescription. (I think that this popular quote is relevant to this post, but I can't decide how.)

I wrote a code generator to take a C enum type and make a string parsing function for it. While writing this parser, I ran into parsing difficulties.

Code has to be generated from some other information. To get that information, I had to read it from another file. So I had to parse it myself before I could write my parser.

On my first try, I started by reading the header file containing the enum type. I immediately ran into apparently necessary feature creep. What if the user put other code before the enum in the file? What if the user defined values for the cases? These cases would require me to expend a lot more work to implement, but a user would be shocked to find that his code suddenly didn't work because he did these perfectly normal things. I implemented more features than I needed for my use case, but still felt that my approach was far too naive and constrained. Eventually I gave up.

The next time, I made a text file listing the cases I wanted. Then I iterated over that and generated both the enum and the parser function. Easy as pi.

For the understanding of non-programmers, which looks easier to deal with?

gardening-tools.h:

  #ifndef GARDENINGTOOLS_H
  #define GARDENINGTOOLS_H
  
  typedef enum GardeningTools {
    Trowel,
    Hose,
    Dynamite
  }
  
  #endif // GARDENINGTOOLS_H

Or gardening-tools.enum:

  Trowel
  Hose
  Dynamite

But they contain the same information! I can generate the second from the first!

If I have to read data, why would I encode it in a format that has more features than I need to use right now?

Hooray for flat, simple data layouts! My three lines of data doesn't need the power of C. Here is the entire spec for my layout: Put a line break after each case name. I get the enum type name from the input file name.

I can add more features if I wish. Since my format is simple, modifying it is easy. Values for the enum cases? Put a space between the case name and value. File name different from the enum name? One extra parameter. Documentation comments? Now lines starting with "//" pass through to the output unmodified. But I probably won't need any of that, so why bother now?

Code generation: Accomplished

Number of library references added: 0