ReadOnly TextBox looks identical to not ReadOnly TextBox

[Balkoth]

Describe the bug
A ReadOnly TextBox looks identical to a not ReadOnly TextBox.

Expected behavior
A win32 edit makes it obvious to the user if he can edit the text or not. This is the expected behaviour.

Screenshots

NuGet package version:
[Microsoft.ProjectReunion 0.8.0]

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)	Yes
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)

[StephenLPeters]

@chrisglein and @MikeHillberg FYI

[chrisglein]

old	WinUI 2.6+

    <StackPanel VerticalAlignment="Center" HorizontalAlignment="Center" Spacing="12">

      <TextBlock FontWeight="Bold">Enabled</TextBlock>
      <TextBox Text="text goes here" Header="IsReadOnly=False"/>
      <TextBox IsReadOnly="True" Text="text goes here" Header="IsReadOnly=True"/>

      <TextBlock FontWeight="Bold">Disabled</TextBlock>
      <TextBox IsEnabled="False" Text="text goes here" Header="IsReadOnly=False"/>
      <TextBox IsEnabled="False" IsReadOnly="True" Text="text goes here" Header="IsReadOnly=True"/>

  </StackPanel>

While the visual treatment has changed here, the fact that IsReadOnly doesn't have a different visual treatment from !IsReadOnly isn't new. It's not the same as a disabled control (since you can copy/paste from it). This is the intended design.

[Balkoth]

Imho the intended design is bad and brushing concerns off like this is also not healthy.

[mrlacey]

This is the intended design.

Can an explanation for this be provided?
How is the end-user expected to know if something can be edited without trying? If it looks like a TextBox but doesn't behave like a text box (can't be changed) it can seem broken.
Having no visual indication of a functional difference seems very inconsistent with other controls and general usability advice.

[Balkoth]

The behaviour of the team behind this shows quite clear why all the modern ui libraries from microsoft should be avoided at all cost for business applications. Where win32 controls just work and have set a standard that is accepted across the industry, some hipster developers come in and think they know better.

[robloo]

I agree its strange read-only looks the same. That said, a Disabled TextBox is usually used to indicate a user cannot interact with a control. I know you loose copy functionality, but disabled should be used in most circumstances.

Perhaps you can provide a screenshot of what classic Win32 does as well?

Generally I agree the WinUI team set themselves up for repeating the same mistakes as the past 'Modern' UI frameworks. They've alienated almost everyone at this point and I've voiced that many places. This is a comparatively minor issue though and you can restyle the control easily if you want.

[shaheedmalik]

Read only should look similar to Disabled. There is no reason why a read only text box should look Identical to an editable one.

[chrisglein]

Hey all, appreciate the passion here. Let me attempt to be transparent with where this is at. I'm trying to run this by the Design team again to get a second look. Ideally I want to get a more detailed answer from them so I can pass it on to you. That's in progress.

Meanwhile I'm looking at other platforms and other UI frameworks and how they handle this. Most of them don't make the state visually distinct. HTML doesn't, WPF doesn't. From a cursory investigation it looks like these aren't core scenarios for iOS UITextField and Android EditText (if you have more info there, share it here). Win32 does visually differentiate with ES_READONLY, but it seems to be in the minority.

If you want to help add clarity here, include examples of standards on other platforms and/or clear+concise scenarios that will illuminate pain points.

[Balkoth]

I think you have to understand that you can not compare desktop and mobile frameworks here, when you come from a win32 background. On your mobile app you might not care about the visual difference between readonly and not readonly, because your input methods are rather limited.

I don't like that you put win32 in a corner here, suggesting that what it is doing is not relevant, when it possibly has an amount of apps written that is equal to all other frameworks you mentioned combined.

I think on desktop it is essential that a user can differentiate visual states of a control, at first glance, without having to guess or try. It is essential to know on which control a user can click and expect something to happen. It is essential to know where a user can input text.

This project is called WINUI not otherplatformsui and is proposed as a successor to all the previous microsoft provided user interfaces on WINDOWS. I expect that it takes the best things from the previous frameworks and carries them on and improves upon them. Making things harder is a detriment to the platform.