[xwiki-devs] Testing Dashboards in 3.0 snapshot
Hi, I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception: uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}} This issue seemed to only happen with an empty dashboard macro (with not gadget yet added). I think we need to work on two things for each feature that we are developping: 1/ Having a status of where we are: In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized 2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there. Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority: - Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more (I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode) - Add a column in your dashboard - Editing a dashboard Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget. The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed). So, WDYT?
- Add a column in your dashboard - Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget? Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now). Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Mar 8, 2011 at 16:01, Luca Anca <[email protected]> wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
So, WDYT?
I'm still in favor of "edit mode edit" for the sake of consistency with how every XWiki application behaves. Guillaume
- Add a column in your dashboard
- Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Mar 8, 2011 at 5:33 PM, Guillaume Lerouge <[email protected]> wrote:
Hi,
On Tue, Mar 8, 2011 at 16:01, Luca Anca <[email protected]> wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
So, WDYT?
I'm still in favor of "edit mode edit" for the sake of consistency with how every XWiki application behaves.
Same Jerome.
Guillaume
- Add a column in your dashboard
- Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca <[email protected]> wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
So, WDYT?
-1 for A) I'm definitely for B) "Edit mode edit", not only for consistency, but also for avoiding surprise side effects when interacting with the dashboard.
- Add a column in your dashboard - Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, 2011-03-08 at 17:57 +0100, Marta Girdea wrote:
On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca <[email protected]> wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
So, WDYT?
-1 for A)
I'm definitely for B) "Edit mode edit", not only for consistency, but also for avoiding surprise side effects when interacting with the dashboard.
What do you have in mind under "surprise side effects"? When drag & dropping I'm always thinking on how hard it is to manipulate the touchpad of a laptop from this pov, for not so very technical users. Do you have another case? Thanks, Anca
- Add a column in your dashboard - Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 03/08/2011 05:57 PM, Marta Girdea wrote:
On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<[email protected]> wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
So, WDYT?
-1 for A)
I'm definitely for B) "Edit mode edit", not only for consistency, but also for avoiding surprise side effects when interacting with the dashboard.
Same for me. Users tend to just move things around, accidentally click the mouse, and then "things just broke by themselves".
- Add a column in your dashboard - Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
My proposal about using view mode is not to be in "edit" mode automatically. My proposal is to have the "edit" button maybe more visible as well as "Add Widget", and more importantly to have the "edit" button not load the "inline" mode, but load in place. Most importantly the "save" buttons don't mean anything as adding a gadget adds an XWiki object and is permanent. Same with moving and removing gadgets. That changes the object right away. So we need to "remove" the "save" actions as they won't mean anything. Ludovic Le 08/03/11 18:07, Sergiu Dumitriu a écrit : > On 03/08/2011 05:57 PM, Marta Girdea wrote: >> On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<[email protected]> wrote: >>> On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote: >>>> Hi, >>>> >>>> I've tried the dashbord on 3.0 snapshot and could not make the "Add >>>> Gadget" function work on an empty dashboard. >>>> From what I see the issue seems to be in the wysiwyg code. I got the >>> no, it's dashboards code, I forgot to handle the case when the column >>> where the gadget should be added doesn't actually exist. >>> >>>> dialog box from the wysiwyg, when clicking on Insert Gadget" I got an >>>> exception: >>>> >>>> uncaught exception: Class$dF: One or more exceptions caught, see full >>>> set in UmbrellaException#getCauses >>>> at >>>> function nr(){try{null.a()}catch(b){return b}} >>>> >>>> This issue seemed to only happen with an empty dashboard macro (with not >>>> gadget yet added). >>>> >>>> I think we need to work on two things for each feature that we are >>>> developping: >>>> >>>> 1/ Having a status of where we are: >>>> >>>> In the case of Dashboard, I think that's updating this page: >>>> http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized >>> I updated the table. There could be new cases, I guess, to comprise the >>> missing things (like adding a column when editing, or others a like), >>> but I prefer to use Jira issues for these. WDYT? >>> >>>> 2/ Write a test plan and have Sorin include the testing of new features >>>> in his testing. >>>> For that he needs to know how to test and what is supposed to be >>>> there/not there. >>>> >>>> Concerning the development priorities, I think for the next period of >>>> development on the dashboard we need to focus on wiring the UI for >>>> "beginners", making it easy for them to create their first dashboard. In >>>> my view this is in priority: >>>> >>>> - Create page with a dashboard macro (In the Add Menu in XE) >>>> - Go to edit more >>> What's "edit more"? >>> >>>> (I'm still convinced that we need the dashboard >>>> editing in "view" mode and not in "inline" mode) >>> What do others think? >>> Knowing that the current edit in inline mode has a few limitations: >>> * remove gadget will be saved immediately, not when the user clicks >>> "save". If the user says remove gadget, confirms the remove and then >>> clicks the "cancel" button in the edit form, the remove will still be >>> saved. >>> * same for add gadget. >>> >>> The way I see the two possibilities: >>> A) "View mode edit" will save on every change >>> B) "Edit mode edit" (implemented as inline edit, now) will save >>> everything at the end (current implementation but with the limitations >>> fixed). >>> >>> So, WDYT? >> -1 for A) >> >> I'm definitely for B) "Edit mode edit", not only for consistency, but >> also for avoiding surprise side effects when interacting with the >> dashboard. > Same for me. Users tend to just move things around, accidentally click > the mouse, and then "things just broke by themselves". > >>>> - Add a column in your dashboard >>>> - Editing a dashboard >>> you mean editing a gadget? as in the parameters of that gadget? >>> >>> Also, I would add to this list, potentially at the top: >>> - finalizing the structure of the dashboard / gadgets objects, so that >>> we don't have migration in the next releases (e.g. if we decide to add a >>> field in the gadget object to identify which is the dashboard of that >>> gadget, in case there are multiple dashboards on one page, we should do >>> it now). >>> >>> Thanks for the feedback, >>> Anca >>> >>>> Also for the 3.1 timeframe I think we need to have some brainstorm to >>>> add some more "Dashboard" friendly macros/gadgets to make dashboards >>>> more usefull and interesting for users, but that's another story. >>>> Right now I think the most important is that we agree on the priorities >>>> for the next step and that for 3.0 we have a simple but coherent >>>> dashboard feature. >>>> >>>> Ludovic > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Mar 8, 2011, at 8:53 PM, Ludovic Dubost wrote: > > My proposal about using view mode is not to be in "edit" mode automatically. > My proposal is to have the "edit" button maybe more visible as well as "Add Widget", and more importantly to have the "edit" button not load the "inline" mode, but load in place. > Most importantly the "save" buttons don't mean anything as adding a gadget adds an XWiki object and is permanent. Same with moving and removing gadgets. That changes the object right away. Actually this is a bug that we need to fix. It's absolutely not normal that when you add objects in the object editor the objects are added even if you cancel the edit Thanks -Vincent > So we need to "remove" the "save" actions as they won't mean anything. > > Ludovic > > > Le 08/03/11 18:07, Sergiu Dumitriu a écrit : >> On 03/08/2011 05:57 PM, Marta Girdea wrote: >>> On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<[email protected]> wrote: >>>> On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote: >>>>> Hi, >>>>> >>>>> I've tried the dashbord on 3.0 snapshot and could not make the "Add >>>>> Gadget" function work on an empty dashboard. >>>>> From what I see the issue seems to be in the wysiwyg code. I got the >>>> no, it's dashboards code, I forgot to handle the case when the column >>>> where the gadget should be added doesn't actually exist. >>>> >>>>> dialog box from the wysiwyg, when clicking on Insert Gadget" I got an >>>>> exception: >>>>> >>>>> uncaught exception: Class$dF: One or more exceptions caught, see full >>>>> set in UmbrellaException#getCauses >>>>> at >>>>> function nr(){try{null.a()}catch(b){return b}} >>>>> >>>>> This issue seemed to only happen with an empty dashboard macro (with not >>>>> gadget yet added). >>>>> >>>>> I think we need to work on two things for each feature that we are >>>>> developping: >>>>> >>>>> 1/ Having a status of where we are: >>>>> >>>>> In the case of Dashboard, I think that's updating this page: >>>>> http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized >>>> I updated the table. There could be new cases, I guess, to comprise the >>>> missing things (like adding a column when editing, or others a like), >>>> but I prefer to use Jira issues for these. WDYT? >>>> >>>>> 2/ Write a test plan and have Sorin include the testing of new features >>>>> in his testing. >>>>> For that he needs to know how to test and what is supposed to be >>>>> there/not there. >>>>> >>>>> Concerning the development priorities, I think for the next period of >>>>> development on the dashboard we need to focus on wiring the UI for >>>>> "beginners", making it easy for them to create their first dashboard. In >>>>> my view this is in priority: >>>>> >>>>> - Create page with a dashboard macro (In the Add Menu in XE) >>>>> - Go to edit more >>>> What's "edit more"? >>>> >>>>> (I'm still convinced that we need the dashboard >>>>> editing in "view" mode and not in "inline" mode) >>>> What do others think? >>>> Knowing that the current edit in inline mode has a few limitations: >>>> * remove gadget will be saved immediately, not when the user clicks >>>> "save". If the user says remove gadget, confirms the remove and then >>>> clicks the "cancel" button in the edit form, the remove will still be >>>> saved. >>>> * same for add gadget. >>>> >>>> The way I see the two possibilities: >>>> A) "View mode edit" will save on every change >>>> B) "Edit mode edit" (implemented as inline edit, now) will save >>>> everything at the end (current implementation but with the limitations >>>> fixed). >>>> >>>> So, WDYT? >>> -1 for A) >>> >>> I'm definitely for B) "Edit mode edit", not only for consistency, but >>> also for avoiding surprise side effects when interacting with the >>> dashboard. >> Same for me. Users tend to just move things around, accidentally click >> the mouse, and then "things just broke by themselves". >> >>>>> - Add a column in your dashboard >>>>> - Editing a dashboard >>>> you mean editing a gadget? as in the parameters of that gadget? >>>> >>>> Also, I would add to this list, potentially at the top: >>>> - finalizing the structure of the dashboard / gadgets objects, so that >>>> we don't have migration in the next releases (e.g. if we decide to add a >>>> field in the gadget object to identify which is the dashboard of that >>>> gadget, in case there are multiple dashboards on one page, we should do >>>> it now). >>>> >>>> Thanks for the feedback, >>>> Anca >>>> >>>>> Also for the 3.1 timeframe I think we need to have some brainstorm to >>>>> add some more "Dashboard" friendly macros/gadgets to make dashboards >>>>> more usefull and interesting for users, but that's another story. >>>>> Right now I think the most important is that we agree on the priorities >>>>> for the next step and that for 3.0 we have a simple but coherent >>>>> dashboard feature. >>>>> >>>>> Ludovic >> > > > -- > Ludovic Dubost > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > > <ludovic.vcf>_______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Mar 8, 2011 at 9:21 PM, Vincent Massol <[email protected]> wrote: > > On Mar 8, 2011, at 8:53 PM, Ludovic Dubost wrote: > >> >> My proposal about using view mode is not to be in "edit" mode automatically. >> My proposal is to have the "edit" button maybe more visible as well as "Add Widget", and more importantly to have the "edit" button not load the "inline" mode, but load in place. >> Most importantly the "save" buttons don't mean anything as adding a gadget adds an XWiki object and is permanent. Same with moving and removing gadgets. That changes the object right away. > > Actually this is a bug that we need to fix. It's absolutely not normal that when you add objects in the object editor the objects are added even if you cancel the edit Just a gentle reminder and "call for votes" on this issue: http://jira.xwiki.org/jira/browse/XWIKI-500 > > Thanks > -Vincent > >> So we need to "remove" the "save" actions as they won't mean anything. >> >> Ludovic >> >> >> Le 08/03/11 18:07, Sergiu Dumitriu a écrit : >>> On 03/08/2011 05:57 PM, Marta Girdea wrote: >>>> On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<[email protected]> wrote: >>>>> On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote: >>>>>> Hi, >>>>>> >>>>>> I've tried the dashbord on 3.0 snapshot and could not make the "Add >>>>>> Gadget" function work on an empty dashboard. >>>>>> From what I see the issue seems to be in the wysiwyg code. I got the >>>>> no, it's dashboards code, I forgot to handle the case when the column >>>>> where the gadget should be added doesn't actually exist. >>>>> >>>>>> dialog box from the wysiwyg, when clicking on Insert Gadget" I got an >>>>>> exception: >>>>>> >>>>>> uncaught exception: Class$dF: One or more exceptions caught, see full >>>>>> set in UmbrellaException#getCauses >>>>>> at >>>>>> function nr(){try{null.a()}catch(b){return b}} >>>>>> >>>>>> This issue seemed to only happen with an empty dashboard macro (with not >>>>>> gadget yet added). >>>>>> >>>>>> I think we need to work on two things for each feature that we are >>>>>> developping: >>>>>> >>>>>> 1/ Having a status of where we are: >>>>>> >>>>>> In the case of Dashboard, I think that's updating this page: >>>>>> http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized >>>>> I updated the table. There could be new cases, I guess, to comprise the >>>>> missing things (like adding a column when editing, or others a like), >>>>> but I prefer to use Jira issues for these. WDYT? >>>>> >>>>>> 2/ Write a test plan and have Sorin include the testing of new features >>>>>> in his testing. >>>>>> For that he needs to know how to test and what is supposed to be >>>>>> there/not there. >>>>>> >>>>>> Concerning the development priorities, I think for the next period of >>>>>> development on the dashboard we need to focus on wiring the UI for >>>>>> "beginners", making it easy for them to create their first dashboard. In >>>>>> my view this is in priority: >>>>>> >>>>>> - Create page with a dashboard macro (In the Add Menu in XE) >>>>>> - Go to edit more >>>>> What's "edit more"? >>>>> >>>>>> (I'm still convinced that we need the dashboard >>>>>> editing in "view" mode and not in "inline" mode) >>>>> What do others think? >>>>> Knowing that the current edit in inline mode has a few limitations: >>>>> * remove gadget will be saved immediately, not when the user clicks >>>>> "save". If the user says remove gadget, confirms the remove and then >>>>> clicks the "cancel" button in the edit form, the remove will still be >>>>> saved. >>>>> * same for add gadget. >>>>> >>>>> The way I see the two possibilities: >>>>> A) "View mode edit" will save on every change >>>>> B) "Edit mode edit" (implemented as inline edit, now) will save >>>>> everything at the end (current implementation but with the limitations >>>>> fixed). >>>>> >>>>> So, WDYT? >>>> -1 for A) >>>> >>>> I'm definitely for B) "Edit mode edit", not only for consistency, but >>>> also for avoiding surprise side effects when interacting with the >>>> dashboard. >>> Same for me. Users tend to just move things around, accidentally click >>> the mouse, and then "things just broke by themselves". >>> >>>>>> - Add a column in your dashboard >>>>>> - Editing a dashboard >>>>> you mean editing a gadget? as in the parameters of that gadget? >>>>> >>>>> Also, I would add to this list, potentially at the top: >>>>> - finalizing the structure of the dashboard / gadgets objects, so that >>>>> we don't have migration in the next releases (e.g. if we decide to add a >>>>> field in the gadget object to identify which is the dashboard of that >>>>> gadget, in case there are multiple dashboards on one page, we should do >>>>> it now). >>>>> >>>>> Thanks for the feedback, >>>>> Anca >>>>> >>>>>> Also for the 3.1 timeframe I think we need to have some brainstorm to >>>>>> add some more "Dashboard" friendly macros/gadgets to make dashboards >>>>>> more usefull and interesting for users, but that's another story. >>>>>> Right now I think the most important is that we agree on the priorities >>>>>> for the next step and that for 3.0 we have a simple but coherent >>>>>> dashboard feature. >>>>>> >>>>>> Ludovic >>> >> >> >> -- >> Ludovic Dubost >> Blog: http://blog.ludovic.org/ >> XWiki: http://www.xwiki.com >> Skype: ldubost GTalk: ldubost >> >> <ludovic.vcf>_______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
On Mar 8, 2011, at 9:35 PM, Marta Girdea wrote:
On Tue, Mar 8, 2011 at 9:21 PM, Vincent Massol <[email protected]> wrote:
On Mar 8, 2011, at 8:53 PM, Ludovic Dubost wrote:
My proposal about using view mode is not to be in "edit" mode automatically. My proposal is to have the "edit" button maybe more visible as well as "Add Widget", and more importantly to have the "edit" button not load the "inline" mode, but load in place. Most importantly the "save" buttons don't mean anything as adding a gadget adds an XWiki object and is permanent. Same with moving and removing gadgets. That changes the object right away.
Actually this is a bug that we need to fix. It's absolutely not normal that when you add objects in the object editor the objects are added even if you cancel the edit
Just a gentle reminder and "call for votes" on this issue: http://jira.xwiki.org/jira/browse/XWIKI-500
I was going to say that we don't need pseudo versions for this since we just need to keep it in memory till the save button is applied. However the pseudo version solution is interesting as backup solution, i.e. if the page crashes you still get your "unsaved" content available. So indeed it would solve 2 needs at once. Thanks -Vincent
Thanks -Vincent
So we need to "remove" the "save" actions as they won't mean anything.
Ludovic
Le 08/03/11 18:07, Sergiu Dumitriu a écrit :
On 03/08/2011 05:57 PM, Marta Girdea wrote:
On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<[email protected]> wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote: > Hi, > > I've tried the dashbord on 3.0 snapshot and could not make the "Add > Gadget" function work on an empty dashboard. > From what I see the issue seems to be in the wysiwyg code. I got the no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
> dialog box from the wysiwyg, when clicking on Insert Gadget" I got an > exception: > > uncaught exception: Class$dF: One or more exceptions caught, see full > set in UmbrellaException#getCauses > at > function nr(){try{null.a()}catch(b){return b}} > > This issue seemed to only happen with an empty dashboard macro (with not > gadget yet added). > > I think we need to work on two things for each feature that we are > developping: > > 1/ Having a status of where we are: > > In the case of Dashboard, I think that's updating this page: > http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
> 2/ Write a test plan and have Sorin include the testing of new features > in his testing. > For that he needs to know how to test and what is supposed to be > there/not there. > > Concerning the development priorities, I think for the next period of > development on the dashboard we need to focus on wiring the UI for > "beginners", making it easy for them to create their first dashboard. In > my view this is in priority: > > - Create page with a dashboard macro (In the Add Menu in XE) > - Go to edit more What's "edit more"?
> (I'm still convinced that we need the dashboard > editing in "view" mode and not in "inline" mode) What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
So, WDYT? -1 for A)
I'm definitely for B) "Edit mode edit", not only for consistency, but also for avoiding surprise side effects when interacting with the dashboard. Same for me. Users tend to just move things around, accidentally click the mouse, and then "things just broke by themselves".
> - Add a column in your dashboard > - Editing a dashboard you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
> Also for the 3.1 timeframe I think we need to have some brainstorm to > add some more "Dashboard" friendly macros/gadgets to make dashboards > more usefull and interesting for users, but that's another story. > Right now I think the most important is that we agree on the priorities > for the next step and that for 3.0 we have a simple but coherent > dashboard feature. > > Ludovic
On Tue, 2011-03-08 at 20:53 +0100, Ludovic Dubost wrote: > My proposal about using view mode is not to be in "edit" mode automatically. > My proposal is to have the "edit" button maybe more visible as well as > "Add Widget", and more importantly to have the "edit" button not load > the "inline" mode, but load in place. So the idea is to have an edit button, next to an add gadget button in the view mode? Edit would allow to drag & drop, add would add automatically? How about the gadget handlers (remove and edit gadget params)? when do those appear? Could you draw something somewhere (a mockup of some sort)? I think if we want to do it like this we need to find a coherent way of displaying these actions. I don't understand what loading in place means? That you have all the view from view mode (panels, etc) and not an extra page load? We could do some little ajax hacks to make is seem as "in place", but why is it so important? > Most importantly the "save" buttons don't mean anything as adding a > gadget adds an XWiki object and is permanent. Same with moving and > removing gadgets. That changes the object right away. Moving is not saved right away, only save and remove (as I mentioned in my email above). > So we need to "remove" the "save" actions as they won't mean anything. Or we could make it work properly. > > Ludovic > > > Le 08/03/11 18:07, Sergiu Dumitriu a écrit : > > On 03/08/2011 05:57 PM, Marta Girdea wrote: > >> On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<[email protected]> wrote: > >>> On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote: > >>>> Hi, > >>>> > >>>> I've tried the dashbord on 3.0 snapshot and could not make the "Add > >>>> Gadget" function work on an empty dashboard. > >>>> From what I see the issue seems to be in the wysiwyg code. I got the > >>> no, it's dashboards code, I forgot to handle the case when the column > >>> where the gadget should be added doesn't actually exist. > >>> > >>>> dialog box from the wysiwyg, when clicking on Insert Gadget" I got an > >>>> exception: > >>>> > >>>> uncaught exception: Class$dF: One or more exceptions caught, see full > >>>> set in UmbrellaException#getCauses > >>>> at > >>>> function nr(){try{null.a()}catch(b){return b}} > >>>> > >>>> This issue seemed to only happen with an empty dashboard macro (with not > >>>> gadget yet added). > >>>> > >>>> I think we need to work on two things for each feature that we are > >>>> developping: > >>>> > >>>> 1/ Having a status of where we are: > >>>> > >>>> In the case of Dashboard, I think that's updating this page: > >>>> http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized > >>> I updated the table. There could be new cases, I guess, to comprise the > >>> missing things (like adding a column when editing, or others a like), > >>> but I prefer to use Jira issues for these. WDYT? > >>> > >>>> 2/ Write a test plan and have Sorin include the testing of new features > >>>> in his testing. > >>>> For that he needs to know how to test and what is supposed to be > >>>> there/not there. > >>>> > >>>> Concerning the development priorities, I think for the next period of > >>>> development on the dashboard we need to focus on wiring the UI for > >>>> "beginners", making it easy for them to create their first dashboard. In > >>>> my view this is in priority: > >>>> > >>>> - Create page with a dashboard macro (In the Add Menu in XE) > >>>> - Go to edit more > >>> What's "edit more"? > >>> > >>>> (I'm still convinced that we need the dashboard > >>>> editing in "view" mode and not in "inline" mode) > >>> What do others think? > >>> Knowing that the current edit in inline mode has a few limitations: > >>> * remove gadget will be saved immediately, not when the user clicks > >>> "save". If the user says remove gadget, confirms the remove and then > >>> clicks the "cancel" button in the edit form, the remove will still be > >>> saved. > >>> * same for add gadget. > >>> > >>> The way I see the two possibilities: > >>> A) "View mode edit" will save on every change > >>> B) "Edit mode edit" (implemented as inline edit, now) will save > >>> everything at the end (current implementation but with the limitations > >>> fixed). > >>> > >>> So, WDYT? > >> -1 for A) > >> > >> I'm definitely for B) "Edit mode edit", not only for consistency, but > >> also for avoiding surprise side effects when interacting with the > >> dashboard. > > Same for me. Users tend to just move things around, accidentally click > > the mouse, and then "things just broke by themselves". > > > >>>> - Add a column in your dashboard > >>>> - Editing a dashboard > >>> you mean editing a gadget? as in the parameters of that gadget? > >>> > >>> Also, I would add to this list, potentially at the top: > >>> - finalizing the structure of the dashboard / gadgets objects, so that > >>> we don't have migration in the next releases (e.g. if we decide to add a > >>> field in the gadget object to identify which is the dashboard of that > >>> gadget, in case there are multiple dashboards on one page, we should do > >>> it now). > >>> > >>> Thanks for the feedback, > >>> Anca > >>> > >>>> Also for the 3.1 timeframe I think we need to have some brainstorm to > >>>> add some more "Dashboard" friendly macros/gadgets to make dashboards > >>>> more usefull and interesting for users, but that's another story. > >>>> Right now I think the most important is that we agree on the priorities > >>>> for the next step and that for 3.0 we have a simple but coherent > >>>> dashboard feature. > >>>> > >>>> Ludovic > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
On 03/08/2011 04:01 PM, Luca Anca wrote:
On Sat, 2011-03-05 at 12:44 +0100, Ludovic Dubost wrote:
Hi,
I've tried the dashbord on 3.0 snapshot and could not make the "Add Gadget" function work on an empty dashboard. From what I see the issue seems to be in the wysiwyg code. I got the
no, it's dashboards code, I forgot to handle the case when the column where the gadget should be added doesn't actually exist.
dialog box from the wysiwyg, when clicking on Insert Gadget" I got an exception:
uncaught exception: Class$dF: One or more exceptions caught, see full set in UmbrellaException#getCauses at function nr(){try{null.a()}catch(b){return b}}
This issue seemed to only happen with an empty dashboard macro (with not gadget yet added).
I think we need to work on two things for each feature that we are developping:
1/ Having a status of where we are:
In the case of Dashboard, I think that's updating this page: http://dev.xwiki.org/xwiki/bin/view/Design/Gadget+Scenarios+Prioritized
I updated the table. There could be new cases, I guess, to comprise the missing things (like adding a column when editing, or others a like), but I prefer to use Jira issues for these. WDYT?
2/ Write a test plan and have Sorin include the testing of new features in his testing. For that he needs to know how to test and what is supposed to be there/not there.
Concerning the development priorities, I think for the next period of development on the dashboard we need to focus on wiring the UI for "beginners", making it easy for them to create their first dashboard. In my view this is in priority:
- Create page with a dashboard macro (In the Add Menu in XE) - Go to edit more
What's "edit more"?
(I'm still convinced that we need the dashboard editing in "view" mode and not in "inline" mode)
What do others think? Knowing that the current edit in inline mode has a few limitations: * remove gadget will be saved immediately, not when the user clicks "save". If the user says remove gadget, confirms the remove and then clicks the "cancel" button in the edit form, the remove will still be saved. * same for add gadget.
The way I see the two possibilities: A) "View mode edit" will save on every change B) "Edit mode edit" (implemented as inline edit, now) will save everything at the end (current implementation but with the limitations fixed).
-1 for View mode, it's much too easy to break things unintentionally. Take a look at what Gnome 3 does, it removes almost all configuration possibilities, in favor of a consistent and error-proof environment.
So, WDYT?
- Add a column in your dashboard - Editing a dashboard
you mean editing a gadget? as in the parameters of that gadget?
Also, I would add to this list, potentially at the top: - finalizing the structure of the dashboard / gadgets objects, so that we don't have migration in the next releases (e.g. if we decide to add a field in the gadget object to identify which is the dashboard of that gadget, in case there are multiple dashboards on one page, we should do it now).
Thanks for the feedback, Anca
Also for the 3.1 timeframe I think we need to have some brainstorm to add some more "Dashboard" friendly macros/gadgets to make dashboards more usefull and interesting for users, but that's another story. Right now I think the most important is that we agree on the priorities for the next step and that for 3.0 we have a simple but coherent dashboard feature.
Ludovic
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (7)
-
Guillaume Lerouge -
Jerome Velociter -
Luca Anca -
Ludovic Dubost -
Marta Girdea -
Sergiu Dumitriu -
Vincent Massol