Maybe could we propose different layouts (full flat (default ?), full grouped, plugin only... defined by a property) mixed with LRU proposition, Search box... accordingly to user preferences/habits/needs ?
Le mar. 12 déc. 2017 à 16:40, Vincent HERILIER <vheril...@gmail.com> a écrit : > In the PR, I proposed, I grouped JMeter native elements as example, but > the PR insured to let some elements at their initial place (JMEter ones to > keep its current usability) and allow others to be grouped (3rd party ones > if required and proposed by their related maintainers). > So it was just allowing the feature, it didn't ordered it. > > Maybe it could be no more compatible with some evolutions you planned and > that avoids it anyway. > Or we could try to make these approaches complementary too... > > Anyway, I stay really interested in JMeter usability improvement. > > Le mar. 12 déc. 2017 à 16:15, Graham Russell <gra...@ham1.co.uk> a écrit : > >> Ah, I didn't appreciate the use case you had. >> >> I still think the additional menu groupings would be detrimental to more >> common use cases. >> >> Perhaps we can keep plugin menus ordered separated from the native ones >> this might help slightly. I will make sure I test my changes with some >> plugins! >> >> I was thinking to keep a LRU list in the search box results which should >> speed things up for most use cases. >> >> Graham >> >> >> On 12 December 2017 at 14:15, Vincent HERILIER <vheril...@gmail.com> >> wrote: >> > I clearly understand your points of view. >> > >> > But with plugins used in my case (and average 300 testers) which bring >> > average 40 config elements and 90 samplers, they are mixed (with JMeter >> > native ones too) for complex and cross-protocol flows we would like to >> > simulate (average 15 protocols - new , redefined protocols or server >> side >> > part - for our needs coverage). >> > >> > Reconfiguring a palette does not really solve my issue because the range >> of >> > required elements changes often or is wide each time. >> > Loading and using a search box often will not really a gain of time too. >> > >> > That's why a protocol grouping is IMHO and in my specific use-case more >> > accurate and quickly usable. >> > I hope beiing wrong and I'm waiting for a quicker menu navigation >> mechanism >> > even it is not a submenu one ;). >> > >> > Thanks for all the work you provide to improve JMeter. >> > >> > Vincent >> > >> > Le mar. 12 déc. 2017 à 14:29, Graham Russell <gra...@ham1.co.uk> a >> écrit : >> > >> >> I agree with Phillipe that adding more menus, and therefore steps to >> >> get to items you need (key presses or mouse moves) and items to read >> >> is not an improvement. >> >> >> >> I like the idea of a configurable palette (with some sensible >> >> defaults), much easier for beginners. >> >> >> >> This still requires use of the mouse, so for more advanced users, what >> >> do we think of introducing a "find/search"? >> >> Pressing ctrl+shift+a loads a pop-up search box, as you type it >> >> filters the list and you click/press enter on the one you want and >> >> it's added to the tree. >> >> >> >> On 12 December 2017 at 13:11, Philippe Mouawad >> >> <philippe.moua...@gmail.com> wrote: >> >> > Hello, >> >> > I am personally against an additional level in the popup menu as it >> would >> >> > be a loss of time. >> >> > If it's about reorganizing the menu order to put most popular ones on >> >> top, >> >> > why not. >> >> > >> >> > A configurable palette in the right or bottom left (now we have >> dropped >> >> > workbench) might be a better alternative. User could put here the >> >> elements >> >> > he uses the most. >> >> > >> >> > Regards >> >> > >> >> > >> >> > >> >> > On Tue, Dec 12, 2017 at 2:05 PM, Vincent HERILIER < >> vheril...@gmail.com> >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> I already proposed a PR in that way ( >> >> >> https://github.com/apache/jmeter/pull/236) and I'm still >> interested in >> >> >> having the capability to group some elements ,per protocol class for >> >> >> example, to reduce the amount of different menus entries shown. >> >> >> >> >> >> Vincent >> >> >> >> >> >> Le mar. 12 déc. 2017 à 10:07, Antonio Gomes Rodrigues < >> ra0...@gmail.com> >> >> a >> >> >> écrit : >> >> >> >> >> >> > Hi, >> >> >> > >> >> >> > About advanced mode, some code has been written and maybe we need >> to >> >> >> remove >> >> >> > it and discuss again and finish it. >> >> >> > >> >> >> > Yes, it's hockey. >> >> >> > >> >> >> > >> >> >> > For the moment I have few free time but I probably write some blog >> >> post >> >> >> > (Apache provide blog) about some features. >> >> >> > >> >> >> > Thanks to the PR >> >> >> > >> >> >> > Antonio >> >> >> > >> >> >> > >> >> >> > 2017-12-11 21:00 GMT+01:00 Graham Russell <gra...@ham1.co.uk>: >> >> >> > >> >> >> > > Ah ok, I noticed something about advanced mode and wondered what >> it >> >> >> > meant, >> >> >> > > probably worth tidying up? >> >> >> > > >> >> >> > > I think those hotkeys should be more prominently documented, I >> only >> >> >> > > recently discovered them, or are there other shortcuts you were >> >> >> referring >> >> >> > > to? >> >> >> > > >> >> >> > > I will attempt a PR with a proof of concept in the coming week. >> >> >> > > >> >> >> > > Thanks >> >> >> > > >> >> >> > > Graham >> >> >> > > >> >> >> > > On Mon, 11 Dec 2017, 09:21 Antonio Gomes Rodrigues, < >> >> ra0...@gmail.com> >> >> >> > > wrote: >> >> >> > > >> >> >> > > > Hi, >> >> >> > > > >> >> >> > > > Sometime ago we have discuss to have an advanced mode with all >> >> >> options >> >> >> > > and >> >> >> > > > an basic mode with only the essentials. Unfortunately there >> was >> no >> >> >> > > > consensus >> >> >> > > > >> >> >> > > > For the moment we have shortcuts >> >> >> > > > >> >> >> > > > +1 for your solution >> >> >> > > > >> >> >> > > > Antonio >> >> >> > > > >> >> >> > > > >> >> >> > > > 2017-12-10 19:36 GMT+01:00 Graham Russell <gra...@ham1.co.uk >> >: >> >> >> > > > >> >> >> > > > > Hi all >> >> >> > > > > >> >> >> > > > > Currently the menus are ordered alphabetically, which is >> fine >> >> for >> >> >> > > > > small menus, and better than not at all for the large ones, >> >> >> however I >> >> >> > > > > think we can do better. >> >> >> > > > > >> >> >> > > > > If the menu has more than 4-5 items in it I think we should >> >> split >> >> >> it >> >> >> > > > > up into chunks of 5-7 with the most popular (e.g. HTTP >> Request >> >> >> > > > > Sampler) at the top. I hope this would ease a bit of RSI for >> >> users >> >> >> > and >> >> >> > > > > help improve the usability. >> >> >> > > > > >> >> >> > > > > Any thoughts? >> >> >> > > > > >> >> >> > > > > Having looked at the code it seems the menus are built by >> >> looking >> >> >> at >> >> >> > > > > the classes, does adding an annotation with "sort order" and >> >> maybe >> >> >> > > > > "group" make sense or is there a better way to dictate the >> >> order of >> >> >> > > > > items in the menus? >> >> >> > > > > >> >> >> > > > > Thanks >> >> >> > > > > >> >> >> > > > > Graham >> >> >> > > > > >> >> >> > > > >> >> >> > > >> >> >> > >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Cordialement. >> >> > Philippe Mouawad. >> >> >> >
