Support from Acquia helps fund testing for Drupal Acquia logo

Comments

EvanDonovan’s picture

I actually agree with chx on this one, after testing #601932: Allow dashboard to limit available blocks. I don't think the dashboard as it stands adds much, if any, value to Drupal core, and there is no API currently that I know of which contributed module developers can use to specify where their blocks should show on the dashboard by default.

Let's leave the idea of a dashboard to be implemented correctly in contrib, by things like Panels module.

Status: Needs review » Needs work

The last submitted patch, dashboard_real_fix.patch, failed testing.

chx’s picture

Status: Needs work » Needs review
FileSize
2.73 KB

Will fix the patch but here are more reasons:

  1. Blocks are per theme. Dashboard is not really per theme.
  2. It can be contended whether it makes sense for the dashboard to have a sidebar -- ie does it make sense to have regions in a dashboard?
  3. Dashboard blocks only appear on the dashboard page and in the current implementation, that page has a different layout. Right now, Drupal does not support different regions per path ( I had a patch for it but due to possible consequences it was laid aside).
  4. Blocks have a global binary status. Dashboard status is more complicated, that's what the other issue is about. It can be said that status is "block available to dashboard" / "block not available to dashboard" but what happens with "block visible on dashboard dy default". edit: i figured this one out.
  5. Admin dashboard blocks are somewhat different to normal blocks. This is exactly what was not thought through. While the "10 newest article" list is useful for navigation, as an admin block it needs some links (like edit) probably in a second row. It's simply a different block. I suspect most other blocks can similarly be separated. The core recent block is not a different block and I must say it shows in the empty table cells it shows -- although it can be fixed visually but it takes a performance hit from checking the edit etc links
  6. This dashboard is per site. That's silly. Drupal does not have a singular 'admin' concept (maybe wordpress has. we are still not wordpress.). At least it should be per role. And it's debatable whether it should be per user. Edit: likely #601932: Allow dashboard to limit available blocks fixes this.
chx’s picture

chx’s picture

FileSize
40.53 KB

Hopefully this passes tests.

Status: Needs review » Needs work

The last submitted patch, dashboard_real_fix.patch, failed testing.

chx’s picture

Status: Needs work » Needs review

#5: dashboard_real_fix.patch queued for re-testing.

moshe weitzman’s picture

Priority: Normal » Major

I have to agree. Dashboard should have implemented its own panes and just used hook_block to get candidate content blurbs that the admin might want to insert. This nicely bypasses both theme and block systems. See the madness we have made at #950878: Disabling the dashboard module permanently removes all blocks from the dashboard and #951212: Dashboard blocks should be configured completely independently from the default/admin theme blocks.

We tried, but we fell short for D7. Dashboard is not yet core worthy. Respect for everyone who tried.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

I'll bet there are opinions on both sides so lets let committers chime in.

webchick’s picture

Version: 7.x-dev » 8.x-dev

Chimed in.

David_Rothstein’s picture

It is very tempting to remove it. It has no maintainer, no one is paid to work on it, and no one wants to work on it.... yet it needs some real work. The only people actually writing or reviewing patches for it (I shouldn't speak for others, but this is my impression) are doing it out of some sense of obligation, not because this is really the way they want to spend their Drupal time. Not a great start for a new module in Drupal 7 :)

All that said, the above describes a lot of other modules in Drupal core too, and the world hasn't ended because of them. From an end-user perspective, the Dashboard module works fine right now (in my opinion, #951212: Dashboard blocks should be configured completely independently from the default/admin theme blocks removes the last couple of things that could really confuse people in the UI), it has no critical bugs, and it has the potential to be a killer feature, if things break right. There is no good way to do it in contrib because how would module authors be convinced to go out and write all these administrative blocks aimed at the dashboard without a critical mass of Drupal sites that have a dashboard module installed?

There are some hacks in the code but I don't think they're overwhelming. It is pushing the block module to its limits (and beyond) but doing it without the block module seems like it would lead to many worse hacks; we'd then have two independent page management systems in Drupal core. If the block module is improved (or replaced) in Drupal 8, the Dashboard module could be improved right along with it, and it's a great test case for any attempt to do that.

carlos8f’s picture

Version: 8.x-dev » 7.x-dev

Some sense of obligation

Actually some sense of ever releasing D7. Seriously, I don't think *anyone* gives a flying hoot about this module. I'm not convinced that @David does either, but props for being diplomatic ;) I work on the dashboard module because I want to clear the issue queue and release D7. Removing it to contrib would certainly straighten our priorities. We maintain a lot of mission-critical stuff in core that is way more important than babysitting petty UX stuff for the dashboard that no one uses or cares about! +1

