[TYPO3-core] RFC: #7986: Vertical aligned Icons in List-Module

[Steffen Kamper]

"Jeff Segars" <jsegars at alumni.rice.edu> schrieb im Newsbeitrag 
news:mailman.1.1207681154.4838.typo3-team-core at lists.netfielders.de...
> Dmitry Dulepov [typo3] wrote:
>> Hi yet again!
>>
>> Dmitry Dulepov [typo3] wrote:
>>> Actually I think this is what disturbed me much in the screenshot: all 
>>> rows are different. I am used to typical toolbars where I see all 
>>> buttons, I know their positions and I always see that button is not 
>>> available when it is greyed out. Examples are well-known: any Windows or 
>>> MacOS app (Word, for example). May be we should the same approach here?
>>
>> I just found the same view in Alan Cooper's "About Face: the essentials 
>> of user interface design". Quoting from chapter 23:
>>
>> "...Unlike menus, we don't depend on toolbar buttons to teach us how they 
>> are used. Although we depend on buttons primarilly for speed and 
>> convenience, their behavior should not mislead us. Toolbar buttons should 
>> become disabled when they are no longer applicable due to the current 
>> selection. They may or may not gray out - this is up to you -
>> but if a button becomes moot, it must not offer the pliant response: the 
>> button must not depress.
>>
>> I've seen programs that make moot buttons disappear alltogether, and the 
>> effect of this is ghastly. The supposedly Rock-of-Gibraltar-like toolbar 
>> becomes this skittish, tentative idiom that scares the daylights of new 
>> users and disorients even those more expereinced (me!)..."
>
> I'm not sure where exactly I come down on the overall question of showing 
> the toolbar icons, but I do have one thought that may be worth some 
> consideration.
>
> Most of the time when a toolbar icon is grayed out it is because the icon 
> doesn't make sense in the current application state. The user can change 
> this state, however, and cause the toolbar icon to become active again.
>
> One example of this would be a mail client with no messages selected. In 
> this state, the reply button does not make sense but as soon as a message 
> is selected, there's a proper state for the reply button.
>
> In list view, the toolbar icons are unique for a specific record rather 
> than the entire application. The backend user cannot make changes that 
> would cause these disabled toolbar icons to be activated (moving records 
> in the list may be the one exception).
>
> This means that the disabled toolbar icons don't indicate the current 
> record state and instead are a static view of what functions that record 
> supports.
>
> Again, not sure exactly where I come down on this RFC but I think there 
> are some distinctions between the icons here and a standard application 
> toolbar.

I have same opinion like Jeff. Also the not usable icons were not visible 
before, we just aligned them.

vg Steffen