[visurfacereader] Re: Poll on flexibility versus ease

Tim:

 

I assume that nothing would be "set in stone" until an "apply" or "ok" would
be executed.  Perhaps the escape key could simply abandant the process.

 

Thanks all over the place.

 

 

From: visurfacereader-bounce@xxxxxxxxxxxxx
[mailto:visurfacereader-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Burgess
Sent: Monday, June 25, 2012 7:42 AM
To: visurfacereader@xxxxxxxxxxxxx
Subject: [visurfacereader] Re: Poll on flexibility versus ease

 

Good feedback thanks.  

 

I need to sit and think about what happens if the user makes the wrong
choice and discovers the error half-way through the definition process.
It's easy enough if the decide that they needed to add individual entries,
as the gaps will be there to be filled, but what if they've defined 20
lamps, each with 3 states.  Pointing the configuration towards a master set
of definitions is easy, but what about the already-described entries?  The
choice would be to abandon them and save space/memory, or hold them in cold
storage in case the user changes their mind again.

 

I'm pretty happy with the ease of use of the SurfaceReader user interface up
to this point and don't want to blow it on this issue.  Given what I've
written above, please comment further.

 

Best wishes.

 

Tim Burgess

Raised Bar Ltd

Phone:  +44 (0)1827 719822

 

Don't forget to vote for improved access to music and music technology at

 

http://www.raisedbar.net/petition.htm

 

 

 

From: visurfacereader-bounce@xxxxxxxxxxxxx
[mailto:visurfacereader-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Noseworthy
Sent: 25 June 2012 10:49
To: visurfacereader@xxxxxxxxxxxxx
Subject: [visurfacereader] Re: Poll on flexibility versus ease

 

Hey Tim:

 

Would it be possible to include a radio button to permit the user to have
the option: all, individual, or off?

 

Thanks all over the place.

 

 

From: visurfacereader-bounce@xxxxxxxxxxxxx
[mailto:visurfacereader-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Burgess
Sent: Monday, June 25, 2012 5:52 AM
To: visurfacereader@xxxxxxxxxxxxx
Subject: [visurfacereader] Poll on flexibility versus ease

 

OK,

 

I'm finalising the code for reading LED lamps and there's a trade-off to
handle.  The current design allows you to define named states (e.g. on, off,
flashing, red, rein, etc.) for each LED that you define.  This is very
flexible and will survive any conceivable LED implementation that a
manufacturer could come up with.  The downside is that, if you've got a
protocol that defines 50 lamps, each of which supports 5 states, you've got
to define a total of 250 states, which is boring at best.  A work-around
would be to provide a check box that, if checked, would make all LED lamp
interpretation for the protocol point to a single set of state definitions.
From a code point of view this is a bit of a cop-out, so I'd appreciate
feedback on what behaviour users would prefer to experience.  

 

I'm under a reasonable amount of time pressure, so I'll have to make a
decision within the next 48 hours or so, so please have a think and respond.

 

Best wishes.

 

Tim Burgess

Raised Bar Ltd

Phone:  +44 (0)1827 719822

 

Don't forget to vote for improved access to music and music technology at

 

http://www.raisedbar.net/petition.htm

 

 

 

Other related posts: