slack-issue.md

Given a block with a static_select as declared below:

{
  "type": "section",
  "text": { ... },
  "accessory": {
    "type": "static_select",
    "placeholder": { "type": "plain_text", "text": "Group1 - Foo" },
    "option_groups": [
      {
        "label": {
          "type": "plain_text",
          "text": "Group1"
        },
        "options": [
          {
            "value": "foo"
            "text": { "type": "plain_text", "text": "Foo" },
          },
          {
            "value": "bar"
            "text": { "type": "plain_text", "text": "Bar" },
          }
        ]
      }
    ],

Issue #1 - Impossible to deselect a static_select option in a msg update Setting the placeholder is ignored in any future updates. In other words it's impossible to "Unset" the selected option by editing the message. I've tried setting the initial option to nil as well. Steps to reproduce once the message JSON above is sent:

1 Observe newly created message

2 Open the menu

3 Select "Baz" option

4 Server Side Respond to the click action, sending the same message as an update

5 Observe the updated message keeps Baz selected

6 This cycle continues on for other selections for the lifespan of the message, for example try selecting Foo and respond from the server the same way

Expected

There should be some way to deselect a static_select option. I understand it seems like a bit of a nitpick and I mostly agree. I wouldn't mind losing the ability to deselect, since im trying to use the "place holder" to improve the poor (in my opinion) aestethics / usability of the display of static_select in the "selected" state. For example the Ellipsis kicks in far earlier the limitation of the boxes initial length. Consider the large unselected length of a static_select:

Notice the text Reasonable Length is well within the limits of the selection box? Well lets select it:

I strongly disagree with the UX of shrinking the width of the menu on the selected state, since it causes objects in a actions block to shift around. I also don't see the point in losing information about the users selected item just to display extra empthy whitespace to the right of Reasonable Len..., since it's clear that Reaonsable Length could be displayed and still provide identical padding on the left as on the right of the visual indicator.

Despite my opinions I understand the rise of the UI design trend that empty white space is some kind of user-value add, so be it. However the behavior becomes more surprising, lets try to change the length of the item to accomodate the perceived limit of len(Reasonable Len...) "17" characters (seems like an OB1 in someones code for a 18 char check :p) - we will jump righ trying the word Reasonable instead to validate our findings and clean up our poor truncated menu:

Well - this is unexepcted. Reasonable has been truncated to Reason. I'm searching for the design rationale of this and I really can't think of anything. We now have not only a variable length static_select box that changes not only by selection state- but is affected by the width of the selected item in an unintuitive way. I think the behavior of the shrinking clicks- it's setting the new width to the minimal size (after giving a bunch of useless whitespace :|) - but okay it's behavior I can reason about.

Lets see what the real limit is- at which point can my users actually see the text they selected?

1234678 - nope

123467 - still nope.. in fact this is the worst case scenario, the user is allowed to see an entire 5 characters which consume less than HALF of the total available space. The other half is dedicated to dots and empty space. It's hard to see how this provides a better UX.

12346 - Okay- so 6 characters is the number of characters I have to limit to in order to not lose text.

Maximum - Lets check the maximum values: 123456789012345678901234567890 123456789012345678901 123456789012345678901

So now with the behavior demonstrated- the response from the slack team may be this is expected and carefully designed behavior, while we value your feedback we value empty white space and minimal amounts of information in a application meant for communication. Okay- fair, but as a thought expirement lets see how this design phillosphy applies to other inputs. Lets see if we can demonstrate additional cognitive load on the user by introducing some entropy.

Lets change Foo to a (ticket|reference|incident|change order|you-get-the-drift) number. Lets try CHG018247517595. When referencing their notes, other systems and so on- those final three numbers are fairly important as they provide the final bits of information needed to advance in the current interactive workflow.

So that is what led me to use the static_select placeholder to display the full text leveraging all the room provided to me by the fairly large element. If the static_selects stopped shrinking and truncating my data I would be less interested in a fix and would happily use "Selected" item- because I could trust that it would display identically.

The entire root cause of this is clear to me, I can infer that the ellipsis function has been defined as something very close to the function below for displaying. Relying on the 75 character option limit:

max_size = 8
def apply_ellipsis(text):
  if len(text) > 8:
    return text[:len(text)-3] + "..."
  return text

Notice it does not truncate text? I believe this is the fundamental flaw to slacks implemented design. By failing to truncate very long inputs, you have created a demand to drive the max_size trigger to an unreasonably low value, while allowing large values to dominate huge areas of your screen. It makes very little sense to allow a massive value, but lose context for very tiny values.

This could be fixed easily by changing the naive implementation of your ellipsis function:

• Slack team creates a maximum desired display width for static selects
• Slack team documents the display character limit needed to keep the desired maximum element width without ellipsis
• Slack team applies ellipsis under one condition: length is greater than the maximum display length
• Slack team redefines the ellipsis function to maintain an upper bound via truncation.

Then developers can control their display values by truncating before displaying the option, so the least-relevant part of a value is ommitted, e.g.:

CHG20190421-32595 slack truncation -> CHG20190421-... developer truncation -> CH...21-32595 // user still has the day of month, and last 4 of the reference

---

albumn of images: https://imgur.com/a/MetZxko

FYI I found that submitting a message update with a new block id causes the initial selection option to be respected, allowing me to use the placeholder text to reference the previous selected item in full.

I did find some potential bugs while testing large text at the ends of the limits in the slack client, it's possible for example to have block text up in the date column by setting a section blocks text & accessory containing static selected item in the "selected" state to 123456789012345678901234567890 123456789012345678901 123456789012345678901. It pushes the section text in the empty whitespace padding where the message dates are.