Author Topic: UI3 icons proposal  (Read 20090 times)

Offline guessed

  • Master Member
  • *******
  • Posts: 5294
  • Karma: +90/-22
  • Release compat is not a bolted-on afterthought
Re: UI3 icons proposal
« Reply #45 on: February 18, 2010, 11:13:46 am »
More like the first, except:

  • the (i) should be in the corner, and only appear "when the user hovers above"
  • The Blue strip at the end should be removed so we can utilise the full length for our label content.
  • Can you put in some of the sample labels that I provided so we can see the effect of longer label strings for wrod-wrapping, top-anchor etc
  • Does the label string really "move up" when the Status overlay occurs as indicated in the example? (hence the reference above about text-anchorage points
  • I don't think we need to see a "success" status, only Error (red) status's or potentially a "delayed" (amber?) status if the action takes longer than ~1-2 seconds to execute.

Offline javier

  • Full Member
  • ***
  • Posts: 172
  • Karma: +0/-0
Re: UI3 icons proposal
« Reply #46 on: February 18, 2010, 11:32:59 am »
i fully agree on these two points:

  • the (i) should be in the corner, and only appear "when the user hovers above"

  • I don't think we need to see a "success" status, only Error (red) status's or potentially a "delayed" (amber?) status if the action takes longer than ~1-2 seconds to execute.

on the other points i'm indifferent/ignorant.

(not that my vote should count too much...)
--
Javier

Offline mcv_alex

  • Full Member
  • ***
  • Posts: 103
  • Karma: +0/-0
Re: UI3 icons proposal
« Reply #47 on: February 18, 2010, 02:12:55 pm »
More like the first, except:

  • the (i) should be in the corner, and only appear "when the user hovers above"
  • The Blue strip at the end should be removed so we can utilise the full length for our label content.
  • Can you put in some of the sample labels that I provided so we can see the effect of longer label strings for wrod-wrapping, top-anchor etc
  • Does the label string really "move up" when the Status overlay occurs as indicated in the example? (hence the reference above about text-anchorage points
  • I don't think we need to see a "success" status, only Error (red) status's or potentially a "delayed" (amber?) status if the action takes longer than ~1-2 seconds to execute.

I think we should avoid the hover functions since some of the users will use touch screens. But the "i" position can be changed in order to maximize the label space.

Offline guessed

  • Master Member
  • *******
  • Posts: 5294
  • Karma: +90/-22
  • Release compat is not a bolted-on afterthought
Re: UI3 icons proposal
« Reply #48 on: February 18, 2010, 03:15:08 pm »
Ah yes, but "Edit" shouldn't be available in Runtime, only Designtime... consistent with the comments from others.

If a [reduced] Dialog needs to be presented by the component for it's control functions [at Runtime] then it's likely going to happen when you press the "main" surface area, no?

I agree that hover stuff should be avoided in Runtime, for the reason you cite.  I should never require a mouse either, not require the user to "Pan or Zoom around" excessively  :)

Offline Joe

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
Re: UI3 icons proposal
« Reply #49 on: February 18, 2010, 04:19:26 pm »
Thing is not everyone has a ranch with just one level. I have a basement, a ground floor, and a third floor. So I tried drawing all 3 floors side by side and then I wanted to just zoom so one was visible at a time. I could drag left or right to see the other.

In either case the full screen zoom left everything worthless to see.
Tabs for different floors of a home could be a great way to handle this while retaining readable zoom levels. I have a split-level home, which gives it twice as many floors as other typical home layouts.

Offline mcv_alex

  • Full Member
  • ***
  • Posts: 103
  • Karma: +0/-0
Re: UI3 icons proposal
« Reply #50 on: February 19, 2010, 02:01:49 am »
Thing is not everyone has a ranch with just one level. I have a basement, a ground floor, and a third floor. So I tried drawing all 3 floors side by side and then I wanted to just zoom so one was visible at a time. I could drag left or right to see the other.

In either case the full screen zoom left everything worthless to see.
Tabs for different floors of a home could be a great way to handle this while retaining readable zoom levels. I have a split-level home, which gives it twice as many floors as other typical home layouts.

I think for the UI3 the possible changes to be done are limited to graphics and functionality but, conceptually speaking, it will remain the same. This is the reason we've started the UI4 in order to find a better solution for the floor planner, in which all the infos to be readable and the access to different sections to be fast and easy.

I can say that we have a nice concept that will be presented on the UI4 Proposals topic. Waiting everybody there to share opinions. We are saying that the new interface will not need any more zoom or pan in order to see all the rooms and devices.  @guessed, does it sound good? :-)