Symphony.

I do now love the idea of separation, however I find it a slight bottleneck in my workflow to have to go back to get into the XSLT editor from the Pages options.

Now I don’t the style at the moment is important, more so the placement of such a button/link.

These are three areas where I believe it could go. Mock

Makes sense to have a link. I vote for the upper right.

Me too, since the old “Configure”-Link was there too.

A link would be a huge help.

I agree with bauhouse — if it goes anywhere, I think it should be a text/image link top right.

However, any type of call to action leads to the problem of it being interpreted as an actor of the form itself. The only calls to action on the page at the moment are Delete and Save Changes, which directly act on the page object itself. Adding another link might be confusing.

Perhaps a green button top right would work. The green buttons seem to be used to signify page transitions (e.g. Create New doesn’t act on the current page, it leads the user to a new page) so might be appropriate in this instance. The grey button colour used on the original Page Editor indicated an in-page transition of the hide/showing of the advanced options for a page.

So if there needs to be a CTA, a green button top right would be the most consistent convention in my opinion.

The configure button was blue, any reason why it shouldn’t be blue still?

I think I meant blue when I said grey. Grey is used for the Deletes.

Ok, so blue is for other options or configuration in this case. Do you not think that is strong enough to be used for the XSLT Page editor?

If grey is for destructive options like Delete, and Green is for new, than Blue should be for additional options as it is used in the old style.

The way I see it Green is for brand new, well the page xslt is not new is it because it’s already been created.

Nick Dunn’s point is an important one. I’m not sure there’s a precedent for this kind of interaction or relationship in Symphony, and the function we’re talking about is crucial enough that it’s worth thinking very carefully about how it is to be designed.

Perhaps it would help clear up a little of the potential confusion if the button didn’t appear, or was disabled, if the page hadn’t yet been saved. Could still be a problem for editing existing pages though…

Maybe it wasn’t such a good idea to separate them? I’ve found myself a couple of times thinking “wich link do I have to click?” and sometimes clicking the wrong one…

According to the CSS, blue is the default, green is for the “create” class, grey is for the actions buttons. We should probably stick to that. By the way, I’ve added a couple commits to my fork of the symphony-2 GitHub project for the two CSS files that control the buttons:

• /symphony/assets/admin.css
• /symphony/assets/forms.css

See the changes here

Nice use of CSS3 there? So do we just need to grab the css or the whole package?

I like the separation myself. I find editing XSLT files through a web-based textarea extremely limiting and almost never used it.

I also like the separation, but for me it’s the route to the XSLT, and it makes sense to make that route as efficient as possible.

Out of interest, how did you write XSLT?

Out of interest, how did you write XSLT?

With wit, flair and a glass of wine?

I work locally with Textmate.

RIght, and then upload the files. Never ever thought about doing that, I suppose it’s no different. I guess I just got used to working within the Symphony way.

Glass of wine certainly helps me. I’m actually sponsored by Wolf Blass.

I actually prefer Espresso than TextMate.

So do we just need to grab the css or the whole package?

Depends on whether you are using GitHub or not. You could replace these two CSS files, or you could just clone my repository. It is exactly the same as the current 2.0.3 release except for these changes. It would probably be best to create a branch.

Assuming you have git installed:

If you already have a clone of the symphony-2 project, skip this. To clone the symphony-2 project:

git clone git://github.com/symphony/symphony-2.git

Then, create a branch:

git checkout -b test

Add a remote location:

git remote add bauhouse git://github.com/bauhouse/symphony-2.git

Then pull the changes:

git pull bauhouse master

To make sure you have only the changes made at this commit, checkout this commit by ID:

git checkout 3399b3f25b42fccb1d6e872d8529a26c881e07f9

Copy the CSS files from this branch repository and replace in the symphony directory:

/symphony/assets/admin.css
/symphony/assets/forms.css

Switch back to the master branch for the current release version:

git checkout master

So, depends on your workflow, whether Git is central to your process or not.

If you are using TextMate and Transmit to work on remote webspaces, you might be interested in a tutorial by Stuart Colville on how to open several remote files in tabs. This technique has become absolutely essential to me. Once you have set it up, it is very simple to use.

Well I use Espresso and I setup a project with server settings, so I can edit in Espresso and pressing save automatically uploads my code.

I’m actually shocked with myself that I missed this more efficient way of doing things.

I do not know Espresso very well, but there’s another great workflow enhancer if you are using TextMate: TextMate can install an Input Manager on OS X which allows you to open any browser textarea’s content (or generally the content of editable textareas in OS X) in TextMate, edit it and save it back to the original textarea. That’s very cool. Maybe Espresso can do something like that as well?