Changes to the find content screen

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Noyz's picture

Like it or not, people make instant decisions. Unfortunately, the instant decision Drupal users are making is 'this looks hard.' As such, the remaining experiences people are having, are under the premises that they are in a hard tool. It's urgent that we change this.

To mitigate this, I want to propose a scenario which is partially based on observation of countless usability studies being performed on Drupal Gardens - which in essence is Drupal.

Users come into Drupal, they see and/or interact with:

  1. the first page
  2. the toolbar; and start experimenting. They interact first with words that have a definite meaning and they can relate to, which happens to be A) content B) appearance
  3. Content / Adding content
  4. Managing (finding) created content
  5. Drupal at large by pogo-sticking in and out of various toolbar options - generally just trying to find meaning and/or reinforce their ideas of what they think Drupal is.

Of these:

  • #1 is a larger conversation best served for it's own thread
  • #2 is covered in this blog post: https://www.acquia.com/blog/journey-build-better-drupal-toolbar Looking back on this post, I don't think we did a good job at documenting why we redesigned the toolbar, so I'll quickly do so here. The reasons were:
    1. People were intimidated by all of the options (dashboard, content, structure, people, configure, reports, etc).
    2. People can't get around their site fast enough to decide if the tool is working for them. That is, outside of shortcuts, adding content follows this path Content > Add Content > Choose content type > Add. 3 preceding pages just to add content.
    3. Choices lacked help, that is, they'd have to click structure to see the options in order to fully understand what "structure' meant.
    4. Booth newbies and developers are confused by Content vs Structure. That is, is a page structure, or content? Taxonomy? Block? New modules regularly either failed, or had to ask prior where to place their modules link.
  • #3 is going in a good direction here, so I also won't cover it
  • #5 can largely be solved by making each area a user drops into more succinct, by simply changing action links to Drop Buttons, which is proposed here: http://drupal.org/node/1480854

Leaving items # 4 to be discussed here.

The problem:

The solution:


AttachmentSize
Original-content-page.jpg325.2 KB
Edited-content-page.jpg229.2 KB
Operations-exposed.jpg236.1 KB
narrow-results-exposed.jpg227.79 KB

Comments

good stuff

Gábor Hojtsy's picture

I think this looks good. Especially that we want to rework the filter stuff and expose more search options. Lots of discussion about that at http://drupal.org/node/355820 and http://drupal.org/node/497804

Big improvement! One missing

moshe weitzman's picture

Big improvement! One missing bit from this page today is a Search form. If you could work that into the design (when search module is enabled), that would be awesome.

All this makes sense. To make

kika's picture

All this makes sense. To make it happen it needs to be broken into chewable parts, separate issues in d.o:

"update options ux (tbd) --

Noyz's picture

"update options ux (tbd) -- I'd also consider improving the wording of the header and the submit button "

In a perfect world, I think these belong below the content. That is, its not normal to work bottom to top. Gmail solves this by doing both. However, I was trying to keep the changes bite sized.

"One missing bit from this

Noyz's picture

"One missing bit from this page today is a Search form"

Good point. So real time search off of title and body? Possible? Basically picking up on the UI/Search behavior for adding a field in views. To save on performance a bit, we could delay the search after a key stroke by a second or so.

I think real time would be a

moshe weitzman's picture

I think real time would be a great UX and would be doable technically. It would delay as you describe, like our autocompletes do now ... Would you expect the search to honor any restrictions in effect like content type? Thats doable too.

I stumbled upon the module

Noyz's picture

I stumbled upon the module Fast Admin Premissions (something like that) the other day, which does AJAX searching on permissions. I wonder if we can just extend that code for content?

I really like the above.

edward_or's picture

I really like the above. Looks great!

filter is exposed only after the user choses to narrow results

I like the idea of hiding until useful but won't the 80% case here be that people are coming to this page to find something and are going to filter in some way? Without filter you get access to recently created content but not much else (unless you have very little content).

Are there any statistics for the use of this page from Drupal Gardens? How ofter filtering is used on this page?

Also it will be good to have

preetinder's picture

Also it will be good to have Taxonomy / Category dropdown as autocomplete field as on sites with few hundred categories in different vocabularies will slow down the page considerably on first loading and on each filter operation.

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: