Tiny enhancement: pressing letter in Conf Maps Browser

Hi,

I sometimes feel like what I just encountered and makes things even a tiny bit more complicated that I'd like, I need to write a feature request. This is one of these ;-)

If you open a Conf Map Browser (Or App Manager), and you want to navigate to a Config Map by pressing its name's first letter, the Browser should scroll in a way so that the first map with this initial letter is the first in the list, not the last.

To understand better what I mean, try this: say you want to load the Config Map named "Modelling". The usual thing you'd probably do is open the conf map browser and simply press "M" on your keyboard. The Browser will scroll down far enough to show the first "Mastering Envy ..." Map as the very last in the list. This is just a tiny stupid thing. I told the browser I am looking for a map starting with M and this guy just scrolls far enough down to show me the first one, instead of showing me all that I can choose from.

I know I can press M multiple times and it will scroll down 1 item with each key press.

Unfortunately, my right hand has already started reaching out for the mouse when I remember. So I have to either go back to the keyboard to press M often enough to get to the one, or (my choice most of the time) first click on the scrollbar on the conf maps list, find the one I want and click on it.

My suggested improvement is really a tiny thing, but makes working with the conf map browser a little better. This may sound ridiculous, and there sure is no justification to invest any time in this improvemend at first sight.

OTOH, there are many of these seemingly irrelevant bits that cost a few hundred clicks or key presses a day and disrupt my train of thought, if only for the blink of an eye.

I am not really asking Instantiations to fix this right now. I am trying to show that an overhaul of VAST with a UX perspective can make the tool so much better. 50 or 100 of these tiny things that each go out of my way make my day significantly more productive - and I won't probably even realize it because the tool just works the way I need it to ;-)

Joachim

... I forgot to mention that if that scrolling happens upwards (say I currently see Maps starting with the letter z), the scrolling is much better: the first one with my letter will be third in the list. Not sure if that is intended or by random. Didn't take the time to look into it.

Joachim

Hi Joachim,

Hi Joachim & Seth,

