Hi, This is indeed long and I am unable to read this now. It might take a while to get to reply.
Cheers, Doru > On Jan 20, 2016, at 10:39 AM, David Allouche <[email protected]> wrote: > > Since you asked to keep challenging… > > Preamble: Sorry, I did one of those long messages again. I hope I am not > annoying people with that. > >> On 19 Jan 2016, at 22:40, Tudor Girba <[email protected]> wrote: >> >> Hi, >> >>> On Jan 19, 2016, at 9:18 PM, stepharo <[email protected]> wrote: >>> >>> >>> >>> Le 19/1/16 20:25, David Allouche a écrit : >>>> BTW, thanks for the explanations for Spotter. >> >> You are welcome. Please keep challenging. This is how good design happens. >> >> >>>>> On 19 Jan 2016, at 18:37, Tudor Girba <[email protected]> wrote: >>>>> >>>>> And then, in Spotter we have another discovery mechanism: Shift. When you >>>>> press it, all clickable things get highlighted (including the arrow). We >>>>> chose Shift because it is something that you type often as part of a >>>>> text, so it will be very likely that you will press it when working with >>>>> Spotter as well. And this will get you to see that something happens. >>>> I am lazy and fearful of RSI. If I can avoid using the shift key at all, I >>>> am quite happy. So I did not notice that the arrows where clickable. >>> >>> :) >>> Same here. >> >> What is RSI? >> >> Most people I know use Shift to type an upper case, and we observed that >> when people search, they often tend to still use uppercase. Not all, but >> many. That is why we put this functionality on Shift. This does not mean >> that it is enough, but we just wanted to increase the chance of people >> stumbling across this without any documentation. It only partially succeeded. > > You already stated your reasoning, and I understand it. I was just making > noise for people like Stef and me, who never use Shift unless they HAVE TO. > >> Anyway, we should externalize the key bindings. Another thing on the to do >> list :) > > Sure, great! > > >>>> Here are a few suggestions that would fit my workflow. >>>> >>>> I also think that "Selectors" should appear after classes and before >>>> packages, and be called "Messages". Typically I want to open a specific >>>> class, or a specific message in a specific class. >> >> #Messages is not a bad name, but then again I also thought that #Selectors >> was explicit enough :). What do others think? > > Any interest in putting "Messages" after "Classes" and before "Packages"? > > Another advantage of "Messages" is that "#m" is unambiguous. Currently, "#se" > is ambiguous (#senders and #selectors), that is a serious annoyance. > >>>> The short list of implementors at the top level is usually noise and might >>>> have confused Stef. It becomes relevant once the message is fully >>>> specified. >>>> >>>> Diving in should be done with right arrow when at the end of the command >>>> line. >>>> Diving out with left arrow at the start of the command line. >>> I was wondering what is the benefit to have cmd - shit arrow vs arrow >> >> Left/Right is used to move inside the text area (there is only one text >> field in the whole UI), and that is why you cannot consistently use it for >> navigating through results. >> >> Navigating when the cursor is at the end is a tempting idea, but it implies >> a mode that is not contextual (you need to things to look at). That is why I >> would not want to have it in this interface. > > Not overloading unmodified right/left arrows sounds like an obvious good idea. > > But as you already mentioned, Spotter is a special context, so one needs to > take a step back to evaluate the interaction possibilities. > > Typically, in the Spotter command line, I never use left-right arrows, and I > think this is common. If people mistype something, and have immediate > feedback, they tend to use backspace to fix it, instead of in-line editing. > > Spotter is also very similar to a class browser like Nautilus, where > left-right arrows are the primary way to dive in and out of packages, > classes, protocols, methods. That makes right and left arrows intuitive to > dive in and out in Spotter. > > If right and left arrows dive in and out, it's very easy to cancel a > mistake, just immediately press the opposite arrow. That also means that > dive-out should remember what was the search line, so immediately diving back > in does not lose the previous input, as is the current behaviour. Can you fix > that? > > Cmd-arrows and Cmd-shift-arrows is uncommon, and it takes a conscious effort > to remember, it's not intuitive in any way. > > Cmd-arrows and Cmd-shift-arrows are slow and hard to reach combinations. They > require me to move my left arm from the shoulder so left hand goes to the > modifier keys corner. Reaching arrows already requires me to move my right > arm so my right hand gets over the arrow pad. So every time I want to dive in > or out, I need to move both arms and completely lose kinaesthetic connection > with the home row. Then to continue filtering I need to find the home row > again. Repetitive switching between home row and cmd-shift-arrows is > frustrating at a deep, motor level. That kind of frustration leads to angry > people and the Dark Side. > > One could consider using Tab and Shift-Tab instead, but that would be a bad > choice. Tab should mean "autocomplete this", and in the context of Spotter > you cannot overload this with navigation. (I could expand on that) > > I am not sure what you mean by "not contextual": I type some words, use > up/down arrows to choose the line I want, which is often not the first one, > then use right arrow to dive in. That is contextual: I am looking at the > list, I already have my hand on the arrow pad, I did a vertical motion action > and now I want to do an horizontal motion action. > > If you insist right-left arrow should not be overloaded in the search line, > then you could use the first down arrow to move out of "command context" and > into "matches context". Other actions like Enter and Backspace need not > depend on the context. But I am convinced it is not necessary to make a > distinction between command context and matches context. > > At the very least, I would like some reassurance that the Spotter UI > machinery would make it easy for people like me to hack in the interaction > behaviour they expect from arrow keys. > >>>> >>>> When a list of paginated (only first N items), then the category line >>>> should be accessible with arrows, so we can dive into a category just with >>>> arrows. >> >> We explicitly chose not to do that because we did not want to mingle >> different kinds of elements in the same list. So, like this, when you press >> Cmd+Right, you will always dive in one single element, and not in many by >> mistake. > > I understand that. But I think it is the wrong trade-off. > > Diving into the wrong element with right arrow is cheap, just press left > arrow to dive out. That's easy to do and totally intuitive. > > To prevent a cheap, easily corrected mistake, you make one of the most common > actions significantly harder. That is bad UI design, sorry to be harsh. > >> Actually, our original goal was to have a way to expand the list in place >> (not only to dive in category). For this we wanted a … line and clicking on >> that would expand the list in place. We did not get to do it yet, but I >> think this would solve quite some of the reported problems. > > Expanding in place is a bad idea. Please do not do that. > > Categories often have dozens, sometimes hundreds of items. Once you have > expanded such a category, the rest of the list is essentially lost, you need > an easy way to cancel that, and that easy way is diving out. Also when you > are scrolling a long expanded list, you do NOT want to scroll past the end > and into another category, that would be annoying, and not useful. > > What you do need is to make it easier NOT to have browse the full categories > at all. For that: > > • Prefix matches should be sorted in lexicographic order of the thing > being matched first, and its container second. > • "items" in the top search, should show implementors only for > "#items", there are a lot of them, and not things like > DialogGroupManagerUI>>#itemSelected. > • When a category is fully specified by #word ("items #i"), it should > display the full list. There should still be the ability to dive into the > category (retaining "items" in the command line), But there is NO benefit in > adding a layer of indirection. > • Non-prefix matches, or matches for a line containing multiple words > need fuzzy search relevance sorting with history sensitivity. For exemple: > • "if else" should find ifNil:else:, ifTrue:else: etc. > • "m m" should find MenuMorph as one of the first results. Only > other classes whose two first two words start with M should come before. > • "menu morph items" should find "#Implementors: > MenuMorph>>#items" > > Here's another few, unrelated, suggestion. For the top-level list: > > • When the line is empty: > • Display a short graphic cheat sheet. Not a wall of plain > text, something pretty with boxes and small bits of text that the eye wants > to read. > • That should explain # words and important action keys. > • That should provide a way to immediately dive into categories. > • Provide an easy way to disable the cheat sheet: a button "Do > not show me this" > • Do not use separate lists per category, but one list with all > matches, sorted by search proximity and with history sensitivity > • History sensitivity here is very beneficial, it effectively > lets one define custom shortcuts, by always using the same letters to reach > to frequently used items. For example in Alfred on my Mac, "sl" finds "Sleep" > first and "Slack" second. > • Categories can be displayed again by typing a single #. > • Keep the categories separated in the list after diving in, it is > essential for things like senders/implementors. > > And some suggestion for all lists: > • Please, please, GET RID OF VERTICAL WRAP AROUND, thanks. When I hit > the bottom of the list, I want to know I got there. > • When a non matching #word is typed ("#x"), the available #words > should be displayed, not the empty list. > • When moving into category with arrow up/down, please scroll more. If > the category list is long compared to the scroller viewport, at 50-75% of the > viewport should display the category I just moved in. > • Scrolling should probably be a bit optimistic. Unless we are at the > end of the list, the current line should never be the first or last > displayed, unless the viewport is very small. > • When the current category name is out of the viewport, it should > stick at the top, maybe with some transparency gradient over the first item, > I need to know what category I am in. It is especially important when > scrolling up, after overshooting. > I hope you are familiar with Alfred (Mac only) and Sublime Text. They both > provide very useful fuzzy search with history sensitivity. > >> But, please do keep challenging. And give it a try with writing your own >> processors. It would help us a lot. > > Right now, I keep bouncing in all sorts of bugs in other packages. So I am > rather happy to just provide feedback for enhancements, so I can spend more > time fixing the actual bugs. :-) > > Regards. -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."
