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/oldDashboar... 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