Item can be edited even without Edit view

[ssalonen]

The problem

I find it inconsistent that you can edit several critical things about an item, even without going to "Edit" mode:

• In item view, metadata can be added without going to Edit view
• In item view, Link can be added without going to Edit view
• In item view, Item can be removed without going to Edit view
• In item view, Direct group members can be modified without going to Edit view.
  • However, same does not apply in reverse direction ("Direct Parent Groups" cannot be modified without going to Edit view). In fact, for some reason, the "Direct Parent Groups" and "Direct Group Members" are visually very different views.

Expected behavior

Steps to reproduce

Your environment

runtimeInfo:
  version: 3.3.0
  buildString: Release Build
locale: fi-FI
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 11.0.15
  javaVendor: Raspbian
  osName: Linux
  osVersion: 5.15.32-v7l+
  osArchitecture: arm
  availableProcessors: 4
  freeMemory: 97366840
  totalMemory: 372244480
  startLevel: 100
bindings:
  - fmiweather
  - modbus
  - network
  - shelly
  - systeminfo
  - zwave
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: false
    macos: false
    windows: false
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    pixelRatio: 1.25
    prefersColorScheme: light
  isSecureContext: true
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: 8
    hardwareConcurrency: 4
    language: en-GB
    languages:
      - en-GB
      - en
      - en-US
      - fi
    onLine: true
    platform: Linux x86_64
  screen:
    width: 3072
    height: 1728
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: filled
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
  userAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
    Gecko) Chrome/104.0.0.0 Safari/537.36
timestamp: 2022-08-24T04:42:29.315Z

Browser console

Browser network traffic

Additional information

[rkoshak]

tl;dr: I agree that the parent groups view on the Item should match the list of members view on the Group. The rest I've questions concerning consistency with how other entities work in MainUI should we change them as well as the cost to the end users by adding an additional step to modify those.

I do not disagree that it can be somewhat confusing but in these cases I think it might be reasonable.

In item view, metadata can be added without going to Edit view

Metadata is associated with an Item but internally it's stored and managed separately from the Item. Metadata is its own thing. From that perspective it actually doesn't make sense that one would have to go into edit mode on the Item to add/modify the metadata.

But from the user's perspective that distinction is not apparent at all. So I can see arguments both ways.

In item view, Link can be added without going to Edit view

The same goes for the Link. Links exist independently from the Thing and the Item. But in this case the fact that the Link is separate and independent is more apparent. We don't have to go into edit mode on the Thing to create a Link either. So in this case it's more internally consistent to not have to enter edit mode to add a Link from the Item. Otherwise, why would I have to enter edit mode for the Item but not the Thing/Channel?

In item view, Item can be removed without going to Edit view

This is consistent with how Rules, Things, Pages, UI Widgets and I'm sure other concepts in OH work. There is always a "remove" button at the bottom. I wouldn't change it here unless it's changed everywhere.

In item view, Direct group members can be modified without going to Edit view. However, same does not apply in reverse direction ("Direct Parent Groups" cannot be modified without going to Edit view). In fact, for some reason, the "Direct Parent Groups" and "Direct Group Members" are visually very different views.

This one I fully agree with. Group membership is clearly a property on the Item itself, not something separate like Links and Metadata. But there is a disconnect. Is it a property on the Group Item or a property on the member Item? In the REST API both have the property included in their JOSN representation. Looking at the actual JSON entry in the JSONDB it's only a part of the member Item, not the Group.

For the member Item, you actually do have to enter edit mode to change that Item's Group membership. But you don't for the Group Item which is inconsistent and I can see how it might be confusing. What's more confusing is that this means that you can modify a property on another Item without entering edit mode for that Item.

The reason the views are very different because they are showing different things. On the Group side, it's showing the members of that Group. You can see their state and click on them to navigate to that Item. On the Item side, it's showing the Groups the Item belongs to. Not all Groups have an aggregation function so does it make sense to show the full list view of the Group Item? I highly prize internal consistency so I'd say yes, it does make sense. Also, the label for the Item is the most prominent attribute of the Item but on the Item's page where we show the Groups it belongs to only shows the Item name of the parent Group.

In all of these cases, we still also have to balance consistency with usability. While consistency sometimes does improve usability, moving all of these properties to only become available after entering edit mode means at least two additional mouse clicks and an additional page to bring up to modify these properties. Are the benefits brought from the consistency

[ssalonen]

Yes good discussion, I did actually bring any advice / guidance how it should work in my opinion. For example, perhaps one can argue to remove the "edit" button altogether? Have everything directly editable by clicking the field or clicking "change" button of a list.

I do not have a strong stance how it should be. I simply find the experience "jarring" myself although the concepts themselves are familiar from the times of text based configs.

Another source of confusion (at least to me): I think now there is a save button which gives me impression that changes are not saved before I press the button. I believe this is not the case: depending on the UI element on item page, some things are committed immediately, some are not. (To be confirmed)

There are clearly technical legacy how all things are stored in different places, I do understand that. I do question whether it is "necessary" to expose this underlying scattered nature of openhab config management to UI users.

Overall this is not necessarily the most horrible thing in the UI, just wanted to bang these issues / improvement areas down (along with others from today) for expert assessment.

[rkoshak]

Another source of confusion (at least to me): I think now there is a save button which gives me impression that changes are not saved before I press the button. I believe this is not the case: depending on the UI element on item page, some things are committed immediately, some are not. (To be confirmed)

I know with Rules and Channels that it does not commit any of the changes until you save. I don't mess with Items much to know what happens there. I suspect, if you make changes to anything that is not on the edit screen, it applies automatically.

That's definitely something worth exploring.

There are clearly technical legacy how all things are stored in different places, I do understand that. I do question whether it is "necessary" to expose this underlying scattered nature of openhab config management to UI users.

I can see good arguments for metadata but there are aspects of Links that make it important that they are presented and interacted with as a separate entity, in particular Profiles. Profiles don't make sense if Links are not their own entity.

I like these issues and also would like to see MainUI become more consistent and useful. It's already pretty good but there is always room for improvement.