Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
Ian.
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
On 27.04.2010, at 16:51, Levente Uzonyi wrote:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
I'd still consider it a bug that the whole menu bar resizes. Would be better if just the text field stuck out.
- Bert -
Levente,
The problem is that I don't really get it when you call this a feature. It is literally at the expense of having a coherent user interface. My understanding of the feature as you describe it is for quick evaluation, which means there should be very little reason to be able to input lengthy code. The search bar could extend on its own on print it but it would be perhaps better to have some kind of tool tip with the print out. In fact, why not inspect it rather than print it? It would mean no need to resize anything.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
I think Levente made a joke writing that the resizing behavior is a feature. It is a bug.
--Hannes
On 4/27/10, Ian Trudel ian.trudel@gmail.com wrote:
Levente,
The problem is that I don't really get it when you call this a feature. It is literally at the expense of having a coherent user interface. My understanding of the feature as you describe it is for quick evaluation, which means there should be very little reason to be able to input lengthy code. The search bar could extend on its own on print it but it would be perhaps better to have some kind of tool tip with the print out. In fact, why not inspect it rather than print it? It would mean no need to resize anything.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
On Tue, 27 Apr 2010, Hannes Hirzel wrote:
I think Levente made a joke writing that the resizing behavior is a feature. It is a bug.
Definitely not.
Levente
--Hannes
On 4/27/10, Ian Trudel ian.trudel@gmail.com wrote:
Levente,
The problem is that I don't really get it when you call this a feature. It is literally at the expense of having a coherent user interface. My understanding of the feature as you describe it is for quick evaluation, which means there should be very little reason to be able to input lengthy code. The search bar could extend on its own on print it but it would be perhaps better to have some kind of tool tip with the print out. In fact, why not inspect it rather than print it? It would mean no need to resize anything.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
OK but then it should behave more appropriately. Only the area where you actually type text should expand and not the whole bar.
--Hannes
On 4/27/10, Levente Uzonyi leves@elte.hu wrote:
On Tue, 27 Apr 2010, Hannes Hirzel wrote:
I think Levente made a joke writing that the resizing behavior is a feature. It is a bug.
Definitely not.
Levente
--Hannes
On 4/27/10, Ian Trudel ian.trudel@gmail.com wrote:
Levente,
The problem is that I don't really get it when you call this a feature. It is literally at the expense of having a coherent user interface. My understanding of the feature as you describe it is for quick evaluation, which means there should be very little reason to be able to input lengthy code. The search bar could extend on its own on print it but it would be perhaps better to have some kind of tool tip with the print out. In fact, why not inspect it rather than print it? It would mean no need to resize anything.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
> Y'all, > > I hereby demand that we rename the search bar to fun bar! 'Cause it's > a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
> > Ian. > -- > http://mecenia.blogspot.com/ >
On Tue, 27 Apr 2010, Ian Trudel wrote:
Levente,
The problem is that I don't really get it when you call this a feature. It is literally at the expense of having a coherent user interface. My understanding of the feature as you describe it is for quick evaluation, which means there should be very little reason to be able to input lengthy code. The search bar could extend on its own on print it but it would be perhaps better to have some kind of tool tip with the print out. In fact, why not inspect it rather than print it?
Because the goal of this feature is to avoid opening windows.
Levente
It would mean no need to resize anything.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
I care about the search bar. If a newbie user does what you said (typing a very long stream), then the search-bar, IMO, is behaving in a very logical and "coherent" manner. What would introduce "incoherence" would be for it to either truncate or for it to change the UI as user as is using it.
I would support if someone wants to take the trouble to only make the text-morph itself expand, beyond the bounds of the menu bar. However, I have been using a search bar like this for > 2 years, and I can tell you, sometimes you I want a one-liner, sometimes a two-liner, sometimes a cut-and-paste, sometimes a quick benchmark, sometimes a calculator, etc.
On Tue, Apr 27, 2010 at 10:08 AM, Ian Trudel ian.trudel@gmail.com wrote:
Levente,
The problem is that I don't really get it when you call this a feature. It is literally at the expense of having a coherent user interface. My understanding of the feature as you describe it is for quick evaluation, which means there should be very little reason to be able to input lengthy code. The search bar could extend on its own on print it but it would be perhaps better to have some kind of tool tip with the print out. In fact, why not inspect it rather than print it? It would mean no need to resize anything.
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Tue, 27 Apr 2010, Ian Trudel wrote:
Hi Levente,
There was a screenshot attached to my previous message. Press and hold a key in the search bar and look at your screen. The entire menu bar will grow as the characters will exceed the search bar's width and it will take over all the screen.
That's exactly what I'm talking about. It's a feature. I guess you didn't try what I suggested. So please try one of these: 0 tinyBenchmarks Smalltalk garbageCollect [ Object compileAll ] bench
It can be improved of course (by making sure that only the search bar grows and not the whole docking bar), but the feature freeze of 4.1 was too close when we added the search bar.
Levente
Ian.
2010/4/27 Levente Uzonyi leves@elte.hu:
On Mon, 26 Apr 2010, Ian Trudel wrote:
Y'all,
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
This is a feature. It lets us use the search bar as an expression evaluator. Just press Ctrl+0, type your expression and print it. You don't have to open (or find) a workspace for that.
Levente
Ian.
2010/4/28 Chris Muller asqueaker@gmail.com:
I care about the search bar. If a newbie user does what you said (typing a very long stream), then the search-bar, IMO, is behaving in a very logical and "coherent" manner. What would introduce "incoherence" would be for it to either truncate or for it to change the UI as user as is using it.
I would support if someone wants to take the trouble to only make the text-morph itself expand, beyond the bounds of the menu bar. However, I have been using a search bar like this for > 2 years, and I can tell you, sometimes you I want a one-liner, sometimes a two-liner, sometimes a cut-and-paste, sometimes a quick benchmark, sometimes a calculator, etc.
Hi Chris,
I respect your opinion. Mine is different and I'd like to elaborate a bit more. Then you can tell me what you think.
Historically, I believe Smalltalk UI does not typically provide a menu bar. Neither in Morphic, which was permanently adopted in Squeak few years ago. Morphic is a considerably less rigid UI and there is a learning curve for mainstream users. It has been decided at some point that Squeak should have a menu bar. Not my particular cup of tea. It does however introduce a familiar element to people who are unfamiliar with Morphic, Squeak and Smalltalk.
What you are telling me is that there is nothing wrong with a menu bar taking an entire screen and hiding everything below because one has typed a lengthy expression; it does not make sense to me and it won't make sense to mainstream users. Smalltalk is great because we can evaluate/print/do anything and everything absolutely everywhere. It's still called a search bar rather than an evaluation bar. Everybody are free to use the bar as they see fit but a search bar should behave as a search bar or otherwise coming off as inconsistent.
I understand that you have been using it this way for more than 2 years but there is something you have overlooked: it is now officially included in a release and by default. It means others may not use it the same way you do and others may not like it the way you do.
I don't know for other Squeakers but I always have at least one workspace to evaluate expressions. So far I have used the search bar... to search! :)
Ian.
Hi Chris,
I respect your opinion. Mine is different and I'd like to elaborate a bit more. Then you can tell me what you think.
Thanks, after reading your e-mail, I believe our opinions are more aligned than you thought..
Historically, I believe Smalltalk UI does not typically provide a menu bar. Neither in Morphic, which was permanently adopted in Squeak few years ago. Morphic is a considerably less rigid UI and there is a learning curve for mainstream users. It has been decided at some point that Squeak should have a menu bar. Not my particular cup of tea. It does however introduce a familiar element to people who are unfamiliar with Morphic, Squeak and Smalltalk.
Aye, I agree with you 100%. I've always been a proponent of Morphic, even back in the years when Seaside was exploding and Morphic was waay unpopular. I consider the 4.1 menu bar a detraction to the object-oriented nature of Squeak and Morphic. I would be so critical as to say I think it perpetuates the "wrong thinking" about OO systems because it has users going there for global "commands". However, as you said, mainstream users will feel comfortable.
What you are telling me is that there is nothing wrong with a menu bar taking an entire screen and hiding everything below because one has typed a lengthy expression; it does not make sense to me and it won't make sense to mainstream users. Smalltalk is great because we can evaluate/print/do anything and everything absolutely everywhere. It's still called a search bar rather than an evaluation bar. Everybody are free to use the bar as they see fit but a search bar should behave as a search bar or otherwise coming off as inconsistent.
I understand that you have been using it this way for more than 2 years but there is something you have overlooked: it is now officially included in a release and by default. It means others may not use it the same way you do and others may not like it the way you do.
Just to clarify: What I have been using for 2 years is actually just a TextMorph dropped on to the desktop. I found that, sometimes, I liked the "light-weightness" of just a simple TextMorph. I then discovered, by keeping a one-line TextMorph at the top of the screen, next to my WatchMorph, I had all those things I mentioned (bench, calculator, "search-bar", etc.) all quickly accessible thanks to that very nice Smalltalk property you mentioned that you can "print-it" anywhere.
So, when I pushed for the search-bar in 4.1, my goal was to carry-forward these properties.
Here is the key point behind my motivations: As you can imagine, if you were to have a "TextMorph workspace" on your desktop (as I do / did), it makes more sense to have "auto fit" turned on than off. However, if someone complains about the big size of the menu-bar in the very rare case that a "search string" extends more than one line, then someone will come up with the solution to turn off "auto fit". IMO, this would be a disaster for the utility search bar, because it loses all of those other really excellent great aforementioned properties; and all just to satisfy a "non-problem" (I say non-problem because, again, it is abnormal to type a really-long string in a search field).
So I didn't mean to send the message, there is "nothing wrong with..." the expansion. I said that it is more "coherent" to not truncate the user input than to truncate it, while also maintaining protection from neutering the wonderfully useful "print-it" power of having that up there... accessible... lurking, for newbies transitioning to power users.. :)
Kind Regards, Chris
I don't know for other Squeakers but I always have at least one workspace to evaluate expressions. So far I have used the search bar... to search! :)
Ian.
I don't know for other Squeakers but I always have at least one workspace to evaluate expressions. So far I have used the search bar... to search! :)
Forgot to mention; I have not once used the search bar to "search." e.g., I never press Return/Enter on it; only ever Command+b, m, n, p, i, etc. Having all of these different "commands" available in one spot, combined with the fact that the search bar can be used for not just input, but also for output, means that the "functional density" of the UI is, currently, pretty good. A high functional-density means a richer system, we should try to maintain that.
Chris,
I like the details you provide as well. In particular your remarks about TextMorph.
Mainstream user's feel immediately comfortable when they see a menu bar.
It is only after some time they will discover that they do not need it.
So we should maintain both paradigms. And it seems that the pragma/method annotation solution comes in handy for this purpose.
The current solution with the search box is fine for me.
--Hannes
On 4/29/10, Chris Muller ma.chris.m@gmail.com wrote:
I don't know for other Squeakers but I always have at least one workspace to evaluate expressions. So far I have used the search bar... to search! :)
Forgot to mention; I have not once used the search bar to "search." e.g., I never press Return/Enter on it; only ever Command+b, m, n, p, i, etc. Having all of these different "commands" available in one spot, combined with the fact that the search bar can be used for not just input, but also for output, means that the "functional density" of the UI is, currently, pretty good. A high functional-density means a richer system, we should try to maintain that.
Hi Chris,
I appreciate that you have taken time to reply to my message. A bit of history into how you have used TextMorph, it's very creative. :) Autofit does make sense within what you have written but not so much when it comes to search itself. Regardless, I could very well live with the feature as long as it is controlled.
Let's say, autofit should affect only the TextMorph and not the menu. Perhaps, the TextMorph should also have a maximum possible height (i.e. a bit less than half the screen?) and a scrollbar could be available when the text overflows. The TextMorph should retrofit whenever it loses focus. This is the kind of behaviour I would expect in the current approach.
Ian. -- http://mecenia.blogspot.com/
Chris Muller-4 wrote:
I consider the 4.1 menu bar a detraction to the object-oriented nature of Squeak and Morphic. I would be so critical as to say I think it perpetuates the "wrong thinking" about OO systems because it has users going there for global "commands". However, as you said, mainstream users will feel comfortable.
If we are including a menu bar as training wheels, to wean new users from decades of UI brainwashing...
Chris Muller-4 wrote:
I have not once used the search bar to "search." e.g., I never press Return/Enter on it; only ever Command+b, m, n, p, i, etc.
And power users don't even use it as a search bar, per se...
Hannes Hirzel-2 wrote:
Mainstream user's feel immediately comfortable when they see a menu bar.
It is only after some time they will discover that they do not need it.
And we hope that they will eventually give it up altogether (as I'm sure many of us do - I have a setup script that hides it in my image).
Then: I think that all this should be made really obvious. Right now, I think the message could be received as: "oh, look, even in Squeak, which is the laboratory for experimentation, they have a menu bar. It must be really solid design. I'll make sure to include one in all my apps..." This seems to be perpetuated by calling the search bar a search bar (which is a symbol that already has a (boring) definition in new users' minds coming in), when it is so much more.
Which brings us back to Ian's original comment:
Ian Trudel-2 wrote:
I hereby demand that we rename the search bar to fun bar! 'Cause it's a lot of fun. :)
What if it was called a fun bar, or everything bar, or search (and so much more) bar, or any phrase that make new users think, "hey, this is something not exactly like what I've seen before, let me investigate a little?" Combine that with obviously available info, like a ballon help or link that said: "hey, we included this for people to transition, but if you're feeling really adventurous, here is this whole new, better object-oriented way for you to handle these kinds of tasks (and maybe link to help system, web page, whatever), there would a clear road to grow and develop instead of an enabler to continue bad habits.
Sean
Sean,
We, as human being, tend to go toward familiar things and dislike change. It rarely gets boring if it is not familiar. The point is that boring is sometimes good. It is very difficult to educate people to use a system that is **too** innovative. There is such a thing as being too good.
I believe you are overestimating the power of curiosity. Curiosity has a very low threshold to hurdles. Moreover, the brain does not like inconsistencies and rejects them systematically: if it feels not right, it is not right. For the same reasons I explained in “A little 4.1 press coverage” when newcomers want to try Squeak but have to go through too many hurdles: most will give up. Being curious does not mean being interested. The curiosity will overcome hurdles only when it is accompanied by interest and potential benefits in the end.
Ian.
Ian Trudel-2 wrote:
We, as human being, tend to go toward familiar things and dislike change. It rarely gets boring if it is not familiar. The point is that boring is sometimes good. It is very difficult to educate people to use a system that is **too** innovative. There is such a thing as being too good.
Absolutely.
Ian Trudel-2 wrote:
Curiosity has a very low threshold to hurdles. Moreover, the brain does not like inconsistencies and rejects them systematically: if it feels not right, it is not right. For the same reasons I explained in “A little 4.1 press coverage” when newcomers want to try Squeak but have to go through too many hurdles: most will give up. Being curious does not mean being interested. The curiosity will overcome hurdles only when it is accompanied by interest and potential benefits in the end.
This part lost me. It sounds true, but what's the hurdle? My suggestion was: if we want a menu/search bar to ease the transition of new users into the Squeak way of doing things, why not provide them with an easily accessible hint (whether by the name of the bar, or a balloon, or whatever) as to what that way is, so that they can pursue it when and if they are interested.
This results only in the removal of a hurdle - the hurdle of knowing that there even is a better way out there, and where to look for information. Superficial adoption is what got us into the current MS/Apple mess - visitors to Xerox that noticed the UI look, without any of the revolutionary object-oriented open system.
Sean
2010/4/30 Sean P. DeNigris sean@clipperadams.com:
This part lost me. It sounds true, but what's the hurdle? My suggestion was: if we want a menu/search bar to ease the transition of new users into the Squeak way of doing things, why not provide them with an easily accessible hint (whether by the name of the bar, or a balloon, or whatever) as to what that way is, so that they can pursue it when and if they are interested.
A balloon could be a good idea but they haven't been updated to the current look. The concept may not sink it quickly: "Smalltalk expressions can be evaluated in the search bar." Most programmers have no notion of dynamic environment and they are used to write-compile-run cycles. The workspace seems to be a better place to get this concept understood. But, hey, a balloon is fine too.
We could also consider having some kind of "Tip of the Day" with various tips. It's not contextual as a balloon but it could bring something to newcomers.
This results only in the removal of a hurdle - the hurdle of knowing that there even is a better way out there, and where to look for information. Superficial adoption is what got us into the current MS/Apple mess - visitors to Xerox that noticed the UI look, without any of the revolutionary object-oriented open system.
This is a very interesting comment. It's not the first time superficial got someone into troubles. Isn't it? :))
Sean
Ian.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
Hannes Hirzel -
Ian Trudel -
Levente Uzonyi -
Sean P. DeNigris