Community
Participate
Working Groups
In the new errorDialog The fact we have to click an icon to get some info and a button to get a different set of info seems counter intuitive How can we have some progressive disclosure and yet be intuitive ?
Its a good point, do you have a suggestion?
I am not a UX expert but a user... so here is what I would like to see as a user the use case always start with: I am getting an error dialog with an error a) I know what to do, I click close... b) I do not know what to do b1) it does not bother me, I do not have time... I click Close b2) it does bother me, but I have no time I want a button that states: 'Send it to support and open a tick automatically for me, use my default data' - b3) it does bother me but I have a bit of time and I am kind of geeky - I want a button that states: 'tell me more', from there I can read doc or info about the possibles solutions from my knowledge base b4) it does bother me and after I read b3, I still cannot find it so I click the 'send to support', but I added he fact that I searched the knowledge base b5) it does bother me, I did not find a solution by I am a Uber-geek, so I click the 'show me the stack trace' button and I start debugging the VM All that should be an extension to the ErrorDialog (provided by 3rd paty) I am suggesting we remove one of the tray... either the one below or the one on the right and we allow the button bar to be extended so as a provide I can add the 'open ticket button' and a 'details..' button Then the 'control' in the details section can provide all we need OR we have no details section in the dialog (because of real estate issue - not a lot of room) and the 'details' closes the dialog and open a 'perspective' or a set of 'view' that may include the dynamic help then provider can add the views they want thoughts ?
Created attachment 115546 [details] Some thoughts on statushandling There is one old bug 173083, which served as a base for the mock up. So I'd imagine following flow: 1. The error appears. This is some friendly message, no technical details. The user is able to decide if he wants to dig into the error, or to ignore it (maybe he does not care, or is skilled enough). 2. If he selects "More" the view is opened with the list of currently handled statuses. All statuses are runtime only (because we have log anyway). 2a. User selects the status which he would like to dig & expands it. 3. If he is not skilled enough, he may just launch support (from the status dialog, but it will be in different form). In this point we may have reporting. 4. Skilled user may want to display all informations contained by the status. 5. If the description exists, we display it. 6. We may propose some recovery actions (RFE for future work). 7. If the user really wants he may even review the stack trace. 8. After the work is done, he may remove the stastus from the view (not on the screenshot). Pros: * clean & ellegant error dialog * no constraints about support size * easy to extend (point 6) * progressive disclosure * user can try to recover from blocking errors Cons: * Yet another error view * Yet another dialog (we have to display reporting)
I like some ideas... couple thoughts 1) we move away from the 'everything' in the Dialog to creating a view... So we still keep the StatusManager.core code.. now the UI may change 2) I do not see the 'Yet another dialog' you are talking about 3) basically what we suggest is linking the 'details' to the 'error log view' and product can 'override the error log view'... not sure if 'eclipse' will want to do that ? In any case, we should still allow products to chose to show UI in dialog if they wish so, but I agree they may decide to have the button open a view (which eclipse should allow... not sure eclipse has to implement such a complex view though ) 4) In IBM there are some usability people, maybe we should ask them... what about other Eclipse Companies ?How do we engage them to tel us what they want to do in their product ?
(In reply to comment #4) > I like some ideas... couple thoughts > 1) we move away from the 'everything' in the Dialog to creating a view... > So we still keep the StatusManager.core code.. now the UI may change > 3) basically what we suggest is linking the 'details' to the 'error log view' By default I would leave details in the dialog as it is now. People got used to it and it could be confusing if the details disappeared. I like the idea of having the support area in a view. But I think that it should be configurable where to show the areas. The status handler creator would decide where to show initially, but then user could change it.
Created attachment 125511 [details] Work in progress I am quite concerned about this feature as the gap between jface ErrorDialog & StatusDialog is going to be bigger and bigger. Maybe it would be good to add an entry to the migration guide?
Created attachment 125512 [details] mylyn/context/zip
Changing Version tag to something more believable.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
