2011/8/9 Stéphane Ducasse <[email protected]>: > Hi > > I would like that we do an analysis of what should stay in implementors > > Here are the menus in 1.2 and 1.4 >
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method. In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'. That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n - if the message is multiple keyword, then this won't work... I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation. To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge > Please comment so that we can add what is really used. > As a general comment I would avoid to do everything with a single tool. > Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no? > Stef > > >
