This patch makes the main admin page into a real dashboard. You can add various items to it, etc etc. Implementation is not great (need sprinkling of t(), theming, and hooks), but it's a "concept (needs review)" kind of thing, not actually patch (code needs review)

Demo at http://dmitrizone.com/mockup-demo.mov and a screenshot at http://img.skitch.com/20090218-8ay6ytrn119hbjrn5yjh3y2wj.jpg

Also, not a duplicate of #374490: Bikeshed: Re-work top-level admin categories because that issue deals with menu items and categories and this one is for the main administer page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

dmitrig01’s picture

Status: Needs work » Needs review
FileSize
17.52 KB

Hooks, need some theming and t()ing. Removed the test for now

dmitrig01’s picture

Implementation for user. theming and t()ing are good.

sun’s picture

subscribing

Frando’s picture

Interesting. In which way do "widgets" differ from blocks, apart from that they're displayed at the admin page and not in regions?

Without having closely reviewed the patch, my first impression is that while the feature is great, the implementation might better be based on blocks, for consistency and reusability. We could maybe simply add a flag to the block table, like "admin_block" or something, to filter down the list of available blocks. With the block refactoring patch that sits in the queue this would be really easy.

UI-wise: It's looking great! I don't think we should drop the existing admin page, though. I would vote for keeping the existing /admin page as a tab on /admin, with the dashboard being the default.

So, as I said, just first impressions. Will think about this some more.

dmitrig01’s picture

Frando:
Widgets are completely different from blocks, mainly because I was lazy. This is just a fancy prototype :-) I probably will make this into a block. The only problem with that is that I would have to make a fake theme for which blocks can be configured, as blocks have settings and these don't :P

Dries’s picture

You want to talk to Neil Drumm if you haven't already. He did some work on this at the Drupal.org redesign code sprint in Paris. Lots of overlap with your work. :)

Status: Needs review » Needs work

The last submitted patch failed testing.

yoroy’s picture

Issue tags: -Usability +dashboard, +ux

While it would be great to have this functionality somehow, somewhere, this patch lacks a vision for how this would be used to actually improve Drupal administration. Yes, proof of concept so it's ok, just saying :)

yoroy’s picture

Issue tags: +ui-pattern
Bojhan’s picture

FileSize
534.71 KB

Dashboard update, mockup of Mark

amc’s picture

yoroy’s picture

We're working towards something like this (click for larger):

yoroy’s picture

marked #544360: D7UX dashboard module a duplicate of this. So… Widgets! How are they different than blocks? We want make small smart displays of status related things. And for core, it's mainly about laying out the architecture to enable it (for contrib), right? I'd like to hear some more technicnical architecture talk here. Fieldbundleblockpanelwidget? Viewsincore part 5.724?

Conceptually and technically, this page is now located at /admin, which makes it the administration homepage. Which is fine, but expands the scope of the page contents a bit, in pointing out next destinations for admin tasks. No matter, that's just content ( I'm missing 'status reports' very much in the mockup BTW)

I'd like to widgetize the status report page, the available updates page, watchdog and statistics, the content listing, comment queues…

What framework can we build for that?

Gábor Hojtsy’s picture

Well #544360: D7UX dashboard module just used block regions and let blocks placed in the dashboard page, which is another approach one can take towards a *simple* dashboard.

sun’s picture

<rant>
So we are re-inventing Panels here?
</rant>

I agree with Gábor - those widgets are mostly duplicating what we already have in existing blocks.

catch’s picture

This would obviously be much better with panels, the question is if we add something like this to core, can we do it in a sufficiently light way that there's a reasonable experience for new installs, and contrib can replace it with something wooshy and panels based easily.

I don't think there's any question this should use hook_block() even if it doesn't use the actual blocks UI for putting things in the dashboard. It's quite possible you want online users, recent comments, a custom menu block etc. here, and on your main site as well - we should let site admins decide what's suitable for the dashboard rather than hardcoding what's available either via hook_widget() or an 'admin' key in hook_block_info(). Also, we already have per-user and per role block visibility, so we could re-use that to make dashboard widgets configurable on that basis.

How about adding sidebar-left and sidebar-right regions on every page for the Seven theme (but called 'dashboard left' and 'dashboard right' in block administration, then having dashboard.module hook_form_alter() or otherwise populate page visibilty to force those blocks only to appear on /admin. Default profile could also enable some obvious blocks there (like recent comments).

catch’s picture

Issue tags: -Screenshot, -ui-pattern, -ux +Usability, +D7UX
yoroy’s picture

Thanks, this is the feedback needed indeed. Apologies for not mentioning Panels… :-)

I totally agree with the blocks approach, we already have a few widgety ones there: number of users online, recent comments…

Regions and blocks sound like a lightweight core approach. Sounds almost like a context (page) sensitive blocks admin… Yes, Panels indeed.

