On 11/25/2009 12:49:30 PM, Richard Jackson wrote:
On 11/24/2009 7:07:18 PM, Stuart Bruff wrote:
> I've already posted
>some thoughts on 'boxes' (although I
>called them Rectangular Areas). I
>envisaged that they would act slightly
>differently to the way Spirit implements
>Solve boxes, eg
>see thread
>http://collab.mathsoft.com/read?114150,1
>2
== I had forgotten about that discussion. I have also asked for extending the capabilities of areas, including locally scoped variables and inputs/outputs. Allowing those extra keywords inside areas would be useful too. I think it's a different topic to this one though (but closely related, of course).
I don't think it is a different topic - under the proposed scheme, the concept of a local variable is different to that which I proposed.
I would like a 'Box' (ie, scope-bounded rectangular Area) to have the ability to change and define 'higher-level' names (eg, variables and functions). This would mean retaining the distinction between a local and normal define. For example, in one of the attached images, I define a Fibonacci function that uses a call to an auxiliary function. I would like to be able restrict the scope of the auxiliary function to the Box, whilst allowing subsequent access at worksheet level to the main function.
*** As an aside, it would be interesting to see how the proposed Spirit Box handles local function definitions. ***
I would like flexibility in the way that the programming constructs can be arranged so as to allow standard 2D arrangement of regions. The proposed scheme may allow this (although it does give the impression of a vertical structure); however, whilst notationally simpler, the use of a brace as a common block terminator could lead to even more confusion in trying to match the beginning of a loop or conditional.
In addition, I would like to see the ability to loop over a section of a worksheet - probably the most requested feature across all experience levels. I'm not sure whether the proposed programming model would allow this - If it is fairly freeform, then it should be possible to just create one Box which would effectively *be* the worksheet - in which case, why not extend the capability to the top level?
I've a feeling, given that a spec exists, that we're going to end up with something that is compromised before it even gets off the ground. Deja vu 😞
Stuart
-----------------------
Standard Program Layout
-----------------------
-----------------------
Free form Box layout - explicit return
-----------------------
-----------------------
Side-by-side independent Boxes
-----------------------
-----------------------
Local v worksheet level definition
-----------------------
-----------------------
Indented Loop structure
-----------------------
-----------------------
One line 2D structure
-----------------------
On 11/24/2009 7:07:18 PM, Stuart Bruff wrote:
> I've already posted
>some thoughts on 'boxes' (although I
>called them Rectangular Areas). I
>envisaged that they would act slightly
>differently to the way Spirit implements
>Solve boxes, eg
>see thread
>http://collab.mathsoft.com/read?114150,1
>2
== I had forgotten about that discussion. I have also asked for extending the capabilities of areas, including locally scoped variables and inputs/outputs. Allowing those extra keywords inside areas would be useful too. I think it's a different topic to this one though (but closely related, of course).
I don't think it is a different topic - under the proposed scheme, the concept of a local variable is different to that which I proposed.
I would like a 'Box' (ie, scope-bounded rectangular Area) to have the ability to change and define 'higher-level' names (eg, variables and functions). This would mean retaining the distinction between a local and normal define. For example, in one of the attached images, I define a Fibonacci function that uses a call to an auxiliary function. I would like to be able restrict the scope of the auxiliary function to the Box, whilst allowing subsequent access at worksheet level to the main function.
*** As an aside, it would be interesting to see how the proposed Spirit Box handles local function definitions. ***
I would like flexibility in the way that the programming constructs can be arranged so as to allow standard 2D arrangement of regions. The proposed scheme may allow this (although it does give the impression of a vertical structure); however, whilst notationally simpler, the use of a brace as a common block terminator could lead to even more confusion in trying to match the beginning of a loop or conditional.
In addition, I would like to see the ability to loop over a section of a worksheet - probably the most requested feature across all experience levels. I'm not sure whether the proposed programming model would allow this - If it is fairly freeform, then it should be possible to just create one Box which would effectively *be* the worksheet - in which case, why not extend the capability to the top level?
I've a feeling, given that a spec exists, that we're going to end up with something that is compromised before it even gets off the ground. Deja vu 😞
Stuart
-----------------------
Standard Program Layout
-----------------------
-----------------------
Free form Box layout - explicit return
-----------------------
-----------------------
Side-by-side independent Boxes
-----------------------
-----------------------
Local v worksheet level definition
-----------------------
-----------------------
Indented Loop structure
-----------------------
-----------------------
One line 2D structure
-----------------------
On 11/29/2009 1:30:54 PM, Richard Jackson wrote:
>> On 11/29/2009 12:36:06 PM, Stuart Bruff wrote:
>> I believe, based on previous experience, that there should be an exceptional case or denying a user the capability to do something, no matter how confusing it *could* be. Do I need to mention SUC?
== In general, I agree with you. SUC is a bad example though, because they decided not to allow users to turn it off only because they couldn't think of a reason to do so, not because they thought of a reason why it would lead to significant problems.
My understanding is different. They had been given reasons why SUC could cause problems before release, and they certainly knew early on in M12's release, but it's only in Prime do we see a reversion to reality. SUC was there in the first place to stop the users playing with sharp edges - not a good move when some of the users like metaphorically fixing bayonets, or carrying out surgery, or even doing a bit of cookery in the kitchen.
== In this case if you make it easy for the user to make a program look like a part of the worksheet (either by turning off the box, or by making the box the same as a text region border, or whatever) there is absolutely no question that users will do it, and get themselves into a lot of trouble.
As amply demonstrated on the Collab, users can get themselves into a lot of trouble doing the Mathcad equivalent of tieing their shoelaces. However, I'm an optimist in that I think people can learn from their mistakes and avoid such things. We have similar little quirks throughout Mathcad (eg, literal v indicial subscripting) but it clicks eventually. Part of the advantage Mathcad's appeal is its presentation (much though it needs improving) and I wouldn't wish to find myself contrained in how *I* organize my worksheets by the need to stop a beginner or infrequent user getting a paper cut. As with subscripts, clicking on a region should show what it is and its scope, so users with access to the worksheet should be able to sort things out readily enough. If the default out-of-the-box template has Box borders on, then it would require a deliberate act to turn them off, at which point it should be caveat emptor.
I attach four examples of Boxes (emulated using text regions), only one of which has bordered Boxes. The existence of the actual boundaries should act to give a reasonable visual discrimination between parallel Boxes, and I suspect one would have to go out of the way to make it very confusing.
>== For example, consider page breaks and right-hand margins - many of use want to be able to turn them OFF from view as they are annoying at times. Perhaps we never intend to print a certain worksheet. The developers have these lines in Mathcad 14 hard coded in
That bit's not my quote.
== If you allow a user to do something you have to weigh the benefits vs the potential problems. If the potential problems are small, then the user should be allowed to do it, even if the benefit is not obvious. This philosophy would allow SUC to be turned off,
But SUC was introduced to stop users having problems with units; given the time and investment put into it, the potential problems of turning SUC off were not seen as small.
== as well as page breaks, etc. But if the potential problems are really large, and the benefits appear to be small, then stopping the user from doing something may be the best choice.
Appear small to who? I'm firmly of the opinion that restrictions should be minimal until it demonstrated to be a significant problem. Only then should the screws be tightened down, and preferably in a way that allows the more expert users to loosen them. For example, a Preferences tab, similar to the Grammar setting in Word, that allows the user to set the degree of 'strictness'.
==At a minimum, it should be made very difficult for the user to get themselves into such trouble. If you make it easy for a user to get themselves into huge amounts of trouble, then they will, and it will often be the beginners
See above. Beginners sometimes grow up to have ideas above their station and then start complaining because they can't do what they want 🙂
Stuart
-----------------------
Bordered Boxes
-----------------------
-----------------------
Borderless Boxes
-----------------------
-----------------------
Borderless, Highlighted Boxes
-----------------------
-----------------------
Borderless Boxes + Vertical Separator
-----------------------
>> On 11/29/2009 12:36:06 PM, Stuart Bruff wrote:
>> I believe, based on previous experience, that there should be an exceptional case or denying a user the capability to do something, no matter how confusing it *could* be. Do I need to mention SUC?
== In general, I agree with you. SUC is a bad example though, because they decided not to allow users to turn it off only because they couldn't think of a reason to do so, not because they thought of a reason why it would lead to significant problems.
My understanding is different. They had been given reasons why SUC could cause problems before release, and they certainly knew early on in M12's release, but it's only in Prime do we see a reversion to reality. SUC was there in the first place to stop the users playing with sharp edges - not a good move when some of the users like metaphorically fixing bayonets, or carrying out surgery, or even doing a bit of cookery in the kitchen.
== In this case if you make it easy for the user to make a program look like a part of the worksheet (either by turning off the box, or by making the box the same as a text region border, or whatever) there is absolutely no question that users will do it, and get themselves into a lot of trouble.
As amply demonstrated on the Collab, users can get themselves into a lot of trouble doing the Mathcad equivalent of tieing their shoelaces. However, I'm an optimist in that I think people can learn from their mistakes and avoid such things. We have similar little quirks throughout Mathcad (eg, literal v indicial subscripting) but it clicks eventually. Part of the advantage Mathcad's appeal is its presentation (much though it needs improving) and I wouldn't wish to find myself contrained in how *I* organize my worksheets by the need to stop a beginner or infrequent user getting a paper cut. As with subscripts, clicking on a region should show what it is and its scope, so users with access to the worksheet should be able to sort things out readily enough. If the default out-of-the-box template has Box borders on, then it would require a deliberate act to turn them off, at which point it should be caveat emptor.
I attach four examples of Boxes (emulated using text regions), only one of which has bordered Boxes. The existence of the actual boundaries should act to give a reasonable visual discrimination between parallel Boxes, and I suspect one would have to go out of the way to make it very confusing.
>== For example, consider page breaks and right-hand margins - many of use want to be able to turn them OFF from view as they are annoying at times. Perhaps we never intend to print a certain worksheet. The developers have these lines in Mathcad 14 hard coded in
That bit's not my quote.
== If you allow a user to do something you have to weigh the benefits vs the potential problems. If the potential problems are small, then the user should be allowed to do it, even if the benefit is not obvious. This philosophy would allow SUC to be turned off,
But SUC was introduced to stop users having problems with units; given the time and investment put into it, the potential problems of turning SUC off were not seen as small.
== as well as page breaks, etc. But if the potential problems are really large, and the benefits appear to be small, then stopping the user from doing something may be the best choice.
Appear small to who? I'm firmly of the opinion that restrictions should be minimal until it demonstrated to be a significant problem. Only then should the screws be tightened down, and preferably in a way that allows the more expert users to loosen them. For example, a Preferences tab, similar to the Grammar setting in Word, that allows the user to set the degree of 'strictness'.
==At a minimum, it should be made very difficult for the user to get themselves into such trouble. If you make it easy for a user to get themselves into huge amounts of trouble, then they will, and it will often be the beginners
See above. Beginners sometimes grow up to have ideas above their station and then start complaining because they can't do what they want 🙂
Stuart
-----------------------
Bordered Boxes
-----------------------
-----------------------
Borderless Boxes
-----------------------
-----------------------
Borderless, Highlighted Boxes
-----------------------
-----------------------
Borderless Boxes + Vertical Separator
-----------------------
On 11/29/2009 11:57:09 AM, Stuart Bruff wrote:
>That problem already exists with
>embedding math regions in a text region.
That's true, it does. It's what made me think about having two anchor points. Now I realize that doesn't solve the problem though, it just changes it. If the "out" anchor point were at the bottom right, this would work the way it appears:
(the a:=1 assignment is of course in a text box)
but unfortunately, this then would not:
Richard
>That problem already exists with
>embedding math regions in a text region.
That's true, it does. It's what made me think about having two anchor points. Now I realize that doesn't solve the problem though, it just changes it. If the "out" anchor point were at the bottom right, this would work the way it appears:
(the a:=1 assignment is of course in a text box)
but unfortunately, this then would not:
Richard
