Home » Eclipse Projects » GEF » UI conventions
| UI conventions [message #197681] |
Wed, 05 October 2005 05:05  |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
this is not directly GEF related, but it's a logical place to post.
are there any UI guidelines/conventions for "long" tool interactions?
i'm thinking about interactions which might require multiple mouse
clicks to complete. and, for example, might popup something like an
auto-complete helper control in the middle of the interaction.
if there is no such guideline/convention doc for GEF, pointers to
equivalent docs for windows or mac or GTK, would be helpful.
regards,
al
|
|
|
| Re: UI conventions [message #197762 is a reply to message #197681] |
Wed, 05 October 2005 15:26  |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> this is not directly GEF related, but it's a logical place to post.
>
> are there any UI guidelines/conventions for "long" tool interactions?
> i'm thinking about interactions which might require multiple mouse
> clicks to complete. and, for example, might popup something like an
> auto-complete helper control in the middle of the interaction.
>
> if there is no such guideline/convention doc for GEF, pointers to
> equivalent docs for windows or mac or GTK, would be helpful.
>
> regards,
>
> al
I have avoided complex actions. if it requires a few steps, I try to
use a wizard. I never invoke a wizard when using a tool though. I used
too, but I reworked my logic so I didn't have to. try to keep things
simple for the user.
I am not familiar with any guidelines. I looked at programs that did
things similar to mine like Visio and TurboCAD, etc.
CL
|
|
|
| Re: UI conventions [message #197937 is a reply to message #197681] |
Thu, 06 October 2005 13:46 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I don't know of such interactions except for possibly creating a polygon or
bendpoints as part of creating a connection. Could you be more specific? You
might be able to get away with just changing the cursor, but that's not very
cross-platform.
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:di00oi$ro2$1@news.eclipse.org...
> this is not directly GEF related, but it's a logical place to post.
>
> are there any UI guidelines/conventions for "long" tool interactions? i'm
> thinking about interactions which might require multiple mouse clicks to
> complete. and, for example, might popup something like an auto-complete
> helper control in the middle of the interaction.
>
> if there is no such guideline/convention doc for GEF, pointers to
> equivalent docs for windows or mac or GTK, would be helpful.
>
> regards,
>
> al
|
|
|
| Re: UI conventions [message #198027 is a reply to message #197937] |
Fri, 07 October 2005 04:13 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
for example, let me give a simplified description of the tool i'd like
right now.
this needs to perform multiple selection. if this were normal multiple
selection, i could use the <shift-click>/<ctrl-click> convention.
but in this case, the order of selection is important. and the feedback
figure is (lets say) a polyline that connects specific points on the
selections in the order selected. the autocomplete helper (if there is
one) would suggest (or restrict selection to) items that could be
selected next (by highlighting them in some fashion).
it does, of course, have to do the normal source/target feedback as well.
in this thread, i'm only secondarily concerned with the mechanics of
tool implementation. this seems do-able using AbstractTool as the base.
AFAICT none of the standard tools can be extended to cover this usage
(i'd love to be wrong!).
what i am concerned with is that i not invent new usage idioms, when
others have already created good ones that have become standardized in
conventions. or to inadvertently violate existing usage semantics. egs.
in this case, i'm not certain if i should use <ctrl-click> because its
semantics (unordered selection?) are apparently violated by the interaction.
and there are other interactions down the road that will (possibly) be
more complicated. so if someone has a handbook or reference to user
interactions, i'd like to check it out :-).
Randy Hudson wrote:
> I don't know of such interactions except for possibly creating a polygon or
> bendpoints as part of creating a connection. Could you be more specific? You
> might be able to get away with just changing the cursor, but that's not very
> cross-platform.
>
|
|
|
| Re: UI conventions [message #198081 is a reply to message #198027] |
Fri, 07 October 2005 13:35 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> for example, let me give a simplified description of the tool i'd like
> right now.
>
> this needs to perform multiple selection. if this were normal multiple
> selection, i could use the <shift-click>/<ctrl-click> convention.
>
> but in this case, the order of selection is important. and the feedback
> figure is (lets say) a polyline that connects specific points on the
> selections in the order selected. the autocomplete helper (if there is
> one) would suggest (or restrict selection to) items that could be
> selected next (by highlighting them in some fashion).
>
> it does, of course, have to do the normal source/target feedback as well.
>
> in this thread, i'm only secondarily concerned with the mechanics of
> tool implementation. this seems do-able using AbstractTool as the base.
> AFAICT none of the standard tools can be extended to cover this usage
> (i'd love to be wrong!).
>
> what i am concerned with is that i not invent new usage idioms, when
> others have already created good ones that have become standardized in
> conventions. or to inadvertently violate existing usage semantics. egs.
> in this case, i'm not certain if i should use <ctrl-click> because its
> semantics (unordered selection?) are apparently violated by the
> interaction.
>
> and there are other interactions down the road that will (possibly) be
> more complicated. so if someone has a handbook or reference to user
> interactions, i'd like to check it out :-).
>
<ctrl-click> is not unordered. use ctrl-click. You can use it in
concert with a special selection tool that numers the itens as you
select them or something. But ctrl-click is definitely ordered. For
example, look at align in most graphical programs.
CL
|
|
|
| Re: UI conventions [message #198117 is a reply to message #198081] |
Fri, 07 October 2005 16:12 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
> <ctrl-click> is not unordered. use ctrl-click. You can use it in
> concert with a special selection tool that numers the itens as you
> select them or something. But ctrl-click is definitely ordered. For
> example, look at align in most graphical programs.
>
assuming <ctrl-click> is ordered, that's obviously the right answer if
you're in _normal_ selection mode.
however, if you've already selected a special tool, you're no longer in
normal selection mode, and the answer is less clear. i've seen several
programs where unordered selection in "tool-mode" is a series of normal
clicks with visual feedback in between. and the interactions i'm
thinking about are definitely tool interactions.
but i don't really want to argue about the specifics of this example,
which i just threw out. just want to know if there is a credible
reference source for such interactions.
regards,
al
|
|
|
| Re: UI conventions [message #198163 is a reply to message #198027] |
Fri, 07 October 2005 19:18 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:di4sj6$bkn$1@news.eclipse.org...
> for example, let me give a simplified description of the tool i'd like
> right now.
>
> this needs to perform multiple selection. if this were normal multiple
> selection, i could use the <shift-click>/<ctrl-click> convention.
>
> but in this case, the order of selection is important. and the feedback
> figure is (lets say) a polyline that connects specific points on the
> selections in the order selected. the autocomplete helper (if there is
> one) would suggest (or restrict selection to) items that could be selected
> next (by highlighting them in some fashion).
>
> it does, of course, have to do the normal source/target feedback as well.
OK, could you be less specific? Are you setting the Tab traversal order for
a GUI?
|
|
|
| Re: UI conventions [message #198224 is a reply to message #198163] |
Sat, 08 October 2005 02:34 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> OK, could you be less specific? Are you setting the Tab traversal order for
> a GUI?
>
No. I'm not sure I understand the relevance.
|
|
|
| Re: UI conventions [message #198336 is a reply to message #198027] |
Mon, 10 October 2005 17:53 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> this needs to perform multiple selection. if this were normal multiple
> selection, i could use the <shift-click>/<ctrl-click> convention.
> but in this case, the order of selection is important. and the feedback
As someone else said, order is maintained in selection.
> figure is (lets say) a polyline that connects specific points on the
> selections in the order selected. the autocomplete helper (if there is
> one) would suggest (or restrict selection to) items that could be selected
> next (by highlighting them in some fashion).
>
> it does, of course, have to do the normal source/target feedback as well.
>
> in this thread, i'm only secondarily concerned with the mechanics of tool
> implementation. this seems do-able using AbstractTool as the base. AFAICT
> none of the standard tools can be extended to cover this usage (i'd love
> to be wrong!).
The connection tool processes 2 separate mouse clicks. I don't see any
reason why a custom tool couldn't process more.
> what i am concerned with is that i not invent new usage idioms, when
> others have already created good ones that have become standardized in
> conventions. or to inadvertently violate existing usage semantics. egs. in
> this case, i'm not certain if i should use <ctrl-click> because its
> semantics (unordered selection?) are apparently violated by the
> interaction.
If you display the polyline as the user selects, and the order already
maintained, this sounds like it would be intuitive.
> and there are other interactions down the road that will (possibly) be
> more complicated. so if someone has a handbook or reference to user
> interactions, i'd like to check it out :-).
The only request we have had like this I think I alluded to. It is to create
bendpoints during the initial creation of a connection. This is low priority
for us so we haven't spent any time on it.
|
|
|
| Re: UI conventions [message #198393 is a reply to message #198117] |
Tue, 11 October 2005 14:20 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>> <ctrl-click> is not unordered. use ctrl-click. You can use it in
>> concert with a special selection tool that numers the itens as you
>> select them or something. But ctrl-click is definitely ordered. For
>> example, look at align in most graphical programs.
>>
>
> assuming <ctrl-click> is ordered, that's obviously the right answer
> if you're in _normal_ selection mode.
>
> however, if you've already selected a special tool, you're no longer
> in normal selection mode, and the answer is less clear. i've seen
> several programs where unordered selection in "tool-mode" is a series of
> normal clicks with visual feedback in between. and the interactions i'm
> thinking about are definitely tool interactions.
>
> but i don't really want to argue about the specifics of this
> example, which i just threw out. just want to know if there is a
> credible reference source for such interactions.
>
> regards,
>
> al
Thata all im tryin to say. the precedent that ctrl-click is ordered is
already set. The tool is not relevant, the users perspective is I
think. The user will expect selection to be resonably well behaved and
consistend regardless to the particular tool used.
I always pull up popular applications like turbocad and visio when I
want to see what the user might be used to. Perhaps you can pull up
apps similar to yours and do the same?
CL
|
|
|
| Re: UI conventions [message #198495 is a reply to message #198336] |
Wed, 12 October 2005 12:01 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
>
> The only request we have had like this I think I alluded to. It is to create
> bendpoints during the initial creation of a connection. This is low priority
> for us so we haven't spent any time on it.
>
i'm already done with the first cut at the custom tool. and in general,
this is sufficiently application specific that it's not clear if it can
be generalized into a GEF tool. i'll find out soon enough, since i need
(at least) a few different such tools.
i foresee no difficulty with the implementation. i'm more concerned
about picking the right interaction idiom.
regards,
al
|
|
|
| Re: UI conventions [message #198511 is a reply to message #198393] |
Wed, 12 October 2005 12:03 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> Thata all im tryin to say. the precedent that ctrl-click is ordered is
> already set. The tool is not relevant, the users perspective is I
> think. The user will expect selection to be resonably well behaved and
> consistend regardless to the particular tool used.
>
>
> I always pull up popular applications like turbocad and visio when I
> want to see what the user might be used to. Perhaps you can pull up
> apps similar to yours and do the same?
>
yeah, i know what you're saying. i try to do the same. unfortunately
outside of tools that are heavily used by software / web developers and
a few mass market office products, most software is extraordinarily
poorly designed.
in any case, thanks for the feedback CL.
regards,
al
|
|
|
| Re: UI conventions [message #198518 is a reply to message #198511] |
Wed, 12 October 2005 12:22 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>
>> Thata all im tryin to say. the precedent that ctrl-click is ordered
>> is already set. The tool is not relevant, the users perspective is I
>> think. The user will expect selection to be resonably well behaved
>> and consistend regardless to the particular tool used.
>>
>>
>> I always pull up popular applications like turbocad and visio when I
>> want to see what the user might be used to. Perhaps you can pull up
>> apps similar to yours and do the same?
>>
>
> yeah, i know what you're saying. i try to do the same. unfortunately
> outside of tools that are heavily used by software / web developers and
> a few mass market office products, most software is extraordinarily
> poorly designed.
>
> in any case, thanks for the feedback CL.
>
> regards,
>
> al
that may be true, but most 'improved' designes are poorly received. If
you have the opportunity to make an improved UI go for it. But even as
we speak, I play a game called eve-online, and they have shif-drag doing
copy whereas normally ctrl-drag does copy. It took me 6 months to
figure out how to do copy just because of that :(
CL
|
|
|
| Re: UI conventions [message #198568 is a reply to message #198518] |
Wed, 12 October 2005 14:18 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> that may be true, but most 'improved' designes are poorly received. If
> you have the opportunity to make an improved UI go for it. But even as
> we speak, I play a game called eve-online, and they have shif-drag doing
> copy whereas normally ctrl-drag does copy. It took me 6 months to
> figure out how to do copy just because of that :(
>
as a concrete example, in this particular case, the similar programs
that i've looked at actually do multiple selection within a _tool
context_ by repeated clicks. _not_ by <ctrl-click>. so if i use
<ctrl-click> i'm 'improving' the design of existing programs and running
the risk, as you point out, of being received poorly by users. if i
don't, i'm violating a common user-interface guideline, and what you and
Randy both suggested as the correct way to go.
however, there are people that spend all their waking hours thinking
about user interaction. there's some good stuff out there written about
it. i'm hoping that i'll find something on "long" tool interactions
somewhere. since no one on the list appears to know of such, perhaps it
doesn't exist. in which case i will have to make my own decisions on
which way to go.
regards,
al
|
|
|
| Re: UI conventions [message #198814 is a reply to message #198568] |
Wed, 12 October 2005 17:44 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>
>> that may be true, but most 'improved' designes are poorly received.
>> If you have the opportunity to make an improved UI go for it. But
>> even as we speak, I play a game called eve-online, and they have
>> shif-drag doing copy whereas normally ctrl-drag does copy. It took me
>> 6 months to figure out how to do copy just because of that :(
>>
>
> as a concrete example, in this particular case, the similar programs
> that i've looked at actually do multiple selection within a _tool
> context_ by repeated clicks. _not_ by <ctrl-click>. so if i use
> <ctrl-click> i'm 'improving' the design of existing programs and running
> the risk, as you point out, of being received poorly by users. if i
> don't, i'm violating a common user-interface guideline, and what you and
> Randy both suggested as the correct way to go.
>
> however, there are people that spend all their waking hours thinking
> about user interaction. there's some good stuff out there written about
> it. i'm hoping that i'll find something on "long" tool interactions
> somewhere. since no one on the list appears to know of such, perhaps it
> doesn't exist. in which case i will have to make my own decisions on
> which way to go.
>
> regards,
>
> al
Well there are tools that work on 1 item and there are tools that work
on an ordered set of items. And occasionally there are tools that work
on sets of items. For instance, CAD has lots of multi point things that
happen where the order of selection makes each selected item do
something different. For instance, rotate-around-point is one such
action. I this case all points are not treated the same. So its not
really a set of items. And they dont use ctrl-click.
I agree, it can get tricky. Especially when you are doing something
new. Between my TurboCAD, my AnimationMaster and my Visio I got all the
graphics interactions covered. I did at one time have a more
complicated interaction, but I reworked the whole thing so it could be
simpler. It now takes longer to do, but I think we gotta strive to keep
it simple.
Good luck m8
CL
|
|
|
Goto Forum:
Current Time: Fri Dec 27 10:27:00 GMT 2024
Powered by FUDForum. Page generated in 0.04103 seconds |
] 
Search
Help
Register
Login
Home
