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.
Comment | File | Size | Author |
---|---|---|---|
#11 | 3748580107_66370ccf57_o.jpg | 534.71 KB | Bojhan |
#3 | administer_dashboard-376103-3.patch | 18.73 KB | dmitrig01 |
#2 | administer_dashboard-376103-2.patch | 17.52 KB | dmitrig01 |
administer_dashboard.patch | 12 KB | dmitrig01 | |
Comments
Comment #2
dmitrig01 CreditAttribution: dmitrig01 commentedHooks, need some theming and t()ing. Removed the test for now
Comment #3
dmitrig01 CreditAttribution: dmitrig01 commentedImplementation for user. theming and t()ing are good.
Comment #4
sunsubscribing
Comment #5
Frando CreditAttribution: Frando commentedInteresting. 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.
Comment #6
dmitrig01 CreditAttribution: dmitrig01 commentedFrando:
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
Comment #7
Dries CreditAttribution: Dries commentedYou 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. :)
Comment #9
yoroy CreditAttribution: yoroy commentedWhile 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 :)
Comment #10
yoroy CreditAttribution: yoroy commentedComment #11
Bojhan CreditAttribution: Bojhan commentedDashboard update, mockup of Mark
Comment #12
amc CreditAttribution: amc commentedRelated: #488570: Block for dblog
Comment #13
yoroy CreditAttribution: yoroy commentedWe're working towards something like this (click for larger):
Comment #14
yoroy CreditAttribution: yoroy commentedmarked #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?
Comment #15
Gábor HojtsyWell #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.
Comment #16
sun<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.
Comment #17
catchThis 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).
Comment #18
catchComment #19
yoroy CreditAttribution: yoroy commentedThanks, 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.
Can we make this page a core-worthy special case in this regard?
Comment #20
Gábor HojtsyThe 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.
Comment #21
sun1) 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?
Comment #22
catcha) 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.
Comment #23
Gábor HojtsyWell, 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.
Comment #24
rickvug CreditAttribution: rickvug commentedWhat 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.
Comment #25
yoroy CreditAttribution: yoroy commentedGood 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.
Comment #26
sun.core CreditAttribution: sun.core commentedComment #27
rickvug CreditAttribution: rickvug commented@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. :)
Comment #28
NaheemSays CreditAttribution: NaheemSays commentedsubscribe.
(mockup in comment 13 reminds me an awful lot about wordpress...)
Comment #29
catch@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.
Comment #30
Dries CreditAttribution: Dries commentedGiven 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.
Comment #31
drifter CreditAttribution: drifter commentedI love #20 (different regions per page template), and would like to work on it given some guidance. Probably too late for 7.0 though.
Comment #32
mcrittenden CreditAttribution: mcrittenden commentedSubscribe.
Comment #33
catchNo working patch here, so changing status.
Comment #34
Gábor HojtsyLooks like the way with blocks is what got more traction among reviewers. Reopened #544360: D7UX dashboard module then, and marking this a duplicate.
Comment #35
isaakordonez CreditAttribution: isaakordonez commented#2: administer_dashboard-376103-2.patch queued for re-testing.
Comment #36
catchNo need to retest duplicate issues.