Author Topic: Detailed UI enhancement requests  (Read 2525 times)

Offline Dolphran

  • Jr. Member
  • **
  • Posts: 85
  • Karma: +1/-0
Detailed UI enhancement requests
« on: July 30, 2012, 03:10:14 pm »
I've been a Vera (Lite) user since June 1st.  As a new user UI5 is my only reference point.  I have no idea what things were like before, but I will take it as a given that things have gotten better over time.

Given the relative maturity of this product I am sometimes quite surprised at its more obvious shortcomings.   Ease of use is  a key factor that I think warrants some serious immediate attention.  I will describe here what I think are some straightforward improvements that would go a long way towards making the product more usable.  I may not be saying anything new here - I'm sure others have voiced similar opinions - this is simply my opportunity to add to the choir and make visible my personal view of what needs fixing most.


1) Organization of Dashboard Elements

I'm using the term "element" to include both Devices and Scenes.  Organization of elements includes both categorization and ordering.   Categorization is currently handled via "Room" and sometimes via element type (e.g. Scenes, or Lights, or All Devices).  There is also a "Pinned" state.  These existing attributes are cumbersome to use and fail to provide  the user with a flexible way to see just the elements he wants in a manner that is suited to that user.

My solution is to have an attribute on every element (device or scene) called UserCategories.  This would be a string containing a semicolon separated list of categories (user supplied names) that the user wishes to associate with the element.  Importantly, each element would have as many categories as the user wishes, and of course each category can be associated with multiple elements.

So for example, Light-A may have the categories, " Lights; Upstairs Lights; Master Bedroom", and Light-B may have the categories, "Basement; Basement Lights; Lights", and Light-C may have the categories, "Lights; Upstairs Lights; Emergency Lights, Upstairs Hallway".  I could then choose to list all elements with the category "Upstairs Lights" and I would see Light-A and Light-C.  The important point is that these categorized elements can show up in multiple different lists grouped together in many different ways.

The existence of this attribute as a standard feature of Devices and Scenes would allow third party remote controls as well as the native Web UI of Vera to give much more flexible ways of displaying just those elements a user wishes to look at.  In the native UI the user's categories could be shown as a set of Tabs similar to the way Various Device subtypes are displayed today.


2) Alternate Conception of Devices, Scenes, and Triggers

For the purposes of defining automation I believe that Scenes and Devices should not be seen as separate things.  Sure, when considering the Z-Wave network (or Insteon or whatever) Devices are physical nodes whereas Scenes are abstractions purely within Vera.  But this is only important when working with the network (perhaps in the 'Setup' area).  When configuring home automation, devices and scenes should not be treated separately.  This will require a slight change to how scenes are defined as I will explain below.

Currently Scenes are things that Triggers do.   But this creates an unnecessary middle man in many circumstances.  Devices come with built-in Actions (buttons on the Dashboard).  Scenes should be seen as simply named collections of actions.   The Dashboard element for a Scene already has a 'Run' button.  This button should be able to be used in exactly the same way as the buttons on Device Dashboard elements.   I will call the Device and Scene Dashboard-elements collectively 'Actions'.

In this new conception Scenes would NOT be what triggers do; in fact scenes would not have triggers as part of their definition at all.  Instead, Scenes would be defined exactly as they are now, EXCEPT that the Trigger definition would not be part of a Scene.  Scenes would just be Action elements that have a single 'Run' button.  (All other aspects of defining a Scene would be just as it is today.)

Trigger definitions would be where Actions are selected.  This is like Scenes today - except that Devices' action buttons as well as Scenes' 'Run' buttons would both be available to be selected.  A Trigger can cause a Light to go on directly - no need for a old-style scene in the middle.  A Trigger could also Run one or more Scenes (as well as directly turn lights on or off) since Device buttons and Scene 'Run' buttons would all be Actions that can happen as a result of the Trigger.

I think this change would represent a great improvement usability.  It makes things simpler for the user that just wants to trigger some lights on and off (no Scenes required), and also allows for easy reuse of complex Scenes (using the 'Run' button from any Trigger) for the advanced user.

Importantly, I also believe that this could be implemented In a straightforwardly backward compatible manner.  Existing Scenes would simply be separated from their Trigger definitions.  Existing Triggers would show up as selecting the 'Run' button of the Scene they used to be a part of.



3) Trigger enhancement via States

Many folks, including myself, have asked that conditional logic (AND, OR, etc.) be added to Trigger definitions.  I now think that this idea is flawed because it confuses two separate concepts - events and states.   Triggers today are events that happen at some moment in time (e.g. user presses a button).  Thus it makes no sense to say one wants to AND two triggers together.   Instead, I believe a user wants to be able to stipulate that a particular trigger is only acted-upon when the system is in a particular State.  I think that the definition of a State is ultimately about one or more LUUP variables being within a certain range of values.   The Combination Switch plugin embodies this concept fairly well and gives a good example of how states might be defined.  In a simple conception of enhanced Trigger definitions we could rely on Combination Switches explicitly by allowing a Trigger to be acted upon only when specified (one or more) Combination Switches are in some combination of On and Off Sates.  Condition logic WOULD be appropriate here- e.g. Trigger X is only acted upon when Combination Switch A and B are both On OR Combination Switch C is Off.    Ideally I think that a new element called States could be made part of the UI, instead of using Combination Switches.   States would have user-specified names and would be easily reused within multiple Triggers.


4) Abstraction between engine and UI

My last point is not a specific feature request but rather a comment on the UI design in general.  A  common flaw in UI design when providing access to an underlying functional layer of some complexity, is the tendency to create a UI that provides direct access to the underlying functionality without an abstraction layer that makes that functionality more user friendly.

Items 2 and 3 above describe new ways to access functionality, not new capabilities.  You can achieve the same ends today, but doing so is cumbersome and confusing.  In item 2 above, I show how Triggers could be made separate from Scenes, but INTERNALLY Vera may still have the conception that what triggers do is launch scenes (small 's' and small 't' to differentiate from what the user sees as Triggers and Scenes).  It is a matter of exposing in the UI a different abstraction from how things may function underneath.    For example in my own Vera I have employed a Combination Switch which launches a scene when its UI button is selected within another scene.  This allows for Scenes to launch other Scenes.  The problem is I need to pains-takingly create virtual devices and go through many steps to wire it together.   This same technique could be used under the covers in a new UI while hiding from the user the in-between bits.  This would allow the lower level code to work as it currently does while providing a different conceptual view to the user.

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Detailed UI enhancement requests
« Reply #1 on: August 01, 2012, 07:40:49 am »
Thank you for the suggestions. We'll take them into account for the next UI version.