How about adding sidebar-left and sidebar-right regions on every page for the Seven theme (but called 'dashboard left' and 'dashboard right' in block administration, then having dashboard.module hook_form_alter() or otherwise populate page visibilty to force those blocks only to appear on /admin.

Can we make this page a core-worthy special case in this regard?

Gábor Hojtsy’s picture

The issue with blocks is that the (a) normal blocks UI will be invaded by some of these dashboard widgets and (b) all regions are populated on all pages.

So (b) can be altered out, but it is still useless work done on all admin page views if the admin and user themes are separate. If they are configured to not be separate, then even worse, all page views. We'd need a pull approach for blocks, or at least some way to specify what page type supports which kind of regions. This would be useful generally for any front end theme too. Eg. front page supports bazillion regions, section pages support less, inner pages support funky regions like ones inside a node body but also support less. Ie. only generate/use regions specified in the (*-)page.tpl.php to be used for the page.

This does not solve (a), but would at least be a end to a much discussed problems with blocks.

sun’s picture

1) Can we make the block admin UI re-usable for different purposes?

2) Depending on 1), can we create a dashboard "Edit" page, where the block admin UI appears to configure blocks for the dashboard, only using the special regions of the dashboard?

3) Profit?

catch’s picture

a) I think that's fine - you might want to display your statistics widget publically, who knows.
b) I meant setting block visibility programatically. Not ideal, but would save the bad work.

We need a pull blocks system but i don't think we can get that in two weeks. Like sun's idea.

Gábor Hojtsy’s picture

Well, given hook_block_list_alter() from #370172: refactor block visibility is in Drupal 7, the list of blocks to be displayed is altered before the blocks are to be rendered, so it would not be a big performance impact after all to use blocks for the dashboard as they are. Huh.

rickvug’s picture

What would generate the site statistics? Statistics.module? Also, what will be generating the charts based on such statistics? I bring this up because Dmitri and I are Google Summer of Code mentors on the Google Analytics API module (http://drupal.org/project/google_analytics_api). Part of the project is implementing statistics reporting and charts. A contextual block and detailed page stats breakdown are already nearing completion. We are now looking for more feedback into a general site statistics dashboard. I see this being linked to having a dashboard in D7 as many (most?) Drupal site's these days rely on Google Analytics for tracking, so it makes sense to pull this information in. Also, I do not see chart generation getting into Drupal core anytime soon so any charting will need to rely on contrib for now.

If interested in this topic, please post feedback at #551082: General statistics overview (dashboard). I'd see this first taking the form of a stand alone page and then integrating with the D7 dashboard when (if) this patch lands.

yoroy’s picture

Good to know! But, let's not focus the discussion on the specific widgets here (although we obviously need them) and work towards an implementation for a widget container page first.

sun.core’s picture

Status: Needs work » Needs review
rickvug’s picture

@yoroy Completely agree that my comment is out of scope for this issue. I don't mean to bring the conversation off course. Just wanting to get the word out to people here who may be interested. Where my previous comment does relate is the opinion that the D7UX screenshot is not possible to implement without contrib. That is where Google Analytics or other projects would come in. I'd see the issue here as building a common framework for the dashboard. Adding other blocks to display stats etc. is something best left for follow up issues.

To comment on this issue, Gabor mentions in #20(a) that this issue may relate to changing the blocks UI as the dashboard and present blocks UI are very different. While I agree that a unified interface is ideal, I don't think that anyone wants to see this issue stalled because of the Blocks UI being long in the tooth. Assuming that #473268: D7UX: Put edit links on everything gets in and an "edit" toggle is included, adding on page drag and drop block re-ordering could be a follow up if time allows. I'm sure that much work would be involved. At least jQuery UI is in core so the JS library choice is clear. :)

NaheemSays’s picture

subscribe.

(mockup in comment 13 reminds me an awful lot about wordpress...)

catch’s picture

@Gabor #23 - either that, or add page visibility settings for each block record inserted for dashboard-specific blocks, probably the new _alter() hook would be less of a wtf though.

Dries’s picture

Given the amount of time we have to code freeze, I think we need to drastically reduce the scope of the admin dashboard. That is, leverage the block system instead of introducing a widget system. For block configuration and placement, leverage the #473268: D7UX: Put edit links on everything patch.

drifter’s picture

I love #20 (different regions per page template), and would like to work on it given some guidance. Probably too late for 7.0 though.

mcrittenden’s picture

Subscribe.

catch’s picture

Status: Needs review » Needs work

No working patch here, so changing status.

Gábor Hojtsy’s picture

Status: Needs work » Closed (duplicate)

Looks like the way with blocks is what got more traction among reviewers. Reopened #544360: D7UX dashboard module then, and marking this a duplicate.

isaakordonez’s picture

Status: Closed (duplicate) » Needs review

#2: administer_dashboard-376103-2.patch queued for re-testing.

catch’s picture

Status: Needs review » Closed (duplicate)

No need to retest duplicate issues.