today we have: [update][debug]. But I really think we should also have start/stop or maybe restart. Also - it's not possible to only run the manifest validation check without pushing the app to the device. I'd prefer: [validate][push][start|stop|restart][debug]. [push] implies [validate]. [start] implies [push]. [debug] implies [start]. Maybe with [validate] a the Manifest editor level.
We should also make it clear that the user is not connected.
Current situation is: If not connected: > ["refresh"] If connected: > ["refresh"] ["debug"] Issues: "refresh" action is very blurry (it checks the manifest from the harddrive, and push to device if device is connected). "debug" might do too much (it starts the app and start a toolbox. Maybe the user doesn't need the toolbox). When not connected, it's not clear that you can do more once connected. I think we can do better. More atomic actions, and better wording. ----- I suggest: If not connected: > ["validate"] • ["install (not connected)" /*greyed out*/] ["debug (not connected)" /*greyed out*/] If connected, app not running: > ["validate"] • ["install"] ["debug"] • ["start"] If connected, app running: > ["validate"] • ["install"] ["debug"] • ["stop"] ["restart"] ----- I think it's important to show the "install (not connected)" button because people might not understand that they can do more if they'd connect a device or start a simulator.
Paul, I think these are good suggestions. Maybe rather than including the text "(not connnected)" we can put that in a tooltip (but still grey out the button). I think debug is fine as the toolbox is the primary debugging tool. Could someone debug an app without the toolbox?
(In reply to Darrin Henein [:darrin] from comment #3) > Paul, I think these are good suggestions. Maybe rather than including the > text "(not connnected)" we can put that in a tooltip (but still grey out the > button). > > I think debug is fine as the toolbox is the primary debugging tool. Could > someone debug an app without the toolbox? Yes. 2 scenarios: 1) My app has a bug. I use the the debug button to understand what's going on. Then fix the source code. 2) I'm writing an app. I write the code and restart the app to see my changes. I think scenario 2 is pretty important. I even believe this will be the main usage.
For scenario 2, isn't that what the Install/Start button does?
(In reply to Darrin Henein [:darrin] from comment #5) > For scenario 2, isn't that what the Install/Start button does? Yes. Maybe restart could also do "stop + install + start" (not just "stop + start").
I've observed someone using the App Manager yesterday. The user didn't realized he was supposed to be connected to get more button. How can we make that clear?
(In reply to Paul Rouget [:paul] from comment #7) > I've observed someone using the App Manager yesterday. The user didn't > realized he was supposed to be connected to get more button. How can we make > that clear? Maybe all the buttons are always present, but just disabled / grayed out. On hover, the title / tooltip could say "Connect to device to Debug." or something.
One of the requirement here is also to kill all the call to top.UI.
Mockups: https://moqups.com/paulrouget/8mMjWEjq Darrin, can you look at this and tell me if that works for you?
My thought is that it still presents the user a lot of (potentially) unclear options (sync, install, reload, run, debug), though it is much better than what we have now. I'd say it's a step in the right direction but a deeper UX rethinking of the buttons/controls is probably needed...
Let me describe here all the operation we need to/can perform from the app panel: - check from disk: this will read the files from the hard drive (icon and manifest file) and update the UI (update the icon, show warning/errors if any, update name, description, author… and update the content of the manifest editor). This is useful when the user changed something in the app directory. - save manifest: if the user changed the manifest from the manifest editor, it writes the manifest on the hard drive. - install: push the app to the device. - uninstall - run: start the installed app on the device - stop - debug: open a toolbox connected to the running app - reload: the running app is restarted These are operations. They can't all be directly translated to buttons: install requires check first run needs install if not installed debug and reload need run if not running We also want a multi-operation button: sync. It checks, then install, then reload. The app panel can be in different states. Not all the operation are possible in all these states. - device disconnected - device connected - app invalid - app valid - app not installed - app installed - app not running - app running
Darrin - can you help to get this right?
A totally different UI is on its way.
Filter on 86b7095e-2bd0-499e-a704-d00f2524aeef / PAUL STOP SETTING QA CONTACT TO THE DEVTOOLS COMPONENT'S WATCHERS EMAIL FOR BUGS YOU FILE :)
QA Contact: developer.tools
Resolved in the new app manager.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 999417
You need to log in before you can comment on or make changes to this bug.