Any plans that the Block Slider works as a normal block within the Block Editor?

  • Resolved abitofmind

    (@abitofmind)


    1 year, 4 months ago

    Do you have plans that one can edit a page/post with the Block Editor and insert a “Block Slider” block normally within the page flow, and there have the same controls as in your own “limited scope” Block Editor variant? Or did you attempt this but decided against it due to UX/API limitations?

    Currently one used a “limited scope” Block Editor instance for Block Sliders. One goes WordPress (Backend) → Block Slider → Add new (slider instance). This uses a UI which is an instance of the Block Editor, but limited to the scope of the slider. And then later inserts a “Block Slider” block into a page/post and then searching for the respective slider ID or name. I only assume this in theory, because in practice it currently ain’t working:

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Munir Kamal

    (@munirkamal)

    Hey,

    Do you have plans?that one can edit a page/post with the Block Editor and insert a “Block Slider” block normally within the page flow, and there have the same controls as in your own “limited scope” Block Editor variant?

    As of now, there are no plans to implement that feature. In the initial version, we had it built this way, and then we attempted to modify it accordingly. This approach is a standard method used in many popular slider plugins because it offers several advantages. It provides ease of management and a clean canvas to design the desired slider according to your preferences. Additionally, this approach allows you to use the slider in other page builders or anywhere using the shortcode.

    I hope the provided information answers your question. That said, we are open to hearing more about why this feature would be essential or beneficial for the majority of our users. Your feedback is invaluable to us as it helps us improve the plugin and make it even better.

    Cheers,
    Munir

    Thread Starter abitofmind

    (@abitofmind)

    Thanks for laying out your design rationales.

    As you wrote that feedback helps you, here is my feedback in my capacity as a senior UX designer (10+ years experience):

    S) S-tandalone UI for Slider Editing

    1. ? Less WYSIWYG as there’s no combined viewing/experience with neighboring elements/backgrounds/etc — as it would be in the integrated variant, see I1.
    2. ? Better possible to test out interactive functions or advanced editing interactions isolated without any unintended/negative side effects in the Block Editor environment.
    3. ? Finding all sliders in one place — Is not really in argument. If the block UI and also its inspector is cleverly made, searching and browsing should be possible entirely within the Block Editor. No standalone backend UI necessary for this IMHO.

    I) I-ntegrated Slider Editing (in Block Editor UI)

    1. ? ? WYSIWYG: No back and forth, change here, reload there. All in one. Test responsive behavior immediately. See layout flow with neighboring elements.
    2. ?? Also the more limited user interaction simulation issues when working integrated within the Block Editor can be bypassed. There are other plugins (look i.e. at Greenshift) which have auxillary buttons in the Inspector pane like “Run animation” or “Start/Stop transition” or “Start/stop hover effects”.
    3. ?? For selecting slides and media management in a Standalone UI you ofc have more flexibility. But if done smartly that should also be possible in the integrated solution. Just thing creatively what can be done in the Tree Pane + Inspector Panel + floating action bar. It should be do-able.
    4. ?? Pace of development:, Gutenberg’s bugs or lack of feature may sometimes hinder achieving your desired features. That probably is a good reason doing it standalone. But still reason I1 — as WYSIWYG as possible — and reasons I2-I3 clever controls, in total sound convincing to me. But if I4 is a show stopper, then that’s a very valid reason to go the standalone approach.
    • This reply was modified 1 year, 3 months ago by abitofmind.
    • This reply was modified 1 year, 3 months ago by abitofmind.
    • This reply was modified 1 year, 3 months ago by abitofmind.
    • This reply was modified 1 year, 3 months ago by abitofmind.
    Thread Starter abitofmind

    (@abitofmind)

    Ad S3: Even the whole slider CRUD administration (create, read, update, delete) could potentially be done solely or at least redundantly in the Inspector:

    Create anyhow happens on canvas. At start of its lifecycle just has its generic name. Then you can rename it to a meaningful name in the tree pane (Gutenberg will make this soon possible!) or in the Inspector in a “Name” field.

    Read will be handled well by your announced upcoming combined browsing/searching in the blank block UI.

    Update happens anyhow visually on canvas.

    Delete could be quite straightforward too. When deleting on canvas you get a dialog:

    What do you want to delete?

CANCEL    This instance here   Original & all instances

  ^         ^                   ^
Primary   Normal button style  Danger style (RED)
Button
    • This reply was modified 1 year, 3 months ago by abitofmind.
Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Any plans that the Block Slider works as a normal block within the Block Editor?’ is closed to new replies.