Talk:Honeycombs: Difference between revisions

m
no edit summary
(the application should support both methods of selection.)
mNo edit summary
 
Line 15:
 
It was looking good, but I think the requirement for the message output and the each-hex-only-once made it more complicated than the gains in illustrating the concepts involved. The user will know that X was selected because the hex changed color, and I don't see the illustrative benefit of each-hex-can-change-only-once. --[[User:Short Circuit|Michael Mol]] 02:56, 26 May 2011 (UTC)
 
Maybe we can drop the message, and just keep a record of which hexagons have neen clicked. Depending on how the widgets work for the language, we could either set this as a property of the widget itself, or keep the information in a separate array. We can then use this record to programmatically prevent reacting to already clicked hexagons. I am open to suggestions on the wording here.
: That's something that's probably best left unspecified so that it can be left maximally to the discretion of the implementer. What's significant is that the on-screen and interactive behavior is preserved, right? Let the implementer worry about that. --[[User:Short Circuit|Michael Mol]] 16:45, 26 May 2011 (UTC)
 
[[User:Markhobley|Markhobley]] 16:37, 26 May 2011 (UTC)
 
This reminds me of a [[wp:Blockbusters (UK game show)|gameshow that used to be on UK TV]]. More on topic, would it be an acceptable solution of the task if there was a single containing widget containing a grid of hexagonal active regions that can be colored/highlighted appropriately? That's much easier to implement… –[[User:Dkf|Donal Fellows]] 09:44, 26 May 2011 (UTC)
 
This task seems oddly specific. --[[User:Paul.miner|Paul.miner]] 22:40, 27 October 2012 (UTC)
:Without a definition of what a "widget" is, which goes deeply into how widgets are implemented, you are asking for a meaningless distinction. And, personally, I do no think we should be asking for that kind of definition -- I think it would be micromanagement and language-specificity of the sort we try to avoid here. --[[User:Rdm|Rdm]] 11:34, 26 May 2011 (UTC)
 
By a widget, I meant an on screen component that has its own set of properties and is capable of reacting to events.
<br>
[[User:Markhobley|Markhobley]] 16:37, 26 May 2011 (UTC)
 
: OK, that's cool. I have just the thing in mind then. (Part of the problem in the general area of GUIs is that there's no standard terminology, leading to this sort of discussion.) –[[User:Dkf|Donal Fellows]] 19:57, 26 May 2011 (UTC)
 
== Does this mean what it says? ==
 
The task page currently says "The application should now wait for the user to select a hexagon, either by using a pointing device, or by pressing a key that carries a corresponding letter on a hexagon."
 
Can this choice of input methods made at design/implementation time? (I am suspecting that the intent was that the choice only be made at runtime, but I think that that should be stated explicitly.) --[[User:Rdm|Rdm]] 16:56, 6 July 2011 (UTC)
 
:For platforms that support pointing devices and keyboards, the application should support both methods of selection. [[User:Markhobley|Markhobley]] 17:30, 6 July 2011 (UTC)