Improved list customization using mosaic - Final Report
This blog post works as a final report for my Google Summer of Code 2017 project. I did my project for the Plone Foundation and my goal was to improve the flexibility of Plone's Mosaic add-on. Most of the work revolved around the creation of inline tiles, which were not confined to the grid that regular tiles used in Mosaic. With the inline tiles I also modified the existing content listing tiles so that layout of list items could be edited with the inline tiles.
My project was based on one of the suggested GSOC-project ideas by Plone. The suggestion was based on an issue listed by my mentor Dylan Jay on Mosaic's github page. In the issue Dylan stated that there wasn't an easy use case to customize listings or searches in Plone. To customize listings or search pages, users needed to edit the TAL-templates which also required knowledge of Plone's python code. The goals of the project were to make it easier for users to create their own listings and search pages. Following along suggestions Dylan had made, I set out to solve these problems with the Mosaic add-on by first implementing inline tile functionality to Mosaic, and with inline tiles I would start to work towards creating specific features that allowed for customization of listings and searchforms. While the tools for editing list UI was lacking, there were already good tool in Plone for performing queries, so I decided to modify existing listing solutions, rather than creating completely new. My initial plan was to use Plone collections for displaying search results, but I ended up modifying the content listing tile that was part of the standard tiles package.
This blog post acts as the final report for the project and describes the work I did during the summer as well as describes the design process on how I ended up using the solutions I did.
My project was based on one of the suggested GSOC-project ideas by Plone. The suggestion was based on an issue listed by my mentor Dylan Jay on Mosaic's github page. In the issue Dylan stated that there wasn't an easy use case to customize listings or searches in Plone. To customize listings or search pages, users needed to edit the TAL-templates which also required knowledge of Plone's python code. The goals of the project were to make it easier for users to create their own listings and search pages. Following along suggestions Dylan had made, I set out to solve these problems with the Mosaic add-on by first implementing inline tile functionality to Mosaic, and with inline tiles I would start to work towards creating specific features that allowed for customization of listings and searchforms. While the tools for editing list UI was lacking, there were already good tool in Plone for performing queries, so I decided to modify existing listing solutions, rather than creating completely new. My initial plan was to use Plone collections for displaying search results, but I ended up modifying the content listing tile that was part of the standard tiles package.
This blog post acts as the final report for the project and describes the work I did during the summer as well as describes the design process on how I ended up using the solutions I did.
What I did this summer
The actual code I did can be found in Plone's github. I wrote code for two Plone add ons: Mosaic and Standardtiles. For my code I created new brances and submitted pull requests in both add-on's respective repository.
I will be updating these branches after the final evaluation deadline is over, but from time stamps it is going to be visible which commits were made after the deadline.
Mosaic pull requests:
I will be updating these branches after the final evaluation deadline is over, but from time stamps it is going to be visible which commits were made after the deadline.
Mosaic pull requests:
Standardtile pull requests:
Inline Tiles
I started my work in June on the inline tiles. The goal was to allow users to drag and drop tiles in and out of the rich text tiles. While inline tiles we're required to implement other goals of the project, they also provided users a way to create more robust layouts with the Mosaic editor. By default, tiles in Mosaic are bound into a grid. Inline tiles however are free from the grid and with the use of TinyMCE:s formating ability, inline tiles allowed users to more freely edit the site layout.
All changes and new code for this functionality was made into the mosaic add-ons javascript code. The drag and drop in mosaic was created using jQuery and I wrote the inline tile functionality in same manner using CSS-classes to mark elements in page and binding event behaviors to certain classes. TinyMCE is used in Mosaic to edit tile content. I used TinyMCE:s own API to insert tiles to the editor content and TinyMCE's Noneditable plugin to make the tile's draggable inside the TinyMCE editor.
All changes and new code for this functionality was made into the mosaic add-ons javascript code. The drag and drop in mosaic was created using jQuery and I wrote the inline tile functionality in same manner using CSS-classes to mark elements in page and binding event behaviors to certain classes. TinyMCE is used in Mosaic to edit tile content. I used TinyMCE:s own API to insert tiles to the editor content and TinyMCE's Noneditable plugin to make the tile's draggable inside the TinyMCE editor.
Tile's inside rich text tile are saved with only the data-url reference just like regular tiles. When saving the parent tile, Mosaic goes through the tile content and replaces the content of inline tiles with the tile's URL.
Using inline tiles to change to create a centered page layout in mosaic editor
Using inline tiles to change to create a centered page layout in mosaic editor
Customizable listings
After the inline tile functionality was implemented, I started working on the ability to use inline tiles to customize the layout of list items in lists. I used the existing content listing tile as the baseline for my work.
As I had stated in my project proposal, the different use cases for customizing the item layout weren't all that straight forward. Me and my mentor Dylan Jay talked a lot about what the final UX for the editable list should be. I had suggested in my proposal to have one of the list items be editable, but that had the problematic use case of what to do when the list was completely empty. We ended up with the solution of having a dummy list item shown at the top of the list when using the mosaic editor. This dummy item had a TinyMCE editor in it and like Rich Text tile, you could edit the content and drag other tiles inside it to customize the layout of list items. The content of the TinyMCE editor is then used to generate a TAL-template for the list item. The conversion replaces tile refences with matching tal-attributes.
In mosaic editor, the list layout is updated live as user makes changes to the TinyMCE content. The updating is done by sending a Ajax request to the tile in the mosaic's javascript.
Another goal with the new content listing tile was to be able to repeat different types of elements. E.g. if user adds a table table row to the TinyMCE editor, the list becomes a table where the user created table rows get repeated for every item in the list. To have a certain type of element repeated, all inline tiles in the editor must be children of the same element. By default the lists are presented as descriptions lists. At the time of writing, there is support to repeat table rows in the list and the implementation can be easily extended to include bulleted lists.
Another goal with the new content listing tile was to be able to repeat different types of elements. E.g. if user adds a table table row to the TinyMCE editor, the list becomes a table where the user created table rows get repeated for every item in the list. To have a certain type of element repeated, all inline tiles in the editor must be children of the same element. By default the lists are presented as descriptions lists. At the time of writing, there is support to repeat table rows in the list and the implementation can be easily extended to include bulleted lists.
Metadata tile
Since Mosaic editor only allows you to add fields that are relevant to the content type of the current view, we also needed a way to add different types of fields to the list. E.g. we might want to add a start date field to list of events, but if we're on a Plone's front page, the mosaic editor doesn't allow us to add said field. To solve this problem me and Dylan also considered various solutions including a separate field menu for content listing and adding all possible fields to the tile menu of mosaic editor. What we ended up was creating a whole new tile from which user could choose what value the tile represents. Currently the user can choose from the metadata fields defined in he portal catalog of the Plone page, but the plan is to add the content type specific fields to the tile settings. The tile was created as a part of the standardtiles add-on.
Creating a simple list of page content's with the content listing tileWhat next?
In my project proposal I presented as the third goal of my project the ability for users to create custom search form with the inline tile functionality. User could drag different search fields to a form tile to allow different search criterias to be used in a search. Due to time constraints I didn't get to implement this functionality, but through the feedback and discussions I had with Plone community members, I did get to plan out that easiest way to star creating would be through the existing contentfiltering add on. I plan to keep working on this feature after summer.
Also in the pull requests I've made are still present some bugs that I'll try to fix as soon as possible.
What went well
For most part I'm glad with the communication between me and my mentors. We mostly communicated in gitter. Me and Dylan had couple of hangouts during the summer to discus my goals for the project and I had some face to face interactions with my other mentor Asko Soukka who lived in the same city as me. I'm also glad that we could decide upon some of the difficult use cases of this project, such as the editing of list item layout and adding fields to a list. While there is still work to be done before all of my work can be properly integrated into Plone, I have really clear vision on what still needs to be done. I was also able to take part in the Plone's Midsummer sprint in Jyväskylä during the summer which was great opportunity to meat other community members.
What could have been improved
As I mentioned in my original proposal, one of the risks of the project were the unsolved issues on how to implement some of the goals of the project. While I think that we could answer these issues well during the project, I wasn't still able to reach all the goals I stated for myself in the proposal. This could have been helped by me being more active in discussing the implementation of upcoming features, while working on the parts I already had a clear plan on.
Kommentit
Lähetä kommentti