Closed
Bug 919502
Opened 11 years ago
Closed 10 years ago
[app manager] revisit the project's controls
Categories
(DevTools Graveyard :: WebIDE, defect, P1)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 999417
People
(Reporter: paul, Assigned: paul)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•11 years ago
|
Priority: -- → P2
Assignee | ||
Updated•11 years ago
|
Priority: P2 → P1
Assignee | ||
Comment 1•11 years ago
|
||
We should also make it clear that the user is not connected.
Assignee | ||
Comment 2•11 years ago
|
||
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.
Comment 3•11 years ago
|
||
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?
Assignee | ||
Comment 4•11 years ago
|
||
(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.
Comment 5•11 years ago
|
||
For scenario 2, isn't that what the Install/Start button does?
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → paul
Assignee | ||
Comment 6•11 years ago
|
||
(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").
Assignee | ||
Comment 7•11 years ago
|
||
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.
Assignee | ||
Comment 9•11 years ago
|
||
WIP
Assignee | ||
Comment 10•11 years ago
|
||
One of the requirement here is also to kill all the call to top.UI.
Assignee | ||
Comment 11•11 years ago
|
||
Mockups: https://moqups.com/paulrouget/8mMjWEjq
Darrin, can you look at this and tell me if that works for you?
Flags: needinfo?(dhenein)
Comment 12•11 years ago
|
||
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...
Flags: needinfo?(dhenein)
Assignee | ||
Comment 13•11 years ago
|
||
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
Assignee | ||
Comment 14•11 years ago
|
||
Darrin - can you help to get this right?
Flags: needinfo?(dhenein)
Assignee | ||
Updated•11 years ago
|
Whiteboard: [waiting-for-ux]
Assignee | ||
Comment 15•11 years ago
|
||
A totally different UI is on its way.
Flags: needinfo?(dhenein)
Whiteboard: [waiting-for-ux]
Comment 16•11 years ago
|
||
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
Assignee | ||
Comment 17•10 years ago
|
||
Resolved in the new app manager.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•5 years ago
|
Product: DevTools → DevTools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•