carlos8f’s picture

By the way, there are already a plethora of contrib dashboard modules which can be customized per-user, per-role, etc. Our version in core looks lame in comparison. Who are we kidding? A dashboard that can't be customized for your own account...

webchick’s picture

Version: 7.x-dev » 8.x-dev

What part of "Chimed in" wasn't clear here?

We have one last critical bug to fix that's 95% fixed. Let's fix it, and move on with our lives. We don't need more distractions.

EvanDonovan’s picture

@webchick: According to all the people who had been working on the issue (who were in disagreement for a long time), it was fixed *enough* that we were in agreement to get something committed, but then you bumped it down to "needs work". If you want anyone else to work on the issue more, I think you're going to have to tell them precisely what more is needed.

Jody Lynn’s picture

Status: Reviewed & tested by the community » Needs review

There's no rush in removing it right now. Let's wait and see how people like it now that D7 is out.

EvanDonovan’s picture

Looks like people actually like it, according to some posts on Drupal Planet.

I think the best way forward would be to refactor the blocks system, as chx has suggested for D8, and then have a new dashboard module based on the refactored blocks system.

quicksketch’s picture

Title: Dashboard is broken beyond repair » Dashboard is broken beyond repair, remove it from core
Category: bug » task

Per #1050616: Figure out backport workflow from Drupal 8 to Drupal 7, major and critical bugs are now preventing development in other areas of Drupal core. Unless this issue is actually a bug (data loss, functionality not working), we can mark this as a "major feature request" or a "normal bug", but not a "major bug". I'm not really sure if this is a "task" or "feature", but let's not mark it a bug (unless you don't want other things to move forward in Drupal core until this is fixed).

Bojhan’s picture

Issue tags: +Usability

lala, tag

yoroy’s picture

Subscribble etc.

xjm’s picture

Tagging issues not yet using summary template.

jenlampton’s picture

subscribe

aspilicious’s picture

FileSize
54.43 KB

Srry if this hurts people...

Status: Needs review » Needs work

The last submitted patch, remove-dashboard.patch, failed testing.

aspilicious’s picture

Status: Needs work » Needs review
FileSize
54.6 KB

Srry xjm for driving you nuts.

Jacine’s picture

It's a pile of hacks upon the ancient blocks system.

I could not agree more with this statement. The changes made to the "Recent content" block should also be reverted (in a follow-up, of course) because it was completely destroyed in the name of this module.

DjebbZ’s picture

Just a note. I worked in the French company that used to fund the development of the Homebox module that basically was integrated into core as Dashboard. They were proud to say that they somehow contributed to D7 core, but even them couldn't fix it, they had to fork it for an internal project and couldn't fix the fork anyway. Truly, it's so buggy it does not deserve its place into core. I'm all for removing it.

coderintherye’s picture

Status: Needs review » Needs work

Here's what I got trying to apply on the latest pull of HEAD. Maybe, just needs to be re-rolled? Sorry for not being more useful, would like to help see this move forward though.

dev-vm drupal (8.x) $ git show-branch
[8.x] - Patch #1263902 by cweagans: Code style: filetransfer.inc.
dev-vm drupal (8.x) $ git apply -v remove-dashboard-v2.patch
Checking patch MAINTAINERS.txt...
Hunk #1 succeeded at 166 (offset -3 lines).
Checking patch modules/block/block.module...
Checking patch modules/dashboard/dashboard-rtl.css...
Checking patch modules/dashboard/dashboard.api.php...
Checking patch modules/dashboard/dashboard.css...
Checking patch modules/dashboard/dashboard.info...
Checking patch modules/dashboard/dashboard.install...
Checking patch modules/dashboard/dashboard.js...
Checking patch modules/dashboard/dashboard.module...
error: while searching for:
<?php

