Date:
08 Apr 2010
Category:
Development Notes
Discuss:
15 comments

Props to Rowan Lewis (aka buzzomatic) for implementing the proof-of-concept shown in the video.

Download the original AVI (13.62 MB)

czheng craig zheng United States

Related Entries

Comments

This looks great! I’ve been hoping you’d add more flexibility to the way fields are organized.

The one concern I can see is that fields have different heights and while you can set it the same as you would with the current system developers are going to have to be much more conscious about what fields are grouped and how.

Is there or will there be a way to group a column of entries? For example, if I wanted to have a text box on the left and then a number of different fields on the right such as category, date and so forth?

Looks terrific! Two questions, though:

  • Are you planning to integrate a “static section” functionality into the core (i.e. sections which have only one entry, as provided in Symphony 2 by Knupska’s Static Section extensions)?
  • Shouldn’t all (standard) fields generally have “Alternate Labels”?

Shouldn’t all (standard) fields generally have “Alternate Labels”?

I rather think all fields should have these. Several times I have given fields long names to make them meaniful in the UI, only to be left with verbose element names in XML.

A tiny thing, but it’d be nice to have the field Type in the representation on the grid. It makes it easier to scan if I know I’m looking for “Article (Select Box Link)” than just “Article”.

This is v. exciting to see.

Doug has a valid point, which will also make an upgrade path more difficult. This new row approach is the opposite from the existing column approach. We have become accustomed to arranging primary fields in the left column, and secondary (meta) fields in the right. Would it still be possible to achieve something like:

 === Fieldset ==============================
|                                           |
|    -------------------     ___________    |
|   |                   |   | Textbox   |   |
|   |   Textarea        |    -----------    |
|   |                   |    ___________    |
|   |                   |   | Textbox   |   |
|   |                   |    -----------    |
|    -------------------                    |
 ===========================================

 === Fieldset ==============================
|                                           |
|    -------------------     ___________    |
|   |                   |   | Textbox   |   |
|   |   Textarea        |    -----------    |
|   |                   |    ___________    |
|   |                   |   | Textbox   |   |
|   |                   |    -----------    |
|    -------------------                    |
 ===========================================

Actually, sod drag and drop. I want to write my sections in foffing ASCII!

  • Roman
  • 08 Apr 10, 10:59 pm

Great work! Looks very pleasing from an editing point of view but I share the concern of doug and nick and would really like to see how the new flexibilities in placing fields will correspond with the look of the publish pages.

I also support the request for “alternate labels” for all fields. If each field would have a kind of “title/name/handle” in addition to the current “label” one wouldn’t have to worry about blown up xml when figuring out the appropriate description for the client.

It also would make the use of foreign language labels much more of a no-brainer as one could stick with a simple english naming scheme for the xml output while having the possibility to use other languages for the labels.

Wow! This is really exciting! I like the way you can lay things out and have a lot of control over it.

I too, am hoping for a few improvements in the default fields. A label or instructions field would be nice as then you could provide explicit directions, yet still keep the naming scheme shorter.

Are there also any changes planned for the Upload field? It’s almost useless because you can’t choose files that are already on the server, and it won’t let you upload duplicates.

Thanks for the feedback so far. Keep it coming… :)

  • Nils
  • 09 Apr 10, 3:17 am

First of all, I like the idea, I like the general look and feel. It’s a good concept that helps keeping the different fields closer to each other which improves usability. But besides this I’ve got some concerns:

First and foremost the introduction of a row-based backend layout is problematic because it increases layout complexity. While it looks very slick in the section editor it’s like a worst case scenario for field extensions that are more interface oriented (like my own Date and Time or the Subsection Manager fields). This is due to two facts: Not only do these fields have to work in and adjust to more than two columns (your example shows at least four columns) but also will they break the whole page layout when they slide up and down their drawer content (e. g. the calendar of the editing screen for subsections). If the user chooses to open a Subsection Manager, all field elements in the backend will move - all and not just one of the columns (which by the way will no longer exist as each row can contain a different number of columns with different widths). This might get quite confusing even for advanced users.

Everything that has been done vertically in 2.0 should now be done horizontally in 2.1 — following the example of this new concept — which seems not a good idea for a list of content (as in: entries of a subsection). While the section editor interface is nice, it forces extension developers to rethink their interface decisions and a lot of field extensions will have to be heavily edited to really fit into this new concept. Please don’t get me wrong: this doesn’t have to be a bad thing — but we all should be aware of this and the fact that this will reduce the number of 2.1-ready extensions with this next major release.

I also think that the field type should be reflected in the UI. One thing I miss in this interface is the option to compare the setup of two fields in a section. I often test different field extensions with similar functionality and I like to see their settings at a glance. Maybe it would be nice to have an option to select multiple fields on the left which would add a settings panel for each field on the right (one below the other).

One thing you explained to be a feature in the video looks like an interface bug to me: Having a single add and delete button in the last row. While I understand the concept it just feels wrong. Maybe always adding the drop area between those two buttons would solve this issue.

Coming to the end my feelings are mixed: I really like this proof-of-concept for the section editor point of view — but I don’t like all the consequences it evokes for the publish area.

P. S.: I just installed a copy of Alistair’s working branch and the section editor really feels fantastic when you use it. So all my concerns are mainly publish area related. The button-like field styles remember me of an unfinished Symphony extension, which is funny :)

Thanks, Nils.

For the record, I think I mostly agree with you. The new section editor delivers a wonderful user experience, but I’ve had several concerns about the form design in 2.1, and this only exacerbates my worries… If implemented as-is, I can imagine the UI becoming very unwieldy, very quickly.

I’m not sure what the answer is, but we’ll have to continue experimenting until we get it right.

This might be a situation where we open it up to the community for ideas.

I think one of the reason to consider that is because you have a very active group of high quality developers and designers who know Symphony on so many levels and have used it for so many things.

That’s a lot of experience and knowledge that you guys can tap into.

Wow, exciting user experience.

One cool way to make the backend more customizable might be to allow a little but of custom CSS on some of the fields. I know Bildy does this. You could use it to do things like: make the Headline or Title field use a larger font, or put your Meta Fieldset Title as more greyed out. Just as an idea/suggestion.

Thanks Craig for sharing. Very intriguing. I look forward to see what y’all have in store. Very nice!

  • Etch
  • 15 Apr 10, 11:52 am

Yeah. This looks phenomenal. Only… Based on my first-time experience with Symphony… Some kind of undo feature could be amazing. I guess that only appeals to the beginners though.

Great vid :)

Great innovation, very excited about it! Was it inspired by Frevvo forms (saas xform in java) where I have been talking about since very long?
You should really check Frevvo out if you consider becoming more user-focussed.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details