Implementation
 Completed

Description

Description

The aim of the gadget integration is to provide XWiki users with a dashboard-like page that will display a list of gadgets. These gadgets can be either internal gadgets (similar to XWiki panels) or external gadgets (coming from the Google Gadget repository for instance). Users can select which gadgets to display on their dashboard from a gadget directory located on the wiki.

Basic technical details

  • use the existing panel class
  • add a "URL" field to the panel class to reference external gadgets
  • personal dashboard of gadgets for each user
  • create a ?xpage=dashboard view for the User profile
  • on that view of the user profile, display a gadget dashboard similar to iGoogle
  • create a list of gadgets / panels from the current wiki
  • access to the google directory of gadgets

Main Elements

Dashboard Macro

A Dashboard will display XWiki and Google Gadgets grouped in columns, and will support drag&drop inside and between the columns (iGoogle like).

Dashboards can be added to any document as Dashboard macros. Also, each user will have a Personal Dashboard on their profile page.

Personal Dashboard Privacy Settings
 We could let each user decide whether her dashboard should be public. However the default setting should be private:

  • If the current user has admin rights: shows gadgets of the profileURL user
  • If the profileURL user has set her dashboard to private & the current user isn't an admin -> don't show the gadgets
  • If the profileURL user has set her dashboard to public -> show it

Implementation details. Use:

Dashboard Macro

  • Parameters: dashboard name, and (maybe) number of columns

Dashboard Velocity Macro Syntax

Option 1) One row per gadget, preceeded by the column number

This is the option currently implemented in the demos linked from the bottom of the page and the code in the sandbox.

{{dashboard name="<dashboard name>" cols="<number of columns>"}}
<column number1> <gadget macro1>
<column number2> <gadget macro2>
...
{{/dashboard}}

{{dashboard name="My Dashboard" cols="3"}}
1 {{gadget /}}  // this gadget is displayed on column 1
1 {{gadget /}}  // this gadget is displayed on column 1, under the one above
3 {{gadget /}}
3 {{gadget /}}
3 {{gadget /}}
{{/dashboard}}

Result:
G1  - G3
G2  G4
  G5

Drawbacks:

  • defines a meta syntax for the content of the dashboard macro (one line per gadget, column number separated with a space from gadget, etc)
  • implementation uses parsing of the macro content as string with regular expressions
  • in this current form, it does not allow layouts more complex than a number of equally sized columns (and extensions of the allowed layouts would require extensions of the meta-syntax, which only make it more complicate)
Option 2) One row per column
{{dashboard name="<dashboard name>" cols="<number of columns>"}}
<gadget macro1i>...   // all gadgets on column 1 (stacked)
<gadget macro2i>...   // all gadgets on column 2 (stacked)
<gadget macro3i>...   // all gadgets on column 3 (stacked)
{{/dashboard}}

{{dashboard name="My Dashboard" cols="3"}}
{{gadget /}} {{gadget /}}  // this gadget is displayed on column 1
     // no gadgets on column 2, so line empty
{{gadget /}} {{gadget /}} {{gadget /}}
{{/dashboard}}

Result:
G1 - G3
G2  G4
  G5
Option 3) Dashboard stored in an object
Option 3
{{dashboard name="Space.Page"/}}

, where Space.Page contains the XWiki Dashboard object; The object contains the gadgets contained by the dashboard, their order and parameters

Option 4) Column macro for layouting, dashboard extends column macro

Column macro refers to Column Macro (which would be moved to the platform macros). The idea is that, unlike options 1 and 2 above, the dashboard macro does not use a meta-syntax inside, but only regular xwiki 2.0 syntax, and uses the column macro to do the layout. Since the dashboard macro should not be about much more than layout, the dashboard macro would only extend the sections macro (the one specifying that a columns section starts). This differentiation between dashboard and regular section macro is important because: 1/ it would ignore all content which is not an instance of a gadget macro (only a macro from the "gadgets" category can be used as a macro, any other wiki syntax is ignored) 2/ it will have custom behaviour on editing (inline editing) -- drag and drop, editing macros/gadgets parameters, etc, 3/ in general it's good to know whether something is a dashboard or only columns layout (it's semantic).

