[xwiki-devs] Editing dashboards: "view" mode or "edit" mode? ( was Re: Testing Dashboards in 3.0 snapshot )

Sergiu Dumitriu sergiu at xwiki.com
Tue Mar 8 17:07:49 UTC 2011

On 03/08/2011 05:57 PM, Marta Girdea wrote:
> On Tue, Mar 8, 2011 at 4:01 PM, Luca Anca<lucaa at xwiki.com>  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

More information about the devs mailing list