Actions

Developer Area/Specifications in Development/Basic magic block

From Mahara Wiki

< Developer Area‎ | Specifications in Development
Revision as of 21:13, 3 May 2019 by Anitsirk (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

At the moment, we are still using the working title of "Magic block" for this new feature as that where it originated from in discussions with Lisa Donaldson and Mark Glynn from Dublin City University. It will become the default block in Mahara when implemented.

Forum discussion

Goal

Be able to create templates more easily by setting up the basic structure, including block headings, but without the need to choose a specific block type from the start.

Benefits

  • A template page can be created and blocks added to it without the template creator determining from the start what content needs to appear in the specific blocks giving more freedom to the portfolio authors.
  • Template creators do not need to add instructions on removing a specific block if the portfolio authors wants to use something else, making the template easier to work with.
  • A block can be dragged into a page but its content doesn't have to be decided on immediately by a portfolio author.

Description

Note: The images on this page are wireframes and illustrate the concept. Icons, buttons etc. are not to scale, and the final icons as well as text can still change.

The content chooser that is currently displayed on the left-hand side of a page when it is in "Edit" mode is removed. Instead, a new block is added to the page without the need to select the content type.

Magic block 1.png

Once a block has been added to a page, its settings can be decided on later. When a block type is selected, it can't be changed unless no settings have been changed yet or the block is not saved but cancelled.

Magic block 2.png

  1. Typically, the block title needs to be set. Since a block type is not automatically selected, it will not receive that directly as default text. It can be left empty, but then nothing will be seen in "Display" mode of a page, and the blocks can only be made out in "Edit" mode.
  2. The content type does not need to be selected upon the creation of the block. This area is the replacement for the current "Content chooser". When a type has been selected, the relevant block settings are displayed in the modal window.
  3. The most frequently used block types are displayed with an icon. At first, this might mean that the order cannot be changed by the site administrator.
  4. Additional content types can be seen when clicking the "More" button. 8 more blocks will be displayed and if there are any left, there'll be another "More" button.
  5. The "Save" button is clicked to make the changes. The block can be updated as often as possible.

Related changes

  • Move the theme selector from the block edit screen to the page settings screen.
  • A new page is created in Admin menu -> Extensions -> Plugin administration, e.g. via a gear icon in the "Plugin: blocktype" section on which it will be possible to order the blocktypes. The ordering is done via drag and drop to reflect their position in a normal modal window (1 row contains 4 icons). The count of number of artefacts that are pulled in via that blocktype are displayed to make it easier for admins to see which blocktypes represent the most popular artefacts. Blocktypes like wall, inbox and others that you can only place on the dashboard and profile are treated differently as their artefact count skews the picture because everyone has them.
  • Auto-populating titles are removed. Exceptions are some dashboard blocks whose block title changes depending on the language you selected, e.g. inbox, topics I'm following.
  • Blocks that currently do not have a title set, e.g. journal, plan, journal entry, but for whom the title can be figured out by the artefact, get the artefact title put into the database.

Tech notes

  • Our current automatic block titles need to be rethought because nothing needs to be selected at the start, and the title should then not be overwritten automatically when a specific block title is selected.
  • Currently we have the 'Viewmanager' javascript file that handles the block configuration / placement on the page. It also handles the loading / saving of the block configuration. This will need some significant changes to work with the new system.
  • We will also need to reconfigure / redo the category list function so that the list is structured like mock-up and remove the drag/drop ability from them. They currently load the categories first then the category items via ajax to save page load time. We will need to change this so the most common are loaded straight away and sitting in the hidden modal on page load and the 'More' button loads more via ajax call.
  • We will list the most common blocks based on an admin setting of the order. This will default to the 4 most common of our choosing - most likely 4 of the following common options 'Text', 'Image', 'Note', 'Files to download', 'PDF', 'Blog post'. Then list others ordered by category (but not show a category) via a 'More' button where we list the next 8 per 'More' click.
  • The admin setting will list the block types so that one can drag/drop them into the order of their choosing. Currently content types are listed in category order / 'sortorder'. We would need to change this to use only the 'sortorder' values.
  • We will need to be able to add the 'magic' block to any view type and allow saving without choosing a content type. It will display like a normal empty block.
  • 'Magic' blocks will not be allowed to have 'tags' as they are not true content but just a place-holder for true content. If a current block can have tags, they'll be displayed in the area of the content item.
  • Versioning needs to be taken into consideration. The placeholder blocks do show up in a version even if there is no content. Then only the heading will be shown. This is current behavior with blocks where only the block title can be selected. That is also beneficial once versioning is expanded to retrieve an old version for a new portfolio.

Future idea

A block type review, i.e. consolidating certain blocks into fewer, is desirable, but not necessary for this feature.