Bugzilla – Full Text Bug Listing
| Summary: | Investigate showing a log (Make the log view an icon down the side? (just like the git and preferences)) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Steve Northover <steve_northover> | ||||
| Component: | Client | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, Silenio_Quarti | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 15.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 506101 | ||||||
| Attachments: |
|
||||||
|
Description
Steve Northover
Another approach would be to get rid of the run bar all together in favor of the shell where the guy types, "cf push". Since we don't have a shell in all environments, we still need the run bar and and the log. The current situation we have is horrible and I felt the quickest way to get to something that was usable would be to add the icon down the side. I am happy enough with any solution that shows a log when the user launches (with a sticky check button to control the behavior default to "true" so he knows where the log is). What can't happen is we go on forever with what we have now. I have a basic solution with a lot of rough edges. 1) User clicks play button 2) Confirmation dialog opens if it is a redeploy, with option to remember choice 3) App deploy starts 4) NEW dialog opens asking if you would like to view the log, with option to remember choice 5) If yes, the log is opened in a new window (same as current show log behaviour) Steve, what do you think of this basic workflow? The dialog could also give the option to display log in current window or in a new window (or eventually an in window slideout or dialog). It is horrible but at least they know that they have a log. If the problem is that they don't know the log exists, maybe we can point them to the button and let them open it the way they do now (if they know it is there). Why can't we open in the same window? Too hard? List of potential workflows and the pros/cons: 1) Open a dialog asking whether to open the log (with option to remember) + Easy to implement + Can give user option of opening in same window or new window + Could highlight log button and show it's icon to remind user how to open log manually - Adds another click to deploy - Possible to have two dialogs to show up, one to collect parameters then the log one 2) Use command parameters to ask user in a tooltip type popup (like Git password request) + Less obtrusive UI than (1) - Less control over UI 3) Highlight the log button, when deploy button is pressed + No interruption of workflow + If we can get status of the deployment we could update the log button to indicate new information - Requires user to notice the log button 4) Put another page icon on the side bar, always open log on deploy in same window - Major workflow interruption - Difficult to implement as the log url depends on what launch configuration is being shown (In reply to Steve Northover from comment #4) > It is horrible but at least they know that they have a log. If the problem > is that they don't know the log exists, maybe we can point them to the > button and let them open it the way they do now (if they know it is there). > This is why I recommend approach (3). When user clicks deploy, we add a blue dot to the log and a blue outline that fades away. As the launch config drop down gets a callback to add a (Stopped) (Started) annotation, we should be able to also update the log button. > Why can't we open in the same window? Too hard? Easy enough to open in same or new window as the button acts as a link. If you always want to view the log, same window would be better, but if looking at the log is optional, a new window would be better. 3) is interesting. It would be the first time we did this. While it is deploying, highlight. After it is successful, clear? ie. we could make the log button follow the state. There is a "yellow" state where the thing is unsure ... Created attachment 267041 [details]
Patch to highlight log button
I changed the open app and show logs links to be buttons. This fixes their weird colors and cleans up the CSS. Also updated the tooltip.
When you start an operation (start, stop), the open log button will have a red animated border. When the operation completes and starts checking status the red border will go away.
The exact UI can be changed pretty easily via CSS. The current color is 'red' but should either match the statusLightRed value or another color of our choice.
When to show the border is also customizable as we get events back in RunBar.js. There is no consistent 'state' value, but we can figure out whether the state is: deploying, stopping, error in client, checking app status, started, stopped.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/?h=cwindatt%2FBug512057_HighlightLogButton I updated the patch with some additional improvements then pushed it to a branch. Buttons now match commandImage style. Blue border rather than red Links act as links, but don't have text decoration (they look like buttons) http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a6b21d793d155406604a6875b261c348b2dd8d0d Applied fix to master We will open new bugs for any tweaks we want to make once we start getting user feedback. |