Implementation of the dashboard macro would be based on manipulating XDOM instead of parsing meta-syntax with regular expressions (as the current implementation for 1 does).

Since section / column macros can be nested, it's very easy to create complex layouts (with split columns, etc), and also, all layouting contributions added for the purpose of dashboard (e.g. percent width columns) would be improvements to the columns layouting in general.

With this implementation, sizes of the gadgets would be controlled by the dashboard's column layout, the gadgets are not responsible for declaring and setting their sizes (same is on iGoogle, gadgets are all scaled to fit the width of the column, whichever that is). However, if a gadget would want to have a specific size, it could have it (in the end a gadget can generate whatever html it wants). This allows good usage of existing xwiki macros as gadgets, since they don't need more parameters or extra code to work in a dashboard. For the gadget title, we could decide that the dahsboard macro would read the title from a gadget parameter but this can create problems with existing parameters of that macro, or we could decide that a gadget is responsible for exposing its own title. As well, the dashboard macro could add extra html around its gadgets in view mode (for decoration purposes) or could just render them as they are.

{{dashboard name="my dashboard" style="gnome"}}
{{column}}
{{gadget /}} {{gadget /}}
{{gadget /}}
{{/column}}

{{column}}
{{gadget /}} {{gadget /}}
{{section}}
{{column}} ... {{/column}}

{{column}} ... {{/column}}
{{/section}}
{{/column}}
{{/dashboard}}
Implementation

In view mode, the dashboard macro will only display the content inside, parsed as wiki syntax, just like the section macro does (no special containers for the gagdets, no extra divs or anything). There is a choice to make about filtering the syntax which does not represent macro calls:

  1. filter all wiki syntax which is not a (gadget) macro call, assuming that only macros in a specific category could be used as gadgets. This approach comes from the fact that the dashboard editor will not be able to edit these random wiki syntax sections, and limiting its content will make the 2 ways of editing the dashboard consistent: what can be created from editing wiki sytnax can also be created from the editor.
  2. don't filter syntax. Allow power users to create more complex dashboards from the wiki editor, even if from the dashboard editor only gadget macros can be manipulated. Build the dashboard such that it can still edit as much as possible the gadgets, even in this case. The con for this approach is that users might find this confusing, they might not be able to reproduce some dashboards that they see and don't understand why, and also the dashboard editor could be slightly more error prone, and inconsistency prone.

In edit mode, the idea is that editing would be done in the inline edit mode for the document containing the dashboard. The dashboard should be rendered just like in view mode only that with annotated html syntax, by passing the outputSyntax parameter to the inline edit URL, with a jsx loaded by the dashboard macro only in inline mode. The dashboard javascript will identify the gadgets in the dashboard by the annotated html comments and allow users to manipulate these gadgets. These changes will be saved in the document by using a hidden input for the document content in wiki syntax, which will be updated to the new value by the dashboard javascript, with an ajax call to a server service (REST resource). Since modifying the annotated html resulted from a macro rendering does not automatically parse back to wiki syntax using the html parser, but the content of the macros needs to be updated (think about the case of a gadget being moved from a column to another, the content of the toplevel dashboard macro needs to be updated), there are 2 approaches we could take:

  1. when something is changed on the client (move a gadget from a column to another, add a gadget, delete a gadget) the js on the client will have the new HTML corresponding to the new content but with outdated annotations. It will send this content to the service, along with a method to identify the dashboard which is being edited in the page (id, for example). The server will parse the DOM of this HTML to obtain the new dashboard macro content by going to the leaf level macros (all macros that don't contain section / column macros anymore) and parse these back to wiki syntax, and so on going up on the parent generating the wiki syntax content of the nested column macros, section macros and finally the toplevel dashboard macro. Note that such a parser doesn't exist yet, it needs to be implemented for this purpose. The updated dashboard macro block such obtained will replace the edited dashboard node in the XDOM of the document (identified by the id), and the serialization as wiki syntax will be the new content of the document, sent as a response to the client to be set in the appropriate content hidden input to be saved.
    • pros: inline with the idea of the wyiswyg editor, which is based on parsing the annotated XHTML back into wiki syntax; only one point of custom model, namely parsing the edited XHTML with outdated annotations, which can be isolated in a single class.
    • cons: quite complicated to understand the flow, how the changes on the client endup being reflected in the wiki content of the page; custom parser for the modified HTML to be parsed in the updated dashboard macro call can be non-trivial;
  2. given that there is a 1-1 correspondence between the tree of gadgets / layout elements inside the dashboard and the corresponding XDOM nodes, an operation based editing can be used: everytime something changes on the client (add gadget, move gadget from a column to another, etc) the operation is sent to the server along with its parameters (name, parameters and position of the added gadget or the initial position and final position of the moved gadget, etc), where it is operated on the XDOM of the document and the serialization as wiki syntax of this xdom is sent as the result to the client, to be set in the appropriate content hidden input to be saved.
    • pros: clear, easy to understand approach, good mapping between the operations that the client js will use anyway (add, edit params, delete, move, etc) to server side operations on the content; 
    • cons: different model, needs a bit of scaffolding to define the model for operations, etc; quite limiting (in terms of allowing extra actions in the future on the dashboard), it really depends on the ability to split user actions on the dashboard in serializable operations in a way which makes them reproducible on the server side; applying operations on the server side XDOM is not straightforward either, because the whole tree does not exist at any point (it's just a single Dashboard macro node, with its wiki 2.0 content holding the column macro calls and the gadget macro calls)

Note that the transformation of changes in XHTML to changes in wiki can be done either on each operation, to be kept in sync all the time, or all at the end. Various user interaction tricks can be used to make all this transparent to the user.

Option 5) Gadget entries stored in objects, dashboard macro only pinpoints the position in the page

The whole point of this approach is to make it easy to edit the dashboard by storing gadgets in structured content, rather than unstructured, wiki syntax.

Gadgets could be stored in objects in the page, and the dashboard macro ({{dashboard  /}}) will read all these objects and draw the dashboard. The objects, DashboardEntry, will contain the following fields:

  • title, which could be velocity code to allow translations
  • content, which will be wiki syntax. In the case of a gadget added from a macro, it will be a macro call. A + for this case is that this allows to easily adding "one time gadgets" without necessarily creating a macro for it
  • position, free field which will make sense depending on the layout chosen for the dashboard. As we thought of it now, it should be a pair of numbers, (container, index), which will allow a gadget to identify the container in which to be placed (e.g. a column index in case of a columns dashboard or more general, an identifier), and its index inside that container. Generally, all layouts should have the notion of gadget container, an element (XDOM or HTML) where gadgets can be placed inside that layout, to differentiate, for XDOM or HTML, these elements from other layout elements.
  • potentially we could add a dashboard name, to allow gadgets for multiple dashboard in the same document.

The dashboard macro will work as following:

  • it will take, as today, a layoutStyle parameter, which will point to predefined layouts. By default, the style will be columns. The number of columns to layout will be taken from the number of columns specified in the dashboard entry objects in the position field
  • when layoutStyle is missing, a layoutType parameter will specify a syntax for the layout of the dashboard (e.g. xul or html) and the content of the dashboard will be a piece of containers definition in this syntax, with ids to identify them. The only restriction for the layout specification is to be convertible in XDOM, since the dashboard macro needs it in XDOM for rendering the gadgets inside -- This will not be implemented right away as the 80% case, the columns layout is addressed by a predefined layout.
  • All this information can be stored in an object, to allow editing the dashboard layout without changing the content of the document (which as we've seen above in option 4), is not easy).
  • A "source" parameter can be added to the dashboard, to specify the document to read the dashboard entry objects from.

Besides making the editing easier, as the editing code will manipulate real structured data instead of having to make sense of the wiki syntax, this approach also allows to have a dashboard macro in a velocity script, thus making it easier for rights checking, or personal dashboards implementation, or dashboards added with the {{include}}  macro.

Also, because data is more structured than in option 4), it will be easier for a velocity script, for example, to manipulate a dashboard programatically (XDOM can be a bit incomfortable to manipulate in velocity).

Wysiwyg editing of the dashboard

Option 1) NO WYSIWYG preview, adding Gadgets through Gadgets/Macros Directory or macro content field

  • WYSIWYG Insertion: no Preview [Mockup]
  • result after insertion (view mode): empty dashboard with appropriate message and a 'Add more gadgets' button at the top which goes to Gadgets/Macros Directory [Mockup]
  • adding Gadgets to the Dashboard (2 alternative ways):
    • by editing the Dashboard macro and writing wiki syntax (for the gadget macros) in the content text area
    • through the Gadgets/Macros Directory; user clicks 'Add more gadgets' on dashboard which sends user to Gadgets/Macros Directory, from where gadgets are added by clicking 'Add it now' buttons next to gadgets/macros

Option 2) WYSIWYG preview, adding Gadgets through WYSIWYG Macro Insertion dialog

  • WYSIWYG Insertion: with Preview (Add/Edit/Delete/Drag&Drop gadgets on the dashboard from here) [Mockup]
  • result after insertion (view mode): dashboard with gadgets and a 'Add more gadgets' button at the top which goes to Gadgets/Macros Directory
  • adding Gadgets to the Dashboard (2 alternative ways):
    • through WYSIWYG Macro Insertion dialog
    • through the Gadgets/Macros Directory; user clicks 'Add more gadgets' on dashboard which sends user to Gadgets/Macros Directory, from where gadgets are added by clicking 'Add it now' buttons next to gadgets/macros

Gadgets Directory

Local Directory
 There will be an internal gadget directory in the wiki. This directory will be divided in 3 parts:

  • XWiki Gadgets defined in the wiki / in the farm (current Panels)
  • Google Gadgets selected out of the global Google Directory by wiki admins
  • If allowed by wiki admins: full Google Gadgets Directory

The Local Directory should contain have a list relevant Gadgets for the wiki; safe / approved / checked if works by admins; relatively small list (compared to Google Gadget Directory).

Adding Gadgets to the Dashboard
 Users can add gadgets from the local repository. If the local repository lets the access to all Google gadgets open, any Google gadget can be added (after being added to the Local Directory in the background)

Adding Gadgets to the Directory
 Who can add gadgets to the wiki directory: Admins or Users or configurable? Configurable:

  • Only admins
  • Users with admin validation
  • Users without validation

Gadget Macro/s: One or Multiple Gadget Macros?

Option 1) A single Gadget Macro

A gadget macro would look like:
 {{gadget type="Gadgets.GoogleDocs" width="100" title="some title" GD_userpref1="val1" GD_userpref2="val2" ... /}}
 or
 {{gadget type="Gadgets.GoogleDocs" width="100" title="some title" userprefs="GD_userpref1=val1&GD_userpref2=val2&..." /}}

, where Gadgets.GoogleDocs, is the document which describes the specific Gadget; can also be a Panels.PanelName for XWiki Gadgets

Option 2) Multiple gadget macros, one for each Gadget

The gadget macros would look like:
 {{googledocs height="100" width="100" title="some title" GDocs_userpref1="val1" GDocs_userpref2="val2" ... /}}
 {{worldclocks height="100" width="100" title="some title" WC_userpref1="val1" WC_userpref2="val2" ... /}}

, where GD_userprefi are the User Preferences specific to Google Docs gadget, and WC_userprefi are the User Preferences specific to WorldClocks Gadget. The User Preferences are defined within a gadget's XML by the Gadget's creators.

Consequnces Option 2)

  • Two different actions: (1) "import" gadgets (mostly for admins/but also users - configurable) (2) add gadgets (already transformed into macros) to the Dashboard (any user)
  • Need for a Macro Directory (instead of a Gadget Directory) (Manage Macros from here: edit/import/delete)
  • Would Add Macro to my Dashboars/Any Dashboard/Panel action in the Macros Directory still make sense? (Similar to "Add Macro to my Dashboars/Any Dashboard/Panel" action in the Gadgets Directory)

Pro Option 2)

  • Use the same WYSIWYG insert macro dialog for Gadgets too

Cons/Questions Option 2)

  • Macro name conflict with regular macros; but solved with the "gadget:" namespace prefix (see Option 3)
  • Wiki macro authors need to have programming rights (to "import" gadgets from Google Directory as XWiki macro) & macros can be defined only in the main wiki of a XEM => In the future, any user should be able to "import" a gadget, provided he has write access to the space where the gadget is imported; Some Macros might not be visible to some other users. This could be solved by allowing users to "import" gadgets in only one space (e.g. Macros space)

Option 3) Multiple gadget macros with namespace prefix

To distinguish easily between the other macros and Gadgets (and have different namespaces), we could prefix the Gadgets with the 'gadget' prefix, like:
 {{gadget:googledocs ...}} and {{gadget:worldclocks ...}}, as Marius Florea suggested.

Panel Wizard

Gadgets Directory vs. Panel Wizard (differences/why distinct?)
Gadgets Directory:

  • must be accessible to all users
  • Role: allows all users to browse all Gadgets and add them to a dashboard macro, personal dashboard or even a side panel container (only admins)

Panel Wizard:

  • must be accessible only to Admins
  • Role: customize the side menus, how many panels to display and in which order; specify the content of these panels (which Gadgets to display by picking them up from the Gadgets Directory)

Option 1) Panels become only empty containers with no content (empty shells)

The Panel Wizard would only let you specify how many panel-container to put and where to put them and once you've defined where panels will be, you populate them using the XWiki/Google Gadget Directory. The Admin will drag&drip the shell panels into the side panels and rearrange them also by drag&drop. http://incubator.myxwiki.org/xwiki/bin/download/Mockups/GadgetsIntegration/gadgetsIntegrationProposal1PanelWizard.png
See mockup

Option 2) Gadgets also displayed in the Panel Wizard, in addition to the Gadgets Directory

The Admins will have direct access in the Panel Wizard to the XWiki/Google Gadget Directory by displaying the Gadgets in the Panel Wizard. The Gadgets won't be completely rendered, but have displayed just the tile, thumbnail and a small description and paged in such way that user won't need to scroll down. The will drag&drop the gadgets into the side panels.

Cons Option 2)

  • The functionality of browsing gadgets will be duplicated in 2 places

Option 3) Have a mini representation of the layout

The mini representation of the layout will have side columns with small boxes in place of the gadgets, that can be rearranged inside and between the columns. Each gadget will only display the title of the gadget, and edit and delete button. In each of the side columns, an Add Gadget link will be displayed. Both the Add gadget and the edit will open the WYSIWYG insert macro dialog box, respectively modify macro dialog box.
See mockup

XWiki as Open Social Container

In the following section, when discussing about Open Social gadgets, we will refer to the specification at http://opensocial-resources.googlecode.com/svn/spec/1.0/OpenSocial-Specification.xml and the target is to build a Core Gadget Container as per the compliance specification in that reference. It means that XWiki will be a gadget container but will not provide the social api for these gadgets to use (at least for the moment). A few terms will be used in this section and, to make sure they mean the same thing for everybody, here's the list:

  • XWiki Gadgets System -- a system of gadgets to be used to build dashboards with gadgets for xwiki (which is the target of this proposal), regardless of whether these gadgets are according to the open social spec or not (implementation could be any).
  • Open Social Gadget -- a gadget published somewhere in the www, using the open social specification for gadgets definition.
  • XWiki Gadget -- a gadget to be used on such a dashboard in XWiki which contains information from the wiki, regardless of the implementation (it's not necessarily an open social gadget, but it could be).

Using external open social gadgets in an XWiki Dashboard

This section is to discuss how will the external open social gadgets (google gadgets or other) be used inside the XWiki gadgets system. There are 2 issues to discuss, the usage paradigm and the actual technical solution. First the usage:

Option 1) Import before use, potentially by admin

this means that before they can be used in a dashboard, a gadget must be imported and approved by an admin, who would specify the gadget definition XML, to be handled (and potentially transformed in some sort of XWiki representation of gadgets) by the gadgets component.

Pros: there is control of what code gets to be executed in XWiki, there can be a coherent gadgets directory built (based on the gadgets already imported), it allows specialized handling of the gadgets when added to the dashboard or to a page, in terms of form used for the user preferences

Cons: less freedom for users / developers to use whatever they want as gadgets, there's an extra step to be done, potential bloat of the wiki by importing one-time-use gadgets

Option 2) Use by (any) definition URL, and list of parameters

this means that when a user will want to add a gadget to a dashboard, they would only specify the url to the XML specification of the gadget, along with the user preferences to be used for the gadgets instance. Control could also be added in terms of domain from which gadgets are approved.

Pros: more freedom for the developers (as any gadget could be used just by a link to its definition URL), less bloat

Cons: less control of what code gets executed in the wiki, no control of the versions of the gadget used (the XML definition would automatically be read when used)

Note that even if option 1) is implemented, the pros of option 2) can be achieved by allowing import to everybody, or creating a 'generic gadget' gadget, which would read an XML spec and render the gadget in it.

The second discussion is about the technologies used to implement the open social core gadget container in xwiki. One approach is the partial integration of Apache Shindig as it was started during the GSoC by AnaMaria.

In the existing implementation, the imported google gadgets are rendered using the google container, by creating the HTML used by google to allow embedding of these gadgets in web pages (however I didn't find the documentation for that). Should we keep this approach?

Publishing XWiki Gadgets as open social gadgets

Gadgets used on the xwiki dashboard, if not coming from imported open social gadgets, should also be published as open social gadgets, as well as any other wiki content that might be interesting as a gadget to be used in other open social containers. According to the opensocial standard, the only thing needed to be done to publish a gadget is to make available its XML specification, which contains preferences definition and gadget content (either as an URL to be requested everytime the gadget it rendered or directly as html + javascript to be rendered by the container).

One of the choices to be made is about the human assistance in defining these gadgets. It can be:

Option 1) Automatic generation of the gadgets specification

potentially from a Gadget XWiki object, which will define the parameters of the gadget and the content of the gadget (either wiki code to be executed for a gadget with content to be fetched from url) or html and javascript for html gadgets. This gadget object could be generated, for the gadgets defined as xwiki macros (see [[Option 2 >> GadgetIntegration#HOption229Multiplegadgetmacros2ConeforeachGadget]] above), automatically from the macros specification: params and content would become user preferences, etc. Also the gadget object could be automatically generated for a wiki document which could be published as a gadget with the click of a button. The generation of the XML or of the gadget content (when requested by the container) could also be done through an action, or a template.

Option 2) Manual specification of the gadgets

basically it means that we either leave it to the developers to handle XML definition, or use a single Gadget XWiki Object to specify the XML with better UIs, but do little to no assistance in automatically transforming a page / macro into a gadget.

This is more an option of whether we think it's very important to automatically generate it and easen the developer's job or not generate it.

Another aspect to decide is whether it's important to allow users/ developers to "write gadgets" in wiki syntax in a wiki style gadgets spec, or only allow html & js specification of the gadgets.

Option A) favor gadgets in wiki syntax

and implement all mechanisms for the wiki syntax to be published as a gadget (see Option 1) above). These mechanisms might include automatic generation of html from the wiki syntax, but, since user preferences / parameters must be taken into account, it might not be straightforward.

Option B) gadgets are HTML & JS or hrefs

and basically leave it to the user if they want to transform a piece of wiki syntax  / page in a gadget, to handle the transformation of the content generated from wiki syntax into gadget content. This would favor developers that have experience with gadgets and know the paradigm, and expect gadgets to be written in HTML & JS, as per the specs.

Full Proposals

The important aspects to discuss when it comes to full proposals of supporting (open social) gadgets in xwiki are:

  1. how will a gadget be represented in the xwiki gadgets system (from a technical point of view)
  2. implementation of XWiki as an Open Social Container (see above) -- use external gadgets and publish data as gadgets
  3. what is a Dashboard (from a technical pov) and how does it contain its gadgets

After making the above issues clear, additional concerns such as the gadgets directory, the interaction with the gadgets dashboard, etc, can be built on top. Based on the individual options for the aspects above, there are 2 proposals:

Proposal A - Gadgets are XWiki macros

The dashboard is a macro and it contains macros inside so that gadgets are xwiki macros, any xwiki macro can be used as a gadget.

  • open social gadgets are imported in the wiki (option 1) above) as macros, each gadget in an individual macro (option 2) above)
  • existing xwiki macros can be used alongside gadget macros in the dashboard
  • automatic export of xwiki macros to open social macros should be implemented to allow publishing XWiki gadgets as open social gadgets (option 1) above )

The idea is that, in the xwiki gadgets system, the gadgets are macros and all macros can be used as gadgets, and mechanisms will be provided to import from and export to the open social format.

Gadgets, because they are macros, will be usable in any xwiki document.

Pros:

  • each gadget has its own type (the macro to which it's imported) which is well defined: we know all params and the types of these params, when gadgets would be used as macros inside a page (not necessarrily in a dashboard) and added through the wysiwyg, we'll have specialized forms (know all params and their types, etc).
  • XWiki macros can be immediately used in a dashboard, without extra effort.
  • closer to an xwiki model for the gadgets (easier to build xwiki gadgets and dashboards for users which are already used to xwiki)

Cons:

  • representation of gadgets as xwiki macros (one for each gadget) constitutes an extra model layer for the XWiki Gadgets system.

Proposal B - All gadgets are open social gadgets

The dashboard is a macro and it contains calls only to the {{gadget}} macro inside.

  • there is a special macro called {{gadget}} to be used for this purpose (option 1) above)
  • the {{gadget}} macro will use the gadget XML URL as a parameter (option 2) above) for the open social gadgets
  • the same {{gadget}} macro will be used for the XWiki Gadgets, only that instead of the URL will take an xwiki page name as a parameter
  • for the XWiki Gadgets, some sort of automatic generation of the gadget specification from a page could be provided to unify the 2 types of parameter for the {{gadget}} macro (option 1) above)

The idea is that the dashboard only operates with one type of content, open social gadgets. These gadgets can be either external gadgets, or xwiki content / gagdets, automatically transformed into open social gadgets. The advantage of this idea is the simplified approach, and the implementation of the open social container in the open social spirit rather than in the xwiki spirit, conversion and work being in the direction of exposing xwiki content as open social content (which is a pro).

Gadgets, because they are macros, will be usable in any xwiki document, just as for the proposal above.

Pros:

  • simpler approach,
  • no extra layer, the {{dashboard}} only operates with open social gadgets (implementation in the spirit of the open social container), easier to use for developers already used to the open social gadgets model

Cons:

  • potentially extra work to make sure that all xwiki content can be automatically represented as a gadget, to be used in the dashboard.
  • generic gadgets, no possibility of providing specific forms for inserting gadgets in pages (for example, the macro wizard in the wysiwyg won't be able to provide a form with the needed parameters).

Additional proposals (old work):

Proposal 1 - Gadgets added on Dashboards through Gadgets Directory, and not WYSIWYG Insert Macro Dialog

The Dashboard macro is just a container and when you add it in a document, it simply prints a small "add more gadget(s)" link . This link sends the user to the Gadgets Directory, together with a URL parameter which specifies the dashboard to add the gadgets to. However, inside the directory, when a gadget is added by clicking 'add it now' button under a gadget, the gadget is not directly added to the dashboard referenced in the URL, but a dialog window pops up which asks the user explicitly this. Options for adding it to the person dashboard or another dashboard are provided.

Looking at things this way, the Panel Wizard would only let you specify how many panel-containers to put and where to put them. Once you've defined where panels will be, you populate them using the XWiki gadget repository. The Panels would be like empty shells which can still be drag&dropped to reposition. 

See Mockups for GadgetsIntegration - Proposal 1

Proposal 2 - Multiple Macros - each XWiki&Google Gadget as its own Macro

Each XWiki and Google Gadget would be a distinct Macro (Option 2 for [Gadget Macro(s): One or Multiple Gadget Macros? >http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HGadgetMacro28s293AOneorMultipleGadgetMacros3F]) 

This way gadgets will be inserted by using the WYSIWYG Insert Macro dialog, and the user would directly choose the gadget-macro she prefers. The 2nd window would ideally be extended to contain a Preview area (see mockup). 

The Dashboard would also be a macro. The 2nd window in the WYSIWYG Insert Macro dialog would ask for the dashboard name and number of columns, and a preview will be provided. In the Preview area, you will be able to click a 'Add Gadgets' button, edit, delete and rearrange the gadgets (the gadgets in the preview area will not be rendered - they will be just small colored boxes). When 'Add Gadgets' is clicked, a new window will appear to choose a macro, continued with the preview and settings for that macro. (see mockup)

As for the Panel Wizard, we would have a mini representation of the layout. See Option 3) Have a mini representation of the layout in Main Elements - Panel Wizard

