Skinr currently uses an overlay provided by the dialog module for it's editing capabilities. Many other theme/style editors use a bottom bar for editing which allows the content on the screen to still be viewed and thus provides a better user experience.

Examples of this include Sweaver and the Drupal Gardens theme editor (and numerous other tools such as Firebug, etc.) So, should Skinr move to a bottom sidebar?

If so, are there any existing bottom bar api type modules similar to Dialog or Modal Frame?


nomonstersinme’s picture

in my opinion it doesn't really matter... but i think its too late for version 2 to change. i do think we need to remove dependency on dialog. Its causing too many problems for people, it should be recommended but not required.

Jacine’s picture

Component: Code » Dialog
Priority: Normal » Major

I think so. We need to figure this out ASAP.

If anyone has implementation suggestions, I'd be happy to hear them.

ericduran’s picture

I've been meaning to comment on this issue but I keep forgetting about it.

I'm not sure if there's any "framework" for the botton bar (I search very little :/ lol ). I did notice that Sweaver provides and api which lets your register a plugging so we can have a skinr tab in it. Also one thing to think about is that skinr does have a lot of fieldsets in there which would probably not display as nice in the smaller UI (But vertical tabs might be able to help with that ;-) ).

One thing I do want to note, is that dialog and ctools (mostly ctools through dialog) do a lot of the heavy lifting in skinr_ui. So if we get rid of it they'll be a lot of extra code to make it work (The modal implementation that is).

I do think that if dialog and jquery_update/ui had an actual release there wouldn't be so many issues with it.

Uhm I guess my comments aren't really that helpful lol since they don't really contain any recommendation or anything helpful. Just my thoughts on the issue.

Jacine’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Jacine’s picture

Component: Dialog » User interface
Status: Active » Needs review

Ok, so I evaluated Sweaver as part of this process to see if we could try to either use their UI or integrate with them on some other level. I think Sweaver is really cool, and while both share a common goal to allow the user to style aspects of their pages, the way it actually works is very different from Skinr. It's much more like Drupal Gardens, where you can click lots of different page elements and assign styles to them.

This is something Skinr tries to avoid specifically. The idea with Skinr is for the themer to create "skins" and keep a lot of design control, whereas Sweaver allows the user much more freedom. It kinda reminds me of Dreamweaver in "design view" because you can pretty much click anything and style it. I think it would be very confusing for users if we tried to join forces, and also a bit counter productive since they are both different.

One thing Sweaver (and Drupal Gardens) does way better than Skinr is the UI. We definitely tried with Dialog API but there are lots of issues with that approach and I think that at the end of the day, a "dialog" was just the wrong way to go about making these edits for the following reasons:

  • The Dialog box is too small, even with very few skins available.
  • It loads a lot of CSS via @import and it's not easily override-able.
  • The behavior of the Dialog is not desirable. While it can be moved around, the page elements behind it cannot be clicked. This isn't terribly important but I've personally found it odd at times, and much prefer the "feel" of the "bottom panel."
  • It is difficult to use when trying to apply grids, and when it is directly overlaying the block or piece of content you are trying to edit.

We also have issues, where we need to depend on other modules, that seem like they may or may not get to a stable release over the course of the Drupal 6 life cycle. Given that, and the ease of using tools like Firebug, Drupal Gardens' theme builder and Sweaver, I think we should follow their lead, and go with the bottom panel. We still have space constraints, but with a little creative styling and the ability to have "grippie" functionality to resize the bar, I think it will be much nicer.

Here are some mockups (PDF) that I made, which detail what this could look like for Skinr.


ericduran’s picture

I really like the design. They're really nice.

I'm all for the bottom bar. So how de we get started?

ericduran’s picture


So I was thinking about turning this into actionable items. So we don't have to implement every single feature at once.

This is what I got so far:
- Edit Form should use Horizontal Tabs for the Theme Settings
- Edit Form should use Vertical Tabs for skinr Group Settings
- Change Create Rule to a Multiple Step Form
- Implement the Bottom Bar (collapse and Expanded)
- Allow the Expanded bar to be resizable.
- Information regarding current selection
- Shortcut Menu
- Skinr Region Selector

I might have miss some. What do we think?

Jacine’s picture

