Decorating read-only controls

[Attila Kovacs 631]

Those who want to take benefits from styling in VCL, how do you decorate your edit-boxes to make the user being able to distinguish between input ones and read-only ones?

As none of the standard VCL components offer neither read-only color (except Konkopka's) nor read-only-style-color, I'm starting to think that I'm just dumb.

Edited April 3, 2019 by Attila Kovacs

[dummzeuch 1517]

I usually just give them the "disabled" color (ParentColor = True). But of course nowadays with Windows 10 that is nearly indistinguishable from the normal state.

[Der schöne Günther 316]

Interesting read:

 

https://ux.stackexchange.com/q/84715

[Attila Kovacs 631]

@Der schöne Günther Indeed. And also funny.

 

But does not apply then styles are overriding every design time decorations except I'm implementing one custom hook for every different control types.

[Guest]

I so so agree with "In terms of UX, copying into clipboard should be taken into account." and the image. This used to work very good back when. Then - enters the designers. If it isn't Win10 native messing something up it's skins. DevExpress even have some skins that show a gray-box for readonly and some skins that do not and they refuse for years to do anything about it because it was "the vision of the designer". Such important functionality. If corrupt legislation and greed won't kill IT, designers will.

[dummzeuch 1517]

6 hours ago, Dany Marmur said:

they refuse for years to do anything about it because it was "the vision of the designer". Such important functionality. If corrupt legislation and greed won't kill IT, designers will.

Not only IT-designers. It's designers <period>. Show me an unusable product and in 90% it will turn out that it was perfectly usable when the engineers finished. And then the designers ruined it.

There used to be a credo "form follows function", but today it's "it doesn't matter whether it works, let's make it flashy."

 

</rant>

[Rollo62 539]

12 hours ago, dummzeuch said:

Not only IT-designers. It's designers <period>. Show me an unusable product and in 90% it will turn out that it was perfectly usable when the engineers finished. And then the designers ruined it.

There used to be a credo "form follows function", but today it's "it doesn't matter whether it works, let's make it flashy."

 

</rant>

Unfortunately 99.99% of the people out there are NO engineers, so that these clear and straight concepts doen't work most of the time.
It seems we have to sit on the users chairs sometimes, and have a look from their perspective.
This catches me also from time to time, if some customer came up with a brilliant simplification idea.
I would propose that all engineers should be forced to work for 2 weeks with their own apps and real data, before launching a product.

This is not embracing designers work here (sure they do their own mistakes), but I praise the "sitting one somebody elses chair" method.

[dummzeuch 1517]

5 hours ago, Rollo62 said:

Unfortunately 99.99% of the people out there are NO engineers, so that these clear and straight concepts doen't work most of the time.
It seems we have to sit on the users chairs sometimes, and have a look from their perspective.
This catches me also from time to time, if some customer came up with a brilliant simplification idea.
I would propose that all engineers should be forced to work for 2 weeks with their own apps and real data, before launching a product.

This is not embracing designers work here (sure they do their own mistakes), but I praise the "sitting one somebody elses chair" method.

I won't disagree here.

[Guest]

21 hours ago, dummzeuch said:

Not only IT-designers. It's designers <period>.

 

</rant>

Yes, what i meant, exactly. IT-folks that bring them in and give them free reign should also have a bashing.

[Bill Meyer 337]

1 minute ago, Dany Marmur said:

Yes, what i meant, exactly. IT-folks that bring them in and give them free reign should also have a bashing.

Does no one read Alan Cooper any more?

[Rudy Velthuis 91]

On 4/5/2019 at 9:22 AM, Rollo62 said:

Unfortunately 99.99% of the people out there are NO engineers

Fortunately. Engineers might think they are the perfect designers, but they aren't either. And it is usually management that wants something flashy, not the designers.

 

A good designer will improve what the engineer does, but this only works if they work together. FWIW, the client is not entirely clueless either. They know their domain. So they should be involved too.

 

I know a few pieces of dental software that could have been vastly improved if a dentist, or even better, a dental assistant, had been involved. The workflow for the assistant would have been much more efficient.

[Sherlock 663]

15 hours ago, Rudy Velthuis said:

A good designer will

Ay, there's the rub: Please! Pretty please! Find me a good designer! When they are not even present in most of the leading UI manufacturers, surely there must be some kind of global shortage.

I am painfully aware of the fact, that an engineer will fail at creating a good UI as well. So the best thing is to have them both talk with each other through the entire development process...a costly thing. *sigh*

[Rollo62 539]

Beauty is in the eye of the observer: That is problem no. 1.

Engineers, Designers, Managers, Bosses (and customers) have all different eyes

 

Edited May 8, 2019 by Rollo62

[Sherlock 663]

Ah...beauty. That comes at the very end of the process. Usability should be main concern which will result in an overall positive UX. Beauty is just glitter and bows and ribbons. Good usability, however, is measurable. Alas this process of measuring is time and resource consuming. Not many managers are willing or even capable of spending money on this, reckoning that usability will improve itself over time. Sadly, more often than not the opposite happens.

[dummzeuch 1517]

6 minutes ago, Rollo62 said:

Beauty is in the eye of the observer: That is problem no. 1.

Engineers, Designers, Managers, Bosses (and customers) have all different eyes

My gripe is not with whether it looks pretty or not, but whether it's usable at all. To get back to the original post's topic: A visual clue that a control is read only, would be nice. But Windows 8 and later 10 ruined that (and that's far from the end of the visual catastrophe these versions introduced).

Or take web sites: It used to be that links were easily recognizable with blue text color and underlined. The first thing that disappeared was the "ugly" blue color. Then web designers also removed the underline. Nowadays you only know for sure that something is a link when you click on it.

Or one example from non software related design failure: The controls for a faucet (Deutsch: Armaturen) used to show with a blue or red dot that was easily visible whether you turn on cold or hot water. Today these dots are still there (not sure whether that's required by law), if you either know where to look or crane your neck to find them. Apparently somebody decided that they spoil the look of the thing, so they are now hiding them. I'd like to know how many people accidentally get burned because of this.

[Attila Kovacs 631]

The word you are looking for is in German "Barrierefreiheit". English, accessibility? I don't know, the German word is more expressive for me.

Designers and engineers should be taught for it. Until then, I'll try my best.

I found Almdev's GP* VCL components very useful, then it allows setting an alpha factor for every color used. From frames to background and fonts,etc...

Thus, I can use the predefined colors and it's even works with themes together. 

The only thing I'm missing is an explicit read-only color-settings like in Ray Konopka's Raize components.

 

[Guest]

4 hours ago, Rollo62 said:

Beauty is in the eye of the observer: That is problem no. 1.

Yes! This is true even if we interpret "beauty" as "usability". At the launch of Windows 95, Mr Gates said that "Windows is now more intuitive than ever". I laughed and said that just because you can access a function in 5 ways compared to 2 it's not more "intuitive". Today the buzzword is "smart". My point being here that users are affected by what software they use over-all. Some users understand the need of different idioms for a personal banking application and the accounting software you use at work. Some do not. Either way, users will "get at" something the way they are used to. So for each new UI "idiom" introduced because of "design considerations" (i mean the chromy flashy thingies) - or other not well thought-through considerations - the ecology of UI signals and what users expect drifts. IMHO this is an escalating problem.

 

Before the web boom and apps, i would claim that it was up to the OS vendor to set the basic style of the UI. Windows had guidelines, but the ones who started to break them was the Office team (as i have heard, not har source on this). Today there are an abundance of UI idioms out there, Googles Material, Windows has, what 5? Mix mobile with this. I can confess i had more issues learning to control my new LG WebOS TV than say Visual Code.

 

This is, albeit, not something to run around and mope about as several posters above have said already. I agree that communication client - vendor, engineer - designer has been and will continue to be the local (project-wide) solution.

[Attila Kovacs 631]

@Dany Marmur Indeed. For example I liked my Iphone 4 much better than any Android one because they had a collection of controls and every app looked in some way the same and I knew where to tap, how to control the device. 

[Rudy Velthuis 91]

13 hours ago, Sherlock said:

Ay, there's the rub: Please! Pretty please! Find me a good designer! When they are not even present in most of the leading UI manufacturers, surely there must be some kind of global shortage.

I am painfully aware of the fact, that an engineer will fail at creating a good UI as well. So the best thing is to have them both talk with each other through the entire development process...a costly thing. *sigh*

No, not through the entire development process. A few sessions together should do.

 

But I think they are present in leading UI manufacturers.

[Rudy Velthuis 91]

8 hours ago, Dany Marmur said:

Today there are an abundance of UI idioms out there

Hmmm... basically, the differences are not that big. The looks may differ but most control sets on different platforms or UI frameworks have similar functionality. There may be some differences between desktop and mobile, but among them, there are not that many basic differences. Sure, there will always be some that try out new controls (like the Office people at MS did and probably still do) and if they catch on, others will copy them. If they don't, they will slowly disappear again. Note that all the big vendors have usability labs, and the smaller ones can and will copy the successful idioms.

 

Even the IMO worst of all of these, Android, is still easy enough to use and doesn't present you with many surprises.

 

So UI controls/idioms are not the problem. The design/structure of an UI, or set of dialogs can however make big differences. I already mentioned the few very bad designs for parts of our dental software. They have usability problems because the designers/engineers don't know the proper workflow in a dental clinic. And because for such items, there are no standard controls.

 

(Weirdly enough, the previous software we had, which was DOS-based, did some of the things we now have problems with much better).

Edited May 8, 2019 by Rudy Velthuis

[Lars Fosdal 1793]

On 4/5/2019 at 6:45 PM, Bill Meyer said:

Does no one read Alan Cooper any more?

Only us old-timers.

[Guest]

15 hours ago, Rudy Velthuis said:

So UI controls/idioms are not the problem.

It is a problem.

15 hours ago, Rudy Velthuis said:

The design/structure of an UI, or set of dialogs can however make big differences.

Of course i agree to this, but IMHO this another discussion.

[Rudy Velthuis 91]

8 hours ago, Dany Marmur said:

23 hours ago, Rudy Velthuis said:

So UI controls/idioms are not the problem.

It is a problem.

Really? I hardly ever see controls that are either unfamiliar or unusable. The controls are not the problem. They may be hard to control programmatically, but that is not a usability problem.

[Guest]

14 hours ago, Rudy Velthuis said:

They may be hard to control programmatically, but that is not a usability problem.

True, that, semantically. I stand corrected 🙂