/**
 * Implements hook_help().
 */
function dashboard_help($path, $arg) {
  switch ($path) {
    case 'admin/help#dashboard':
      $output = '';
      $output .= '<h3>' . t('About') . '</h3>';
      $output .= '<p>' . t('The Dashboard module provides a <a href="@dashboard">Dashboard page</a> in the administrative interface for organizing administrative tasks and navigation, and tracking information within your site. The Dashboard page contains blocks, which you can add to and arrange using the drag-and-drop interface that appears when you click on the <em>Customize dashboard</em> link. Within this interface, blocks that are not primarily used for site administration do not appear by default, but can be added via the <em>Add other blocks</em> link. For more information, see the online handbook entry for <a href="@handbook">Dashboard module</a>.', array('@handbook' => 'http://drupal.org/handbook/modules/dashboard', '@dashboard' => url('admin/dashboard'))) . '</p>';
      $output .= '<h3>' . t('Uses') . '</h3>';
      $output .= '<dl>';
      $output .= '<dt>' . t('Tracking user activity') . '</dt>';
      $output .= '<dd>' . t("By enabling blocks such as <em>Who's online</em> and <em>Who's new</em>, site users can track who is logged in and new user signups at a centralized location.") . '</dd>';
      $output .= '<dt>' . t('Tracking content activity') . '</dt>';
      $output .= '<dd>' . t('By enabling blocks such as <em>Recent blog posts</em>, <em>New forum topics</em> and <em>Recent comments</em>, site users can view newly added site content at a glance.') . '</dd>';
      $output .= '</dl>';
      return $output;

    case 'admin/dashboard/configure':
      // @todo This assumes the current page is being displayed using the same
      //   theme that the dashboard is displayed in.
      $output = '<p>' . t('Rearrange blocks for display on the <a href="@dashboard-url">Dashboard page</a>. Blocks placed in the <em>Dashboard (inactive)</em> region are not displayed when viewing the Dashboard page, but are available within its <em>Customize dashboard</em> interface. Removing a block from active dashboard display makes it available on the main <a href="@blocks-url">blocks administration page</a>.', array('@dashboard-url' => url('admin/dashboard'), '@blocks-url' => url("admin/structure/block/list/{$GLOBALS['theme_key']}"))) . '</p>';
      return $output;
  }
}

/**
 * Implements hook_menu().
 */
function dashboard_menu() {
  $items['admin/dashboard'] = array(
    'title' => 'Dashboard',
    'description' => 'View and customize your dashboard.',
    'page callback' => 'dashboard_admin',
    'access arguments' => array('access dashboard'),
    // Make this appear first, so for example, in admin menus, it shows up on
    // the top corner of the window as a convenient "home link".
    'weight' => -15,
  );
  $items['admin/dashboard/configure'] = array(
    'title' => 'Configure available dashboard blocks',
    'description' => 'Configure which blocks can be shown on the dashboard.',
    'page callback' => 'dashboard_admin_blocks',
    'access arguments' => array('administer blocks'),
    'type' => MENU_VISIBLE_IN_BREADCRUMB,
  );
  $items['admin/dashboard/customize'] = array(
    'title' => 'Customize dashboard',
    'description' => 'Customize your dashboard.',
    'page callback' => 'dashboard_admin',
    'page arguments' => array(TRUE),
    'access arguments' => array('access dashboard'),
    'type' => MENU_VISIBLE_IN_BREADCRUMB,
  );
  $items['admin/dashboard/drawer'] = array(
    'page callback' => 'dashboard_show_disabled',
    'access arguments' => array('administer blocks'),
    'type' => MENU_CALLBACK,
  );
  $items['admin/dashboard/block-content/%/%'] = array(
    'page callback' => 'dashboard_show_block_content',
    'page arguments' => array(3, 4),
    'access arguments' => array('administer blocks'),
    'type' => MENU_CALLBACK,
  );
  $items['admin/dashboard/update'] = array(
    'page callback' => 'dashboard_update',
    'access arguments' => array('administer blocks'),
    'type' =>
error: patch failed: modules/dashboard/dashboard.module:1
error: modules/dashboard/dashboard.module: patch does not apply
Checking patch modules/dashboard/dashboard.test...
Checking patch modules/system/system.admin.inc...
Hunk #1 succeeded at 2452 (offset 41 lines).
Checking patch modules/system/system.test...
Hunk #1 succeeded at 1515 (offset -16 lines).
Checking patch profiles/standard/standard.info...
Checking patch profiles/standard/standard.install...
Checking patch themes/seven/style-rtl.css...
Checking patch themes/seven/style.css...
jenlampton’s picture

Status: Needs work » Needs review
FileSize
49.42 KB

rerolled :)

Status: Needs review » Needs work

The last submitted patch, remove_dashboard_from_core-1054616-29.patch, failed testing.

jenlampton’s picture

Title: Dashboard is broken beyond repair, remove it from core » Dashboard is broken beyond repair, remove it from core
Status: Needs work » Needs review
FileSize
49.91 KB

also removing it from the standard install profile this time. :)

