24 Mar
2011
24 Mar
'11
6:41 p.m.
On Thu, 2011-03-24 at 03:47 +0100, Sergiu Dumitriu wrote:
On 03/22/2011 05:26 PM, Luca Anca wrote:
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?
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/oldDashboa…
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?
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