Status: Needs review » Needs work
921 bytes
18.02 KB
170.89 KB

Hey Eric, great list :)

I was able to get a lot of work done the styling aspects of this over the last couple of days.

  • Tabs for themes are in place, but we need to make them go away in certain places, i.e. when editing a block normally.
  • Vertical tabs for groups are in place, but there are some hiccups... some styles are showing in all panes. I modified the structure of the form in a few places, but did not update the validators. :P
  • I implemented the grippie on the bar.
  • Most of the styling is done.

I wont be able to work on this for a bit, so I'm attaching the patch, in case anyone wants to see it. However, it completely breaks Skinr... you have been warned.

ericduran’s picture

21.33 KB


Here's an updated patch from what jacine added. This is a start to integrating the edit skin contextual link to ajax. Right now the links work using ajax and the bottom bar gets updated, the js isn't being reattached. Still working on this, just posting incase anyone else also wants to work on it.

I'll also put up the same warning Jacine put up. " However, it completely breaks Skinr... you have been warned."

ericduran’s picture

20.28 KB

So apparently I posted a broken, broken patch lol. Here's a semi-working (broken) patch.

ericduran’s picture

20.39 KB

This is a better patch, now the js is reattached properly. So we can load any of the forms in the bottom bar.

Now we still need to clean up the bottom bar, display it collapsed initially, implement the ajax form callback, fix the form submits, and implement the cog menu :-)

Again this is not even close to being completed. Just mostly to keep track of stuff :-) and if anyone wants to help.

Jacine’s picture

Title: Should Skinr use a bottom bar rather than a modal/overlay? » Implement a Skinr UI editor that displays on the bottom of the page, instead of using Dialog API.

Updating title. To anyone interested, this is going to be implemented in 7.x first and then backported.

lpalgarvio’s picture

I would suggest either try a move to Ctools Dialog, or utilize Admin, like Context does.

Would be more in favor of Ctools because that would simplify your work, while maintaining both the D6 & D7 version, and also providing the same experience to users.

Unless the goal is to change D7 version and then port to D6... choose your best path from a developer point of view.

note: Admin might be too small unless it streches...

EDIT: nevermind the Ctools suggestion above, i've just read the post above.
just read the Admin part... and probably bash it to pieces because work is already undergone ^_^

Jacine’s picture

LPCA, we are not going to be using a modal, so we do not need any Dialog integration anymore (see comment #5). We will be using core's AJAX API, and CTools for other areas where it makes sense. Anyway, we are still in the early stages of this, but I hope this clarifies things a bit.

Jacine’s picture

BTW, re:

note: Admin might be too small unless it streches...

We've already implemented "grippie" functionality on the bar, so it can easily be adjusted.

SeanBannister’s picture

Haven't had a chance to test this but it'd be great if it didn't conflict with the Sweaver UI if you've got both modules installed as I know some people such as myself do.

Personally as a Sweaver user I'd really like to see this as a tab in Sweaver but I understand that you don't want that to be a dependency. I'm just wondering if it would be possible for Sweaver to hook in if both modules were installed and display this as a tab in Sweaver. It'd make the interface a little more consistent as I think a lot of people will start using both of these modules. Thanks for the great work.

Jacine’s picture

@SeanBannister Sure, we will try our best to avoid conflicts with Sweaver. As for any integration plans, they are completely on hold until we can get our own UI figured out among other things. If you want to follow that, see this issue: #853384: Integrating with the Sweaver module.

swentel’s picture

Subscribing - will follow this and think about possible integration with Sweaver later this week.

puya’s picture


tchopshop’s picture


nomonstersinme’s picture

just adding a suggestion for rule creation - if the new form is two steps, which i think it will be, change the initial button from 'Add' to 'Continue' so people know there is another step.

nomonstersinme’s picture

60.45 KB

Adding a revised doc that removes the tabs at the top for theme and basically just shows you the theme thats enabled with a description text that says "this is your currently enabled theme" - just a suggestion.

Also my previous comment i realized is not necessary as in the mockups it clearly states that there are more than one step in the rule creation form.

moonray’s picture

moonray’s picture

Version: 7.x-2.x-dev » 8.x-2.x-dev
Issue summary: View changes