| thinner palette UI when docked [message #198485] |
Wed, 12 October 2005 11:52  |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i noticed that palette UI refresh was on the TODO list for 3.2.
i'd like to vote for a skinnier bar when the palette is tucked away on
the side of the editor frame. it doesn't need to be any thicker than the
bare minimum needed to click on it. i don't think it needs the word
Palette on it either, which is currently placing a lower bound on the width.
in fact it doesn't even have to occupy the entire height of the editor
frame. a small handle or tab (possibly a figure on one of the layers)
peeking out of the edge of the editor should be enough to start a
fly-out. that would minimize the screen real estate occupied by the
palette when it's not in use.
as a compromise there could be two modes for palette use. the current
one for new users, and the minimum real-estate one for power users.
a slicker palette look-n-feel would be very nice, but IMHO optimizing
screen real-estate is a more important goal.
i know the palette can be placed in a separate view window, but IMO that
usage is not very intuitive. and ignores the important use case where
the editor window is already taking up the entire workspace area. it's
also visually unappealing since the palette width may not correspond to
the viewers width. in fact, i wouldn't care if the Palette-in-View
support was dropped entirely.
regards,
al
|
|
|
| Re: thinner palette UI when docked [message #198845 is a reply to message #198485] |
Thu, 13 October 2005 00:27  |
| Eclipse User |
|
|
|
Originally posted by: none.unknown.com
Open a feature request if you want this tracked. Getting rid of the palette
view is not an option (it was introduced since a lot of clients were
creating their own palette view). We can consider making the collapsed
flyout narrower though.
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:diitdj$f9n$1@news.eclipse.org...
> i noticed that palette UI refresh was on the TODO list for 3.2.
>
> i'd like to vote for a skinnier bar when the palette is tucked away on
> the side of the editor frame. it doesn't need to be any thicker than the
> bare minimum needed to click on it. i don't think it needs the word
> Palette on it either, which is currently placing a lower bound on the
width.
>
> in fact it doesn't even have to occupy the entire height of the editor
> frame. a small handle or tab (possibly a figure on one of the layers)
> peeking out of the edge of the editor should be enough to start a
> fly-out. that would minimize the screen real estate occupied by the
> palette when it's not in use.
>
> as a compromise there could be two modes for palette use. the current
> one for new users, and the minimum real-estate one for power users.
>
> a slicker palette look-n-feel would be very nice, but IMHO optimizing
> screen real-estate is a more important goal.
>
> i know the palette can be placed in a separate view window, but IMO that
> usage is not very intuitive. and ignores the important use case where
> the editor window is already taking up the entire workspace area. it's
> also visually unappealing since the palette width may not correspond to
> the viewers width. in fact, i wouldn't care if the Palette-in-View
> support was dropped entirely.
>
> regards,
>
> al
>
>
|
|
|
| Re: thinner palette UI when docked [message #198861 is a reply to message #198845] |
Thu, 13 October 2005 02:26 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Pratik Shah wrote:
> Open a feature request if you want this tracked. Getting rid of the palette
> view is not an option (it was introduced since a lot of clients were
> creating their own palette view). We can consider making the collapsed
> flyout narrower though.
>
where/how do i open a feature request? bugzilla?
since the main benefit of the palette view is that you don't have the
dead real-estate of the collapsed flyout, i'm guessing that the need
will go away if the suggestion i made gets incorporated. especially if
the "tab-only-collapsed-flyout" can be implemented. just a thinner
flyout may not be enough (the bulk of the height is still
non-interactive real estate).
it would certainly be worth asking clients why they wanted a palette
view in the first place. maybe i'm wrong and there's another reason.
thx,
al
|
|
|
| Re: thinner palette UI when docked [message #198954 is a reply to message #198861] |
Thu, 13 October 2005 15:55 |
| Eclipse User |
|
|
|
Originally posted by: none.unknown.com
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:dikh47$ge1$1@news.eclipse.org...
> Pratik Shah wrote:
> > Open a feature request if you want this tracked. Getting rid of the
palette
> > view is not an option (it was introduced since a lot of clients were
> > creating their own palette view). We can consider making the collapsed
> > flyout narrower though.
> >
>
> where/how do i open a feature request? bugzilla?
Yes. Mark it as an enhancement. This won't be a priority, and we might not
even address anything (except maybe the thinner collapsed flyout).
PaletteView is also beneficial for really large palettes (hundreds of
items), and some clients use it exclusively (i.e., no flyout in the editor
if the view is not there). The real estate gain from making the flyout
shorter is not going to be much (esp. if we make it narrower), and I don't
think it's best in terms of usability (do you know of any other program that
does the same?).
>
> since the main benefit of the palette view is that you don't have the
> dead real-estate of the collapsed flyout, i'm guessing that the need
> will go away if the suggestion i made gets incorporated. especially if
> the "tab-only-collapsed-flyout" can be implemented. just a thinner
> flyout may not be enough (the bulk of the height is still
> non-interactive real estate).
>
> it would certainly be worth asking clients why they wanted a palette
> view in the first place. maybe i'm wrong and there's another reason.
>
> thx,
>
> al
|
|
|
| Re: thinner palette UI when docked [message #199014 is a reply to message #198954] |
Thu, 13 October 2005 17:08 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The only change I would consider would be to place the Palette "tab" above
the vertical scrollbar.
This would require that we never display the canvas' real scrollbar, and
that we link selection of an external scrollbar to the canvas.
"Pratik Shah" <none@unknown.com> wrote in message
news:dim00m$d94$1@news.eclipse.org...
>
> "Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
> news:dikh47$ge1$1@news.eclipse.org...
>> Pratik Shah wrote:
>> > Open a feature request if you want this tracked. Getting rid of the
> palette
>> > view is not an option (it was introduced since a lot of clients were
>> > creating their own palette view). We can consider making the collapsed
>> > flyout narrower though.
>> >
>>
>> where/how do i open a feature request? bugzilla?
>
> Yes. Mark it as an enhancement. This won't be a priority, and we might
> not
> even address anything (except maybe the thinner collapsed flyout).
> PaletteView is also beneficial for really large palettes (hundreds of
> items), and some clients use it exclusively (i.e., no flyout in the editor
> if the view is not there). The real estate gain from making the flyout
> shorter is not going to be much (esp. if we make it narrower), and I don't
> think it's best in terms of usability (do you know of any other program
> that
> does the same?).
>
>>
>> since the main benefit of the palette view is that you don't have the
>> dead real-estate of the collapsed flyout, i'm guessing that the need
>> will go away if the suggestion i made gets incorporated. especially if
>> the "tab-only-collapsed-flyout" can be implemented. just a thinner
>> flyout may not be enough (the bulk of the height is still
>> non-interactive real estate).
>>
>> it would certainly be worth asking clients why they wanted a palette
>> view in the first place. maybe i'm wrong and there's another reason.
>>
>> thx,
>>
>> al
>
>
|
|
|
| Re: thinner palette UI when docked [message #199021 is a reply to message #198485] |
Thu, 13 October 2005 17:10 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
BTW, if you really want some pixels back, you should complain to platform-UI
about the 2-pixel margin around the inside of every workbench part :-)
> i'd like to vote for a skinnier bar when the palette is tucked away on
|
|
|
| Re: thinner palette UI when docked [message #199045 is a reply to message #198954] |
Thu, 13 October 2005 17:31 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> Yes. Mark it as an enhancement. This won't be a priority, and we might not
> even address anything (except maybe the thinner collapsed flyout).
> PaletteView is also beneficial for really large palettes (hundreds of
> items), and some clients use it exclusively (i.e., no flyout in the editor
> if the view is not there). The real estate gain from making the flyout
> shorter is not going to be much (esp. if we make it narrower), and I don't
> think it's best in terms of usability (do you know of any other program that
> does the same?).
>
interesting. i've never even thought about a palette with hundreds of
items.
i've not seen any programs do this with a palette. i have seen it used
to hide an edit toolbar (which served the same purpose as the palette).
i can't recall exactly which program it was (it was some kind of stock
market application), but i do remember being generally impressed by the
amount of thought that had gone into their UI design. from what i
recall, there actually was a usability issue, because i didn't find the
toolbar right away. but once i knew it was there, it was easy to find
again. so the usability is an issue only for a beginning user, but the
benefits accrue to the power user.
the real-estate gain doesn't seem like much, but every little bit helps
with the power user.
regards,
al
|
|
|
| Re: thinner palette UI when docked [message #199052 is a reply to message #199021] |
Thu, 13 October 2005 17:37 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
> BTW, if you really want some pixels back, you should complain to platform-UI
> about the 2-pixel margin around the inside of every workbench part :-)
>
didn't even know about it. if it's serving no useful purpose (overall
visual appeal is a useful purpose up to a point) it should certainly be
reclaimed.
|
|
|
| Re: thinner palette UI when docked [message #199189 is a reply to message #199014] |
Fri, 14 October 2005 05:34 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
> The only change I would consider would be to place the Palette "tab" above
> the vertical scrollbar.
> This would require that we never display the canvas' real scrollbar, and
> that we link selection of an external scrollbar to the canvas.
>
AFAIK, the vertical bar is always on the right (at least in locales
where the language is written left to right). so in order for the flyout
to remain intuitive the palette would have to be on the same side as the
vertical bar.
i personally would be OK with this option. it's not the most appealing
option visually, but it serves the purpose.
it would probably make sense to have this be a mode switch on the
palette, with the default being the current UI. as long as the expert
user has the option to switch to optimized real-estate use, it satisfies
my concerns.
actually, if the ability to switch to the expert mode was itself
programmable, i.e. an individual application could decide not to enable
it, no current programs would need to be affected at all.
the ability to link to an external scrollbar needs to be flexible
though. i've an implementation that decorates the editor with a ruler
similar to the ruler in the text editor hierarchy, i.e. it's a composite
ruler that allows an annotation area as well as a measuring ruler. it
could probably be modified to also include a scrollbar and the "palette
tab".
regards,
al
regards,
al
|
|
|
| Re: thinner palette UI when docked [message #199229 is a reply to message #199189] |
Fri, 14 October 2005 11:21 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
on further thought, i realized that there's another option. GEF could
provide a ShowPalettAction and HidePaletteAction combo. the actions
would be enabled in "expert" mode, and would cause the palette to flyout
and collapse respectively. in "beginner mode" the current UI could be used.
it would then be up to the application to decide upon the UI that would
be appropriate to run the actions.
this is not ideal, but might be preferable to having the palette flyout
"tab" always above the vertical scrollbar (which is not the most
intuitive place for it).
it also allows app developers to experiment with the UI to find one
that's intuitive for their users.
regards,
al
|
|
|
Powered by
FUDForum. Page generated in 0.03517 seconds
] 
Search
Help
Register
Login
Home
