Community
Participate
Working Groups
Couple questions: 1) Click "Clone Repository" and a slideout opens. Click "More" which opens a big dialog with more fields. Now, there is no way to go back to the slideout other than just close the big dialog and click "Clone Repository" again. Should we have something like "Less" button on the big dialog? 2) Click "Clone Repository" and a slideout opens. When the slideout is open, click "Init Repository". Now you have two dialogs, the slideout and a big one for Git Init operation. Shouldn't we close the slideout in this case? 3) I wonder if another click on "Clone Repository" could close the slideout? I'm not sure why, but the first think I do when I want to close the slideout is clicking on the command link itself...
We definitely need a more predictable pattern here. Right now the slideout will stay open until another slideout is invoked, it is dismissed, or until the command has a reason to rerender. It's a bit random. The modality of the slideout needs to be more formalized. This makes for very unpredictable behavior from the users perspective. And I agree that if the user invokes another command, the slideout should probably go away. The only exception I can imagine is the "modal" commands like find/replace that should stay open until someone else needs that slideout.
*** Bug 365928 has been marked as a duplicate of this bug. ***
I think all the ideas here are good but I'm afraid to do much with this right now. I think I'd like to address the longer term issue of using the slideout more universally, and making it so that "more" just adds more info the slideout rather than invoke a dialog. I thought about implementing an "auto close" for the parameter slideout if another command (that doesn't use parameters) runs, but I fear that this could introduce unforeseen problems or be just as unexpected as what happens now. For example... I'm going to clone something...then I decide to fetch some branches, but I still intended to clone... if fetch authenticates then it will take over the slideout, but if no authentication is needed, maybe I didn't want that other slideout to close. need more thought.
*** Bug 365926 has been marked as a duplicate of this bug. ***
an idea from bug 365926 was whether we should use tooltip dialogs as a better "more" menu. I'd still like to first try putting content inline. As long as something is not overlayed, we have a better chance to get to it on a small device via scrolling, not have the "positioned off the screen" problems, etc. Note that we do currently use tooltip dialogs for object-level parameter collection. I want to see how this is all playing in real use cases and then we can figure out what makes sense.
Created attachment 213593 [details] screenshot of a dialog launched from "slideout" I noticed this in my online banking app. There is an "in-dom" field for adding a payee, much like our slideout. You can press a button and it launches a dialog. This plays well because: 1) the original field stays where it was (it's permanent on the page) 2) the dialog launches next to it
Created attachment 213594 [details] screenshot part 2 after the dialog is dismissed, the new thing created by the dialog is highlighted. The original "slideout" that launched the dialog is still there. It is permanent on the page, so it's not quite the same as our slideout case. I thought it was a natural workflow
Created attachment 213604 [details] gmail search field with "more" in gmail, you can type a search term or you can push a button for the options. When the options open, you get a dialog, but its lightweight appearance and positioning seem more integrated with the original field. Maybe an approach like this would be useful. The slideout would remain open and a lightweight dialog would appear directly underneath.
moving out of 0.5M2 to 0.5 milestone until we have more specific buckets for future
a discussion with mcq today about positioning slideouts closer to the invoking command made me realize something. There is a continuum at play here: command -> the field(s) is really needs -> the advanced stuff. The desktop paradigm was show a button/menu for the command, open a dialog with the simple field(s) really needed, have a More/Advanced button for the advanced stuff. Our slideouts are really doing the same, but with an alternate presentation. But the banking app in the first attachment demonstrates a pattern where the command/field are shown together, because you always need that field. And then the dialog is only needed for the advanced case. Gmail does this with some menus. The menu command and parameter are in the menu together. Then other options in the menu let you make other choices or launch a dialog.
Created attachment 216710 [details] screenshot of command/parameter grouped in a menu
moving milestone to 2.0 M1 for future triage.
See bug 381740 for a discussion of confusion that occurs because the invoking button seems like the place to finish the command rather than the more subtle "submit" button. Wanted to make a note here since we are doing a temporary fix in the other bug.
Anton has added a gear menu in the editor for editor settings. It is going in the direction discussed in comment 10. I just don't think we'll get to a unified story in 2.0. We'll want to look at our use of: 1 - popup dialogs (such as sftp connection creation, operations popup) 2 - home grown popups (advanced search options popup, editor ctrl+H popup) 3 - the gear menu in the editor (popup styled to be part of invoking command) 4 - slideouts 5 - dialogs It seems to me that 1-3 could be unified. So that if there is affordance for a popup, we connect it to the affordance as Anton has done. We need to do *something* with slideouts and we could use something like 1-3, but we need to be careful about dismissal of the slideout. The only thing special about a slideout today is that it can be called from a URL binding. That is, the user could follow a link to Orion and be prompted for something. So we have to make sure we don't use a UI that is too easy to dismiss (an errant click on the page, etc.). It may not be apparent that reloading the page would bring the popup back. But there's no reason it couldn't look like #1-3, we just may want to make the user have to explicitly dismiss it. And if we have a style of popup that must be dismissed explicitly, why not attach buttons to it and call it a dialog?
What are the advantages of commands over just adding buttons? I find the commands complicated, and would prefer just to add HTML buttons with the appropriate class.
(In reply to comment #15) > What are the advantages of commands over just adding buttons? I find the > commands complicated, and would prefer just to add HTML buttons with the > appropriate class. I find the commands easy and I like the separation between logic and UI. I especially like "object" commands where I implement them once and they are rendered in all places where the object matches visibleWhen condition.
What are the advantages of commands over just adding buttons? I find the commands complicated, and would prefer just to add HTML buttons with the appropriate class.(In reply to comment #16) > (In reply to comment #15) > > What are the advantages of commands over just adding buttons? I find the > > commands complicated, and would prefer just to add HTML buttons with the > > appropriate class. > > I find the commands easy and I like the separation between logic and UI. I > especially like "object" commands where I implement them once and they are > rendered in all places where the object matches visibleWhen condition. They're definitely not easier for me than the familiarity of creating a button in HTML/JS - I have to copy existing ones each time I make a new one. It's funny that you write about the separation of logic and UI - I had to think about that, because I see the commands as an integration of logic and UI. I will have to think more about it. Please can you give me a couple of examples where you make use of an 'object' command. [ Just trying to understand this better - my instinct tells me that I'd prefer to stick to just normal web buttons, but I want to understand why commands are better ]
The other part of it is consistency. We were able to get rid of dijit menus and drop downs, etc. in one place. Tomorrow we could decide that all popups should drop down from the button like the gear menu and it would be done in one place. And...the parameter support is what enables the URL bindings to link directly into a page and prefill in the parameters. It's also how extension points are able to add to the UI. I'm sure there are different ways to structure it but all those decisions need to be encapsulated somewhere so we aren't copying buttons all over the UI and implementing different solutions to the same problem.
(In reply to comment #18) > I'm sure there are different ways to structure it but all those decisions > need to be encapsulated somewhere so we aren't copying buttons all over the > UI and implementing different solutions to the same problem. I suggest we continue this discussion in bug 390356. That bug is about improving the usability of the command service API.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
