The block interface has a strong presence in Drupal. With the emergence of the Panels module, which allows for far more intelligent block configurations - we see the need to change this interface. In usability testing done on the blocks interface we saw a number of clear usability issues. This task sets out to explore alternative interfaces for blocks, this should go beyond redesigning the individual page but rather more crazy ideas for example allowing them to be dragged into place.

Remind this is design only, no need to execute or prototype the ideas - as long as you clearly explain what your ideas are.

Challenges
- Keep the interaction usable with 30/40 blocks (many of them inactive).
- Allow for easy browsing of inactive blocks.
- Keep the user closer to the context (rather than only IN administration).

Deliverable
The deliverables are sketches/wireframes/mockups with written annotations explaining your ideas (these can be quite high-level). We envision you would get to about 3 fully explored ideas, but we welcome as many explorations as you can.

Resources
http://www.jeffnoyes.com/content/drupal-7-usability-improvements-part-ii...
http://www.squarespace.com/
http://wordpress.org/
Plone: Deco project

Primary contact
Bojhan

CommentFileSizeAuthor
#11 Idea #1.png12.33 KBLoganb
#11 Idea #2.png25.95 KBLoganb
#11 Idea #3.png15.16 KBLoganb
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

vosechu’s picture

Status: Active » Postponed (maintainer needs more info)

The description is close but I'm left feeling like a newbie would need a lot of guidance here to figure out just why we even care about the blocks interface since to them it probably feels like it works just fine.

I also think that the deliverable should include some references to UX documents/articles about where they got their ideas. I'm concerned that without research they aren't going to come up with anything even remotely new and interesting, certainly not something that is going to cause the stir required to get a new module rocking. Basically, with the information above I don't think any student is going to come up with Context (I specifically chose that because you hadn't mentioned it above but it is a radically different way of doing blocks).

That said, if you're willing to guide them through it and you're really passionate about this I think it's something that we really need and there's nothing like fresh blood to bring a new perspective.

Marking as postponed to find out whether you're wanting to hand-hold or document more but the format looks rtbc'able to me and the idea is great. Just respond with your thoughts and I'll rtbc so we can get on to generating more great ideas!

DrupalIssue-954412

Bojhan’s picture

I will add additional information later (really late here). But essentially I am willing to hand-hold, which is quite common for any UX task really. I agree we need to be more clear on the troubles users have here, which is mostly when its actually being used heavily.

I purposely avoided things like Context or Panels, which are largely development orientated solutions to developer problems, although they touch base on a lot of problems users face as well - they are in essence different. This approach should be design-led and require the student to really only think of ideas, not architectural parts. Although context comes close to an exploration, I think its orientation as described above is diffrent.

Design explorations may need inspirational referrals, but not actually research. As it should be mostly be about being creative and finding your own solutions (don't underestimate the imagination of a student, or anyone for that matter, a highly underused skillset).

vosechu’s picture

Status: Postponed (maintainer needs more info) » Reviewed & tested by the community

Awesome, I'm excited to see how this comes out. Let us know if you want any help!

cwgordon7’s picture

Issue tags: +gci-research

This looks great, thanks!

carlos8f’s picture

Brilliant. We totally need a new block interface that won't send Drupal newbies screaming for their lives! The usability test results are dramatically poor for the block module.

cwgordon7’s picture

Hi Bojhan,

Can you please estimate the time, in hours, that it would take a student to complete this task once it is claimed? This estimate is required to input the task into the google system. Thanks!

Bojhan’s picture

I would say 5 hours.

dawehner’s picture

Status: Reviewed & tested by the community » Fixed
dawehner’s picture

Status: Fixed » Active

.

webchick’s picture

Project: Google Code-in » Drupal core
Version: » 8.x-dev
Component: User Interface » block.module
Loganb’s picture

FileSize
15.16 KB
25.95 KB
12.33 KB

I am fairly new to building interfaces so I am certain that you will have some things that you will like me to edit. I have included a description of each on the design. I am ready to hear your feedback and am willing to fix or edit anything that you think needs to be.
Thanks
Logan Brown

Bojhan’s picture

For some reason your pictures dont work do you mind uploading them without spaces or hashes?

webchick’s picture

Fixing the links (I hope):

http://drupal.org/files/issues/Idea%20%231.png
http://drupal.org/files/issues/Idea%20%232.png
http://drupal.org/files/issues/Idea%20%233.png

I'll go look for that bug later and see if it can be turned into a GCI task. ;)

Loganb’s picture

Yep, those are the designs. Thank you.

Bojhan’s picture

Hey,

Good job on these explorations! I think 2 or 3 would need some more clarifications as I am not sure a. How you get to these pages, b. How do these interactions handle 30/40 modules. c. Does it require some mode? For example, do I go into "block" editing mode.

In general I recommend placing comments along side the screen and just putting a number in the actual mockup. That way you can focus the mockups on the idea you want to propose, and the side for lengthy comments. For example ( http://www.flickr.com/photos/28899893@N05/4220657138/ )

For actual wireframing what you are using now is fine, if you want something more see Axure .

Loganb’s picture

Would you like me to redo the designs? I will be more than happy to. Yes, it would require that you go into block editing mode. I think that having a list of smaller options with the same content will allow you to have 30/40 modules but allow the user to click on one and it be larger.

Bojhan’s picture

@LoganB Yes, I would like you to. Don't be afraid to create a few more pictures to explain your idea, one per idea is pretty sparse if you want to explain the whole interaction.

valthebald’s picture

Version: 8.x-dev » 9.x-dev

Bumping

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kthull’s picture

(Sorry if this somehow double posts. Maybe I wasn't logged in when I typed my previous comment.)

I would rather see the Place block UI mirror the Add field UI currently in views. Creating multiple UIs for similar tasks seems like a bad overall experience.

So when I click on Place block, I'd like a popup that lets me search by name, and also filter by category, that allows me to check multiple blocks to place. After all selections are made, then I'm taken through the config for each block.

This is a solid UI from views, which I think makes total sense for blocks.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.