Introduction

    User dashboards are an extendable framework within MindTouch to create user-centric dashboards. These dashboards, powered by DekiScript templates (or as a fall-back, PHP plugins) will provide users structured views into their MindTouch activities. This specification covers the development of the underlying framework, and not specific functional use cases; see user activity dashboard for an example of dashboard view that is enabled by this feature.

    Intended Audience

    The framework is intended for developers to enable more powerful views for end-users. User dashboards will be available for all versions of MindTouch, although the implemented dashboard views will be available only in commercial versions of MindTouch.

    Goals

    The philosophy is to build the minimal possible framework for v1, get feedback, and streamline the architecture based on experience:

    • Easy to author dashboard plugins: Strive for minimal "hello world" examples in PHP and Dekiscript
    • Easy to extend the API: Have a simple API to add a module to the dashboard. New features will be added unobtrusively, maintaining backwards compatibility.
    • Easy to style the dashboard page: The dashboard HTML will be straightforward; other plugins can customize / jQueryify as needed.

    Specifically, the dashboard framework will allow

    • Users to author dashboard plugins using PHP or DekiScript Templates
    • Admins to specify the default dashboard plugins for users

    Non-Goals For This Release

    The following are "nice to haves" which aren't slated for v1. They're open to discussion / reprioritization.

    • User-customization of dashboard plugins
      • Users browsing for new plugins to install
      • Users removing plugins
    • Custom dashboard plugin ordering
    • "All in one" widgetized UX
    • UX for importing / exporting plugins
      • Use API to export template page + properties as single file, for easy sharing / plugin installation
    • Local settings storage for dashboard widgets (i.e. per-user customization)
    • Dashboard options UI for widget preferences
    • Default HTTP / AJAX handlers for user interaction (v1 widgets primarily read-only)
    • Template creator
      • Simple 1-page interface to create a new dashboard template (specify properties, etc.)
      • Open up page, ready for editing so you can hack away.

    Additional information

    Design inspiration from facebook tabs and the wordpress plugin interface.

    Status

    Implemented in 10.0 as "user_dashboard" plugin.

    Functional Specification

    Features available to the end user:

    • Integration with User Pages
      • The main user page (/User:KalidA) will be the endpoint for the dashboard
      • The contents of the default page will appear inside a "home" dashboard tab
      • Other tabs will appear alongside (one tab per plugin)
    • Admins can add/remove plugins from the default list
    • Plugins can be public or private to the dashboard owner

    Use Cases

    User wishes to see their dashboard / activity relevant to them

    User clicks "My Page" (redirects to their user page). They see their dashboard plugins and can click on a tab for more details.

    User wishes to edit their user page

    While on their dashboard (/User:username), the user can click "edit" and modify their user page as expected. Once finished editing, they are returned to their dashboard with the changes visible.

    User wishes to create subpages

    Users can create subpages from their dashboard (/User:username/mypage) by visiting the new URL, or using "Create Page" while on the dashboard home.

    Module author wishes to create a customized dashboard page for end users

    The author writes a module that will register with MindTouch Dashboard (in PHP or DekiScript). The admin installs and enables the module for the site. When the user navigates their dashboard, the module appears as a dashboard tab, displaying data to the user.

    Admin wishes to create a customized dashboard page for end users

    The admin writes a DekiScript page (/MyDashboardPage) which generates the desired output. After verifying the page renders correctly, he visits the control panel and adds its path to the list of enabled dashboard pages. At this point, users see "MyDashboardPage" as a tab on their dashboards.

    These new dashboard pages can be added without modifying files on the server (uploading new modules, changing LocalSettings, etc.).

    Admin options:

    • List of pages to include (required)
    • Pages are added to the dashboard in the order listed, after all php plugins
    • Page permissions: if a dashboard page is restricted for viewing, only authorized users will have it added to their dashboard.

    Future Enhancements

    Admin Configuration UI:

    • Pages are only added if found; pages are shown as not found when they are deleted but still enabled in the dashboard.

    Screen shot 2010-03-31 at 3.12.00 PM.png

    Future Enhancements

    V2 Options:

    • Enable per-user customization of dashboard page list

    User has numerous dashboard tabs

    Javascript is enabled

    The tabs appear on two rows.

    tab-multiline-1.png

    The active row always closest to content:

    tab-multiline-2.png

    HTML-only

    All tabs will be rendered on the page, overflowing within the context of the nav pane. Html-only css settings can modify the background to appear as separate boxes, vs. tabs:

    tab-overflow-html.png

    Technical Specification

    UI requirements

    1. Dashboard Tabs: The dashboard renders allowed plugins as tabs. One plugin is active at a time.
    2. Dashboard Contents: Dashboard plugins have a fixed area to render their html.

    Architecture Overview

    Allowed Plugins And Dispatching

    • Admin specifies custom plugins with $wgDefaultDekiUserDashboardPlugins[] in LocalSettings.php (similar to Special Pages)
    • Dashboard plugins hook Hooks::DATA_GET_USER_DASHBOARD_PLUGINS
      • All registered plugins instantiated when hook fired
      • Only the single active plugin is rendered

    Architecture: Plugin Metadata

    Plugins will specify the following:

    • Required
      • Plugin name - identifies plugin for the admin's enabled plugin list
      • Plugin id - user-facing name (myplugin) used in css identifiers and links. Defaults to plugin name.
      • Plugin title - display title of the plugin in the dashboard tab
    • Optional, to be implemented for plugin browsing
      • Plugin description
      • Screenshot
      • Author name
      • Plugin url / homepage

    PHP Plugins will explicitly specify the above parameters in the class definition. DekiScript plugins will store their metadata in page properties.

    Architecture: PHP Plugins (Implemented)

    PHP Plugins

    • Installed into /deki/plugins/user_dashboard/my_plugin/my_plugin.php
    • Plugins extend base class
      • Plugins register with global dashboard hook
      • Plugin customizations / features
        • $User - the user who owns the dashboard
        • $UserPageInfo - PageInfo for the dashboard page itself
        • $pluginName - name used to identify the plugin
        • $privatePlugin - if true, plugin only visible to owner of dashboard
        • $displayTitle - name on plugin tab
        • initPlugin() - allow for run-time customizations
        • getPluginId() - customize name appearing on plugin css Ids and named anchor links (#my_plugin)
        • getHtml() - override to render html for plugin
        • includeDashboardJavascript("filename.js") - include js file from plugin folder (only added on plugin render)
        • includeDashboardCss("filename.css") - include css file from plugin folder (only added on plugin render)
      • New features added by extending the base class [ie. getting and setting dashboard options, default AJAX handling, etc.].
    DekiPlugin::registerHook(Hooks::DATA_GET_USER_DASHBOARD_PLUGINS, array('DashboardHelloWorldExpanded', 'getDashboardPluginsHook'));
    
    class DashboardHelloWorldExpanded extends UserDashboardPlugin
    {
        protected $pluginName = 'hello_world_dashboard';
        protected $privatePlugin = true;
            
        public static function getDashboardPluginsHook(&$plugins, $User)
        {
            $Plugin = new self($User);
            $plugins[] = $Plugin;
        }
            
        public function initPlugin()
        {
            $this->displayTitle = 'Hello, World! (Private)';
            $this->includeDashboardJavascript("hello.js");
            $this->includeDashboardCss("hello.css");
        }
    
        public function getPluginId()
        {
            return 'hello';
        }
    
        public function getHtml()
        {
            $html = '<span id="helloworld">Hello, world. From the dashboard plugin.</span>';
            return $html;
        }
    }

    Goals:

    • Do heavy lifting in base class, users specify minimal amount
    • Avoid gotchas in terms of forgotten setup parameters

    PHP Plugins Wrapping DekiScript

    PHP Plugins can wrap a given DekiScript page by extending UserDashboardPage which provides:

    • $pagePath - path to page to load
    • parent::initPlugin() - called to setup the $pagePath and handle errors
    DekiPlugin::registerHook(Hooks::DATA_GET_USER_DASHBOARD_PLUGINS, array('UserHomePage', 'getDashboardPluginsHook'));
    
    class UserHomePage extends UserDashboardPage
    {
        protected $pluginName = 'hello_page';
    
        public static function getDashboardPluginsHook(&$plugins, $User)
        {
            $Plugin = new self($User);
            $plugins[] = $Plugin;
        }
    
        public function initPlugin()
        {
            $this->displayTitle = 'Home Page';
            $this->pagePath = 'Template:Hello';
    
            parent::initPlugin();
        }
    
        public function getPluginId()
        {
            return 'hello_page';
        }
    }

    This plugin will behave like a regular plugin, but render a given page.

    DekiScript Templates

    DekiScript pages can be included in the dashboard, requiring no PHP code changes by the administrator.

    Configuration:

    • Admins will configure the default DekiScript pages in the control panel
    • Paths stored as comma-separated values as a configuration setting:
      • ui/deki_dashboard_pages = "Page1, Template:Page2, Sample/Page/Here"

    PHP integration: The framework will read the configuration above. If there are dekiscript pages to include, it will create UserDashboardPage objects initialized with the appropriate page. Dekiscript templates appear after PHP templates.

    Future Ideas

    • Plugin metadata: Loaded from page properties.

    • Namespace: Currently, DekiScript plugin templates can live anywhere (as long as specified by admin in settings). In the future, a designated location may auto-load dashboard plugins (such as Template:Dashboard:My_Plugin), or having a specific page property.

    Dashboard Tab Ordering

    By default, dashboard tabs will be ordered as follows:

    • PHP plugins: loaded in order hooked (first the defaults, then those added separately in LocalSettings.php)
    • Admin-specified dekiscript pages: loaded in order listed in the config key

    Admins can override the default ordering with a config key:

    • ui/deki_dashboard_order = "Page1, Template:Page2, Sample/Page/Here, user_home"
    • The values are a comma-separated list of page paths or PHP plugin names (TODO: should we explicitly require php plugins to have a prefix like plugin:user_home?)

    Any dashboard tabs that aren't listed will be listed last, in their default order.

    In a future iteration, both config keys (for custom dekiscript and tab ordering) will have a dedicated UX in the control panel.

    Dashboard Framework And Hooks

    Hooks

    • Hooks::USER_DASHBOARD - executed when dashboard is rendered, passes User whose dashboard is being rendered
    • Hooks::DATA_GET_USER_DASHBOARD_PLUGINS - global list of all dashboard plugins. Plugins add themselves to array of dashboard items. 

    On dashboard page load (/User:KalidA)

    1. Filter for proper preconditions (valid user, etc.)
    2. Load all allowed dashboard plugin classes (defaults & admin-specfied), which hook DATA_GET_USER_DASHBOARD_PLUGINS
    3. Get array of instantiated dashboard plugins
    4. Initialize all plugins with proper defaults (User, etc.)
    5. If HTML request, render framework html & active plugin (?view=active_plugin_id)
    6. If AJAX request, return JSON with active plugin details

    Dashboard Plugin Loading

    When the dashboard is rendered, users can switch tabs to change plugins.

    CSS/Javascript

    Note: plugin css will always be included before user custom css.

    <script src="plugin_name/plugin_name.js">
    <link href="plugin_name/plugin_name.css" rel="stylesheet" type="text/css">

    HTML 

    <div id="deki-dashboard">
      <ul id="deki-dashboard-tabs">
        <li class="active" id="deki-dashboard-tab-plugin_id">
            <a href="http://192.168.1.90/User:Admin?view=plugin_id">Home Page</a>
        </li>
        ... other plugin tabs...
       </ul>
    <div id="deki-dashboard-contents">
       <div id="deki-dashboard-plugin_id">
    </div>
    

    Non-javascript interaction (HTML-only)

    • The plugin tab link will reload the dashboard, indicating the active plugin (?view=my_plugin_id)
    • The entire page will be refreshed (css & js reloaded) with the current tab in the foreground

    Javascript interaction

    • When a tab is clicked, an AJAX request is sent to dynamically load a plugin's information.
      • Links between plugins with class "deki-dashboard-link" will be converted to ajax loads.
    • The return value includes the html & resources to dynamically load:
    {
    name: "",
    html_contents: "",
    css: [],
    js: []
    }
    • Once loaded, a plugin's data stays cached for fast switching

    Future Enhancements

    Per-user plugin list

    Plugin Add

    • Find all registered and allowed plugins
    • For each create DekiDashboardPlugin instances as above
    • Render list of plugins (with description, screenshots as available)
    • User clicks "add plugin" which adds plugin to their default page properties ("mindtouch_dashboard_plugins"):
      • Plugin list is comma-separated
      • Dashboard:My_plugin, my_php_plugin, my_other_php_plugin

    Plugin Removal

    • Delete plugin name from list of of plugins in page properties

    API requirements

    None.

    Open Issues

    • Since the profile modules are templates, will they support being upgraded between releases?
    • How do we store metadata (description, screenshot, url) for Dashboard Templates without having it be rendered?
    • Since plugins can live side-by-side when AJAX loaded, there is potential for javascript / css conflicts

    Integration With User Pages

    The default user page (User:Foo) will be the root of the dashboard:

    • The actual user page contents will be visible as a dashboard tab (plugin user_dashboard)
    • The user page is editable as normal
    Tag page

    Files 8

    FileVersionSizeModified 
    Viewing 11 of 11 comments: view all
    @guerrics @maxm whaddya think?
    Posted 17:07, 19 Jan 2010
    <3 at first sight
    Posted 16:48, 20 Jan 2010
    @royk did I read correct that this will be a Core feature also?
    Posted 12:23, 3 Feb 2010
    @rion, it says so right at the top "This feature will be made available in Core".
    Posted 16:13, 3 Feb 2010
    @kalida does this mean that the "hello world" example could be available in both php as well as dekiscript templates? i'd like to emphasize the value of building these dashboard views inside dekiscript.
    Posted 15:10, 16 Feb 2010
    @RoyK: Yep, we definitely plan to support dekiscript templates as dashboard plugins. It's probably the easiest way for users to get started.
    Posted 14:09, 18 Feb 2010
    http://developer.mindtouch.com/Deki/Specs/User_Profiles_%28via_LDAP%29 has a good activity dashboard we might want to consider for the profile.
    Posted 22:12, 22 Feb 2010
    @royk Maybe my page will be a good starting point of example templates:

    http://developer.mindtouch.com/User:carles.coll

    On our wiki, we have also a takslist template what takes all the tasks all over the wiki for this user.

    I also like the look and fel of templates inside boxes, like the ones in igoogle. Also collapsed ones, like the Messages zone on my user page, you click and it gets the full content, with a resume like 2/100 ( 2 new messages from a total of 100 ) on the box title will be perfect. On Pages Monitor: 3 new changes on Box title an so on, this way you don't have to charge the full data, and you aliviate the server charge (and also de user charge).

    I'm thinking on having a Template like: Template:Box{template,with,height,collapsed}, I don't se the need of any kind of plugin system, with tags an templates you can do whatever you have said on this page.

    Carles.
    Posted 09:24, 10 Mar 2010
    I like it. The more I look at the features of Olympic, the more I wish it has shipped already. I keep going back to look at the main page just to check that it hasn't been shipped yet...
    Posted 11:40, 10 Jun 2010
    This Spec superceded the LDAP User Profile spec... but I see no mention here of being able to reference the AD data (user physical addresses, phone numbers, et cet.) Has that aspect of the project been abandoned?
    Posted 07:09, 7 Jul 2010
    @MentalNomad: Currently, there's no plan to directly integrate AD data, but could be something we add in a future version. We'd like to make it easy to add additional dashboard modules.
    Posted 14:47, 30 Jul 2010
    Viewing 11 of 11 comments: view all
    You must login to post a comment.

    Copyright © 2011 MindTouch, Inc. Powered by