A better UI for Skinr

Thats cool, this is a good step in the right direction for increasing the usability of this module.

I'm just wondering if instead of:

$content.show;
$content.hide;

We could match the style of the fieldsets using :

$content.slideDown("fast");
$content.slideUp("fast");

Hi, it would be of great help if you can attach some screenshots showing off your work. Like a before and after screenshot, so we know what your patch is about and have motivation to test it out.

By reading the patch and files (not testing them), I see some issues with coding style and conventions:

skinr.module

+      // add unique id to our fieldset for ui js porpuses
+      $form['skinr_settings']['block_group']['#attributes'] = array('id' => 'skinr-settings');
+      // add our js and css files for the ui

Code comments should start with capital letter and should end with period so, the first comment would be:

+      // Add unique id to our fieldset for ui js purposes.

(Also there's a typo in 'porpuses' => 'purposes')

skinr_ui.js

You should use Drupal.behaviors for attaching your behaviors to elements.

Same rule for code comments here.

File should start with '// $Id$'

You should declare 'open' variable for cross browser compatibility.

This file should be renamed to skinr.js

skinr_ui.css

.skinner-ui-processed label.skinr-settings-tab.opened { border-bottom: 0px; }

It's better to have this indented so:


.skinner-ui-processed label.skinr-settings-tab.opened {
border-bottom: 0px;
}


This should be renamed to skinr.css

Please make this a single patch file with the files by taking a patch from the skinr directory. Check Creating patches for more info.

I'll test your patch when I get a chance.

Manuel Garcia, thanks for the patch! Could you upload or link to screenshots of the before and after for this as well?

Not sure if this will be needed anymore given the changes we are working on, but due to the lack of activity, I am postponing this for now.

Hey, something that originated from Paris, nice :)

I will shamelessly hi-jack this one to discuss the ui design for skinr in the context of the new Drupal 7 administrative info architecture and work what Skinr and Appearance page can be to eachother.

Original discussion: #2828536: Drupal 7 site is always redirecting to a permanent address (http://drupal.org/node/536440#comment-2828536)

It's a task that needs work. Screenshots of the existing Skinr admin pages would be a good start. We don't have to let jacine do that! :)

Ha, there's quite some competition for this kind of stuff now: Acquia Gardens vs Buzzr vs Skinr.
From all what I've seen, Skinr loses in the UI :(

If I get Gardens right, the principle is: You click an element, then you get the nice settings bar at the bottom at the page to change it.

Wouldn't that be a direction to take Skinr? As it is geared mainly towards Non-CSS- and Non-Tekky people (or it could be), those should not need to worry, if it is a header, block, h2 or whatever thei're editing right now.

A big task as this might be, could be worth it. When D7 comes out, the UX team is basically unemployed for some time :P
So maybe we can hit you hard with as nice as hard-to implement Screenshots and UI Plans.

Here are some Screenshots of the actual 2.0 UI.

I did not try it out much, but recently someone demoed Skinr in our Usergroup, so hope to basically understand how the module works.

Good:
+ Overlay basically a good concept
+ Skinr detects if you are editing a block or a node and shows the appropriate settings window
+++ Live Preview of applied settings
+ Icons for Settings, so you can identify them as actionable buttons

Not so good
- Overlay overlays the live changes. So you do not see them
- Skinr could be detecting a lot finer which kind of element you are editing. By most of a third of the settings are really applicable to, say, a heading.
- Why does one have the theme chooser at the bottom. I am editing the theme I am looking at and have no concept whatsoever even what a theme is.
- Classical Drupal form style: No use of horizontal space, one big list. This list is very narrow, so the real estate (which is always more on the horizontal) allows for a lot more. No optical hint as to what setting applies to which element. Small Icons like in a wysiwyg editor for say alignment, Image floating and everything could help a lot. If you filter more by element and applicable settings, this is less needed, but sure still very handy.

Reading up on what the others have written, some of this has been said before. Take it as someone else thinking the same :P.

i'm closing this since we are working on a new UI via #917448: Implement a Skinr UI editor that displays on the bottom of the page, instead of using Dialog API.