[xwiki-devs] [Discussion] Customize button for the dashboard

Luca Anca lucaa at xwiki.com
Thu Mar 24 17:41:27 UTC 2011


On Thu, 2011-03-24 at 03:47 +0100, Sergiu Dumitriu wrote:
> On 03/22/2011 05:26 PM, Luca Anca wrote:
> > Hi all,
> >
> > I've got some suggestions that the current way of editing the dashboard
> > is not really intuitive (Edit ->  Inline Form), and mainly because users
> > wouldn't necessarily look under "Edit" for a method to change the
> > dashboard. Also, other users that I've observed, forgot that they need
> > to go in some edit mode before changing things.
> >
> > I also agree that without documentation no user would figure out that
> > editing a dashboard is under Edit ->  Inline Form. While editing will
> > still remain "in inline mode", from the technical pov, we need to
> > provide a easier way for users to discover this.
> >
> > Let's look at the following options:
> 
> One important thing to keep in mind is that most users don't have a 
> submenu under Edit, just the one top menu entry.
> 
> > 1/ Add a "Customize" menu entry under edit, in the page menu, as
> > proposed in the mockups from Cati, a long time ago:
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/GadgetsDashboard .
> 
> Doesn't work for simple users.
> 
> > 2/ Add a "Customize this dashboard" button in the dashboard in view
> > mode, in the top right corner, something like
> > http://dev.xwiki.org/xwiki/bin/download/Design/GadgetIntegration/oldDashboardCustomize.png but styled better to integrate with the current dashboard.
> 
> Best thing from a discoverability PoV, but stands in the way of a clean UI.
> 
> > 3/ Define and implement a mechanism to allow the inline form edit to be
> > triggered for a document without that document having to include a
> > document which has an object in it. E.g. as Vincent proposed at one
> > point, trigger inline mode when an object is present in the current
> > document.
> >
> > I should note that solutions 1 and 3 still assume that the user will go
> > to "Edit" to try to customize the dashboard, which can also be
> > problematic (I cannot figure it out for sure right now, we need fresh
> > users or proper UX expertise which I don't have).
> 
> Well, everything in XWiki should be editable this way. Users should 
> learn this. Eventually they will look for an "Edit" link or button, and 
> they will click on it.
> 
> How does this fit with the idea that every user should have his own 
> dashboard?

If editing a dashboard that is defined in this document {{dashboard}}
macro call is in this document but the data is stored someplace else (in
the user document) is possible, then it fits well. 
I'm not sure I understand what the question is about, from which pov?

> 
> The main homepage is problematic since it includes a dashboard defined 
> somewhere else. It's wrong, IMO, to even offer to edit a dashboard 
> that's somewhere else in the context of another document, using the edit 
> mode of that document. It's like allowing to edit the {{include}}d 
> documents.

This is a very interesting discussion that you opened here. In
particular, if the current document "{{include}}s" a document with a
dashboard, you can still edit it, with the same warning.

My first thought was to tell the user: "you cannot edit this dashboard,
since it's not defined in this document. Go to document X if you want to
edit, it, that's where it's defined." But nothing guarantees that
document X actually displays a dashboard (has a {{dashboard}} call
inside), it could have only the objects. I know it's not really ok, I
don't like it that much either, but it's sort of the most friendly
solution I could think of.

Also, I liked this solution because I had a way to warn the users that
their changes might impact all other docs using that dashboard.

However, in my view, the usage of another doc's objects in the current
dashboard should not be used very often (only by people knowing quite
well what they do). I introduced it to preserve the possibility to use
Main.Dashboard as a "template" dashboard, for space webhomes et all, and
to prevent recopying and recopying the same objects over and over again
in every space webhome.

> 
> 
> In conclusion, it depends on what is going to be edited. If the 
> dashboard is supposed to be defined in the current document, then it 
> should be edited inline using the normal edit button.
> 
> If it's required to be able to edit dashboards that are just living 
> inside a document, while their data resides someplace else, then the 
> inline edit mode is completely wrong. It will mess with the rest of the 
> page. 

What other things?

> In this case, a button inside the dashboard UI itself is best.

That will go to which document's edit mode?

Thanks a lot,
Anca





More information about the devs mailing list