Message card

[Bagera]

Description

A message card shows the the message ID, the original message, a text area with the translation, what parameters are available and last change.

Design Specification

card state	button state	button label
Has unsaved changes	Enabled	Save
Has saved changes	Disabled	Updated
No changes	Disabled	Published

Fig. 1: Message without changes. Does not have focus.

Fig. 2: Message with saved changes. Does not have focus.

Fig. 3: Message with unsaved changes. Does not have focus.

Fig. 4: Message with unsaved changes. Has focus.

When a card has focus or is hovered, it has an outline. When a card has focus, any parameters are shown.

[henrycatalinismith]

Started on this today.

Initial notes:

• Not enough contrast on the secondary text colour for the message IDs so I've used a darker grey. In the screenshot above I've tried making the final part bold so that there's still a nice highlight on it. Let's see what we think of that.
• The original layout here only works on desktop. You get better results building mobile layouts first and then working your way up to desktop, so that's what I'm doing here.
• Displaying the parameters only when the card is focused is going to be challenging. I think we're probably going to need to switch from FixedSizeList to VariableSizeList anyway for various reasons. The item size calculation will have to account for factors like zoom level and window width. If we allow the text input field to grow, that will need to be taken into account as well. And then adding the disappearing parameters will affect it too. I've spent some time searching GitHub for example implementations of this itemSize calculation and I've yet to see a single one even 15% as complex as this, which suggests to me that our expectations are misaligned with what's actually practical in these virtualised lists.

[WULCAN]

• Not enough contrast on the secondary text colour for the message IDs so I've used a darker grey. In the screenshot above I've tried making the final part bold so that there's still a nice highlight on it. Let's see what we think of that.

Yes, the first design has so low contrast on the identifier prefix that it is almost hidden. Figure 3 and 4 though has a darker grey for the default message. That was better at drawing attention to the default message, away from the identifier prefix. With your new design, the identifier draws more attention, away from the default message.

• The original layout here only works on desktop. You get better results building mobile layouts first and then working your way up to desktop, so that's what I'm doing here.

I agree but I think we are losing a nice aspect of the first design: the relation between the default message and the translation. In the first design, it's almost like a book with the default message on the left and the translation on the right. In the new design, the default message looks more like a title for the translation.

[henrycatalinismith]

Nice yeah gonna tidy up the colours to match the design closer.

In the new design, the default message looks more like a title for the translation.

Fixing this with spacing, no worries.

[henrycatalinismith]

This GIF gives a sense of the kind of space constraints this design needs to satisfy in practice as opposed to the relatively idealised conditions in the mockups. Note how few of the viewport widths shown here have enough space for feat.smartSearch.filters.journey.inputString's message ID and source text. There simply isn't enough horizontal space for the side-by-side layout even on smaller desktop-class viewports, let alone mobile devices.

Coming back to this now:

the default message looks more like a title for the translation.

The underlying problem here is the unlabeled input fields. I've alleviated it a little with some extra spacing, but unlabeled input fields are an accessibility fail, as well as a missed opportunity to make an app more self-documenting and approachable for its able bodied users. So I'm going to tweak this a little further, like so.

Before	After