6 May
2015
6 May
'15
4:39 p.m.
On 06 May 2015, at 16:18, Ben Coman
<btc(a)openinworld.com> wrote:
On Wed, May 6, 2015 at 9:17 PM, Esteban Lorenzano <estebanlm(a)gmail.com
<mailto:estebanlm@gmail.com>> wrote:
no, I meant “context menu” the ones that appear by right clicking.
in other stuff, I agree 100% with what you said.
just also: is not about taste (“I prefer”), this is really studied (human-computer
interaction)… and visual accessing is really important.
Esteban
On 06 May 2015, at 15:05, Tudor Girba
<tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
I would like to still be careful about those contextual actions and not mix the global
with the contextual ones.
I know.
But common sense is to have all possible actions in a tool with a visible representation
(in toolbars, menus, others). Functionality accessible *just* through the contextual
menus
Just confirming I read this right, by "contextual menus" you don't mean
right-click "context menus" but menus that change their visible menu items per
the theme of the rest of your post. I have a strong preference for not hiding menu items,
just disabling them. It helps discoverability. If its disabled, I can google the term
for how-to use/enable it. If I can't see it, I'm blind, and if it appears, its a
surprise - and surprises are not good in UI design.
btw, some discussion here...
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=…
<http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=94078>
cheers -ben
are not good (and you will see no serious GUI design guidelines recommend it… quite the
oposite).
One example: I made a configurations browser replacement. It shows all packages in a
list, with tags for filtering and another pane to show descriptions (btw… a readonly text
panel also would be ok)…
Now, by selecting a configuration and right clicking, you can install it.
This is plain wrong.
Why?
Because the main purpose of such tool is to allow users to install.
So by making them live just in the context menu you are hiding (or at least making not
obvious) the main interaction the tool has as a purpose.
Btw… I already reported this like 3 years ago, when I used Glamour to doing real life
apps. This was the first observation I had each time I explained the system to users.
At the moment, I just made my extensions.
But now I’m making tools for Pharo, so I cannot just extend.
@Esteban: do you need these for lists or other presentations?
Lists, Tables, Trees… anything that can have a contextual menu with important
interactions.
Esteban
Cheers,
Doru
On Wed, May 6, 2015 at 2:58 PM, Andrei Chis <chisvasileandrei(a)gmail.com
<mailto:chisvasileandrei@gmail.com>> wrote:
On Wed, May 6, 2015 at 11:50 AM, Esteban Lorenzano <estebanlm(a)gmail.com
<mailto:estebanlm@gmail.com>> wrote:
honestly, right now I can “tolerate” not having it… probably in the future I will need
it, but I’ll let you know.
Right now, in fact, I would like to propose a fix for:
- toggle action in toolbars
- selection visible actions in toolbars (the ones that appears also when right clicking,
for example… I want some of them to be also visible in the toolbar, but enabled/disabled
according necessity)
AFAIS, both are needed to achieve what I want on the tools I made: all important options
should be always visible.
will you accept a contribution in this sense?
Definitely :)
Just one comment about selection visible actions in toolbars. Right now the purpose of
the toolbar is to show actions that apply on the entire presentation.
Adding actions here that depend on the selection would complicate things. Still as long
as those actions do not disappear, but get disabled it could work.
Cheers,
Andrei
Esteban
> On 05 May 2015, at 22:13, Andrei Chis <chisvasileandrei(a)gmail.com
<mailto:chisvasileandrei@gmail.com>> wrote:
>
> There is no dedicated presentation for having an input text.
> Lists and tree presentations can have an input text at the bottom for
filtering/searching.
>
> The closest solution would be to maybe have a pane fixed width in a tabulator and
them add a text area inside that pane.
> It would look sort of like a text input, but I'm not sure how well it would work
for you.
>
> If the above doesn't work and you really need a text input we can add one :)
>
> Cheers,
> Andrei
>
> On Tue, May 5, 2015 at 6:48 PM, Esteban Lorenzano <estebanlm(a)gmail.com
<mailto:estebanlm@gmail.com>> wrote:
> Since GLMInputTextPresentation (or how it was called, I forget it) is gone, and
actually was never there…
> how can I have the equivalent? I’m sure you had the problem in which you need some…
how do you solve it?
>
> Esteban
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev