Revamp skin editor...

[Aaron]

Steve,
I must come clean and have not tried to dig into skinning until today.
It looked tedious so I avoided it hoping the interface would get better when I was ready to use XL for my home.

So I waited but it is still a bunch of tabs.

I'm hoping you'll take this as constructive... the skining interface could use some serious improvement.

My suggestion, and hope, is that it would be geared towards mass changes and not one button one tab at a time.

Have something like a grid where it could have all buttons/items on a single screen if desired (filtering is nice too).

We could then quickly identify an item (not need to switch to the screen), highlight it, and make changes in a grid format. Most of the tabs are unnecessary and only enable our enemy carpal tunnel to take control.

I'm not even creating an entire skin, just mod'ing Badda's but removing screens and changing buttons and the like is just tedious with the current interface.

Unless moving a button, it is totally unnecessary to even see the screen. I can change the even triggered, the images, etc and not need to see it. I'd like to make mass changes to several buttons at once... highlighting several in a grid and changing the text size, or the select image, etc should be made easy to do. IMO.

just my $0.02

flame away if you must

[Colby]

Well some time ago we had a debate on how the skin editor should go. There where those who voiced a vote for a table approach as you suggest and then there were those who had other opinions.

I created a mockup back then of how I would make the skin engine. It takes some of my favorite elements from some of the graphics/web programs I use everyday. (Photoshop, Dreamweaver, Flash, MS Word, etc..)

Hover over the buttons to see what they would do, click some of the buttons to see what additional properties boxes open.

I agree creating a skin is tedious. That is why there are so few complete ones. But, XL has come along way since the original skin engine. I dont think it needs to be overhauled. I would suggest mastering what is there, and see how powerful it really is.

[Aaron]

very nice mock-up.

I do think that it is much more efficient to greatly reduce the number of tabs and go with an approach that allows for ease of mass/multiple editing.

If you think about what the majority of people will be doing, which is editing existing skins, this just makes good sense.

[Colby]

Contrary. Who is to say most people are going to modify skins as opposed to creating. Do the majority of Photoshop Users modify pics, or create art?

Actually there is very little that would even need mass edited. If it is fonts, colors, or shapes that is simply a matter of assigning a resource. If it mass change images, you can create your new graphics and save over with the same name. What else needs mass editing?

I do agree the tab system is kind of hard to use. Thats why my approach uses docks, that can be interconnected. "One page; all the properties about everything open at once"

[Aaron]

I did not explain myself well...

my thought and experience using other HTPC front-end is that a small percentage of users actually create skins (less then 10%) and the remaining users either use them as is, or mod them to some extent.

In my case:
I want to remove a few screens, add a screen, remove buttons, move buttons from one screen to another, change several existing button images to other images that exist in the skin (not create new images), resize many buttons and change text size, and change many button events.

This alone takes a long time when you need to go into each button to make the changes instead of being able to select all the buttons on a screen, or several screens, and tell it to change the ext size all at once.

In a grid format, the buttons could all be in a list and I could scroll down and change the events at a click of a button in seconds, instead of 10 minutes.

Basically a large properties page that scrolls. It would be huge (filtering would be good) but editing a dozen or so buttons at once would take seconds.

Colby, I'm back to this and I know you said you did not want it before but it does make skin changes much faster...

[rembetis]

I vote for Colby's approach, if only because I'm pretty familiar with Adobe and Macromedia products. But you could kind of combine the ideas by having a "properties" subwindow that shows the individual characteristics of each item and harnass the "Resource" feature already in the skinning editor to do a kind of Cascading Style Sheet, so changing one instance changes them all...

[Aaron]

The idea is to be able to directly edit one or several items at the same time just from picking it from a list, no need for a gui at all.

I have no need for the gui just to change all my images button on three screens from blue_glow.png to green_glow.png.

If you want the toolbar like ps that is fine but it does nothing to solve the problem of quickly editing one or more objects... image editing is very different then "object" editing. This is one reason why development programs don't look like photoshop.

[Colby]

I have no need for the gui just to change all my images button on three screens from blue_glow.png to green_glow.png.

Well if you dont care about the GUI, open the xml of the screen and do a find a replace function. One step and "blue_glow.png" becomes "green_glow.png". I still see no need for the table view.

[Aaron]

I have no need for the gui just to change all my images button on three screens from blue_glow.png to green_glow.png.

Well if you dont care about the GUI, open the xml of the screen and do a find a replace function. One step and "blue_glow.png" becomes "green_glow.png". I still see no need for the table view.

Colby, that is not a solution... it solves nothing. What if you want to keep some of the images and change some... again, it must be done one at a time currently.

Here's some more specifics...

Tell me how long it would take you to ddo these with the current skinner... or even the "dock", which adds no real efficiency just saves screen real estate:

1) moving buttons from one screen to another.
- in grid view I can simply change one field on the needed (selected) lines and all those buttons would be moved to a new screen.

now do this for 10 buttons....

Via grid:
takes 2 seconds... CTRL-Click each one, change the property in one place, cascades to all selected.

Via dock/current method:
takes 5-10 minutes... go to each screen, choose the object, cut, go to the screen you want it on, paste... repeat 10 times.

yeah... that's efficient!

2) change button images.
- in grid view I can simply change one field on the needed lines and all lines and all those buttons change image display.

now do this for 10 buttons on different screens....

Via grid:
takes 2 seconds... CTRL-Click each one, change the property in one place, cascades to all selected.

Via dock/current method:
takes 5-10 minutes... go to each screen, choose the object, select the propety to change, select the image to change it to... repeat 10 times.


I seriously cannot understand how anyone could not see how much faster and more efficient this is. Though, I do make my living making fortune 500 businesses (via information technology) more efficient. I guess things that are obvious to me are not to others.

Anyway, I gave it a shot at explaining the efficiencies gained in doing it this way. This is the same method used to modify objects in a object oriented database. I did not invent this.

I'd e interested to hear from Steven on this... he is far to quiet lately.

[Colby]

1) moving buttons from one screen to another.
I mutiselect and Cntrl X and Cntrl V. Cut and paste. 2 seconds

Or. I select the buttons as multiscreen buttons and the will be on all the pages I specify in the advanced tab. 1.5 seconds

yeah... that is efficient!


2) change button images.
With a docklet method I could have my images as thumbnail dock and I drag the target line from the image to the thumbnail. (like dreamweaver) I get what I see, and dont have to hunt for fileversions or paths as in your system. You would still be inputting data one by one in your system the only difference is you dont have to goto each page. Big whoop.

I seriously cannot understand how anyone could not see how much faster and more efficient this is

I must come clean and have not tried to dig into skinning until today.

Maybe you are close minded and inexperienced.

Do you even use dreamweaver? A skinning program that doesnt use graphical page layout is equivalant to creating websites using just HTML. You will never have a good skin engine if you rely on coordinates, and speadsheets as opposed to a WYSIWYG interface.

How often are you changing images anyway? Only once and it is done right.

I believe there is a solution that neither of us have thought about yet.

[Aaron]

I've skinned several other HTPC front-end and used Pronto-edit and Tonto also.

I'm not saying get rid of the GUI, I'm saying add a quick view to it.

the grid I showed does not use manual path inputs... there are images there. The idea is to use a drop-down list to select the image, plus the grid allows you to show multiple image states... the dock would require you to drag-drop on each image on each page separately, then how do you tell it what image to replace (selected, not selected, hover)?

I could see a combo of both the dock and the grid being very useful... you could use the dock to turn on/off the quick view grid, drag items from the dock to the grid, etc.

This may actually be the best of both worlds.

As for changes, and how often...
if you have home automation and home theater using many different devices, as I do, things do change as you are adding, removing, and changing devices and settings.

Home Automation software (good ones) all give you a grid view of the devices. It is an easy way to make quick changes and see all the settings quickly.

I use the xAP plug-in and in this case it would be nice to be able to filter the grid view and show all the xAP devices next to each other, and then make the changes as necessary.

You cannot always drag-n-drop changes (you will not always have predefined settings - like apps as PS does) to all items and events and such... often you will need to type in text... so in these cases the grid is the fastest.

As I said earlier... I think the best would be to have both.

I'd think it should be fairly simple for Steven to create a window that enumerates all the items into a grid format. Listing properties that are most used.

The dock, I'd think, would be more of an endevor. But I'm no .net programmer either... only dabbled.

[Colby]

I remember this debate about a year ago. Even if the grid view is a great idea, I am sure it is low on the priorty list of stevens time. If it were he would have implemented it when he redid his skin. We can only dream, I dont look for changes too soon.