ReadOnlyDisplayAppearance behaviour: Best mode missing (disabled + c&p + scrolling)

[Blama]

Hi Isomorphic,

IMHO the best mode for read-only FormItems is missing from the configuration options:

• Default-ReadOnlyDisplayAppearance.READONLY is missing visual pointers to the read-only nature of the items
• ReadOnlyDisplayAppearance.DISABLED also disables copy&paste (and perhaps scrolling)
• ReadOnlyDisplayAppearance.STATIC takes away information about the nature of an item (e.g.: free-entry or dropdown? text or "real" date?) and gives an "unknown" UI to a user who also knows the readWrite-version of the form.

A setting of ReadOnlyDisplayAppearance.DISABLED plus copy and paste and easy scrolling via mousewheel and scrollbars would be the best behaviour for me. I'd say it is not possible to use anything else than ReadOnlyDisplayAppearance.DISABLED currently for the reasons given. But then the no-copy&paste is annoying and the no-scrolling (which might be a bug) is perceived as UI defect (happened to me).

I'm using current 5.0p/5.1d.

Best regards
Blama

PS: You removed the "start as disabled"-mode from the online showcase. I'm sure you have reasons for this, but it would make testing easier.

[Isomorphic]

This is way too vague to answer at the moment.

1. in what skin and for what specific formItem are you seeing a lack of visual cues that the item is disabled? How can this be reproduced?

2. on what formItem type were you having difficulty with copy and paste, and were you expecting scrolling?

3. what "start as disabled" mode are you talking about? Does this refer to some specific sample?

[Blama]

Hi Isomorphic,

please see this Testcase using Simplicity skin:
BuiltInDS.java:

package com.smartgwt.sample.client;

import com.google.gwt.core.client.EntryPoint;
import com.smartgwt.client.core.KeyIdentifier;
import com.smartgwt.client.data.Criteria;
import com.smartgwt.client.data.DSCallback;
import com.smartgwt.client.data.DSRequest;
import com.smartgwt.client.data.DSResponse;
import com.smartgwt.client.data.DataSource;
import com.smartgwt.client.types.ReadOnlyDisplayAppearance;
import com.smartgwt.client.util.PageKeyHandler;
import com.smartgwt.client.util.Page;
import com.smartgwt.client.util.SC;
import com.smartgwt.client.widgets.form.DynamicForm;
import com.smartgwt.client.widgets.form.fields.ComboBoxItem;
import com.smartgwt.client.widgets.form.fields.SelectItem;
import com.smartgwt.client.widgets.form.fields.SpinnerItem;
import com.smartgwt.client.widgets.form.fields.StaticTextItem;
import com.smartgwt.client.widgets.form.fields.TextAreaItem;
import com.smartgwt.client.widgets.form.fields.TextItem;
import com.smartgwt.client.widgets.layout.HStack;

public class BuiltInDS implements EntryPoint {

	public void onModuleLoad() {
		KeyIdentifier debugKey = new KeyIdentifier();
		debugKey.setCtrlKey(true);
		debugKey.setKeyName("D");

		Page.registerKey(debugKey, new PageKeyHandler() {
			public void execute(String keyName) {
				SC.showConsole();
			}
		});

		HStack stack = new HStack();
		stack.setLeft(20);
		stack.setTop(20);
		stack.setWidth100();
		stack.setMembersMargin(20);

		Testform enabledForm = new Testform("ENABLED");

		Testform roroForm = new Testform("Readonly-Readonly");
		roroForm.setReadOnlyDisplay(ReadOnlyDisplayAppearance.READONLY);
		roroForm.setCanEdit(false);

		Testform rodiForm = new Testform("Readonly-Disabled");
		rodiForm.setReadOnlyDisplay(ReadOnlyDisplayAppearance.DISABLED);
		rodiForm.setCanEdit(false);

		Testform rostForm = new Testform("Readonly-Static");
		rostForm.setReadOnlyDisplay(ReadOnlyDisplayAppearance.STATIC);
		rostForm.setCanEdit(false);

		Testform disabledForm = new Testform("DISABLED");
		disabledForm.setDisabled(true);
		stack.addMembers(enabledForm, roroForm, rodiForm, rostForm, disabledForm);
		stack.draw();
	}

	private class Testform extends DynamicForm {
		private StaticTextItem typeField;
		private TextItem scientificName;
		private TextItem commonName;
		private SelectItem status;
		private ComboBoxItem status2;
		private SpinnerItem lifeSpan;
		private TextAreaItem information;

		public Testform(final String type) {
			super();
			setWidth(200);
			setDataSource(DataSource.get("animals"));
			typeField = new StaticTextItem("TYPE");

			commonName = new TextItem("commonName");
			scientificName = new TextItem("scientificName");
			status = new SelectItem("status", "Status(SI)");
			status2 = new ComboBoxItem("status", "Status(CBI)");
			lifeSpan = new SpinnerItem("lifeSpan");
			information = new TextAreaItem("information");
			information.setHeight(100);
			setFields(typeField, commonName, scientificName, status, status2, lifeSpan, information);
			fetchData(new Criteria("scientificName", "Loxodonta africana"), new DSCallback() {
				@Override
				public void execute(DSResponse dsResponse, Object data, DSRequest dsRequest) {
					typeField.setValue(type);
				}
			});
		}
	}
}

I attached a sceenshot (Missing_visual_cues_and_other_problems.jpg). To answer your question 1:

• See (1) in the screenshot. I can't tell apart the TextItems and TextAreaItems in enabled and setCanEdit(false)+ReadOnlyDisplayAppearance.READONLY. Also for the other items it is not that intuitive/easy to see.
• See (2) in the screenshot. I can't use setDisabled(true) or setCanEdit(false)+ReadOnlyDisplayAppearance.DISABLED, because of the unusable native scrollbars. I get valid user complaints.
• See (3) in the screenshot. Minor unrelated bug.

To answer your question 2:

• I can't c&p in setDisabled(true) or setCanEdit(false)+ReadOnlyDisplayAppearance.DISABLED (correct behaviour per docs)
• I can't scroll in setDisabled(true) or setCanEdit(false)+ReadOnlyDisplayAppearance.DISABLED (see linked thread above)

IMHO the best would be:

• c&p and scrolling from setCanEdit(false)+ReadOnlyDisplayAppearance.READONLY
• Gray font for both data and label from setDisabled(true) or setCanEdit(false)+ReadOnlyDisplayAppearance.DISABLED

This mode would have the best from both worlds and the other two modes would not be needed then, anymore IMHO. Again, "disabled" is unusable because of the TextAreaItem problem.
I'd see ReadOnlyDisplayAppearance.STATIC as more of a print-preview mode. It hides the nature of the data (free entry or dropdown).


To answer your question 3:
You had a checkbox "start disabled" in the marked location in the 2nd screenshot, which affected all samples.

Best regards
Blama

[Isomorphic]

We agree that the default appearance for canEdit:false fields (readOnlyAppearance:"readOnly") is the most usable one and that's why it's the default.

We've already covered why the other modes can't be improved (native limitations).

As far as how readOnly controls should appear: opinions vary. A drawback of making them look similar to disabled controls, or even making the color fainter in any way, is that end users will assume that means the control is disabled and will not attempt clipboard copy or scrolling.

As far as other ways of calling out readOnly fields as special, we've seen some apps with no appearance difference for readOnly fields, some using a distinct appearance for titles, some using trailing text (like our formItem.hints), some using a distinct background color for the input itself or its surrounds...

At the moment we are leaving the decision up to the application developer, but we may provide a default appearance difference in the future, or perhaps an optional one.

About the "Start as disabled" checkbox: this was an internal testing option never meant to be exposed. It won't be reintroduced because it's mysterious to a new user just arriving to browse examples.

[Isomorphic]

One item we forgot to address - we agree spinner controls should not show up in "static" mode (you circled this with a 3) and we'll change that.

[Blama]

Hi Isomorphic,

thanks for explaining. You are right, there are different ways of visually marking readOnly items. I'll go for the default readOnlyAppearance:"readOnly" then and modify the text color via CSS myself. Shouldn't be too difficult.

Best regards
Blama

[Blama]

Hi Isomorphic,

not as simple as I thought. readOnly-FormItems with ReadOnlyDisplayAppearance.READONLY have no special readOnly-CSS suffix.

What do you mean by

At the moment we are leaving the decision up to the application developer, but we may provide a default appearance difference in the future, or perhaps an optional one.

?
Do I have more options than sticking with either of the default ReadOnlyDisplayAppearance?

Best regards
Blama

[Blama]

Hi Isomorphic,

I was able to solve it like this:
Java:

DynamicForm df = new DynamicForm() {
	{
		setReadOnlyDisplay(ReadOnlyDisplayAppearance.DISABLED);
	}
};
DynamicForm.setDefaultProperties(df);

TextAreaItem tai = new TextAreaItem() {
	{
		setReadOnlyDisplay(ReadOnlyDisplayAppearance.READONLY);
	}
};
TextAreaItem.setDefaultProperties(tai);

skin_styles.css:

textarea[readonly="TRUE"] {
	color: rgb(172, 168, 153);
}

This way I can scroll in readOnly TextAreaItems, while still having the appearance of disabled, like for the rest of the FormItems.
The scrolling was the most important point in this thread for me.

This seems like a little hack to me, but it should not interfere with anything, should it? If not then I'm all good.

Best regards
Blama

[Isomorphic]

We meant that you have all the normal styling APIs available to you to style your readOnly fields, such as formItem.textBoxStyle.

As far as this approach, it seems like this would make readOnly TextItems render as disabled, preventing copy and paste, so that seems like a bad idea.

[Isomorphic]

Tomorrow's build now automatically omits the spinner icons for readOnlyAppearance:"static" SpinnerItems.

[Blama]

Hi Isomorphic

We meant that you have all the normal styling APIs available to you to style your readOnly fields, such as formItem.textBoxStyle.

As far as this approach, it seems like this would make readOnly TextItems render as disabled, preventing copy and paste, so that seems like a bad idea.

The problem here is that FormItemBaseStyle defines no suffix for readOnly / canEdit: false (which would be a major change, I suppose).
I'd always have to use

formItemInstance.setCanEdit(false);
formItemInstance.setTextBoxStyle("mystyle");

when I enter read-only mode and

formItemInstance.setCanEdit(true);
formItemInstance.setTextBoxStyle(itemDefaultStyleString);

when I enter normal mode. Usage of just dynamicForm.setCanEdit(false) is not possible as I see it.

The non-c&p-capability of all FormItems (besides TextAreaItem) you mention is true, but I did not get complaints here, so far. I got complaints for the non-scrollable TextAreaItem, which I solved.
I'll check if my elementtype[readonly="TRUE"]-CSS rule would also target TextItems and its childs and perhaps solve it that way (I am only changing the text color).
Or am I missing something regarding your formItem.textBoxStyle suggestion?

Best regards
Blama

[Isomorphic]

Right, as we covered, the framework does not provide a distinct style series for readOnly fields, in part because there is no web-wide design consensus on how a readOnly field should appear.

We're considering providing a distinct style series in the future, but for now, you would need to call setTextBoxStyle() (or modify appearance in some other way, such as setTitleStyle()) to specially style readOnly fields.

[Blama]

Ok, thank you.
I'd have to do this for every FormItem instance on readOnly/readWrite change then, correct?

Is there a reason I shouldn't use the CSS approach I showed for TextAreaItem from your point of view?

Best regards
Blama

[Blama]

Tomorrow's build now automatically omits the spinner icons for readOnlyAppearance:"static" SpinnerItems.

I forgot: Thanks for fixing this one!

[Isomorphic]

Technically, your approach relies on details of the rendered DOM, which is always undocumented and unsupported.

If we find ourselves in the situation where we cannot use the DOM "readonly" attribute because it's broken in some browser, and instead have to implement our own equivalent of the native behavior without using that attribute, your CSS would no longer apply to the control we render.

This is pretty unlikely so it's a reasonable risk to take.