Panels 3 UI Design Thread
This is a working thread to discuss the (still far in the future) Panels 3 UI. I want to get work started on ideas to improve the existing UI, and for the moment we are allowed to go pie in the sky and suggest features. Please assume that pie in the sky features will eventually be shot down, though, but it's on the table because sometimes pie in the sky can really work or be made to work.
Here are things I know:
- I've decided I want to totally eliminate the popup modal and instead go with clicktips. See http://plugins.learningjquery.com/cluetip/demo/ and look at option #8.
- I want a unified editing system like Views have.
- Node override/add/edit will probably have its own UI. (internal code may or may not be separated, Sam and I are still discussing this, and currently we are in disagreement. We'll work that out.) Similar concepts may also have their own UI, such as taxonomy/term/% override (and maybe taxonomy administration could be a part of this) as well as user/%.
- Panels pages should keep most of the features it currently has, though we can strip some of them away.
- Layout management should merge more nicely with the content management screens where possible.
- Panels node is under consideration for being renamed to panel node type. Suggestions welcome.
- The terminology I use -- display -> panel -> pane is up for debate. Currently contemplating panel -> panel region -> pane as being more immediately understandable.
- I want, as much as possible, to have editing a thing near viewing a thing.
- Content selection needs serious work. Right now my thoughts are more hierarchical, possibly with a search mechanism.
- Style selection needs to be more interesting than a select box. Perhaps it should use the same selection mechanism as content. And perhaps we may need to have our own generic foo selection widget that is hierarchical and can handle complex display with images.
Given this as a start, I am now taking ideas. Please don't overdo the first ones, we're in a very early phase and so quick wireframes or screens that you can put together quickly are the best use of time.
Groups:
Login to post comments
Layout creator
A better flexible layout creator (I can help with this)
Finding the ingredients
I mentioned this months ago but neclimdul and I were just discussing it because he was faced with it and yoroy suggested I post here.
Panels is wonderful for assembling pieces from all over the place and bringing them together in a pleasing final product. But going the other way is tough. If you are presented with a panels page and told to fix something, there's no easy way to work backwards to get to the pieces. If you have a nodequeue that has a view that has a view pane that's in a mini panel that's added to the panels page, good luck looking at that page and knowing it's the nodequeue you need to change. There needs to be some way to follow the path backwards so you can make changes in the future.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Custom panes need to be able
Custom panes need to be able to have a WYSIWYG editor attached to them. This way an inexperience user can still add simple panes to pages without having to slog through learning HTML to do it.
This is more about Drupal
This is more about Drupal having a good wysiwyg api and the D6 behaviors system. It should be much more doable now than it was in D5.
some first screenshots
Screenshot 1:
Screenshot 2:
My try on what is happening here. Merlinofchaos, maybe you can do your version as well and explain a bit more in depth.
1: You have already chosen which kind of Panel you will be building, in this case overriding (panelizing) the Node view (other overrides can be e.g. "Taxonomy term view", "Node>Edit view", "User-profile")
2: Task Handler: "you build a stack of apes you pass the banana along to". It is a top-down stack of handlers (filters, operations…) you push your node through. Only one of the filters will apply.
3 & 4 are two examples of handlers, as added through 5.
6: You have clicked the configuration icon for the panel-handler (4 in first screenshot).
7: This one steps you through the options we recognize from Panels2: Change layout, Layout settings, Panel content. Like in Views2.
8: Returns to the list as in screenshot 1
For me, the Taskhandler (2, 3 and 4) is quite abstract. I think it contains the main setup for your Panel, but I'm not clear yet on why I'd want to build a top-down stack of possible operations on a node (or taxoterm, profile, etc.) for this.
It's because different node
It's because different node types often have radically different display needs. It turned out to be one of Panels most interesting features to have multiple displays based upon the argument, where each node type could have its 'own display' or they could all share a generic display.
This actually makes it, I think more straightforward. For 3, you've got some 'complex' display that is probably analogous to og_panels. IN fact, let's pretend that 3) said "Organic group panel" instead of what it says.
In that case, it's: "If this is an organic group node, let the group decide how to display it." Then that task handler would accept the node. Processing of the task list would stop and og would go on its merry way.
But if it's not an og node, it would fall to the next handler, which is a panel for node types 'Artist' and 'Album'. If it's one of those two types, that Panel will display it. If not, it will fall to the next item.
Since there is no next item, the built in node display takes care of it.
Arguments in admin-panel-pane-content
Hi Earl,
I would like to see the arguments of the views shown in the panes as I look to the content on: admin/panels/panel-page/[display]/edit/content. Now I can't see as admin what arguments what pane contains.
See for screenshot the present UI and as you can see I have a couple of times the same view, but the view contains different arguments. The view name is "resultaten" (dutch for results):)
Thanks for considering altering this in the admin UI!
Greetings,
Martijn
Why Cluetips?
Why cluetips? What does it offer vs the dozens of other jQuery popup plugins?
Is there any way I can talk you into building on top of my Popups API instead? One of the advantages of using a solution specifically designed for drupal is that the XHTML of the popup window is in a themable .tpl file.
Also, add my vote to the "panel -> panel region -> pane" renaming.
My understanding of your
My understanding of your popup api is that it tends to be much more standalone than what I work with; also, since this is moving toward a CTools dependency I'm leery of adding more dependencies to this, which is already going to force 2 packages. I'm already unhappy with the Image cascade of dependencies and I don't want to duplicate that.
In the 1.1 release I have
In the 1.1 release I have broken out the API into it's own module to make it easier for other modules to build on top of it. I am sure there is more that can be done, but I think it is a good start, and I would be happy to build on any suggestion you had.
I get wanting to limit the dependencies, although it feels like a paradox. We all want to build widely useful API modules, but actually building on top of those API's feels like it places a burden on the users, forcing them to do multiple downloads. I wonder how the work on the module to securely download modules is coming along. Automatic dependency downloads could be a real killer feature in D7.
5 cent
Current Popup API doesn't allows using tableheaders and any behaviors in popup level, only one level...
Popup API does allow js
Popup API does allow js behaviors, but as of the 1.1 release, if the behavior is not in the originating page, you need to use the "additional_javascript" and "additional_css" options in the hook_popups rule. The 2.x-dev version has code that attempts to eliminate this requirement and autoload any needed javascript or css files along with the popup.
Of course, there are some problematic behaviors. tableheaders.js and teaser.js both break the first rule of behavior and act outside of the context, so that applying them to the html in the popup breaks the original page. There might be ways to work around this though. You should open an issue in the popup queue.
Why not join forces with views?
Views already has nice editing system so maybe better to unify UI platform and split UI from API ?
Voting
voting for unifying UI
I have a dream, where CCK, Views and Panels all are integrated into the core and have same UI with easy intuitive workflow.
Unification
I agree. The all on one screen Views UI is much more efficient to use than the multi tab multi page Panels UI.
I also think of would be great to be able to use one centralized Universal UI to make all changes and settings regarding how content is displayed and formatted. I hate having to jump back and forth between Views and Panels and CCK field settings and sometimes Themes settings and Contemplate to control the granularity of display formatting.
WYSIWYG seems more valuable for entering and editing nodes. At the level of selecting and placing content in blocks and panels and pages live preview seems like the solution. It might be great to have something like Firebug type functionality there though so we can quickly identify the CSS needed to format the content as desired. If we wanted to make it REALLY easy to use we could allow for actual reading from and writing to tpl and css files to minimize use of FTP and manual editing of those files.
Views and panels overlap
Currently Views allows for multiple displays of each view with control over how many nodes to be displayed in each and whether the nodes should be displayed as lists with only titles or teasers etc. Panels also allows for some control/override of these options. This allows for flexibility but creates some redundancy and confusion.
Maybe the. Views UI should simply generate queries and return the results. Then only at the UI for placing content would we further define how which and how many of the query results we want to place in a given instance and how we want to format them.
I think I am saying that the current Views2 UI is great but let's move some of that functionality to the Panels UI. Does that make any sense?
Terminology: from this
Terminology: from this issue: http://drupal.org/node/256479
panels components and terminology
I'm not sure about replacing the term "Panel" with "Region" as it is a different type of region than the already existing regions defined by one's theme.
Would it be possible to
1) have every Panel "item" be a Mini Panel (and thus re-useable and placeable in more than one instance at a time)
2) replace the Drupal Blocks system with these Mini Panels, which could then be used within the Panels environment as now but also be available to be used in the old Blocks way (they would be much more configurable than Blocks are currently), or we just eliminate Blocks and work exclusively and entirely with Panels and Mini Panels. The term for these could be "Mini Panels" or "Panel Items" or "Blocks." I think I vote for "Panel Items." "Blocks" is shortest to type and makes sense but might confuse some people at first since the old "Blocks" would still be out there in use for some time.
Cluetips issue
I've been trying to use Panels 3 seriously for about a week, now. If the "action" menu on the Pages screen is a preview of Cluetips, I'm not optimistic that it will work well as a replacement for the old modals.
Not directly relevant to the cluetip tool, but:
--
eric scoles | http://brandcool.com
That isn't actually
That isn't actually cluetips, it's a dropdown tool I wrote. I'm not sure I understand the coming off the bottom of the page issue; is it too much of a burden to scroll down? How do you deal with select boxes when you open them up and they go off the bottom of the page? They are meant to act very, very similar.
When you talk about the simple links, I'm not sure I understand the context.
Screenshots attached
Scrolling down doesn't help. The dropdown extends beyond the bottom of the page, not just the window; the page can't be scrolled any further. The only solution I've found so far that works is to shrink the page down until the whole drop-down fits on screen. (See first attachment, pages-menu.png.)
There's a similar problem that crops up in the layout designer, where the drop-down slides under the edge of the current container, obscuring some of it. On small regions, it hides most of it, and I have to guess at what the options are. (See second attachment, layout-designer-menu.png.)
My description of the link to display the drop-down was inaccurate: There is in fact a downward-pointing arrow at the beginning of the line. So I suppose people "should" see that as an affordance for a drop-down, but I didn't -- I was expecting a new page, or something more persistent than these drop-downs. Actually, a select box would be better, now that I think about it: It would not extend beyond the bottom of the screen, would provide a clear affordance for selection, and would be persistent when I move the mouse pointer away from it. In order to keep these drop-downs displayed, I have to be careful to quickly move my mouse pointer over them; otherwise, they go away before I'm able to fully apprehend what's on the menu.
--
eric scoles | http://brandcool.com
Ok, my dev site puts a bunch
Ok, my dev site puts a bunch of chatter at the bottom so it never occurred to me that this could happen. I'll figure a way to address it.
Right now the down arrow I use to indicate a menu is clearly not indicative enough -- you aren't the only one to have mentioned that. There's a bunch of stuff that needs a visual update just now, so we're working on that.
The dropdown getting obscured by another container is kind of an annoying side effect of how the dropdown positions itself and I may have to find another method, as that just doesn't seem to truly work right. in all situations.
The biggest problem I'm
The biggest problem I'm having with the Panels 3 UI is that I have no clue how it's all supposed to fit together. This really is a UI issue: If you can't understand what it's supposed to do, you won't be able to make it do what you need it to.
I know that now we have something called a 'delegator' (which we never see in the UI), and that we have these things called 'tasks' that seem to be something like pages but might not be, and which are not identical with the old panels pages. We also have 'handlers', but I don't know what those are, either. And I haven't found anything so far that explains any of that.
I know that I'm supposed to be able to use a new visual layout tool to create pages, but I don't have a clue how it works, since I can no longer see a UI for creating regions (panes). I have a panel layout that came in from Alpha 2, but I can't see any way to create a panel layout in Alpha 3 (with the new design tool).
Right now, if you want a complex layout in D6, Panels 3 is really the only game in town. But it's simply not accessible for any but the most persistent and technically astute users. Panels 2 was hard enough to train users on; for Panels 3, I can't even imagine where to start.
--
eric scoles | http://brandcool.com
Yes - same here
Hi Eric,
just subscribing to your comment.
It just shows that it is very difficult to write the manual and tutorials for the things we know. It isso diffcult for the people who know what they are doing and how it fits together to take a step back and explain the process to someone trying to understand it from the "outside".
So,
one - we should all appreciate the work of people providing manual, tutorials and documentations more.
two - there are so many badly written documentations around not because the person is unhelpful - but because it is so difficult to take that step back.
three - we have to appreciate good documentations even more. While still be grateful for anyone attempting to write documentation.
four - this should make us aware of how valuable good teachers are.
five - we are still on the "outside" - so if we all who are on the outside come back to where we found a bit of advice and report back how we got a step further it might just help the outsiders to go forward and the insiders to take that step back.
I just made a real step back by upgrading Panels, APK & CTools to their latest version - (12-July 2009) - because now I lost the panel that appeared magically on installing all the above a few months ago.
Well, other than singing praise of good teachers I haven't added anything to the issue at hand - and thus please remind me to come back along the way of finding my way into the maze of CCK, Views, Panels, APK, C.Profile & co.
Ah, well, of course thanks to all those even creating all the problems for the outsider - the module writers and maintainers. Without you we would not have the challenge and the progress. And of course we all are volunteers and that deserves a few more cheers .....
.
This is totally OT, but I suspect you missed the "enable it" step in the release notes. If that's not it, please take it to the issue queue rather than going further OT.
On topic: Panels / CTools just had a massive UI upgrade. Anyone following this thread should go check it out. It's 100% better.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
... just the wrong end of the stick ...
I think you just got the wrong end of the stick. My comment was meant to be along the line of the one below. Maybe i even proved the point how difficult it is to write clear documentation ;-).
I very much appreciate all the work from all the people contributing their skills and especially all those modules with hours and hours of work in your own time, freely given to the community. Just amazing and fantastic.
My point is just for all to be aware how difficult it is to write documentation (and in the trail of it to be a good teacher). That is it. No criticism, just pointing out the reality. There are tons of people out there getting frustrated with instructions everywhere on anything, flat pack furniture is a good example.
And, of course, there is more thrill, satisfaction and glory in writing a fantastic module than in trying to explain it to new comers. That is fine and thus we should all appreciate much more the work of people helping others to learn. In some cultures teachers are the most respected people along with doctors. In the West we lost that.
So, thanks for your tutorials I found them in my quest - of course the UI had changed the terminology and interface a bit in the latest release (July 09), but I got it going a bit and yes, I did find the release not along the way. So, nothing to complain there.
What remains though is that I am still struggling to really get going with Panels as the current (revised) interface is still not very clear and intuitive. I will work it out and get there and shall happily help fellow drupalers - mostly in drupal.org - once I get to the point being able to add something worthwhile.
Please, just take the core of my thought - good documentation is a really hard job and we all should be more aware and grateful for those teaching us well. And to make things clear and simple takes a great deal of work. It is easy to construct something complicated.
Thanks for your work and that of so many others here
No worries
I didn't take offence... Just wanted to give you a tip of what might be wrong.
As for documenting, yeah, there's a lot of work to be done. The good news is that it's something anyone can do, not just the maintainer. As you found, I wrote tutorials for Panels, which not only isn't my module, but I was brand new to Panels 3 at the time. I just wrote down what I learned as I learned it. If everyone picked their favorite underdocumented module and wrote some docs, we'd be in a lot better shape.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
A Little Thanks
I don't see this type of comment very often, so just thought I'd say, "Thanks for Views and Panels."
I'm a rather technical regular user. I've done a decent amount of programming in Perl, some in PHP, and even started building a custom CMS in Ruby/Rails. Then I discovered Drupal and Views. The UI could definitely use some UX work, but I got it enough to make things work. Then, I really got the power of views and suddenly I felt so empowered to build the kind of site I wanted. I controlled my content and how I wanted it displayed and where. Joy.
However, suddenly I hit a wall. All I wanted was a custom node page (pretty easily created with views) with comments. I read and watched everything I could find. I asked in the forums. Seems that it's not possible. So I switched back to the non-views/classic way of customizing a view: Theming. Really, I haven't felt that stupid and incompetent in a long time. Some apps/languages/frameworks have a steep learning curve, but Drupal (in that area) has a learning cliff-of-insanity. So, finally after hitting roadblock after roadblock, I gave up and went looking elsewhere at other CMSs.
Then I remembered seeing Panels. After watching/reading a few tutorials I created exactly what I wanted in about 1/2 hour, including messing with options and getting it to work with my view. I can't tell you how happy I am. Now Drupal has switched from something that I can play with for a year (Really! I have a job to do), to something that provides a real solution to my problem.
Looking at the trajectory of Drupal 7 UX design, Views, Panels, and CCK, I really believe that Drupal is moving from being a CMS/framework for hard-core PHP developers to something that the rest of the world can use and be awestruck by.
So, thanks to everyone working to make Drupal suck less or even awesome.
Conan.
on documentation
Hi:
Just to add to thanks for Views and Panels.
I've made change from Panels 2 to 3, can see improvements.
Would like to add to voices re documentation; maybe need for taking step back. Or, for people like me, maybe take a large leap or several back!
I don't really understand, say, "In a Panel, you can create contexts, which represent the objects being displayed. For example, when displaying the node view, NID argument on the page is converted into a context through the 'arguments' system."
- to me, this is in pretty deep and dense Drupalese. Likely doesn't help I barely know what a Drupal argument is; use pathauto so barely see arguments in URLs. So little clue re what I should do here. I just ignored contexts using Drupal 2, yet wonder if could be helpful to me.
I did earlier try and look for info on arguments, contexts, elsewhere, but still baffled.
I saw re Panels 2 being "revoked", so should upgrade to 3. Rather expected some kerfuffle, and so took time before upgrading.
Maybe best to make it clear that should uninstall and delete Panels 2? (or get confusing things like Panels 2 sub-modules showing up but not working).
For the Panels page design - I had a look, but flummoxed, till found some info from Michelle.
Here, I see re rows and columns - to me call to mind creating something like an Excel table; but in practice quite different.
Maybe can change some terms here, too.
Layout - seems to be more like basic template.
In content, I also do layout (for flexible template): so "content" is layout plus content.
Columns seems ok term.
But rows - won't always end up what I think of as row-shaped. Instead, might be better as "boxes" - as can hold more columns, or regions.
Regions - maybe can call these Content regions; being a bit more verbose might help.
When set "fixed" width, might have short note saying you can drag to width you want. I had to figure this out; once I found that could do this, very nifty - as is the layout creator overall.
Anyway, hope this is of some help; give an inkling of what might help someone who is by no means fluent in Drupalese, but can find Panels very useful.
What cpelham said
I'm trying to use Panels 3 in concert with Views 2, and as I read down these comments, I found myself nodding in agreement with each of cpelham's UI comments.
There seems to be significant areas of overlap between themes, Panels 3, and Views 2 (with Panels 3 sitting in the middle.) As a designer/admin type with a modest amount of Drupal experience, I'd like to reiterate that there are plenty of opportunities for winnowing down the UI options for laying out pages and parts of pages, and for selecting the content to display there. The current options are daunting indeed.
Oh, and: thank you for the superb contributions to making Drupal an extraordinarily powerful platform.