Status: Needs review » Needs work

The last submitted patch, remove_dashboard-950956-32.patch, failed testing.

RobLoach’s picture

Status: Needs work » Needs review
Issue tags: +Platform Initiative
FileSize
54.74 KB

If people still want Dashboard, we should move them to contrib at Dashboard module.

coderintherye’s picture

Status: Needs review » Reviewed & tested by the community

The patch applies cleanly and tests pass on the latest head.

I ran through a standard install, and it worked as expected with no errors.

The patch itself is very straight forward, and so I would mark that this is ready to go pending an ok from a core maintainer.

I'm going to be bold and mark it RTBC.

David_Rothstein’s picture

So what's the actual rationale for removing it?

Looking back through the issue it seems the most recent relevant comments were these, and I don't believe they've been discussed or addressed since then:

#16
Posted by Jody Lynn on January 8, 2011 at 11:51pm

There's no rush in removing it right now. Let's wait and see how people like it now that D7 is out.

------

#17
Posted by EvanDonovan on January 9, 2011 at 11:19am

Looks like people actually like it, according to some posts on Drupal Planet.

I think the best way forward would be to refactor the blocks system, as chx has suggested for D8, and then have a new dashboard module based on the refactored blocks system.

EvanDonovan’s picture

Issue tags: +Needs committer feedback

I think #26 is relevant as well, where Jacine agrees with the statement that it is a pile of hacks on the blocks system.

But I don't think we should be in a rush to remove it. Let's keep it in for now, and see whether it can be re-architected to work with the "Context" object once WSCCI moves along to Phase 3.

Tagging with "Needs committer feedback" in light of that.

webchick’s picture

My committer feedback doesn't count for D8, but IMO I think Dashboard is a wonderful proof of concept module for what the block system should be capable of doing without any hacks. Therefore, if it requires hacks, let's fix the underlying block system. Additionally, removing feature modules like this makes building Snowman harder.

chx’s picture

It's tempting to remove it, yes, but right now I see absolutely no reason to do it. A year ago yes because I didnt want it in D7. Until iit blocks anything in D8, why nuke it? I would wait for Snowman.

catch’s picture

Assigned: Unassigned » Dries
Status: Reviewed & tested by the community » Needs review

For me personally I think we should have refactored the block system before adding dashboard, but we can't go back in time two years to do that.

If it turns out to be difficult to refactor the block system because it keeps breaking dashboard tests due to reliance on quirks of the current API, then I'd be happy to do things like comment out all dashboard tests while refactoring is going on (adding a critical bug to make them pass again or similar).

In terms of just removing it, I'd like to see feedback from yoroy, Bojhan and eaton on here, which there is currently none, so I'm putting this back to CNR, but also assigning to Dries (since I have spent much of the past four years opening issues like this then having them not committed I am a bit too biased towards nuking stuff).