Actually...I see the scroll jumping algo in Windows Explorer will try and make the bottom item (once it's reached) the top item if it can.

Hi Seth,

first, I am happy you didn't just go ahead rolling your eyes. There's enough important stuff to do, I guess. I will try playing with your code change, but can already see how much we'll be in agreement that it's not geood enough. Just as you say, consecutive key presses should not immediately reposition the list pane as long as the next item is still in the viewport.

Here in Germany we have a saying: "if you lift one corner of the carpet, it's almost sure you'll find a lot of dirt and will have to remove it completely to get things cleaned". I think UX topics are the same here. So let's not get started discussing about tab navigation between panes in Browsers, arrow keys, optional drag&drop and stuff.... ;-)

So I mostly wanted to add another mosaic piece to a list of arguments for more focus on the usability of VAST (and, almost more important, its GUI widgets that will be used by our users/customers).

Joachim



Am Samstag, 15. Oktober 2016 15:48:56 UTC+2 schrieb Seth Berman:

Hi Joachim,

This is ok...but I don't like how the selection sticks to the top item....it's disorienting when there are multiple items starting with the same letter and is always adjusting both the selection and view on every keypress (unless your at the bottom).

I think it should behave more like windows explorer which would be to

1. Make the initial selection the top item.
2. Consecutive selections with the same starting letter are selected...but the if they are in view...the viewport is not scrolled.
3. Once the last item in the viewport is reached...the viewport is scrolled such that the item shows in the middle of the viewport (in general..obviously there are boundary conditions at the bottom)

Minimizing scrolling while maximizing the number of items with the same letter seems to make the most sense to me.

When looking at GTK Linux based "explorers"...I see they choose the bottom item...but they have a special text box that comes up to the side where you are typing the name of what you are looking for....they don't seem to use the concept of pressing the same letter multiple times to scroll through a list.

-- Seth

On Saturday, October 15, 2016 at 9:24:45 AM UTC-4, Seth Berman wrote:

Hi Joachim,

Change the last few lines in EtWindow>>stsFindItem:clientData:callData:
to the following and run with that for awhile to see how you like it.

found isNil

ifFalse: [

widget

deselectAllItems;

selectPos: found notify: true;

topItemPosition: found]

 

On Saturday, October 15, 2016 at 4:58:17 AM UTC-4, Joachim Tuchel wrote:

... I forgot to mention that if that scrolling happens upwards (say I currently see Maps starting with the letter z), the scrolling is much better: the first one with my letter will be third in the list. Not sure if that is intended or by random. Didn't take the time to look into it.

Joachim

Lou,

I guess it's worth more than you think. And I hope these things all land on some to-do-list at Instantiations (I am sure they do).
 
We are all in the same boat here: long-time users that have educated themselves in getting along with these little inaccuracies and "strangenesses". So sometimes it is good to take a step back and look at these things that you've learned to get along with. How much better would things work if it just worked as expected, especially for people working with VAST for the first time (yes, such people exist, I teach new Smalltalkers in VAST from time to time).

Just think of Scintilla and code assist.. We've accepted that syntax highlighting, code completion, folding and numbering etc. are not so important for Smalltalk Browsers, because we all write short methods and the language is so super easy. Until we had all of that in our tool and saw how much it improved our productivity. Every time I have to work on code in 7.5 or 6.0, it feels painful and I can hardly understand I could work with that for almost 2 decades....

It sure is a lot of work to implement such improvements, but they have a big impact on prooductivity. Even seemingly tiny things like saving me a click in some job I have to do a few dozen times a day makes a difference.

Joachim


Am Samstag, 15. Oktober 2016 15:41:18 UTC+2 schrieb Louis LaBrunda:

Hi Joachim & Seth,

+1 from me for what it is worth.  Also, in some browsers, I don't remember which at the moment, the focus is somewhere other then the list on the left and if you type the first letter, you change something you don't want to change and have to back out of the change and get to the list to find what you are looking for.

Lou

On Saturday, October 15, 2016 at 4:52:30 AM UTC-4, Joachim Tuchel wrote:

Hi,

I sometimes feel like what I just encountered and makes things even a tiny bit more complicated that I'd like, I need to write a feature request. This is one of these ;-)

If you open a Conf Map Browser (Or App Manager), and you want to navigate to a Config Map by pressing its name's first letter, the Browser should scroll in a way so that the first map with this initial letter is the first in the list, not the last.

To understand better what I mean, try this: say you want to load the Config Map named "Modelling". The usual thing you'd probably do is open the conf map browser and simply press "M" on your keyboard. The Browser will scroll down far enough to show the first "Mastering Envy ..." Map as the very last in the list. This is just a tiny stupid thing. I told the browser I am looking for a map starting with M and this guy just scrolls far enough down to show me the first one, instead of showing me all that I can choose from.

I know I can press M multiple times and it will scroll down 1 item with each key press.

Unfortunately, my right hand has already started reaching out for the mouse when I remember. So I have to either go back to the keyboard to press M often enough to get to the one, or (my choice most of the time) first click on the scrollbar on the conf maps list, find the one I want and click on it.

My suggested improvement is really a tiny thing, but makes working with the conf map browser a little better. This may sound ridiculous, and there sure is no justification to invest any time in this improvemend at first sight.

OTOH, there are many of these seemingly irrelevant bits that cost a few hundred clicks or key presses a day and disrupt my train of thought, if only for the blink of an eye.

I am not really asking Instantiations to fix this right now. I am trying to show that an overhaul of VAST with a UX perspective can make the tool so much better. 50 or 100 of these tiny things that each go out of my way make my day significantly more productive - and I won't probably even realize it because the tool just works the way I need it to ;-)

Joachim

Hi Guys,

Hi Joachim,

Thanks a lot, Seth!

Am Montag, 17. Oktober 2016 21:21:56 UTC+2 schrieb Seth Berman:

Hi Joachim,

I'm always happy to hear feedback, to include suggestions for improvements, so you can be sure my response is never to roll my eyes:)

You have done a good job explaining the issue and it seems like a good usability improvement to consider.
I will make note of it.

On Sunday, October 16, 2016 at 1:43:15 AM UTC-4, Joachim Tuchel wrote:

Hi Seth,

first, I am happy you didn't just go ahead rolling your eyes. There's enough important stuff to do, I guess. I will try playing with your code change, but can already see how much we'll be in agreement that it's not geood enough. Just as you say, consecutive key presses should not immediately reposition the list pane as long as the next item is still in the viewport.

Here in Germany we have a saying: "if you lift one corner of the carpet, it's almost sure you'll find a lot of dirt and will have to remove it completely to get things cleaned". I think UX topics are the same here. So let's not get started discussing about tab navigation between panes in Browsers, arrow keys, optional drag&drop and stuff.... ;-)

So I mostly wanted to add another mosaic piece to a list of arguments for more focus on the usability of VAST (and, almost more important, its GUI widgets that will be used by our users/customers).

Joachim



Am Samstag, 15. Oktober 2016 15:48:56 UTC+2 schrieb Seth Berman:

Hi Joachim,

This is ok...but I don't like how the selection sticks to the top item....it's disorienting when there are multiple items starting with the same letter and is always adjusting both the selection and view on every keypress (unless your at the bottom).

I think it should behave more like windows explorer which would be to

1. Make the initial selection the top item.
2. Consecutive selections with the same starting letter are selected...but the if they are in view...the viewport is not scrolled.
3. Once the last item in the viewport is reached...the viewport is scrolled such that the item shows in the middle of the viewport (in general..obviously there are boundary conditions at the bottom)

Minimizing scrolling while maximizing the number of items with the same letter seems to make the most sense to me.

When looking at GTK Linux based "explorers"...I see they choose the bottom item...but they have a special text box that comes up to the side where you are typing the name of what you are looking for....they don't seem to use the concept of pressing the same letter multiple times to scroll through a list.

-- Seth

On Saturday, October 15, 2016 at 9:24:45 AM UTC-4, Seth Berman wrote:

Hi Joachim,

Change the last few lines in EtWindow>>stsFindItem:clientData:callData:
to the following and run with that for awhile to see how you like it.

found isNil

ifFalse: [

widget

deselectAllItems;

selectPos: found notify: true;

topItemPosition: found]

 

On Saturday, October 15, 2016 at 4:58:17 AM UTC-4, Joachim Tuchel wrote:

... I forgot to mention that if that scrolling happens upwards (say I currently see Maps starting with the letter z), the scrolling is much better: the first one with my letter will be third in the list. Not sure if that is intended or by random. Didn't take the time to look into it.

Joachim

Seth,

I've been using this for a while now and have to agree. The scrolling behavior is not really much more pleasant. The second and consecutive hits are always visible, that is a plus. But scrolling the list for every conscutive hit is not good.

So I guess there is not much point in integrating this "halfway" solution into the product other than because it is a tiny bit better.

Joachim


Am Samstag, 15. Oktober 2016 15:48:56 UTC+2 schrieb Seth Berman:

Hi Joachim,

This is ok...but I don't like how the selection sticks to the top item....it's disorienting when there are multiple items starting with the same letter and is always adjusting both the selection and view on every keypress (unless your at the bottom).

I think it should behave more like windows explorer which would be to

1. Make the initial selection the top item.
2. Consecutive selections with the same starting letter are selected...but the if they are in view...the viewport is not scrolled.
3. Once the last item in the viewport is reached...the viewport is scrolled such that the item shows in the middle of the viewport (in general..obviously there are boundary conditions at the bottom)

Minimizing scrolling while maximizing the number of items with the same letter seems to make the most sense to me.

When looking at GTK Linux based "explorers"...I see they choose the bottom item...but they have a special text box that comes up to the side where you are typing the name of what you are looking for....they don't seem to use the concept of pressing the same letter multiple times to scroll through a list.

-- Seth

On Saturday, October 15, 2016 at 9:24:45 AM UTC-4, Seth Berman wrote:

Hi Joachim,

Change the last few lines in EtWindow>>stsFindItem:clientData:callData:
to the following and run with that for awhile to see how you like it.

found isNil

ifFalse: [

widget

deselectAllItems;

selectPos: found notify: true;

topItemPosition: found]

 

On Saturday, October 15, 2016 at 4:58:17 AM UTC-4, Joachim Tuchel wrote:

... I forgot to mention that if that scrolling happens upwards (say I currently see Maps starting with the letter z), the scrolling is much better: the first one with my letter will be third in the list. Not sure if that is intended or by random. Didn't take the time to look into it.

Joachim

Hi Joachim,

On Thursday, October 27, 2016 at 1:51:03 PM UTC-7, Seth Berman wrote:

Hi Joachim,

Agreed...thanks for trying it and the feedback.

-- Seth

On Thursday, October 27, 2016 at 2:06:40 AM UTC-4, Joachim Tuchel wrote:

Seth,

I've been using this for a while now and have to agree. The scrolling behavior is not really much more pleasant. The second and consecutive hits are always visible, that is a plus. But scrolling the list for every conscutive hit is not good.

So I guess there is not much point in integrating this "halfway" solution into the product other than because it is a tiny bit better.

Joachim


Am Samstag, 15. Oktober 2016 15:48:56 UTC+2 schrieb Seth Berman:

Hi Joachim,

This is ok...but I don't like how the selection sticks to the top item....it's disorienting when there are multiple items starting with the same letter and is always adjusting both the selection and view on every keypress (unless your at the bottom).

I think it should behave more like windows explorer which would be to

1. Make the initial selection the top item.
2. Consecutive selections with the same starting letter are selected...but the if they are in view...the viewport is not scrolled.
3. Once the last item in the viewport is reached...the viewport is scrolled such that the item shows in the middle of the viewport (in general..obviously there are boundary conditions at the bottom)

Minimizing scrolling while maximizing the number of items with the same letter seems to make the most sense to me.

When looking at GTK Linux based "explorers"...I see they choose the bottom item...but they have a special text box that comes up to the side where you are typing the name of what you are looking for....they don't seem to use the concept of pressing the same letter multiple times to scroll through a list.

-- Seth

On Saturday, October 15, 2016 at 9:24:45 AM UTC-4, Seth Berman wrote:

Hi Joachim,

Change the last few lines in EtWindow>>stsFindItem:clientData:callData:
to the following and run with that for awhile to see how you like it.

found isNil

ifFalse: [

widget

deselectAllItems;

selectPos: found notify: true;

topItemPosition: found]

 

On Saturday, October 15, 2016 at 4:58:17 AM UTC-4, Joachim Tuchel wrote:

... I forgot to mention that if that scrolling happens upwards (say I currently see Maps starting with the letter z), the scrolling is much better: the first one with my letter will be third in the list. Not sure if that is intended or by random. Didn't take the time to look into it.

Joachim