Hi,

On 23.03.2015, at 16:26, Ben Coman <btc at openinworld.com> wrote:

> 
> On Mon, Mar 23, 2015 at 10:00 PM, Marcel Taeumel <marcel.taeumel at student.hpi.uni-potsdam.de> wrote:
> According so Shneiderman [1, p.445], simple but frequent tasks should take no
> longer than 1 second. Personally, I find this too long for opening a context
> menu. Let us shoot for at most 500 milliseconds. Now bench. Where are we?
> 
> If it lies within scope, let us favor this flexible programming interface
> instead of performance improvements that many users will not
> notice/appreciate here.
> 
> [1] Shneiderman. "Designing the User Interface". 5th Edition. Pearson. 2010.
> 
> Jakob Nielsen was the reference text for my undergraduate Human Computer Interaction course...
> http://www.nngroup.com/articles/response-times-3-important-limits/
> 
> * 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
> 
> * 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
> 
> * 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect. 
> 
> Context menus should feel instantaneous.
> cheers -ben

So I did a quick bench for 
	"Open the context menu for the messages list in a browser"
by emulating #getMenu: of PuggableListMorph/ScrollPane like this:

	| browser |
	browser := Browser new.
	browser selectSystemCategory: browser class category.
	browser selectClass: browser class.
	browser messageCategoryListIndex: 1.
	browser messageListIndex: 1.
	[ 
		| aMenu aTitle |
		aTitle := nil.
		aMenu := MenuMorph new defaultTarget: browser.
		browser perform: #messageListMenu:shifted: with: aMenu with: false.
		aTitle ifNotNil:  [aMenu addTitle: aTitle].
	] bench

For the trunk I get:	'7,070 per second. 141 microseconds per run.'
For my version I get:	'2,630 per second. 381 microseconds per run.'

Yes, it is slower, but we are long away from noticeable effects on the UI, I'd say.
Are there still objections?

Best
	-Tobias