See Mockups for GadgetsIntegration - Proposal 2

Scenarios

Following are a few usage scenarios for the gadgets feature, where, in the brackets, we have marked which of the proposals above favor them (meaning that it would be easier to implement / more straightforward in that case), if there is unbalance between the 2 proposals. Also, under the scenarios I have listed possible paths for each scenario.

  1. User adds a dashboard to a page, next to other content (between text parts, for example).
  2. User navigates a list of available gadgets (from xwiki or open social gadgets) and adds one to a dashboard. (slightly favored by option A)
  3. User rearranges the gadgets on the dashboard by dragging and dropping them to their new places.
    1. directly, view mode is also edit mode
    2. pushes a button to switch the dashboard to edit mode, does the changes, and pushes a button to save the changes
  4. User edits the parameters of a gadget by pushing a button displayed next to the gadget in the dashboard.
  5. User removes a gadget from a dashboard by pushing a button displayed next to the gadget in the dashboard.
  6. User edits the gadgets in the dashboard and their organization using wiki syntax, and not the visual editor (favored by option A, it would be very hard to know the right parameters to use for option B).
  7. User creates a dashboard layout in asymetric manner (not all gadgets have the same size, unbalanced columns, etc -- for example think of the current Main.WebHome, where recent changes, spaces, tagcould would be gadgets).
  8. User adds a new open social gadget to a dashboard (one which does not exist in the gadgets directory yet).
    1. by just specifying  the gadget URL (favored by option B)
    2. user has to import the gadget before he can use it (favored by option A)
  9. User adds a gadget in a wiki page without necessarily having a dashboard in that page, just next to content, for example (favored by A, for which a better interaction for this task will be provided).
  10. User easily creates a gadget whose content is a fragment of wiki syntax. (favored by option A where users can already use an existing macro to achieve this purpose)
  11. Developers can expose an XWiki Gadget as an open social gadget with the click of a button.
  12. Users want to operate with the dashboard as with a collection of gadgets: all operations are on gadgets (add gadget, remove gadget, edit gadget) not other elements (like text or links, etc).
  13. When the user accesses a dashboard, it should render fast and easy (as opposed to the jira 4 dashboard, for example). (potentially favored by option A), depending on some technical details )

Q&A

  1. How should Gadgets in Directory be stored?
    1. - Use the same Panels.PanelClass for Gadgets? Append fields? (URL, other?)
  2. How should Installed Gadgets be stored? (Installed Gadget by User)
    1. - Create an InstalledAppClass with reference to user ID (user doc's fullName) and app ID (gadget doc's fullName)
  3. Where should Gadget UserPrefs be stored?
    1. - UserPrefs are made or key/value pairs
    2. - Bind UserPref both to Gadget/Panel ID and User ID (installed Gadget by user); (store user ID / gadget ID / key / value for each pref)

Google Gadgets fields / XWiki Panels fields

Required fields when submitting a Gadget to Google Directory: http://www.google.com/ig/submit (http://code.google.com/apis/gadgets/docs/publish.html#Submitting)

  • title
  • description
  • author
  • author_email
  • screenshot  (suggested)
  • author_location  (suggested)
  • author_affiliation  (suggested)
  • title_url  (suggested)
  • directory_title  (required if title contains user prefs)

XWiki Panels.PanelClass fields:

  • name
  • type
  • description
  • content ==> for Gadgets not used
  • category
  • User should only submit URL of gadget when adding it directly to the wiki directory (like form Submit your gadget on http://www.google.com/ig/submit) -> and not added from iGoogle directory
  • We should parse the XML and check for required fields + keep (some of) them in the Gadget XWiki Class/Panel

Related

Mockups

Demo on Incubator

UI Design by evalica

SVN


 


Related proposals

per page of Page
Type Status
The environment prevents the table from loading data.
 
Page

Tags: gsoc
Created by Ecaterina Moraru (Valica) on 2013/11/06 13:04
    

Get Connected