Bojhan’s picture

Issue tags: -Usability

Please use "Needs usability review" for feedback from the UX-Team, if you cant assign.

I don't think feedback from the UX-Team is needed here though. At the time that Dashboard went in we concluded that it was not up to the standards of UX in core. It was pushed in anyway, with the expectation set by Dries that this would be solved in the polish phase and by contrib provided blocks.

Sadly the latter hasn't happend. I've tried to persuade a number of contribs such as Google Analytics and Mollom to make a beautifull block, but it either resulted in a ugly one or not one at all. It simply isn't a priority for most if not all contrib maintainers.

We could employ a strategy that improves the current dashboard blocks. But I am very hesitant, because I never understood why its part of our product strategy. In Drupal the concept of a "administrative home" has laregly been mitigated by concepts such as toolbar and admin_menu. You really need it in tools such as Wordpress, Movable Type, Expression Engine etc. because you navigate to admin first, and than to your actionable items - this is not the case in Drupal. If its in, because we need to compete on functionality - than we are doing a really bad job.

This is really Dries his baby, so I will leave it up to him to give feedback that will hopefully help decide.

Bojhan’s picture

Issue tags: +Usability

tag

EvanDonovan’s picture

Thanks, Bojhan - it's great to hear your perspective. Do you think contrib maintainers would be more interested in providing blocks for Dashboard if it were a more feature-rich system with a better UI, like the Homebox module?

jenlampton’s picture

I still think it needs to be removed from core, because it doesn't add anything useful on it's own. If we're leaving it to contrib to make dashboard into an actual dashboard - then the dashboard itself should live in contrib.

I certainly don't think this gets in the way of Snowman, since snowman can't use contrib modules - and Dashboard is not very useful without contrib. On it's own, it just causes confusion.

DjebbZ’s picture

I agree with people that want to remove it : it's just another interface for the existing blocks management page with drag and drop. I also understand chx when he says that we should revamp the block system (well, I think everybody agrees with him). But if we wait too long before taking any action, we may not have enough time to make anything else than just remove it from core.

jenlampton’s picture

I also agree with Dejbbz. The blocks system is already getting a revamp in D8 - and the existing dashboard will probably need to be thrown out and rebuilt anyway. Let's start now :)

yoroy’s picture

Bojhan gives a good overview of the UX & product considerations.

I suspect you'll find more full dashboard replacements in contrib than contribs that provide blocks for core dashboard. What I do not understand is the hurry to remove it. Does it hamper the underlying block system refactoring? It's a good test case for what a new and smarter block system should be able to support.

EvanDonovan’s picture

I agree with yoroy. chx originally opened this issue back when Dashboard was blocking 7.x stable release. Now it's not blocking anything. We might as well keep it in for now as a test case, and then remove it prior to 8.x release if it seems like it's not going to be useful.

Accordingly, I think this should be marked "postponed".

moshe weitzman’s picture

For me, the bottom line is that this module is currently below every standard that we have. It does not meet UX standards, code elegance standards, etc. We should not keep such code in core and hope that someone brings it up to par. I agree with Jen that it should be removed now, and a subsequent patch can bring it back when it has a better case to make. It is demoralizing to the dev team to keep subpar code in core. Who is standing up and saying "I use this module and love it and want it to stay?" I have not heard anyone. That's telling.

RobLoach’s picture

We could fork the Drupal core version of Dashboard over to the 8.x branch in http://drupal.org/project/dashboard . The demand for it will be proved in contrib if people help support it over there.

Dries’s picture

Assigned: Dries » Unassigned
Status: Needs review » Postponed

I still believe that a functional dashboard would be a great addition to Drupal core -- as proven by many other systems, good dashboards can make a big difference. Drupal has real challenges when left to use by mere humans such as editors, and we need to look for ways to address these.

I'd like to keep the dashboard module in core for the time being so we can help make sure that the block system refactoring fulfills its promise. I will revisit this decision 6 months from now on June 1st, 2012. Hopefully we'll have made some progress on improving the Dashboard module by then.

I'm marking this 'postponed' for the time being. Feel free to re-assign this to me on June 1st, 2012.

Dries’s picture

Take a look at this video: http://www.youtube.com/watch?v=dzPH5t2q-Pk

It's a video of the my.fcc.gov prototype built in Drupal. It is using Drupal with a partial node.js backend.

Some of the Dashboard blocks are really neat (e.g. mini views).

Pretty cool, if you ask me. Good example of why we need WSCCI and node.js integration.

lelizondo’s picture

Are they using Homebox or the Dashboard module from core? It looks like Homebox

David_Rothstein’s picture

It looks like a Drupal 6 site, so they can't be using Dashboard.

Bojhan’s picture

Who cares what module or version it is, what Dries is mostly aiming at is the UX it offers through new technologies(although I don't get that part).

What are the takeaways that make our dashboard better?

jenlampton’s picture

We should keep in mind that we aren't going to have views in core - so what the dashboard can actually provide (in terms of usefulness) will be quite limited.

I still hold that this should live in contrib unless we can *actually* make it into a useful dashboard - and without views that's going to be really hard. But let's see where we are in June :)

David_Rothstein’s picture

Who cares what module or version it is, what Dries is mostly aiming at is the UX it offers through new technologies(although I don't get that part).

What are the takeaways that make our dashboard better?

This issue isn't about improving the UX of the Dashboard module, though. It's about whether or not the module fundamentally belongs in core.

  1. UX issues can always be fixed. (Although the sentiment here that the current UX is terrible doesn't seem based on actual facts; the usability testing that was done in #601932: Allow dashboard to limit available blocks showed that at least for basic tasks, the Dashboard UX is pretty good already, and about 9 million times better than the Block module UX.)
  2. Bugs can also be fixed. (Although again, the "dashboard is buggy" sentiment in this issue seems to fly in the face of actual evidence from the issue queue.)
  3. What can't be fixed is a strategic mistake.

So is there a strategic mistake? The idea of Dashboard in core is really just that modules can define blocks intended for it, and those can be treated specially in the UI. It's much harder for a contrib dashboard to introduce a concept like that (and none do as far as I know), unless there were a single contrib dashboard that absolutely everyone used. So far, though, core blocks don't use this feature as much as they should (Snowman definitely could help though), and contrib modules haven't picked it up much either. That's where we're at.

Where the my.fcc.gov dashboard might be relevant for this issue is as an example to look at concerning what kinds of blocks it actually uses. What kind of contrib modules would need to start doing some dashboard-strategy-homework in order for it to actually be successful?

When I watch the video, it strikes me that pretty much everything there is a custom-made block, and most of them look like Views. So maybe more than patches for lots of contrib modules, do we actually just need a patch for Views to add something like a "this block should be available on the site's administrative dashboard" checkbox to block displays? A simple feature like that might go a long way in allowing the Dashboard's usefulness (as a centralized core feature) to be properly evaluated.

David_Rothstein’s picture

I apparently cross-posted with @jenlampton who was also thinking about Views :)

So it's definitely true that not having Views limits how useful the dashboard can be. But then again, not having Views limits how useful a site can be too (at least for most kinds of sites). I'm not sure I would agree that the "lack of Views" limits the dashboard proportionally more than it limits the overall site.

I think if you've managed to build a semi-useful site with core only, you could probably then build a dashboard that's equally useful, if you throw enough core blocks onto it. For example, between recent comments, recent content, recent users, the statistics module blocks, etc... you can probably get a pretty good overview of what's going on with your website. This would definitely be useful for Snowman to explore, IMO.

lelizondo’s picture

Who cares what module or version it is, what Dries is mostly aiming at is the UX it offers through new technologies(although I don't get that part).

I only asked because Homebox is much better right now than the Dashboard module. And one of the reasons, at least the way I see it, is because Homebox lives in contrib.

I do agree with Dries when he says that we need a good Dashboard, I really do, but I also think that we could have a better Dashboard if it is in contrib and not in core. Views wouldn't be half the module it is right now if it was in core.

Anyway, we'll talk again next year.

Bojhan’s picture

@David Sorry for being so harsh :) I just didn't like the discussion steering towards, it would be soo much better with X, in core rather than dashboard.

Yhea, I will revist this issue in half a year when all the magic has happend and the Dashboard is awesome.

jenlampton’s picture

I'm also concerned that having such a bad example of "how to create a context" in core isn't going to help anyone learn to code for Drupal. Hopefully by D8 (after WSCCI gets somewhere) this won't be such a huge issue anymore, but for now I'm tagging this issue for learnability.

webchick’s picture

My first D8 core patch was an attempt to make the default dashboard more useful, but got held up on the "Will aggregator/dashboard be part of D8?" question (grumble, grumble). See #1266310: Add a "Drupal news" block to an appropriate administrative area in the Standard profile.

I think we can actually do quite a bit of smallish patches like that to make the dashboard in the standard profile much more useful, even without Views.

yoroy’s picture

D.o. news block would be nice, I'd love to see the software create some more links back to the mothership d.o. like that. Snowman should have enough wiggle room to add its own custom block if necessary as well.

I think everyone agrees the current implemenation is no good. The value of the dashboard concept *for core* remains to be determined I think. Dreaming up useful widgets that provide people with meaningful status info would be a good start (silly ones work too).

David_Rothstein’s picture

I think everyone agrees the current implemenation is no good.

Per #57, I don't agree that it's no good, and gave some specific evidence to support that...

Either way, if people have real, actionable ideas for a better implementation it would be useful to create issues for them (and cross-link them here). Otherwise this issue isn't really postponed on anything specific, so when June 1 2012 comes it's very unlikely that anything will have changed.

Bojhan’s picture

Status: Postponed » Active

Dries his deadline has past. I think we made no changes to the dashboard, that impact UX. It looks like no one in the core community at least, is interested in improving it. So I still stand by my decision, that this has such bad UX - that it has no place in core.

moshe weitzman’s picture

Assigned: Unassigned » Dries

Assigning to Dries for a decision as per #51.

Dries’s picture

In #51 I said I would revisit this on June 1st. No progress was made the past six months.

There is a lot of evidence that the idea of having a good dashboard is still valid and very important. For example, it is one of the reasons why people pick WordPress over Drupal. It just happens to be that (i) core's technical implementation of the dashboard module may be poor, (ii) that the dashboard has poor usability, but most importantly, in my opinion, that (ii) we lack good content and functionality on the dashboard.

I'm going to spend some time on this with the Spark team. Everyone is welcome to get involved too. However, I'd like to compare the dashboards of different CMSes, re-envision what a dashboard could be, and figure out how we can arrive to a good, functional dashboard in Drupal that users love.

I do think it could be good to innovate on this outside of core. But if we nail it, and we come back with a great dashboard that content authors or admins love, I do feel it belongs in core. So I'm comfortable removing it from core now, but I will bring it back into core given positive feedback from users.

Thoughts?

moshe weitzman’s picture

Status: Active » Needs review

#34: dashboard.patch queued for re-testing.

Bojhan’s picture

@Dries I think that would be a great approach! This is a major win, in terms of creating a UX standard that core needs to adhere to - something I am personally happy about.

I would like to add, that people aren't just welcome to join in, but really should! Because in the end, core needs to have a community that is willing to maintain a Dashboard in core - that's one thing we learned from D7UX.

Status: Needs review » Needs work

The last submitted patch, dashboard.patch, failed testing.

tim.plunkett’s picture

Assigned: Dries » tim.plunkett

I'm rerolling this patch.

tim.plunkett’s picture

Ooops, sorry for unassigning. I can't fix that myself. But yeah, I'm midway through rerolling this (there is data in the DB dumps that can be killed off).

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned
Status: Needs work » Needs review
FileSize
245.12 KB

Okay this removes all dashboard data from drupal-7.bare.standard_all.database.php.gz as well, but it was very tedious so I'm going to hold off on drupal-7.filled.standard_all.database.php.gz until someone confirms that this needs to be done for this issue.

catch’s picture

Actually it's fine to leave the dashboard in those db dumps, since it still exists in D7 and if it goes back into 8.x later we'll need a tested upgrade path anyway.

webchick’s picture

Priority: Major » Normal

This is not major.

tim.plunkett’s picture

FileSize
56.3 KB

This should do it.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

Looks right to me too. Wait for green before commit.

Bojhan’s picture

Assigned: Unassigned » catch

I am sure @catch would be happy to remove it.

Dries’s picture

Assigned: catch » Unassigned

@Bojhan: I don't understand why you assign this patch to catch?

@All: before we commit this patch, I'd like to work with webchick to setup a contrib project for it. Give me a couple more days.

Bojhan’s picture

@Dries You can commit it too.

David_Rothstein’s picture

(ii) that the dashboard has poor usability

I pointed out above that the evidence we have (from actual user testing) shows the opposite to be true. If we remove the Dashboard module, we'll be removing one of the easier-to-use interfaces that currently exists in Drupal core.

but most importantly, in my opinion, that (iii) we lack good content and functionality on the dashboard.

With the possibility of Views in core, it seems like that would be a really good opportunity to change the default dashboard content (as well as giving users much better opportunities to add their own content to it). But I'm not sure that interface would all really come together in time for Drupal 8.

webchick’s picture

Created an issue at #1659368: Move core dashboard module to this project in 8.x branch? to move this into contrib.

yautja_cetanu’s picture

Surely with the layouts iniative the dashboard makes sense now?

Layouts + views in core would make the dashboard a really cool example use-case of what can be done with layouts and views. I realise that this would probably mean completely rebuilding the dashboard though.

Crell’s picture

Sure, the Layouts initiative should (if successful) make it possible to build a really solid dashboard.

Such a SCOTCH-based dashboard would be so far conceptually and architecturally from the current dashboard module, however, that it would be easier to implement from scratch rather than trying to evolve the current one. That's why we want to just euthanize the current one first, as that makes it *easier* to build a new one after we've razed the old one to the ground.

Dries, it's been more than a couple of days... :-)

webchick’s picture

We had to wait two weeks for the abandoned module process at #1659368: Move core dashboard module to this project in 8.x branch?:. It's now been two weeks, but I'm on-site in Boston and in meetings 24/7. I'll try and get to it if I can, but it may be middle of next week when I'm back home. It doesn't seem to be overly urgent.

RobLoach’s picture

Status: Needs work » Reviewed & tested by the community
Issue tags: -Usability, -Needs issue summary update, -Needs committer feedback, -Platform Initiative, -Increases learning curve

#76: drupal-950956-76.patch queued for re-testing.

@webchick: The only person that got back to me from the email I sent two weeks ago was agentrickard, and he said he didn't have access to the project administration.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, drupal-950956-76.patch, failed testing.

webchick’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Usability, +Needs issue summary update, +Needs committer feedback, +Platform Initiative, +Increases learning curve

Ok, per #1659368: Move core dashboard module to this project in 8.x branch? I've assigned myself as a co-maintainer of this module, and pushed the latest 8.x code into http://drupalcode.org/project/dashboard.git/tree/refs/heads/8.x-1.x

I believe this just needs a re-roll and then we can remove it.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
56.31 KB

Rerolled.

Bojhan’s picture

Status: Needs review » Reviewed & tested by the community
webchick’s picture

Title: Dashboard is broken beyond repair, remove it from core » [Change notice] Dashboard is broken beyond repair, remove it from core
Priority: Normal » Critical
Status: Reviewed & tested by the community » Active

Ok, committed and pushed to 8.x.

There's a CHANGELOG.txt notice, but we should probably also have a change notice too.

tim.plunkett’s picture

Status: Active » Needs review
webchick’s picture

Title: [Change notice] Dashboard is broken beyond repair, remove it from core » Remove Dashboard from core
Category: task » feature
Priority: Critical » Normal
Status: Needs review » Fixed

Looks good, thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

eMPee584’s picture

awesome!
...and it took only two years to rip it out.

xjm’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update, -Needs committer feedback