Skip to content

Instantly share code, notes, and snippets.

@nickdunn

nickdunn/symphony-extensions.markdown

Created August 28, 2010 10:01
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nickdunn/554972 to your computer and use it in GitHub Desktop.
Save nickdunn/554972 to your computer and use it in GitHub Desktop.
Download ZIP
Symphony extension ideas
Raw
symphony-extensions.markdown

Extension todo list

  • check fork queue for ALL repos!

Publish Tabs

  • re-release once Symphony 2.2 is out

REST API

  • tidy & define scope
  • authentication with a /content/ page rather than prefs?

Order Entries

XML Select Box

  • check outstanding pull requests

Unique Text Input

Search Index

Section Schemas

Uploadify

Entry URL

Static Site Exporter

  • rework Alistair's extension from 2007(!) (S2 rev5) to 2.1.1
  • remove FTP publishing complexity (leave as a proposed feature)

XML Importer

SymQL

Entity Diagram

Select Box Link

Bi-Link

NEW ideas

  • Internet Explorer styles
  • Video Encode field
  • Backend Params into JS (from Custom Admin)
  • XSLT Calendar Utility (from bekonscot.co.uk and fulhamrugby.co.uk)
  • XSLT heading normaliser (similar but different to Nils')
  • Far Future Cache Controller (http://github.com/nickdunn/far_future_cache_controller) needs more thought
  • Custom SQL viewbuilder: 1. Selecting from a single section (JOINs and filters), joining sections together (UNIONs)
  • Google Aaalytics: Entry URL type field to map an entry to URL in GA, table and graph in Publish form, sparkline in publish table, Dashboard panel. Cache results. Async caching with an AJAX request for other pages?
  • Entry Attribute Builder. Choose a DS. Choose another DS or an SQL query to run. A way to return the result of a query and append as an attribute onto an Entry. May require Custom SQL view builder above, or accepts a plain SQL statement (easier!).
  • Vanity URL builder (domain.com/foo => ...), much like Router, but simpler

Extensions to retire or discontinue support for?

  • Vimeo Videos
  • Gravatar
  • Pingomatic
  • Incrementnumberfield
  • EventEx?
  • Uploadify
  • Database Manipulator?
  • DB Sync
@simoneeconomo
Copy link

I think that "Pingomatic" and "Incrementnumberfield" are very useful extensions, so please don't retire them! :)

Concerning new ideas: since part of my EDUI extension will become part of the core, it would be nice to have one single Filtering extension for Publish, Datasources and Events sections. What do you think?

@nickdunn
Copy link
Author

nickdunn commented Jun 1, 2011

Fear not! This is an old list and I have since updated DB Sync and Increment Number among others, so they are safe.

Filtering, yes it makes sense to unify if we can. Let's schedule a chat to figure out how much is going into the core and what can be merged into extensions.

@designermonkey
Copy link

Dude, your idea for a Vanity URL Builder extension tickles me... I've been musing over how one could merge the Router and Root Page Params extensions into a meaty URL Manipulator extension, we should bash heads on this...

@nickdunn
Copy link
Author

Concerning new ideas: since part of my EDUI extension will become part of the core, it would be nice to have one single Filtering extension for Publish, Datasources and Events sections. What do you think?

Agreed. I've just played with EDUI for the first time and while I like it, I find the filtering quite "heavy". If we can make the whole thing disappear visually (not literally, I mean so that it's all less obvious) then we should try and merge them together. After the CSS updates are done in 2.3?

I've been musing over how one could merge the Router and Root Page Params extensions into a meaty URL Manipulator extension, we should bash heads on this

Yep, I'm game.

@simoneeconomo
Copy link

If we can make the whole thing disappear visually (not literally, I mean so that it's all less obvious) then we should try and merge them together.

What do you mean?

After the CSS updates are done in 2.3?

Sure!

@nickdunn
Copy link
Author

What do you mean?

Ha! Erm, not really sure until I have a try myself. I think I mean that EDUI you have to consciously click a "Filter" button, a large panel expands right in full view (dark background grabs attention), and you have to focus heavily on the filter. But in Publish Filtering the search box is already there, defaulting to the most common search need (a "contains" match on the first field), and is quite subtle.

So if we were to come up with a method of multiple filters, merging Publish Filtering and EDUI, I'd personally prefer it to borrow heavily from Publish Filtering: a subtle, light UI that doesn't need revealing. But then again it's only my personal taste. I've started rewriting the JS for Publish Filtering now that the backend (my integration branch) supports multiple filters in the publish area (?filter[handle]=value&filter[handle2]=value) so we can stack up filters.

Are you thinking of a Symphony/jQuery plugin to manage this UI, or for our extensions to agree a set of design/markup/CSS principles to share instead? If we go with a jQuery plugin I think it will need to be very modular since the two extensions presently operate very differently (callback functions etc.), and only the UI is similar.

@simoneeconomo
Copy link

I think I mean that EDUI you have to consciously click a "Filter" button, a large panel expands right in full view (dark background grabs attention),

It only happens when no filters are active. If there's at least one filter, the panel is expanded by default on page load.

But in Publish Filtering the search box is already there,

I'm not sure about this solution. I think that the interface should be as less cluttered as possible. If you want to filter results, a panel appears that allows you to do that. Otherwise, I think it should look as if there isn't any filtering panel.

I'd personally prefer it to borrow heavily from Publish Filtering: a subtle, light UI that doesn't need revealing. But then again it's only my personal taste.

Yeah, in an ideal world we would not rely on "assumptions" but facts. ;) Unfortunately we can't afford that, but we can still get feedback from our users.

I've started rewriting the JS for Publish Filtering now that the backend (my integration branch) supports multiple filters in the publish area (?filter[handle]=value&filter[handle2]=value) so we can stack up filters.

Great. I like the syntax, probably better than EDUI's ?filter=field:value;field:value :)

Are you thinking of a Symphony/jQuery plugin to manage this UI, or for our extensions to agree a set of design/markup/CSS principles to share instead?

Good question. My idea was to write an extension to filter results in the following areas: Publish, Datasources, and Events. We certainly need to agree a set of principles, but I'm not sure about the plugin. Nils mentioned a future Drawer plugin for Symphony 2.3 that we could make use of, but writing a plugin for the whole UI is overkill in my opinion. Thoughts?

As a sidenote: we should go quite easy supporting multiple filters. I've just released an extension that uses datasources to filters entries in the backend and it looks to me like a better way to support multiple filters. What about a "light" mode for the Publish area that only supports single filtering? What's your opinion?

@simoneeconomo
Copy link

Hey Nick, look at this: http://documentcloud.github.com/visualsearch/ I think it would be great to use an enhanced search box to filter results!

@nickdunn
Copy link
Author

Hey that's neat. Very neat! It has a couple of features that I'm not so keen on though:

  • you have to type the name of the column to filter by first — I like the immediacy of a pre-selected field list, it's one click to open the dropdown, one click to choose a field, then type the search and hit enter. VisualSearch requires me to click into the box and start typing the field.
  • there is inherent support for free text searching, which Symphony doesn't support

I've got a couple of ideas I want to play around with that are inspired by VisualSearch though.

@nickdunn
Copy link
Author

Here's an example of how light I feel the UI should be: http://d.pr/GtUU. It's so light that it doesn't draw your eye. It's there, but it's not the focus of the page.

Having watched a lot of users (not developers) using Symphony, they fall back to the search quite a lot. On one project we have a Videos section with about 1,500 entries, and videos are the sole proposition of the site. The content producer constantly has to search for videos by their title (this is the nature of the content work she has to perform), and so hiding the search behind a Filter button is going to be frustrating for her. The existing UI attempts to provide smart defaults so that:

  • the first field is chosen in the dropdown, usually the distinguishing unique content for an entry (its title)
  • the comparison operator defaults to "contains" so that partial matches are easier
  • the input box has focus, or can be given focus with a single click

For this reason I am reluctant to hide the search form.

I'll keep playing with this direction for a bit longer :-)

@nilshoerrmann
Copy link

Nils mentioned a future Drawer plugin for Symphony 2.3 that we could make use of, but writing a plugin for the whole UI is overkill in my opinion. Thoughts?

That Drawer plugin would be quite simple: a button, a div and an animation on click to toggle the drawer panel.

@nilshoerrmann
Copy link

Having watched a lot of users (not developers) using Symphony, they fall back to the search quite a lot.

One of the main problems for this is that the Symphony pagination is a mess. It just doesn't work with large sections.

For this reason I am reluctant to hide the search form.

I think it really depends on how the hiding works in general. In nearly all our client projects I've used Publish Filtering in sections where I would have loved to be able to hide the interface initially. It's not a good idea everywhere but it would be good to have the option to hide it.

We have started using localStorage for the collapsible duplicators so when I'm thinking of a system wide drawer I'd think of a remembering interface. Johanna and I just implemented something like this in our fork of Craig's Documenter: it now remembers if the Documenter itself was opened and it remembers if certain content blocks were collapsed or opened. It feels really smooth and it gives you more freedom to arrange the system the way you want it: either clean and simple or noisy but informative.

Here's an example of how light I feel the UI should be: http://d.pr/GtUU. It's so light that it doesn't draw your eye. It's there, but it's not the focus of the page.

I like the lightness of your design, it's quiet and simple. There is one problematic area though: the rounded corners of each filter panel. They look visually nice but they interfere with the visual grid that's underlying the rest of the interface (thinking of the virtual lines created by the texts outside and inside the filter panels). The same problem applies to the default Symphony buttons by the way. While looking beautifully the filter panels don't feel grounded – I'm missing a uniting element that completes this composition.

This seems to be a general decision we have to make in Symphony 2.3: rounded or squared.

@simoneeconomo
Copy link

That Drawer plugin would be quite simple: a button, a div and an animation on click to toggle the drawer panel.

No, no. I think you misunderstood! I'm fine with the Drawer plugin, I meant that we don't need to write a more complex plugin to manage more complex features that would be useful only for the Filtering extension. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment