[IAEP] Working math graphs/plots

Edward Cherlin echerlin at gmail.com
Sat Dec 13 00:55:35 EST 2008


On Fri, Dec 12, 2008 at 8:50 PM, Gary C Martin <gary at garycmartin.com> wrote:
> On 13 Dec 2008, at 01:53, Edward Cherlin wrote:
>
>> On Wed, Dec 10, 2008 at 8:25 PM, Gary C Martin <gary at garycmartin.com>
>> wrote:
>>>
>>> On 11 Dec 2008, at 00:24, Edward Cherlin wrote:
>>>
>>>> On Wed, Dec 10, 2008 at 2:51 PM, Reinier Heeres <reinier at heeres.eu>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I agree that the plotting functionality is not really well exposed,
>>>>> although help(index) will show you it's available and help(plot) will
>>>>> tell you how to use it. Try plot(sin(x),x=0..360) for example. I'll
>>>>> work
>>>>> on the exposure of plotting in the next release; suggestions on how to
>>>>> do this exactly would be welcome.
>>>>
>>>> Just exposing help would go a long way to solving the problem.
>>>
>>> Help is already exposed in the hover menu for each toolbar icon. Not
>>> discoverable enough?

OK, to be brutally explicit, I want a help icon on the toolbar, with a
menu of what you can get help on.

>> Absolutely not enough. I have to wait for the menu to expand _twice_.
>> How was I supposed to discover that?
>
> You could always read the Calculate wiki page, that's where I first read
> about the plot feature ~11 months or so ago.

Don't tell me what _I_ can do. Tell me what a non-English-speaking
child in outback Cambodia without an Internet connection is supposed
to do.

> In the perfect world, every
> feature you needed at any moment would be clearly represented in the UI.
> Different individuals use software in different ways, it's always very hard
> to get this right (and it's _never_ perfect).

Imperfect I can deal with. Not there is beyond me.

>>> Seems Reinier' s Calculate has much more effort/detail
>>> put in than any other activity so far.
>>
>> That doesn't mean that he got it right. I really, really hate delayed
>> hover menus, and I hate doubly-delayed hover menus many times more.
>
> Being cheeky here... so right click and move on with life :-p

No, I hadn't discovered that, either. :-D

> (and, as a Mac
> user, you have no idea how much it pained me when I first saw the project
> was going for 2 mouse button use).

I have taught preschool children click-and-drag and right click. I
don't like them. I prefer one button, and click to grab, click to
drop. At some age, two buttons and a set of game controls, or a
programmer's third button, become practical. The question is the ratio
between effort of learning and effort saved working.

> Sometimes I like the whole concept of hover menus, sometimes I think they
> sucks. The idea is certainly going to have to be reworked (along with a
> large chunk of the existing UI) if we get Sugar to a gen 2 touch interface.

Has anybody here seen Hiroshi Ishii's Minority-Report-style UI? He
showed at at the Engelbart-fest, Program for the Future.

>> First, because they are inherently not discoverable, and secondly,
>> because you are wasting my time, and every other user's time. I reject
>> the argument that we are trying to teach children to click icons
>> directly, and note that it doesn't even apply in the case of help.
>
> For me, I always consider the need for help text (and manuals) to be a level
> of failure in design. Help texts are a large burden on everyone (quality,
> translation, UI space, updates, accuracy), but often are the cheapest first
> pass when you realise some feature not discoverable enough.
>
> Any concrete UI suggestions for calculate features (or activities** in
> general) to be more discoverable for you?

Answer given above. _Every_ option should be discoverable visually.
Forget hover. If a command must take an option, put the options on the
menu for the item and just let me click it.

> You're not allowed to add this as
> another potential FLOSS book TODO ;-) Well OK, I guess that might be a
> workaround if there's no better UI effort (and teachers like static books,
> right?).

No!!! No FLOSS Manuals for what should be obvious. Make it
sufficiently obvious, or add a tutorial, if you are going to do
non-standard things with mice and menus. No, scratch that. Just make
it obvious.

I am about to start writing digital textbooks. I need the tools to
stay out of the way so I can teach _ideas_.

> ** my latest casual discovery was that Write has customised its keep toolbar
> icon, so if you hover you can choose to keep a copy as RTF, HTML, or plain
> text. Well hidden, but this could be extended to 'keep' to all kind's of
> interesting places (i.e. push to a Moodle server, an outbound email, web
> site upload). Hopefully some Journal 'sharing'  feature will be a generic
> solution for any activity.
>
> --Gary
>
>> My general principle of UI design is, never, ever try to be smarter
>> than your user. Not even if you are. Now that I know that help is on
>> the menus on double delay, I will almost never use it that way,
>> because typing is faster, but I will resent it every time I have to
>> type it, because the menu could be faster.
>>>
>>> --Gary

-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://wiki.sugarlabs.org/go/User:Mokurai


More information about the IAEP mailing list